Yammer Security Policy 4nu5a

Yammer Information Security Policy

1

Information Security Policy 1. Executive Summary 1.1 Abstract The Yammer Security Policy establishes the policy foundation for Yammer’s 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/partner’s business , 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 Yammer’s core production infrastructure and services.

Yammer MBI, Do Not Distribute

Yammer Information Security Policy

Cross Functional Security Team (CST)

Data Owner

Data Custodian

2

A team composed of senior representatives from Yammer Engineering, Customer , and Legal that collaborates in order to implement Yammer’s Information Security Management System For any given data asset, the person or group of people whose job function is most closely aligned with the data’s purpose and is held able for handling and care of the data The person or group who grants istrative or operational access to a given data asset

2 Information Security Policy Objective: To provide documented management direction and 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 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 MBI, Do Not Distribute

Yammer Information Security Policy

3

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 ed 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 MBI, Do Not Distribute

Yammer Information Security Policy

4

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 organization’s 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 – s 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 system’s 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 MBI, Do Not Distribute

Yammer Information Security Policy



5

Audit Mechanisms – Design and implement audit mechanisms to detect unauthorized use and to 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 ing 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 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 age is to combine with the previous Principle to highlight the importance of the “three A’s”: authentication, authorization, and audit. 2

Yammer MBI, Do Not Distribute

Yammer Information Security Policy

6

3 Organizational Security Policy Objective: The management of information security within the organization.

3.1 Information Security ability All Yammer Staff and Contingent Staff are able for understanding and adhering to the guidance contained in this Policy and any applicable documents ing 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 able 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 able 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 MBI, Do Not Distribute

Yammer Information Security Policy

7

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 s 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 MBI, Do Not Distribute

Yammer Information Security Policy

8

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 ing 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 ability and Inventory of Assets All major Assets used to the delivery of Yammer must be ed for and have a nominated owner. The Asset Owner is able 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 Asset’s 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 MBI, Do Not Distribute

Yammer Information Security Policy

9

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 • ister 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 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 MBI, Do Not Distribute

Yammer Information Security Policy

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 employee’s 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 MBI, Do Not Distribute

Yammer Information Security Policy

   

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 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 ed 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 MBI, Do Not Distribute

Yammer Information Security Policy

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 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 owner’s approval of all changes made to the system, program, or data over which he/she is able.  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 who require access and are authorized to perform certain duties, as per Section 5.5. (*ref Security Policy for Access Controls)

Yammer MBI, Do Not Distribute

Yammer Information Security Policy

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 MBI, Do Not Distribute

Yammer Information Security Policy

   



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 Asset’s 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 MBI, Do Not Distribute

Yammer Information Security Policy

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 Microsoft’s 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 MBI, Do Not Distribute

Yammer Information Security Policy

   

   

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 B 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 MBI, Do Not Distribute

Yammer Information Security Policy

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 of their contracts. Incidents must be escalated as described in Sections 4.6, 4.7 and 5.4. LCA is the point of 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 MBI, Do Not Distribute

Yammer Information Security Policy

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 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 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 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 ing Yammer.

9.1

Controls Against Malicious Software

All information systems ing 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. s must be made aware of the dangers of ing 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 MBI, Do Not Distribute

Yammer Information Security Policy

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- 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 log’s retention requirements. Logging of the following activities should be considered:  Registration and Modification Events  and Events  Maintenance  Security Setting Changes  Logging Level Changes

Yammer MBI, Do Not Distribute

Yammer Information Security Policy



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 MBI, Do Not Distribute

Yammer Information Security Policy

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 Service’s 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 and network context of each piece of data before delivery to the , 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 MBI, Do Not Distribute

Yammer Information Security Policy

22

10.3.4 Security in Application Systems - Output Data Validation Data output by application systems must be validated prior to being stored or ed 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 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 MBI, Do Not Distribute

Yammer Information Security Policy

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 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 deg and implementing appropriate procedures to ensure security is addressed appropriately during the development and processes. 10.8.1 Security in Development and 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 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 MBI, Do Not Distribute

Yammer Information Security Policy

24

10.8.3 Security in Development and 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 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 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 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 ed 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 MBI, Do Not Distribute

Yammer Information Security Policy

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 MBI, Do Not Distribute

Yammer Information Security Policy

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 MBI, Do Not Distribute

Yammer Information Security Policy

27

accordance with manufacturer’s 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 MBI, Do Not Distribute

Yammer Information Security Policy

28

12 Document Control 12.1 About this Document Author Effective Date Email

Matthew Sutkus August 1, 2013 [email protected]

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 - 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 ing policies and procedures based upon the results from an evaluation process.

Yammer MBI, Do Not Distribute

Yammer Information Security Policy

29

istrative 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 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 s 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 asset’s sensitivity. 3

This is per ISO27002 categorization of assets.

Yammer MBI, Do Not Distribute

Yammer Information Security Policy

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-s of Yammer. Control –A process and/or technical mechanism utilized to enforce or 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 , 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 ed 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 MBI, Do Not Distribute

Yammer Information Security Policy

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- – 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 ing policies and procedures in meeting the program’s 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 MBI, Do Not Distribute

Yammer Information Security Policy

32

Identity Management – A business strategy for the unified control of 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 ing infrastructure that receive, process, or transmit data in 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 t 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 s 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 MBI, Do Not Distribute

Yammer Information Security Policy

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, Microsoft’s 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 ing 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- or partner submitted data must be made. Operations – The execution of processes and procedures ing the delivery of Yammer. Responsible for performing system istration, engineering and service management , 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, ing 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 , making these areas more efficient, cost-effective and error-free. Operations Management – The oversight of processes and procedures ing 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 MBI, Do Not Distribute

Yammer Information Security Policy

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 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- facing environment(s) used for operation and of the live site, containing end- or partner-derived data, servicing requests, or performing maintenance tasks against end- 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 MBI, Do Not Distribute

Yammer Information Security Policy

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 team’s 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 MBI, Do Not Distribute

Yammer Information Security Policy

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 ing 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. Profile – A collection of information about a particular person or information system, usually stored in a central repository. 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 ed by Yammer Staff regardless of hosting location. Yammer Staff – Microsoft employees involved in the development, marketing, sales, 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 MBI, Do Not Distribute

Yammer Information Security Policy

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

Yammer MBI, Do Not Distribute

Comments Initial Draft Align more closely with SOA