Yammer Security Policy

Yammer
Information Security Policy

1. Executive Summary
1.1 Abstract
The Yammer Security Policy establishes the policy foundation for Yammers information
security activities and provides clear guidance for staff and contingent staff in order to
protect the confidentiality, integrity, and availability of customer data.
1.2 Scope
This document applies to any person, group, or entity that meets the following conditions:
The person is an employee, contractor, partner/partners business contact, or other
party that has access to Yammer systems or data
The person requires access to data owned by Yammer or customer data stored
within Yammer systems that is not released to the general public and is/would be
classified as non-public data.
1.3 Roles and Responsibilities

Role
General Manager, Engineering
Director of Security
Security Engineer
Director of Infrastructure
Responsibility
The Microsoft executive responsible for
directing engineering efforts for Yammer. The
General Manager is a high-level escalation
point for all engineering issues, including
security.
Engineering executive responsible for directing
the security program and protecting the
confidentiality, integrity, and availability of the
Yammer application and customer data. The
Director of Security is the escalation point for
all security issues.
Security representative tasked with
implementing policies and controls to protect
the Yammer application and customer data.
An engineering executive responsible for the
provisioning, upkeep, and resiliency of
Yammers core production infrastructure and
services.
Yammer MBI, Do Not Distribute
Yammer
Cross Functional Security Team (CST)
Data Owner
Data Custodian
A team composed of senior representatives

from Yammer Engineering, Customer Support,
and Legal that collaborates in order to
implement Yammers Information Security
Management System
For any given data asset, the person or group
of people whose job function is most closely
aligned with the datas purpose and is held
accountable for handling and care of the data
The person or group who grants administrative
or operational access to a given data asset
2 Information Security
Policy Objective: To provide documented management direction and support for the consistent
implementation of information security and privacy for Yammer. To assess risks to Yammer,
develop mitigating strategies, and monitor existing policies and effectiveness of safeguards.
2.1 Yammer Security Policy

The Yammer Security Policy, hereafter referred to as the Policy, exists in order to provide
Yammer Staff and Contingent Staff with a current set of clear and concise Information Security
and Privacy Policies. These policies provide direction for the appropriate protection of Yammer
and customer Personal Identifiable Information (PII). Information security in this policy refers
to both the security of Yammer assets and customer PII.
The Policy has been reviewed, approved, and is endorsed by Yammer management.
The Policy applies to all Yammer Staff and Contingent Staff that support the Yammer
Application. This policy also applies to individuals who may not be employed by Yammer but will
be allowed to access, manage, or process information assets of Yammer, or to introduce new
applications or services into Yammer facilities.
The Policy contains rules and requirements that must be met in the delivery and operation of
Yammer. More detailed Requirements and team-specific Standard Operating Procedures
(SOPs) must be developed as adjuncts to this Policy to provide implementation level details for
carrying out specific operational tasks. The Requirements and SOPs must be the instruments by
which this Policy is converted into appropriate mitigating controls, processes and procedures
that govern the actions and activities of Yammer Staff and Contingent Staff.
The Policy must be located in a central repository that is accessible to all Yammer Staff.
Yammer
The Policy must be made available to all new and existing Yammer Staff for review. All Yammer
Staff are required to represent that they have reviewed, and agree to adhere to, all policies
within the Yammer Security Policy documents.
All Yammer Contingent Staff must agree to adhere to the relevant policies within the Policy in
accordance with the process in Section 7.1.
Effective Date
This policy takes effect for all Services upon its approval by management. All Services must be in
compliance with the policy guidelines herein no later than the release date of the next major
service version, unless earlier compliance is specified by the Yammer Security team.
For the purpose of auditing, the compliance date for this version is July 31, 2013.
This document supersedes all previously approved versions upon its approval, regardless of the
service version currently in use for a particular customer offering. If the contents of this policy
conflicts with any other Microsoft policy, the stricter of the two policies will be enforced.
Exceptions to the Policy must be authorized by both Yammer Security management and the
affected asset owner.
2.2 Guiding Principles

The broad goal of information security in Yammer is to maintain the Confidentiality, Integrity,
and Availability (CIA)1 of data while ensuring compliance with legislative, regulatory, and
contractual requirements. To achieve this goal, Yammer has identified a set of core security
principles to guide the creation of a policy. The Policy is derived in principal from the ISO27002
framework; however the Policy also reflects appropriate industry best practices. The Policy will,
in turn, be further supported by formal, detailed Requirements, a standard, formal code
development process (Security Development Lifecycle (SDL)) and, in some cases, team-specific
Standard Operating Procedures (SOPs). From these simple principles, Yammer builds and
maintains the foundations of a strong security posture.
CIA or Confidentiality, Integrity, and Availability is a commonly accepted security

concept credited to the Carnegie Mellon CERT/CC Coordination Center.
1
Yammer
CIA
Principles
Policy
Requirements
SOPs
Universal Participation Every component of an organization could be a potential

avenue of entry for unauthorized intruders. Thus a strong security infrastructure
requires the cooperation of all parties in the organization. Everyone is responsible for
security.
Risk-Based security An organizations security is defined by the unique risks it faces.
These risks should be identified regularly and should remain the primary focus of any
security policy or program.
Deny All That is Not Explicitly Permitted Anything not explicitly allowed is denied.
Least-Privilege Users and systems should only have minimum level of access necessary
to perform their defined function. All unnecessary levels of access should be restricted
unless explicitly needed.
Defense-in-Depth Overall security should not be reliant upon a single defense
mechanism. If an outer security perimeter is penetrated, underlying layers should be
available to resist the attack.
Compartmentalization If one compartment is compromised, it should be equally
difficult for an intruder to obtain access to each subsequent compartment.
Secure Failure When a systems confidentiality, integrity, or availability is
compromised, the system should fail to a secure state.
Defense through Simplicity A simple system is more easily secured than a complex
system, as there is a reduced chance for error.
Dedicated Function Systems should be single-purposed to avoid potential conflicts or
redundancies that could result in security exposures.
Need-to-Know Information will only be circulated to those parties that require it in
order to perform their defined business function.
Effective Authentication and Authorization Firmly established identity and role-based
authorization are essential to making informed access control decisions.
Yammer
Audit Mechanisms Design and implement audit mechanisms to detect unauthorized

use and to support incident investigations.2
2.3 Policy Review and Evaluation

The Yammer Security Policy is to undergo a formal review and update process at a regularly
scheduled interval not to exceed 1 year. In the event of a significant security event, the Policy
may be reviewed and updated outside of the regular schedule. The security policy document
owner (Yammer Security Group), in conjunction with select Yammer stakeholders, will conduct
the review process. This group of individuals must develop and review any changes found to be
necessary within the Yammer Security Policy document.
2.4 Organizational Risk Assessment

Periodic risk assessments must be performed for Yammer in order to review the effectiveness of
existing information security controls and safeguards, as well as to identify new risks. These
assessments must ensure that all policies and supporting procedures properly address the
environment in light of changing regulatory, contractual, business, technical, and operational
requirements. Risk assessments must take place at least once every 12 months, or more
frequently as circumstances necessitate.
2.5 Mitigation Strategy

All risk assessment findings must be referenced against past assessment results in order to
determine:
Which existing controls and safeguards may have become ineffective or outdated
Which new controls and safeguards are necessary as a result of changes to Yammer
All risks which have been determined to be insufficiently controlled must be prioritized and
addressed via enhanced or new mitigating controls and safeguards. New risks must also be
tracked via the Plan of Action and Milestone (POA&M) process.
2.6 Monitoring Effectiveness of Safeguards

All Yammer system controls and safeguards implemented through the risk mitigation strategy
must first be tested to verify that they address the identified risks and do not introduce
additional unintended risks into the environment. Once the controls and safeguards have been
fully implemented in the production environment, they must be monitored for their
effectiveness in mitigating the risk they were designed to address. This continuous monitoring is
a shared responsibility among O365 GRC, O365 Security Operations, and individual workload
compliance champs.
This is adapted literally from NIST Special Publication 800-27 Engineering Principles for
Information Technology Security (A Baseline for Achieving Security), page 14, Principle 20.
The intent of this passage is to combine with the previous Principle to highlight the
importance of the three As: authentication, authorization, and audit.
2
Yammer
3 Organizational Security
Policy Objective: The management of information security within the organization.
3.1 Information Security Accountability

All Yammer Staff and Contingent Staff are accountable for understanding and adhering to the
guidance contained in this Policy and any applicable documents supporting this Policy, including
but not limited to Yammer Data Classification Policy and Procedure, Microsoft Security
Standards, Microsoft SQL Standards, the Key Management Standards and relevant Standard
Operating Procedures (SOPs). Any individuals not employed by Yammer but allowed to access,
manage, or process information assets of Yammer, or to introduce new applications or services
into Yammer facilities are also accountable for understanding and adhering to the guidance
contained in this Policy and any of the applicable documents mentioned above.
The Yammer Security Team is responsible for defining security policy and standards, reporting
on compliance, and responding to security incidents. The Yammer Security Team is also
accountable for monitoring the effectiveness of security controls and safeguards mandated by
Yammer Security Policy or associated requirements. It is the responsibility of the teams that
design, operate, implement or utilize such controls to ensure that they are utilized appropriately
and that they remain effective.
3.2 Information Security Coordination

A management process with the goal of security coordination must be established and adhered
to. This process is established in order to coordinate Yammer information security objectives
and controls with those of other security organizations as well as corporate functions such as
Legal and Corporate Affairs, Sales and Marketing, TWC Corporate Privacy, Information
Technology, Human Resources, Facilities, and Internal Audit within Microsoft.
In particular, Yammer must use Legal and Corporate Affairs approved messaging guidelines in
developing sales and marketing materials when describing the security controls and practices of
Yammer. This language must accurately represent the Yammer Risk Management Program.
3.3 Allocation of Information Security Responsibilities

Each physical location from which Yammer is operated must have a local on-site individual
responsible for local security management, or third-party security staff that is covered by a
contract with security provisions.
Yammer must also appoint an individual responsible for liaising with the Yammer Security group
and Privacy group to coordinate the secure delivery of that service.
Yammer
3.4 Authorization Process for Information Systems

All Yammer applications must be subject to a security controls and privacy review process
before being implemented in a production environment ( Spec Review). This process
determines that the service meets security policies and requirements and has sufficient
safeguards in place to control potential risks. During Spec Review, security, legal, and privacy
personnel will determine if more specific intervention is required.
3.5 Specialist Information Security Advice

Internal or external information security and privacy specialists will be available and will be
consulted as needed to provide expert information security advice to Yammer. Yammer should
seek the advice and guidance of an information security or privacy specialist for initiatives that
may impact security or privacy while they are in early formative stages. Advice from internal or
external information security specialists should also be sought following a serious security
incident or breach.
3.6 Cooperation Between Organizations

Yammer must maintain appropriate contacts with external parties such as law enforcement
authorities, regulatory bodies, service providers, securi ty groups, and industry forums to ensure
appropriate action can be quickly taken and advice obtained when necessary. Roles and
responsibilities for managing and maintaining these relationships must be defined and allocated
pursuant to Section 2.3 - Allocation of Information Security Responsibilities of this Yammer
Security Policy.
3.7 Independent Review of Information Security

Yammer must engage an independent party to conduct periodic assessment and security control
review of the Yammer in order to determine that organizational practices properly reflect this
Yammer Security Policy and are operating with sufficient effectiveness. This assessment and
review must also assist in determining if the organization faces any new vulnerabilities or
threats. At a minimum, this assessment and review must occur annually.
3.8 Third Party Security Considerations

Access to physical and logical assets by third parties* to Yammer facilities, systems, and/or
assets of Yammer must be controlled, per sec. 9.1 in the security policy. All third party requests
for access must be justified by business requirements, assessed for potential risks and necessary
control requirements, and directed to appropriate Yammer management for review and
approval. Physical access to LBI/MBI physical assets by 3 rd parties will default to assignment for
approval by Data Center Management. In the case of physical assets classified as containing HBI
and PII, the asset owner may provide documented, reviewable delegation of authorization for
the HBI and PII physical assets to Data Center Management.
Where a third party is allowed to (i) access, process, host or manage Yammer information assets
or information processing facilities, or (ii) add products or services to Yammer information
processing facilities, arrangements must be made in a formal contract to define responsibility
Yammer
and requirements for the security, confidentiality, integrity and availability of the information
assets involved. Appropriate security standards should be addressed in the agreement, to
provide a level of protection against identified risks equivalent to that provided by the Yammer
Security Policy. Pre-existing third party contracts should be amended to include appropriate
language upon renewal.
*Third Party: Non-FTE vendors and consultants who work on or provide products or services to Yammer or in Yammer/Microsoft
Data Centers.
Access to Yammer/Microsoft Assets must be controlled on the basis of justifiable business needs and class of 3 rd party (ref. 2.8, 9.1). Third parties
can include: 1) Information Security vendors, including vendors and consultants providing 24 X 7 services in critical environ ments; 2) vendors
providing services on a frequent, but not continuous basis, such as circuit technicia ns or vendors handling backup storage; 3) Vendors supporting
equipment or applications, such as vendors engaged by product groups to supply, install and troubleshoot hardware; 4) On -demand vendors
such as plumbers, janitors, handymen and electricians requiring access to the data center production or pre-production environment and 5)
Visitors to a Microsoft facility, including potential customers and vendors.
4 Asset Classification and Control

Policy Objective: To maintain appropriate protection of organizational assets.
4.1 Accountability and Inventory of Assets

All major Assets used to support the delivery of Yammer must be accounted for and have a
nominated owner. The Asset Owner is accountable for maintaining a complete inventory of
their major Assets, and providing the appropriate level of protection for each Asset throughout
its existence. The inventory must clearly identify, at a minimum, each Assets owner, current
location, and security classification. The security classification must be based on the Asset
Classification. All information which transits or is stored by Yammer must be classified
according to the Yammer Data Classification Policy and Procedure and assigned an Asset Owner.
All physical assets in GFS datacenters should be listed and tracked in MSAsset.
4.2 Asset Handling Procedures

Procedures for the handling of Assets in all forms must be in accordance with the relevant
Yammer privacy statements, and the Yammer Data Classification Policy and Procedure. These
standards must be met throughout the existence of the Asset, from acquisition, during storage,
during transmission, and through disposal.
5 Personnel Security
Policy Objective: To reduce the risks of human error, theft, fraud or misuse of facilities.
5.1 Including Security in Job Responsibilities

Maintaining adequate security of Yammer is the responsibility of all Yammer Staff. Where
appropriate, formal security roles and responsibilities should be documented, including
Yammer
detailed responsibilities for the protection of specific assets or the execution of specific
security processes or procedures. These security roles and responsibilities should be
formally assigned to an individual or team. An individual with formally assigned security
responsibilities may delegate security tasks to others; however this individual will remain
responsible and must confirm that any delegated tasks have been correctly performed.
Such roles and responsibilities include, but are not limited to:
Establish, document, and distribute security policies and procedures
Clearly identify and define the assets and security processes associated with each
particular system
Identify security events related to each particular system and monitor for their
occurrence
Establish, document, and distribute security incident response and escalation
procedures
Administer user account and authentication management
Monitor and control all access to logical assets (data, code, documentation) and
physical assets (hardware, hardcopy documentation, storage media)
5.2 Personnel Screening

The hiring of Yammer Staff responsible for the delivery and operations of Yammer must follow
Microsoft hiring practices. Where appropriate, a complete background check may be
conducted. In addition, the following screening components should be considered: verification
of identity, character references, academic and professional qualifications verification, credit
check, and a check of public records.
5.3 Confidentiality Agreements

Confidentiality and non-disclosure agreements are put in place to protect secret, sensitive, or
confidential information and assets. All new Yammer Staff are to be required to sign an
agreement at the time of hire as a condition for employment. All Yammer Contingent Staff must
also sign a non-disclosure agreement at the time of engagement and before being given access
to the Yammer Production Network.
5.4 Terms and Conditions of Employment

The Non-disclosure Agreement (NDA) and/or the Employee handbook must include statements
regarding information and asset protection responsibilities. They must also describe the
penalties for the violation of these responsibiliti es. Also communicated must be the fact that
Yammer security responsibilities extend outside of the work site, and beyond the standard
operating hours of their employment and continue for a defined period after employment ends.
It is also the duty of Yammer Staff to be in compliance with regulatory mandates. The on-going
communication of these mandates is the responsibility of Law and Corporate Affairs, Human
Resources, Microsoft GRC, and Yammer Security.
Yammer
10
5.5 Information Security Education and Training

All appropriate Microsoft Staff are to take part in a Yammer-sponsored security-training
program, and to be recipients of periodic security awareness updates. Security education is
an on-going process and must be conducted regularly in order to minimize risks. The
training program should include: the Yammer security program, staff security
responsibilities, and asset ownership and classification. Periodic security awareness
updates must address timely security matters.
All Yammer Contingent Staff will be required to take any training determined to be
appropriate to the services being provided.
5.6 Responding to Security Incidents and Malfunctions

All Yammer security incidents, weaknesses, and malfunctions are to be reported by Yammer
Staff and Yammer Contingent Staff immediately. The reporting and handling of these
events are to follow prescribed procedures pursuant to Section 5.4 Incident
Management Procedures of this Yammer Security Policy. Microsoft LCA will be informed
of any violations by Yammer Contingent Staff.
4.7 Disciplinary Action
Yammer Staff suspected of committing breaches of security and/or violating Yammer Security
Policy equivalent to a Microsoft Code of Conduct violation will be subject to an investigation
process and appropriate disciplinary action up to and including termination. All potential
security breaches involving Yammer Staff or Contingent Staff will be immediately reported to
Microsoft HR, LCA, and the employees manager, and an investigation of the incident will take
place. Contingent Staff suspected of committing breaches of security and/or violation of
Yammer Security Policy will be subject to formal investigation and action appropriate to the
associated contract, which may include termination of such contracts. Once a determination has
been made that Yammer Staff has violated Policy, Human Resources must be informed, and will
then be responsible for coordinating disciplinary response.
6 Operations Management
Policy Objective: To ensure the correct and secure operation of information processing
facilities.
6.1 Documented Operating Procedures

Operating procedures which are identified as required activities by the Yammer Security Policy
document must be formally documented and approved by Yammer management. Operating
procedures for systems providing Yammer should also be formally documented, approved, and
communicated. At a minimum, the Yammer operating procedures must specify actions
addressing the following activities:
Yammer
11
The handling and processing of information assets classified according to the Yammer
Data Classification Policy and Procedure
Error and incident response procedures
System maintenance, backup, and shutdown/reboot procedures
24x7 Yammer support contact information
6.2 Operational Change Control

An operational change control procedure must be in place for Yammer and system changes.
This procedure must include a process for Yammer management review and approval. This
change control procedure must be communicated to all parties (Yammer and third parties) who
perform system maintenance on, or in, any of the Yammer facilities. The operational change
control procedure will consider the following actions:
The identification and documentation of the planned change
Security impact assessment of the change
Change testing in an approved environment
Change communication plan
Change management approval process
Change abort and recovery plan
Documentation updates
6.3 System Update and Patch Management Process

To help prevent the risk of exposure to known security exploits, it is the responsibility of each
Asset Owner to ensure that their systems have applied the latest security related patches
approved by the Yammer Infrastructure group. For systems residing in an approved Yammer
environment, security patches must be applied in accordance with the minimum acceptable
platform version supported by Yammer Infrastructure, unless requested sooner by the Yammer
Security Team. For systems, which are physically connected to both Yammer and non-Yammer
environments, the strictest security patch policy applies.
6.4 Incident Management Procedures

Incident management responsibilities and procedures which cover all Yammer serviees must be
established. Additionally, all third parties which Yammer is dependent upon (e.g. outsourced
data centers) must have acceptable incident management procedures in place. At a minimum,
the incident management procedures may include:
A notification process
Security incident data collection and analysis processes
A security incident documentation template and repository
An internal and external communication plan
Recovery procedures for system failures, data corruption, loss or denial-of-service, and
total service compromise incidents
A process for post-mortem analysis
Sufficiency of preventative measure(s) analysis
Yammer
12
All information gathered during incident and malfunction remediation activities is to be treated
as Microsoft Confidential Information.
The disciplinary process for dealing with Yammer Staff found to be in violation of the security
policies or procedures must follow appropriate Microsoft Human Resource guidelines, or be
subject to the terms and conditions of the third party contract.
6.5 Segregation of Duties

Segregation of duties must be implemented for all sensitive or critical functions in Yammer
environments in order to minimize the potential of fraud, misuse, or incompetence. At a
minimum, segregation of duty controls must include:
The asset owners approval of all changes made to the system, program, or data over
which he/she is accountable.
System and operations staff who performs work on Yammer must not be the same as
those who approve or have direct supervisory responsibility over the cha nge process.
System and operations staff who performs work on Yammer must not be the same as
the person who performs audit activities.
Non-Operational roles such as development and quality assurance staff must not have
access to production systems unless specifically approved for conditional access with the
Homie conditional access tool. In cases where conditional (e.g. related to specific
activities on specific systems), limited-duration access for non-operations staff is
required in the Production environment, the following requirements must be entered
into a Homie request before access is granted:
1) Justification: a valid reason for access must be provided and must specify the
purpose, duration requested, and associated systems to be accessed.
2) Approval: the request must be approved by a member of the Approvers List
(Primarily comprised of managers and security staff)
Independent authorization of all work duties to be performed through Operational
Change Control section.
6.6 Separation of Non-Production and Production Systems

Separate environments must be maintained for the Non-production and for Production
operations of Yammer. Movement or copying of HBI and/or PII data out of any Production
environment or a Non-Production environment is expressly prohibited. Data, including
customer data or logs containing PII, may only be removed from the Production environment for
a specific business purpose, as approved by the Yammer Security Team and LCA. All changes
between environments, and within the Production environment, are to be subject to Section 5.2
Operational Change Control policy.
Access to the production environment must be carefully controlled* to allow access only to
those Yammer Staff and Yammer Contingent Staff members who require access and are
authorized to perform certain duties, as per Section 5.5. (*ref Security Policy for Access Controls)
Yammer
13
6.7 External Facilities Management

Risks that may be introduced by the use of an external facilities environment and provider
should be identified with appropriate mitigating controls and safeguards. Incident response
procedures, disaster recovery plans, and service level agreements must all be reviewed before
any Yammer components may be established in the external facility.
6.8 Capacity Planning

A capacity planning procedure of both processing and storage requirements must be in place in
order to ensure adequate resources are available for Yammer. This capacity planning should
include operating requirements, projected trends, new business requirements, and resistance to
denial-of-service attacks in order to avoid preventable system deficiencies.
All disaster recovery, business continuity, or service continuity failover sites must also be
recipients of any increased main production site resource.
6.9 Baseline Security Configuration Standards

All Yammer applications must have available documentation that identifies the minimum
acceptable configuration standards. These standards may include:
Hardware requirements and configuration guidelines
System configuration guidelines including:
o Information (data) control requirements
o Application system requirements
o Operating systems requirements
o Network configuration requirements
Systems must not be configured to default to a less secure state in the event of a system error,
compromise, or malfunction.
6.10 System Acceptance

Acceptance criteria must be established for new systems, upgrades to existing systems, and
changes to processes in order to ensure that services meet this Yammer Security Policy and any
associated procedures and standards. A formalized procedure documenting system a cceptance
must be integrated with the operational change control procedure. This process will assist in
ensuring adherence to the change control and system acceptance policies in all cases of Yammer
environmental change.
6.11 Information Backup

Some Yammer applications which contain information required for operation is to be subject to
regularly scheduled backup procedures. At a minimum, the backup procedure must include
specifications that:
Information is to be stored on archive media at regularly scheduled intervals.
Information which is transferred to archive media during the backup process must abide
by Section 3.3 Asset Handling Procedures of this Yammer Security Policy.
Yammer
14
A copy of the backup media is to be stored off-site in a secure location.

Critical backup information is to be identified in order to speed recovery processes.
All stored media is to be erased according to the Yammer Data Classification Policy and
Procedure.
A procedure must be put in place which periodically verifies the integrity of the backup
data utilizing test restorations. (This requirement may be incorporated into procedures
associated with Section 6 Business and Service Continuity Management of this Yammer
Security Policy.)
Applications which employ near-real time data replication between redundant sites are
exempt from the requirement to back-up data to physical media.
6.12 Operations Records

Yammer is required to keep maintenance and operations records containing documentation
that reflects all operational activities. Copies of all operational change controls pertinent to
Yammer must also be included in the operations log. The retention period for these records
much be in accordance with the Microsoft Online Service Privacy and Regulatory Requirements.
At a minimum, log entries must exist for:
Operator name
Date and time
Description of system event or operator action
System error (if any)
Backup rotation activity changes (if applicable)
Applicable operational change control
6.13 Fault Logging

Faults that are identified and logged as specified in Operations Records section, must be
communicated to the appropriate Yammer Staff or Yammer Contingent Staff for review and
action.
6.14 Media Management

All Yammer applications must utilize approved media storage and disposal management
services. Paper documents must be destroyed by approved means at the pre-determined endof-life cycle. Other media, such as tapes, drives, and disks, must be cleansed of all data and
destroyed according to the Yammer Data Classification Policy and Procedure. Yammer does not
use physical media for data transport without explicit approval from the Yammer Security Team.
6.15 Asset Exchange

In order to minimize the risks associated with the exchange of Assets between organizations all
such exchanges involving Yammer must be approved by the Asset Owner. The exchanges must
also follow specific transportation and exchange procedures depending on the Assets security
classification per Asset Handling Procedures of this Yammer Security Policy. Asset exchanges
with non-Microsoft parties must be made only in connection with an agreement approved by
LCA.
Yammer
15
7 Business & Service Continuity Management

Policy Objective: Protecting external customers and the internal Microsoft business by
providing a service and functional resiliency and recovery capability to restore subscribed
services and business core competencies in a predetermined timeframe during a significant
outage.
Both programs will be represented in the section by the naming convention of Continuity
from this point forward.
7.1 Continuity Management Process

A process for the development and maintenance of a Continuity Management program must be
in place for the Yammer Production Environment. The process must contain strategy for the
recovery of the Services and its dependent business processes in a pre-determined timeframe.
7.2 Business Impact and Dependency Analysis

A business impact and dependency analysis must be performed prior to the service launch and
reviewed at appropriate releases to ensure content is reflective of the fluid environment in the
Online space. The analysis must include:
Identify the Recovery Time Objective and Recovery Point Objective
Define time critical processes and functions
Assess impact on six focus areas defined in the enterprise BCM methodologies.
Determine dependencies based on the SIPOC model
Identify gaps on current capability and impact versus the defined recovery window and
data points.
7.3 Writing and Implementing Continuity Plans

The Online Services Continuity Program (SCM) must be developed and coordinated with
Microsofts overall Service Continuity planning efforts in scope and in execution. All areas of the
Online Services framework must integrate with other Microsoft Service Continuity plans without
conflict of roles, responsibilities, or actions. The SCM plan documentation must be located in a
central repository that allows for easy review by appropriate Online Services Staff and Yammer
Contingent Staff.
Aspects of the Continuity plan that require the acquiring or provisioning of systems, resources,
and facilities must be completed in a timely manner consistent with business objectives in
preparation for natural or man-made disasters.
7.4 Continuity Planning Framework

The Online Services plan framework may include:
Assignment of key management responsibilities
Yammer
16
Conditions for escalation, notification and declaration

Crisis management plans for mitigation, assessment and immediate response
Identification of documentation for recovery of all critical processes and functions
associated with the impacted service
Estimates for Continuity Solution Implementation:
o Total cost of business disruption
o Total Online Services acceptable downtime
o Total resource requirements for business resumption
o Strategy alternatives and pricing
o Timeframe for solution and implementation
Continuity plans with documented procedures for addressing various scenarios
Change control and information access procedures
Training plans for preparing all appropriate parties to execute the recovery plan
A Continuity validation, maintenance, and revision process
7.5 System Availability and Performance

The Online Services Continuity plan must address provisions for Microsoft, the service, or
internal process availability and minimum acceptable performance standards. In cases of a third
party hosting solution, contractual commitments for service availability and performance should
be negotiated as appropriate.
7.6 Fault Tolerant and Redundant Architecture

Online Services requirements for redundant architectures and fail over devices or facilities must
be included in the Online Services Service Continuity Plan. The BCP must include conditions and
procedures for the activation and use of these redundant and fail over devices or facilities.
7.7 Validation, Maintaining and Re-Assessing Continuity Plan

Validation and maintenance, including the updating of the plan, must be conducted at
scheduled intervals at regular intervals. The plan must be maintained and reflect the current
with the production Online Services environment. Validation must include appropriate Online
Services, staff, procedures, and configurations to ensure the solution is capable of recovering
the Online Services service and continuing key business processes in a timely manner. The
validation process must follow industry best practices and ensure resolution on all issues and
gaps with solution and plan updated accordingly.
8 Compliance
Policy Objective: To assess Yammer compliance with the Yammer Security Policy document.
Yammer
17
8.1 Enforcement of Contractual Requirements

Yammer Staff are responsible for monitoring the performance of third parties with whom they
contract for services. In the event a violation of security standards (as described in Section 2.8) is
suspected, Yammer Staff shall investigate and enforce the terms of their contracts. Incidents
must be escalated as described in Sections 4.6, 4.7 and 5.4.
LCA is the point of contact for third party vendor contract management.
8.2 Safeguarding of Organizational Records

Important Yammer records relating to the Yammer Risk Management Program, independent of
media type, must be retained, stored, protected, and, if appropriate, destroyed according to the
established information handling procedures for the records. These records must be retained in
controlled facilities for protection against loss, destruction, and falsification. In addition,
measures must be put in place to ensure the ability to recover these records into a useable
format for the duration of the records retention period according to the Microsoft Online
Service Privacy and Regulatory Requirements and other retention requirements.
8.3 Prevention of Misuse of Information Systems

All Yammer applications and systems exist for business use only. Yammer Staff and Yammer
Contingent Staff must not use the information systems for any purposes other than those
approved by the asset owner.
8.4 Collection of Forensics Data

In instances where the Yammer Security Team has determined that a compromise or misuse of
Yammer has occurred, all data from affected system(s) must be retained and stored in a manner
to protect the confidentiality, integrity and availability of such data until a thorough assessment
can take place and any legal proceedings, if any, are conducted. All access to forensics data
must be controlled. Documentation of all incident specifics and remediation activities must be
kept.
8.5 Reviews of Security Policy and Technical Compliance

Yammer asset owners must ensure procedures within their area of responsibility are carried out
correctly to achieve compliance with the Yammer Security Policy. As such, asset owners must
regularly review their compliance with the appropriate security policies, standards, and any
other security and privacy standards. Appropriate actions must be taken if any non-compliance
is found as a result of the review. Audits and assessments in this context refer to internal
demonstration of compliance with Yammer Security Policy as opposed to independent third
party audits of Yammer for the purpose of demonstrating regulatory or industry compliance.
Information systems must be regularly checked for compliance with security implementation
standards either manually or with the assistance of automated tools in coordination with the
Yammer Security Team.
Yammer
18
8.6 Response to Audit Findings

All audit findings, investigations, and remediation activities must be documented and retained
until destruction is authorized pursuant to policy and/or authorized by LCA.
All audit findings must be communicated to the appropriate asset owners, the Yammer Security
Group, and appropriate Yammer executive management. Audit findings must be placed on a
defined remediation program in order to track and achieve resolution. Audit findings that are
found to be high risks to the Yammer must be addressed with the highest handling priority.
8.7 Data Protection and Privacy of Personal Information

Protecting user data and privacy is critically important. Yammer asset owners must classify and
handle Personally Identifiable Information (PII) in accordance with the Yammer Data
Classification Policy and Procedure and the Microsoft Online Service Privacy and Regulatory
Requirements. (See Yammer Security Policy Section 3, Asset Classification and Control. Some
sectors such as governmental sales, healthcare, or Finance, may have additional requirements in
some countries. For information on privacy and regulatory requirements for a specific sector,
please contact MS Online Risk Management.
Yammer must appoint an individual responsible for coordinating data protection and privacy. A
service must take into consideration privacy and regulatory compliance requirements, with
appropriate technical and organizational measures to protect PII. PII must not be processed
except for legitimate business purposes. In addition, a service must adhere to the contractual
obligations in the Product Use Rights and regulatory requirements for the handling and
monitoring of PII. Privacy reviews must be completed and signoff by the privacy SME before
implementation, with an approved support organization and an incident response process in
place to escalate privacy incidents.
9 Communications Security
Policy Objective: To protect important information against loss, modification, misuse, or
unauthorized disclosure while in transit across networks and to protect the supporting
Yammer.
9.1
Controls Against Malicious Software
All information systems supporting Yammer must be protected from malicious software through
the use of preventative and detective controls. All software in use must be approved for the
Yammer environment. Users must be made aware of the dangers of downloading files from
unknown or un-trusted sources.
9.2 Network Controls

Network controls are required to be in place in order to mitigate risks to Yammer when data is
transferred across the network.
Yammer
19
9.3 Network Controls - Encryption

Encryption technology must be used to protect the confidentiality and integrity of
communications according to the Yammer Data Classification Policy and Procedure.
9.4 Electronic Commerce Security

Controls must be applied to assist in securing Yammer authentication, authorization, pricing,
order processing, settlement, and fulfillment processes.
9.5 Wireless Security

The use of wireless devices within a Yammer environment is discouraged, but allowed provided
certain restrictions and requirements are met. (See Yammer Network Security Policy for
restrictions and requirements.)
9.6 Security of Electronic Mail

Electronic mail systems must only be used for approved business purposes. All electronic mail
systems should employ adequate safe guards to protect emails in transit and storage.
9.7 Event Logging and Notification

All Yammer applications should be configured to log all exceptions and security-relevant events.
High security events should generate proactive alarms and notifications to Yammer Staff and
appropriate Yammer Contingent Staff. Where feasible, logs must be aggregated in a central
location and correlated for security events which may have impacted multiple systems. All logs
must be stored and retained according to Yammer record retention rules.
9.8 Monitoring System Use

Yammer must implement monitoring technology and/or procedures to prevent unauthorized
access to systems and to ensure timely detection and response to security incidents. Audit logs
must be examined in a timely manner, and all identified anomalies must be investigated for
possible Yammer misuse or compromise. Any log event which indicates a potential violation of
the Yammer Security Policy document must be immediately brought to the attention of the
Service Desk (SOC).
9.8.1 Security Logging, Monitoring, and Reporting Considerations
Yammer system logs contain records of past system events including Yammer Staff and Yammer
Contingent Staff and end-user actions. All Yammer and systems must have logging enabled and,
when needed, have the ability to securely transmit those logs to a central collection point. All
logs must be maintained for a specified period of time according to the logs retention
requirements. Logging of the following activities should be considered:
Account Registration and Modification Events
Login and Logout Events
Account Maintenance
Security Setting Changes
Logging Level Changes
Yammer
20
System Policy Changes
Automated monitoring and reporting tools must be available and used to assess the security
posture of Yammer.
9.8.2 Proactive Vulnerability Scanning and Penetration Testing
Yammer must proactively monitor the information systems servers for possible exposures. This
must include a regularly scheduled scanning of known system vulnerabilities and penetration
testing from outside as well as inside the Yammer environment.
Proactive monitoring must be scheduled pursuant to operational change control procedures,
performed by authorized Yammer Staff or others authorized by Yammer Security and conducted
in such a fashion so as to minimize impact to the production environment.
9.9 Clock Synchronization

In order to both increase the security of Yammer, and to provide accurate reporting detail in
event logging and monitoring processes and records, all Yammer must use consistent clock
setting standards (e.g. PST, GMT, UTC etc.). When possible, Yammer must use synchronization
protocols in order to maintain accurate time throughout the Yammer environments. The clock
synchronization protocol used should be Network Time Protocol (NTP).
9.10 Mobile Computing

Mobile computing devices are not permitted in, or directly attached to, any Yammer production
environment, unless those devices have been approved for use by Yammer Management.
Mobile computing access points must adhere to section 8.4 of this policy.
9.11 Tele-working
Suitable protection must be afforded to remote sites where Yammer Staff or Yammer
Contingent Staff remotely access Yammer systems. Physical as well as logical controls must be
put in place to ensure the security of the remote site is comparable to that at primary work
facilities. Yammer Staff and Yammer Contingent Staff connecting remotely from home must
adhere to corporate remote access policies for gaining access to Microsoft Networks.
10 System Development and Maintenance

Policy Objective: To ensure that security is built into information systems, software, and the
development process.
10.1 Security Requirements Analysis and Specification

A specification review analysis must be completed for all system development projects. This
analysis document will act as a framework and include the identification of possible risks to the
finished development project as well as mitigation strategies which can be implemented and
Yammer
21
tested during the development phases. Critical security review and approval checkpoints must
be included during the system development life cycle for products that have a foreseeable
security impact.
10.2 System Development Security Guidelines

Basic guidelines for secure system development and implementation techniques must be
documented and made available to all Yammer Staff and Yammer Contingent Staff responsible
for system development.
10.3 Security in Application Systems

All Yammer applications including those developed or hosted by and/or purchased from third
parties must undergo a comprehensive security review before entry into the Yammer
Production Network. In addition, no software is to be deployed or utilized in the Services
production environments without formal approval as required by Section 5.2 Operational
Change Control. Any software to be installed on Service assets must be formally documented
and given explicit approval. Service Application software and software developed or utilized by
Service Operations personnel must be transferred into the production environments via
Deploymacy (the Yammer deployment tool) or Maven.
10.3.1 Security in Application Systems - Input Validation
Yammer management must define acceptable standards to ensure that data inputs to
application systems are accurate and within the expected range of values. Where appropriate,
data inputs should be sanitized or otherwise rendered safe before being inputted to an
application system.
10.3.2 Security in Application Systems - Control of Internal Processing
Internal processing controls must be implemented within the Yammer environment in order to
limit the risks of processing errors. Internal processing controls must exist in applications as well
as in the processing environment. Examples of internal processing controls include, but are not
limited to, the use of hash totals, load balancing controls, and job scheduling software.
Security Context, which is the checking of user and network context of each piece of data before
delivery to the user, shall be defined for all applicable pieces of code and shall not be skipped
unless necessary.
10.3.3 Security in Application Systems - Message Authentication
Message authentication must be considered for applications where there is a security standard
to provide for non-repudiation or protect the integrity of the message content. An assessment of
security risk must be carried out to determine if message authentication is required, and to
identify the most appropriate method of implementation. Message Authentication must be
enabled between all systems which process, handle, backup, or otherwise manipulate customer
data assets as defined in the Yammer Data Classification Policy and Procedure.
Yammer
22
10.3.4 Security in Application Systems - Output Data Validation

Data output by application systems must be validated prior to being stored or passed on to
subsequent systems for further processing. Procedures must be developed and implemented to
facilitate the process of reviewing output data and responding to potential errors.
10.4 Cryptographic Controls

Cryptographic controls must be designed and implemented, to protect the confidentiality,
integrity and availability of Yammer information according to the Yammer Da ta Class ification Policy
and Procedure
10.4.1 Cryptographic Controls - Cryptographic Control Policy

All Yammer must implement the minimum acceptable cryptographic standard specified by the
Yammer Data Classification Policy and Procedurewhere cryptography is used. Yammer staff
must be responsible for giving consideration to state, federal, international, and other
controlling regulations and restrictions around the use of cryptographic techniques.
10.4.2 Cryptographic Controls Encryption or other security technology
The Yammer environment must use appropriate security technology as defined by the Yammer
Data Classification Policy and Procedure to protect the confidentiality of assets during
transmission or storage.
10.4.3 Cryptographic Controls - Key Management
Appropriate measures defined in the Key management procedure document must be taken to
protect all keys from modification, destruction and unauthorized disclosure. See Key
Management Procedure.
10.5 Control of Production Software

The control and management of software installed in the production Yammer environment is
the responsibility of Yammer Staff and Yammer Contingent Staff responsible for operations.
10.5.1 Control of Production Software Deployment Process
Software must undergo appropriate testing and staging before being released into the Yammer
production environment to minimize impact to system integrity and availability. Production
software must be deployed according to approved Yammer procedures. The capability to
release software into production should be restricted to a limited number of authorized Yammer
Staff or Yammer Contingent Staff. These Staff members are responsible for ensuring tha t
acceptance criteria are met prior to deployment.
10.5.2 Control of Production Software Software Integrity Checking
The integrity of Yammer production software must be confirmed on a regular basis. A
mechanism such as an automated version control system (Github Enterprise) must be
implemented to help facilitate this process.
Yammer
23
10.6 Protection of System Test Data

Production data is not permitted in the Yammer development, testing, and staging
environments unless it is in accordance with the Yammer Data Classification Policy and
Procedure.
10.7 Access Control to Source Code Library

Access to Yammer source code libraries must be limited to authorized Yammer Staff and
Yammer Contingent Staff. Where feasible, source code libraries should maintain separate
project workspaces for independent projects. Yammer Staff and Yammer Contingent Staff
should be granted access only to those work spaces which they need access to perform their
duties. An audit log that details all access attempts and modifications to the source code library
must be maintained and reviewed on a regular basis to identify unauthorized activities.
10.8 Security in Development and Support Processes

Yammer executive management must ensure that all system development and maintenance
activities are performed in accordance with applicable security policies and procedures.
Yammer executive management is responsible for designing and implementing appropriate
procedures to ensure security is addressed appropriately during the development and support
processes.
10.8.1 Security in Development and Support Processes - Version and Change Control
Procedures
A formal change control procedure must be followed when making changes to any production
Yammer system. This procedure must include a review and approval process. This change
control procedure must be communicated to all Yammer Staff and Yammer Contingent Staff and
third parties who perform system maintenance on, or in, any of the Yammer facilities. At a
minimum, the procedure must include the following actions:
The identification and documentation of the planned change
Assessment of the change impact
Change testing in an appropriate non-production environment
Change communication plan
Change management approval process
Change abort and recovery plan
Where possible, the system version and change control procedure must be integrated with the
operational change control procedure as detailed in Operational Change Control of the Yammer
Security Policy document.
10.8.2 Security in Development and Support Processes - Technical Review of System Changes
Technical reviews of significant Yammer system changes must be performed by appropriately
qualified Yammer Staff or Yammer Contingent Staff.
Yammer
24
10.8.3 Security in Development and Support Processes - Restrictions on Changes to Software

Packages
Modifications to software packages must not be made unless explicitly approved by the Yammer
staff and version and change control procedures have occurred.
10.8.4 Security in Development and Support Processes Pre-Production Design Analysis
A design analysis for possible security risks and mitigating controls must be performed for all
Yammer systems during the system design phase prior to the development and deployment of
the system.
10.8.5 Security in Development and Support Processes - Security Code Review
A formal review process must be implemented to ensure that new or modified source code
authored by Yammer staff is developed in a secure fashion, no malicious code has been
introduced into the system, and that proper coding practices are followed. The reviewers
names, review dates, and review results must be documented and maintained for audit
purposes in a Security Journal.
10.8.6 Security in Development and Support Processes - Security Quality Assurance
A formal security quality assurance process must be implemented to test all Yammer systems
for vulnerability to known security exposures and exploits. The process must include the use of
automated security testing tools.
10.9 Access Control to Definitive Software Libraries

Access to Services Definitive Software Libraries (DSLs, including Maven, Ruby Gems, and internal
apt repositories) must be limited to authorized Staff. Permission to, change, update, or add to
the files in the DSLs must be limited to only the necessary and appropriate Staff.
10.10 Supported Software Versions

Pre-release (alpha, beta, etc.) software must not be installed in any Yammer production data
center environment. Software that has not been commercially released is not allowed earlier
than the release candidate stage without prior approval from Risk Management and Change
Control Process. Use of legacy web servers, database servers, email servers, and other legacy
applications in any [Comments]data center introduces substantial security risk to the
environment.
11 Physical and Environmental Security

Policy Objective: To prevent unauthorized access, damage or interference to physical
production facilities.
11.1 Physical Security Perimeter

Physical security perimeters must be established around all Yammer components. A physical
security perimeter is something that builds a barrier such as a wall, a card controlled entry gate,
Yammer
25
or a manned reception desk. The construction of the barrier should be physically sound and
extend to the real floor and ceiling of a space if necessary.
Additional physical barriers, such as locked cabinets erected internal to facility perimeters,
may also be required for certain assets according to the Yammer Data Classification Policy and
Procedure.
11.2 Physical Entry Controls

Physical entry controls must be placed at all physical access points to Yammer. At Yammer
managed facilities, these entry controls must include the use of electronic access cards. For
third party managed facilities, commensurate physical entry controls must also exist.
Additional entry controls, such as cardkey access to cages or key access to locked cabinets
erected internal to facility perimeters, may also be required for certain assets according to the
Yammer Data Classification Policy and Procedure.
Visitors to Yammer facilities must be properly authorized, visibly identified as visitors, and
supervised at all times. Records of all visitor access must be maintained.
11.3 Identification Badges

All persons must show a valid form of government issued photo ID before being granted access
to Yammer managed facilities and data centers. Visitors photo ID may be held until the
individual leaves the premises. A Microsoft-issued badge or other Microsoft ID must be visible at
all times while on the premises. Visitors will not attempt to weaken, tamper with, or breach
physical security perimeters and entry controls. In facilities managed by third parties the use of
appropriate identification mechanism mandated by the third party is acceptable.
11.4 Surveillance
Subject to existing laws and corporate privacy policies, surveillance measures must be put in
place for monitoring of Yammer facilities and Data Centers. Such measures include security
patrols as well as video surveillance equipment.
11.5 Securing Offices, Rooms, and Facilities

All environments in which Yammer is located, whether pre-production or production, must be
secured against unauthorized access. This includes offices, conference rooms, off-site meeting
locations, labs, data centers, and other facilities used for work related to Yammer. Information
regarding the location and purpose of Yammer facilities should not be disclosed to outside
parties or published in a publicly accessible area. In facilities shared with other organizations or
purposes, adequate separation and control must exist between Yammer areas and non-Yammer
areas.
Yammer
26
11.6 Working in Secure Areas

Additional controls and guidelines need to exist for working in controlled areas which contain
sensitive assets as defined by the Yammer Data Classification Policy and Procedure..
Unsupervised work in controlled areas must be avoided to limit opportunities for malicious
activities. Photographic, video, audio or other recording equipment must not be brought in to
controlled areas without Yammer management authorization.
11.7 Isolated Delivery and Loading Areas

All Yammer delivery and loading areas which are adjacent to, or near Yammer facilities, must be
controlled. Delivery and loading areas must be separated and isolated from areas housing
Yammer. All pickups and deliveries to these delivery and loading areas must be logged.
If isolation is not possible in a facility, then deliveries should be tracked and moved into the
controlled areas as soon as possible.
11.8 Equipment Siting and Protection

All Yammer equipment must be placed in environments which have been engineered to be
protective from environmental risks such as theft, fire, explosives, smoke, water, dust, vibration,
earthquake, harmful chemicals, electrical interference, and radiation. All portable Yammer
assets must be locked or fastened in place in order to provide protection against theft or
movement damage.
11.9 Power Supplies

All Yammer components must be protected from power outages, electrical disturbances
(spikes), or other unanticipated power occurrences. The Yammer production environment must
consider the use of options to achieve continuity of power supplies including multiple power
feeds, uninterruptible power supplies, backup generators, and specially negotiated contingent
power resources.
Emergency power shut-off switches should be accessible by Yammer Staff and Yammer
Contingent Staff in case of an emergency.
11.10 Cabling Security

All power and information system cables within any Yammer environment must be labeled
appropriately and protected against interception or damage. When Yammer-owned power and
information system cables must traverse an area outside of Yammer control, use of armored
conduit must be considered. Power and information system cables must be separated from
each other at all points within an environment to avoid interference.
11.11 Equipment Maintenance

All Yammer equipment and systems must be regularly maintained in order to guarantee
operational efficiency. Maintenance of any equipment or system must be performed in
Yammer
27
accordance with manufacturers recommendations, carried out by authorized personnel, and

recorded in a maintenance ticket.
11.12 Security of Equipment Off-Premises

The use and/or storage of Microsoft managed information processing equipment and/or media
containing HBI or MBI data (as defined by Yammer Data Classification Policy and Procedure)
outside a Yammer managed facility must be approved by the asset owner(s).
Protection afforded to equipment and/or media located outside a Yammer managed facility
must be commensurate with protection afforded to equipment and media located in a Yammer
managed facility. For third party hosting arrangements, the third party must comply with
Partner/Vendor Risk Management Security Requirements.
Where third party access to or handling of equipment and/or media containing HBI or MBI data
is required, third party security obligations should be reflected in a contract.
11.13 Secure Disposal or Reuse of Equipment

Yammer information assets designated for disposal must be destroyed. The appropriate means
of disposal will be determined by the asset type according to the Yammer Data Classification
Policy and Procedure. Records of the destruction must be kept and stored. Re-use of
equipment is allowed only after proper media erasure procedures have been completed
according to procedures as outlined in the Yammer Data Classification Policy and Procedure.
11.14 Clear Desk and Clear Screen

All work surfaces and Yammer system monitors must be clear of information when not in use.
Any Yammer information stored on physical media must be stowed out of sight when not being
used. Additionally, any physical media must be stored according to the Yammer Data
Classification Policy and Procedure when not in use.
Yammer
28
12 Document Control
12.1 About this Document
Author
Effective Date
Email
Matthew Sutkus
August 1, 2013
msutkus@yammer-inc.com
12.2 Revisions
Revision
0.1
0.2
0.3
Date
11/14/13
11/29/2013
Author
Matthew Sutkus
Matthew Sutkus
Matthew Sutkus
0.4
12/2/2013
Matthew Sutkus
8/6/13
Comments
Initial Draft
Correct some typos
Remove some bad
links
Add LCA as third
party vendor
management
12.3
12.4 Approvals
Name
Josha Bronson
Role
Version
Director of Security 0.4
Adam Pisoni
Yammer General
Manager
0.4
Approval
Yammer Approval 1
12/3/13
Yammer Approval 1
12/3/13
12.5 Glossary
Access Control The implementation of rules and security mechanisms with the purpose of
limiting or preventing unauthorized use of information, resources, and facilities. Reference:
ISO/IEC 27002:2005
Account - A set of credentials that corresponds to exactly one person used for access to systems
or applications.
Adjustment The process of revising the Yammer Risk Management Program and supporting
policies and procedures based upon the results from an evaluation process.
Yammer
29
Administrative Safeguards The formulation of policies and procedures for the management of
Yammer that help ensure the consistent implementation of controls in the Yammer
environment. Reference: Department of Treasury, Interagency Guidelines Establishing Standards
for Safeguarding Customer Information and Rescission of Year 2000 Standards for Safety and
Soundness; Final Rule, 12 CFR Part 30, et al.
Asset Any item used to support the delivery or operation of Yammer, including information,
software, physical, and service assets.3 A major Asset is one considered essential to the
function of Yammer at the discretion of the Asset Owner.
Asset Owner the creator, generator, originator, or primary possessor of an Asset, or agent(s)
to which the Asset Owner has given consent to act as a fiduciary with regard to specific assets,
according to a documented agreement.
Assurance Ground for confidence that an information system meets its security objectives.
Reference: The CISSP Prep Guide, Ronald L. Kurtz and Russell Dean Vines, Wiley Computer
Publishing, 2001.
Attack A malicious act to compromise Yammer.
Audit Synonym for Security Audit.
Authentication The process of determining that a person or information system attempting to
access an asset is really the entity they say they are. Reference: The Information Systems Audit
and Control Association and Foundation (ISACA).
Authorization The act of granting access to an asset on the basis of authenticated
identification. Reference: International Telecommunication Union (ITU) T Security Definitions,
March 2002.
Availability The process of ensuring that authorized users have access to information and
associated assets when required. Reference: ISO/IEC 27002:2005
Service Continuity Management (SCM) Documented processes and procedures for ensuring
that essential business functions can continue to operate during and after an unforeseen
circumstance such as a natural or man-made disaster. Reference: ISO/IEC 27002:2005
CISSP Acronym for Certified Information Systems Security Professional , a current industry
standard certification offered by the ISC2 organization. Reference: www.isc2.org
Classification The act of categorizing assets into defined groups according to the assets
sensitivity.
3
This is per ISO27002 categorization of assets.
Yammer
30
Communications Security Controls and safeguards designed to protect the security,

confidentiality, and integrity of information when in transit. Reference: ISO/IEC 27002:2005
Compliance The act of adhering to internal and external requirements for the Yammer
environment. Reference: ISO/IEC 27002:2005
Confidentiality The process of ensuring that information is accessible only to those authorized
to have access. Reference: ISO/IEC 27002:2005
Consumer Individuals who are the end-users of Yammer.
Control A process and/or technical mechanism utilized to enforce or support Security, Privacy,
or Business and Service Continuity requirements. Examples of controls include a Change Control
process, an AV system, video surveillance at a Data Center, and peer review of code.
Control owner Individual responsible for ensuring a control is operational and effective.
Operational meaning the control is functioning as designed and expected; effective meaning: a)
the control has been applied as appropriate, and b) the control meets the formal requirements
expressed in Policy or Standards.
While control ownership is ultimately assigned to a particular role the responsibilities related to
a control (operational support, incident response, etc) may be distributed between multiple
teams or personnel, based on the function provided by each owner.
For example, an Anti-Virus system would be owned by the AV Service Manager, but could be
supported by multiple teams, all contributing to the overall effectiveness of the system: (1) A
team responsible for operating the system maintenance, updates, incident response (system
disruptions), for ensuring the AV system is meeting security standards and verification that the
control is detecting malware. (2) A team responsible for ensuring that the control is applied to all
relevant systems. (3) A team responsible for responding to events and incidents generated by
the AV system. (4) A team responsible for providing updated requirements. Periodic review of
the control by the designated control owner is required in order to validate operation and
effectiveness. Such review may include metrics related to operation (uptime, reliability, etc.),
metrics related to % of coverage (all servers, all changes, etc), and metrics related to compliance
with Policy or externally-derived requirements.
Controlled Areas Areas with physical and logical access controls in place to prevent
unauthorized access.
Countermeasure Actions, devices, procedures, techniques, or other measures that reduce the
vulnerability of a system. Reference: ITSecurity.com Dictionary
Criteria A standard on which decisions may be based.
Yammer
31
Critical Risk Threats that pose critical impact to the security of the analyzed entity. Yammer
must take action to mitigate immediately.
Cryptography The discipline that embodies principles, means, and methods for the
transformation of data in order to hide its information content, prevent its undetected
modification and/or prevent its unauthorized use. Reference: International Telecommunication
Union (ITU) T Security Definitions, March 2002.
Denial-of-Service The prevention of authorized access to resources or the delaying of timecritical operations. In a shared network, this threat can be recognized as a fabrication of extra
traffic that floods the network, preventing others from using the network by delaying the traffic
of others. Reference: International Telecommunication Union (ITU) T Security Definitions,
March 2002.
Disaster Recovery Plan (DRP) Procedures that define the appropriate actions to be taken in
emergency situations that affect environmental and computing resources.
Domain A set of items that fall under one logical categorization for ease of reference and
management.
Encryption A method used to translate information from plaintext into a secure form that is
near impossible to unscramble and interpret during transmission and storage.
Reference:ITSecurity.com Dictionary
End-User Synonym for Consumer.
Environment The physical and logical surroundings in which Yammer are delivered or
operated.
Evaluation Assessment of the sufficiency of the Yammer Risk Management Program and
supporting policies and procedures in meeting the programs mission and objectives.
Exploit The methodology for enacting an attack against Yammer using exposures.
Exposure Direct or indirect risks to Yammer that could result from the absence of mitigating
controls.
Guideline A recommendation for the implementation of a control or safeguard to meet the
Yammer Security Policy.
High Risk Threats that pose significant impact to the security of the analyzed entity. Yammer
must take action to mitigate, but on a timeline based on business priorities.
Yammer
32
Identity Management A business strategy for the unified control of user online identities,
authentication information, and access profiles across the organization using a combination of
technologies and processes.
Information Acquisition The collection or receipt of data by Yammer.
Information Disposal The permanent destruction of data to prevent recovery.
Information Processing Transactions on data by an information system or an individual.
Information Security The preservation of confidentiality, integrity and availability of
information. Reference: ISO/IEC 27002:2005
Information Sharing The disclosure of data to an outside party not associated with the delivery
or operation of Yammer.
Information Storage The persistence of data in physical or logical format.
Information System A combination of hardware, software, and supporting infrastructure that
receive, process, or transmit data in support of the delivery and operation of Yammer.
Information Transmission The transfer of data across communication networks or across
physical distances. Transmission can originate from or terminate at one of the Yammer.
Infrastructure All personnel, services, information, systems, and assets that operate together
with the purpose of providing Yammer.
Integrity Safeguarding the accuracy and completeness of information and processing methods.
Reference: ISO/IEC 27002:2005
Intrusions Attacks that yield unauthorized access.
ISO 27002 An information technology code of practice, prepared based upon the British
Standards Institution (BS 7799 standard), and adopted by a Joint Technical Committee in parallel
with its approval by the national bodies of International Standards Organization and
International Electrotechnical Commission. Reference: ISO/IEC 27002:2005
Least-Privilege The principle that users and processes should operate with no more privileges
than are absolutely necessary to perform the duties of their current role or function. Reference:
ITSecurity.com Dictionary
Yammer
33
Low Risk Threats that pose minimal impact to the security of the analyzed entity. Yammer may
take action to mitigate based on business priorities.
Medium Risk Threats that pose moderate impact to the security of the analyzed entity.
Yammer must take action to mitigate, but on a timeline based on business priorities.
Microsoft Confidential Information Nonpublic information that Microsoft designates as being
confidential. Microsoft Confidential Information includes, without limitation, information in
tangible or intangible form relating to and/or including released or unreleased Microsoft
software or hardware products, the marketing or promotion of any Microsoft product,
Microsofts business policies and practices, and information Microsoft received from others that
Microsoft is obligated to treat as confidential. Reference: Microsoft Corporation Non-Disclosure
Agreement, Microsoft Law and Corporate Affairs, 04/09/2002
Maturity - A level of review and refinement associated with an organiza tional process
supporting security development.
Mitigating Control Synonym for Control.
Need-to-Know A principle by which information is only provided to those with a legitimate
need for that information. Reference: ITSecurity.com Dictionary
Non-Production Environments utilized for development and testing of online services,
commonly known by names such as: development, sandbox, testing, staging/pre-production,
etc. No claims to safeguard end-user or partner submitted data must be made.
Operations The execution of processes and procedures supporting the delivery of Yammer.
Responsible for performing system administration, engineering and service management
support, including functions such as order management, inventory management, provisioning
and activation of new systems, maintenance of existing systems, network topology management
and maintenance, and stability/performance diagnostics of online services, supporting
infrastructure services and networks, facility management, and client ma nagement. Operations
also drives optimization of the online services and associated environments, including
automation of manual operations of the network, delivery services, and support, making these
areas more efficient, cost-effective and error-free.
Operations Management The oversight of processes and procedures supporting the delivery
and functioning of Yammer. Reference: ISO/IEC 27002:2005
Organizational Security The structure through which individuals and groups cooperate
systematically in the implementation of the Yammer Risk Management program. This structure
includes the allocation of roles and responsibilities to individuals and groups as well as rules
guiding the interactions between these individuals and groups. Reference: ISO/IEC 27002:2005)
Yammer
34
Personally Identifiable Information (PII) - Any information relating to an identified or

identifiable individual or that can be traced back to an individual. Such information may include
name, country, street address, e-mail address, credit card number, Social Security number,
government ID number, IP address, or any unique identifier that is associated with PII in another
system. It may consist of a single piece of information or a collection of pseudonymous
information. It includes IP addresses and UIDs. Also known as personal information or personal
data.
Personnel Security Controls and safeguards designed to mitigate risks of human error, theft,
fraud, or misuse of Yammer introduced by Yammer Staff or Yammer Contingent Staff through
the careful screening of staff members and the institution of staff training and awareness
programs. Reference: ISO/IEC 27002:2005
Physical Safeguards The formulation of policies and procedures regarding the protection of
Yammer facilities and assets contained within that help ensure the consistent implementation of
controls in the Yammer environment. Reference: Department of Treasury, Interagency
Guidelines Establishing Standards for Safeguarding Customer Information and Rescission of Year
2000 Standards for Safety and Soundness; Final Rule, 12 CFR Part 30, et al.
Physical and Environmental Security Controls and safeguards designed to maintain the
confidentiality, integrity, and availability of Yammer facilities and assets contained within.
Reference: ISO/IEC 27002:2005)
Policy Synonym for Security Policy.
Procedure Implementation methodology with detailed instructions on carrying out specific
operational tasks. The procedure is the instrument by which the Yammer Security Policy is
converted into action.
Process The act of implementing a Procedure.
Production - End-user facing environment(s) used for operation and support of the live site,
containing end-user or partner-derived data, servicing user requests, or performing
maintenance tasks against end-user and/or partner data.
Requirement Minimum acceptable configuration specification which would render the system
compliant with the Yammer Security Policy.
Risk - The possibility of suffering loss, modification, misuse, or unauthorized disclosure.
Yammer
35
Risk Assessment The analysis of threats to, impacts on, and vulnerabilities of Yammer assets
and the likelihood of an occurrence of loss, modification, misuse, or unauthorized disclosure.
Reference: ISO/IEC 27002:2005
Risk Management The process of identifying, controlling and minimizing or eliminating risks
that may affect Yammer. Reference: ISO/IEC 27002:2005
Risk Rating A qualitative metric assigned to a risk to reflect the likelihood of an occurrence of
loss, modification, misuse, or unauthorized disclosure and the impact of that occurrence.
Safeguard Synonym for Control.
Security Audit An independent review and examination of system records and activities in
order to test for adequacy of system controls, to ensure compliance with established policy and
operational procedures, to detect breaches in security, and to recommend any indica ted
changes in control, policy and procedures. Reference: International Telecommunication Union
(ITU) T Security Definitions, March 2002.
Security Policy A non-technical collection of rules that defines Yammer approach to
information security. These rules have been agreed upon and endorsed by Yammer executive
management, and are required to be implemented in order to achieve the Yammer Risk
Management Program mission and objectives.
Security Violations Any action or process which breaks the agreed upon policies or procedures
set forth by Yammer executive management.
Standards mandatory prerequisite for all of Yammer. Standards are subordinate to Policy
statements, and are designed to provide more explicit definition of Policy intent. Standards
statements are typically published in a consolidated Standards document (for example, Yammer
Security Standards). Applicability to Yammer shall be clearly declared in the opening Scope
section of a given Standards document. Compliance with a given Standard must be documented
in a team-specific SOP.
Standard Operating Procedure (SOP) A document that describes how to implement a
configuration or execute a process that is considered mandatory for a specific Yammer
workload. SOPs serve as the documented record of a given teams compliance with relevant
Policy and/or Requirement statements. For example, an SOP authored by the Networking team
could describe the team-specific process for configuring network equipment according to the
Network Access Control section of the Yammer Security Policy.
System Synonym for Information System.
Yammer
36
System Development and Maintenance The utilization of a repeatable methodology for the
planning, development, testing, deployment, operation, and modification of an information
system. Reference: ISO/IEC 27002:2005
System Failures Unavailability of whole or significant parts of Yammer due to natural or manmade causes.
Technical Safeguards The formulation of policies and procedures regarding the
implementation of security technologies that help ensure the consistent implementation of
controls in the Yammer environment. Reference: Department of Treasury, Interagency
Guidelines Establishing Standards for Safeguarding Customer Information and Rescission of Year
2000 Standards for Safety and Soundness; Final Rule, 12 CFR Part 30, et al.
Third Party - Non-FTE vendors and consultants who work on or provide products or services to
Yammer or in Microsoft Data Centers. Access to Microsoft Assets must be controlled on the
basis of justifiable business needs and class of 3 rd party (ref. 2.8, 9.1). Third parties can include:
1) Information Security vendors, including vendors and consultants providing 24 X 7 services in
critical environments; 2) Vendors providing services on a frequent, but not continuous basis,
such as circuit technicians or vendors handling backup storage; 3) Vendors supporting
equipment or applications, such as vendors engaged by product groups to supply, install and
troubleshoot hardware; 4) On-demand vendors such as plumbers, janitors, handymen and
electricians requiring access to the data center production or pre-production environment and
5) Visitors to a Microsoft facility, including potential customers and vendors.
User Profile A collection of information about a particular person or information system,
usually stored in a central repository.
User Awareness The ongoing process of receiving up-to-date information and education
concerning policies, procedures, and best practices for the secure delivery and operation of
Yammer.
Yammer Application Enterprise social networking product offered by Microsoft and accessed
or consumed by connecting via the Internet on a computer or mobile device/tablet.
Yammer Service- Any application or Service hosted in a data center managed by Yammer staff
or any application or service supported by Yammer Staff regardless of hosting location.
Yammer Staff Microsoft employees involved in the development, marketing, sales, support or
operation of a Microsoft Online Service.
Yammer Contingent Staff - Any vendors, agents or contractors on assignment to or engaged by
Microsoft who are allowed to access, manage, or process information assets of Yammer, or to
introduce new applications or services into Yammer facilities.
Yammer
37
Yammer Executive Management The executives responsible for particular Yammer and
certain key direct reports to these executives.
12.6 Revisions
Revision
0.1
0.2
Date
7/1/13
11/26/13
Author
Matthew Sutkus
Matthew Sutkus
Comments
Initial Draft
Align more closely
with SOA

Yammer Security Policy

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Yammer Security Policy

Transféré par

Droits d'auteur :

Formats disponibles

Yammer

Information Security Policy

Information Security Policy

1.3 Roles and Responsibilities

Yammer MBI, Do Not Distribute

Cross Functional Security Team (CST)

A team composed of senior representatives

2.1 Yammer Security Policy

Yammer MBI, Do Not Distribute

2.2 Guiding Principles

CIA or Confidentiality, Integrity, and Availability is a commonly accepted security

Yammer MBI, Do Not Distribute

Universal Participation Every component of an organization could be a potential

Yammer MBI, Do Not Distribute

Audit Mechanisms Design and implement audit mechanisms to detect unauthorized

2.3 Policy Review and Evaluation

2.4 Organizational Risk Assessment

2.5 Mitigation Strategy

2.6 Monitoring Effectiveness of Safeguards

Yammer MBI, Do Not Distribute

3.1 Information Security Accountability

3.2 Information Security Coordination

3.3 Allocation of Information Security Responsibilities

Yammer MBI, Do Not Distribute

3.4 Authorization Process for Information Systems

3.5 Specialist Information Security Advice

3.6 Cooperation Between Organizations

3.7 Independent Review of Information Security

3.8 Third Party Security Considerations

Yammer MBI, Do Not Distribute

4 Asset Classification and Control

4.1 Accountability and Inventory of Assets

4.2 Asset Handling Procedures

5.1 Including Security in Job Responsibilities

Yammer MBI, Do Not Distribute

5.2 Personnel Screening

5.3 Confidentiality Agreements

5.4 Terms and Conditions of Employment

Yammer MBI, Do Not Distribute

5.5 Information Security Education and Training

5.6 Responding to Security Incidents and Malfunctions

6.1 Documented Operating Procedures

Yammer MBI, Do Not Distribute

6.2 Operational Change Control

6.3 System Update and Patch Management Process

6.4 Incident Management Procedures

Yammer MBI, Do Not Distribute

6.5 Segregation of Duties

6.6 Separation of Non-Production and Production Systems

Yammer MBI, Do Not Distribute

6.7 External Facilities Management

6.8 Capacity Planning

6.9 Baseline Security Configuration Standards

6.10 System Acceptance

6.11 Information Backup

Yammer MBI, Do Not Distribute

A copy of the backup media is to be stored off-site in a secure location.

6.12 Operations Records

6.13 Fault Logging

6.14 Media Management

6.15 Asset Exchange

Yammer MBI, Do Not Distribute

7 Business & Service Continuity Management

7.1 Continuity Management Process