Sample Cloud Application Security and Operations Policy [release]

V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license.

1

Sample Cloud Application Security and Operations Policy

A guide for the development of a cloud security policy

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. January 2015 C. Niggel C. Nwatu R. Mohan

Sample Cloud Applications Security and Operations Policy


2

Table of Contents Using This Document ................................................................................................................... 3 Data Modeling and Leveling ......................................................................................................... 4 1) Authentication and Administration ......................................................................................... 5

1.1) Authentication ................................................................................................................. 5 1.2) Account Provisioning ....................................................................................................... 6 1.3) Account Access Termination ........................................................................................... 7 1.4) Account Deprovisioning .................................................................................................. 7 1.5) Roles and Authorization (User Control Consolidation) .................................................... 8 1.6) Access Control Granularity ............................................................................................. 9

2) Auditing .................................................................................................................................. 9 2.1) Logging ........................................................................................................................... 9 2.2) Vendor Monitoring, Reporting, and Alerting .................................................................. 10 2.3) Internal Monitoring, Reporting, and Alerting .................................................................. 11 2.4) Internal Application Database ....................................................................................... 12

3) Business Continuity ............................................................................................................. 12 3.1) Interoperability and Portability ....................................................................................... 12 3.2) Backup .......................................................................................................................... 13 3.3) Disaster Recovery ......................................................................................................... 14

4) Data Security ....................................................................................................................... 14 4.1) Response Expectations ................................................................................................ 14

5) Communication Security ...................................................................................................... 15 5.2) Provider Network Security Testing ................................................................................ 15 5.3) Provider Application Security Testing ........................................................................... 16 5.4) Thick-Client or Physical Appliance Security .................................................................. 17 5.5) Mobile Client Security ................................................................................................... 17 5.6) Data Loss Prevention .................................................................................................... 18 5.7) 3rd Party Application Interoperability ............................................................................ 18 5.8) Virtualization .................................................................................................................. 19 5.9) Storage at Rest ............................................................................................................. 19

6) Vendor Governance ............................................................................................................. 20 6.1) Provider Policy and Standards Assurance .................................................................... 20 6.2) Incident Response ........................................................................................................ 20

7) Brand Reputation ................................................................................................................. 21 7.1) Contract Considerations ................................................................................................ 21 7.2) Discovery ...................................................................................................................... 22 7.3) Subpoena ...................................................................................................................... 22 7.4) Email Integration ........................................................................................................... 22

Appendix A: Application SSO Classes ....................................................................................... 23



3

Using This Document Modern employees have lots of data to work with, and they expect easy-to-use tools that work everywhere they do. To accomplish this, organizations are now taking on a “Cloud First” strategy, and moving critical infrastructure onto hosted providers. This de-centralization means that as ever-increasing amounts of data and processing are shifted out of the direct control of IT and security management, security teams must institute a suite of controls that will ensure the safety of company and customer data. We have developed this Cloud Application Policy Framework to help those responsible for the Confidentiality, Accessibility, and Integrity of corporate data identify the controls that must be in place to successfully complete this mission. The policy document is split into two sections – Data Modeling and Leveling, and Cloud Assurance Criteria. In the Data Modeling section, we provide guidance on how to identify the different security classifications of the data in your environment, and break them out into three levels. In the Cloud Assurance Criteria section, we provide controls to be placed on each of the levels. The goal is to create a security policy that supports fast deployment of low-risk applications (Level 1), while providing a comprehensive review of high-risk applications (Level 3). No two companies have the same data models and security threats, so we have licensed this document using a Creative Commons Attribution, Non-Commercial, Share-Alike license. This license encourages you to modify the policy and release it under a similar license back to the security community. We also recommend that you set up a consistent review schedule internally for your policy, as the cloud security space is changing rapidly. Just as you patch your systems, updating your policies with new practices is key to maintaining a secure environment. Please send us your comments on, changes to, and implementations of the policy described in this document. Through the collective knowledge of the security community, we can safely navigate the waters of the cloud security landscape. - The LinkedIn Cloud Security team


4

Data Modeling and Leveling In order to develop a balance between security and usability, the policy has been written to support three levels of application security, based on the US NIST 800-60 framework. NIST 800-60 assists administrators with classification of their data by defining the potential impact unauthorized disclosure, modification, and disruption would have on the business. Begin by identifying the different data types used in your organization. Most organizations will have 3 data types, representing data belonging to the Corporation, data belonging to Employees, and data belonging to Customers. Once classified by type, objects should be classified by potential impact, as defined by the NIST framework. POTENTIAL IMPACT

Security Objective LOW (Level 1) MODERATE (Level 2) HIGH (Level 3) Confidentiality Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. [44 U.S.C., SEC. 3542]

The unauthorized disclosure of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.

The unauthorized disclosure of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.

The unauthorized disclosure of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

Integrity Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. [44 U.S.C., SEC. 3542]

The unauthorized modification or destruction of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.

The unauthorized modification or destruction of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.

The unauthorized modification or destruction of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

Availability Ensuring timely and reliable access to and use of information. [44 U.S.C., SEC. 3542]

The disruption of access to or use of information or an information system could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.

The disruption of access to or use of information or an information system could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.

The disruption of access to or use of information or an information system could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

Table 1: NIST 800-60 Classification, from http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol1-Rev1.pdf

For each objective, determine if the potential impact for your data is limited, serious, or severe. If during the course of your review, you have selected multiple levels, round up to determine your final level (the high water mark). For example, a report containing employee names and social security numbers may have High Confidentiality, but Moderate Integrity and Availability, because it could be easily recreated. Because the Confidentiality rating is High, the document must be ranked as High (Level 3). You will want to ensure an application handling that data meets the Level 3 assurance requirements as documented below. There will be cases where an application is unable to meet the requirements defined to handle the appropriate data at the time of review. To accommodate these cases, the assessor will suggest compensating controls that can be enforced.


5

Cloud Assurance Criteria As we continue to leverage cloud-based services, a framework has been developed to enable the business to easily understand the security controls that must be in place to ensure the Confidentiality, Integrity, and Availability requirements for this data. This document defines the specific assurance criteria an application must meet in order to handle data at each classification. Each Assurance Criteria defines up to 4 levels of controls, which map to the potential impact determined for your data type. All applications must meet the Base Requirements. A Level 1 application must meet the Base Requirements and the Level 1 Requirements. A Level 2 application must meet the Base Requirements, Level 1 Requirements, and Level 2 Requirements. A Level 3 application must meet all requirements for that Assurance Criteria. There will be cases where an application is unable to meet the requirements defined to handle the appropriate data at the time of review. To accommodate these cases, the assessor will suggest compensating controls that can be enforced. In this document, Hosted Applications or Cloud typically refer to Software as a Service (SaaS). With this in mind, we have focused the controls on this class of hosted service. Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) have their own unique requirements. Where these are valuable, we have captured them under a PaaS/IaaS heading.

1) Authentication and Administration

1.1) Authentication Authentication is defined as validating a user’s identity and basic-level authorization through determining if a user is allowed to access a system.

1.1.1) Base Requirements Company will maintain an in-house centralized and authoritative authentication store that can be integrated with third-party services through industry standard protocols. This authentication store is described in the Application Classes section of Appendix A: Application SSO Classes. There are four classes of Authentication levels, ranging from a secure password store to fully integrated authentication & account provisioning/deprovisioning. Company will also maintain a two-factor authentication platform utilizing time-based one-time passwords, which will be integrated with the authentication store. At no time are third-party OAuth access methods to be used on any Company-approved cloud applications (i.e. logging in with your personal social network account is forbidden).

1.1.2) Level 1 The service should integrate with Company’s primary authentication service, but it is not required. If user credentials are stored in the service, they must be stored using industry standard cryptographic hashes and hash salting. If the application integrated with SSO, it is



6

expected to be run at a Class 0 or 1 level.

1.1.3) Level 2 The service must integrate with Company’s primary authentication service at a Class 2 level or above. Exceptions will be granted for services that support 10 users or less if the following criteria are met

• Multifactor Authentication is enabled for all accounts using the service • There is a documented user provisioning and de-provisioning procedure with a

named manager who accepts ownership of the process

1.1.4) Level 3 The service must integrate with Company’s primary authentication service at a Class 3 level or above. Users must authenticate with a second factor when connecting with a new client and again after an interval determined by security during the application assessment.

Additional roles and features within a Level 3 application may require multifactor authentication for each use, as required by security. Where necessary, exceptions will be granted as per the rules stated for Level 2 applications.

1.1.5) Notes Application-specific passwords will be permitted for mobile clients that do not support multifactor authentication. These passwords must be strong, and rotated at least every 3 months.

1.2) Account Provisioning Account Provisioning consists of the creation of the user account in the hosted system, which in many cases is performed separately from adding the user to the Identity and Access Management system.

1.2.1) Level 1 Automated account provisioning is preferred, but not required. Automated account provisioning consists of on-demand provisioning through the SAML request, or support for an automated feed of a delimited file format through a secure channel such as SFTP.

1.2.2) Level 2 Automated account provisioning through a SAML request, an API call, or an automated feed of a delimited file format through a secure channel is required. If an API is not available for automation, there must be a documented user provisioning and deprovisioning process with a named manager who accepts ownership of the process.

1.2.3) Level 3 The application must support the ability to query the account provisioning status through an API and report back to a provisioning system.



7

1.2.4) Notes The requirements defined in this section refer to Employees and Contractors who have a company network account. Contractors who do not have a company network account are supported in limited cases for applications up to Level 2. There must be a documented provisioning and deprovisioning process with a named manager who accepts ownership of the process.

1.3) Account Access Termination Account Access Termination is separate from Account Deprovisioning, as in many cases access to the account is separate from the disposition of the account and user-generated content in an application. Access Termination relates only to preventing access to an application after a user role change.

1.3.1) Level 1 A process must be documented that supports termination of access within 24 hours of a receipt of a termination request, including documented confirmation of completion. Ideally this will be supported by an automated process through the IAM system, but this is not required.

1.3.2) Level 2 A process must be documented that supports termination of access within 1 hour of the receipt of a termination request, including documented confirmation of completion. Ideally this will be supported by an automated process through the IAM system, but this is not required.

1.3.3) Level 3 Accounts must be immediately terminated upon receipt of a termination request by an automated process. When an account is terminated, the application must close any open sessions owned by that account. Manual processes are only allowed as part of a variance granted to applications that have 10 users or less.

1.4) Account Deprovisioning Account Deprovisioning details the disposition of the account in the service, and management of the user-generated data (if any) related to the account.

1.4.1) Level 1 Accounts must be able to be deprovisioned through a manual or automatic practice. A documented process is not required.

1.4.2) Level 2 Accounts must be able to be deprovisioned through an API call or a delimited file transferred through a secure upload method. A written process must be maintained by the application owner that defines a disposition strategy for content attached to a user’s account.



8

1.4.3) Level 3 Accounts must be able to be automatically deprovisioned through an API by a Company-managed deprovisioning system. A written disposition strategy must be maintained by the application owner and validated by security for content attached to a user’s account.

1.5) Roles and Authorization (User Control Consolidation)

1.5.1) Base Requirements The application platform must provide the application administrator the ability to restrict access through the designation of various roles and functions. The application must provide the means to authorize users through the least privilege model.

1.5.2) Level 1 The service must provide the administrator the ability to distinguish “administrator users” and “regular users”. The “regular users” shall be given authorization to the cloud service capabilities by “administrator users.”

1.5.3) Level 2 The service must provide the administrator the ability to create user roles and explicitly grant authorization to data and capabilities following the least privilege model based on role and/or function. By default a user should have no access. Authorization for additional permissions must be granted by the administrator with the appropriate access controls, and be performed in an audited manner. Additional authentication mechanisms such as 2FA or one time-limited use passwords should be available.

The following administrative roles are considered a minimum set that must be available for a Level 2 application

• Super Administrator • User create / modify / update / delete • Read-Only Administrator or Log / Audit Read-Only role

1.5.4) Level 3 The system must provide a role-based access control model enabling the following additional roles above a Level 2 application

• Administrator w/o access to view content (Admin Audit Account) Third party access requests, including invitations to share content with end users, must be directed to and approved by an application administrator. These access requests must respect the Company Change Management workflow in order to ensure organizational compliance.

1.5.5) Notes If an administrator applies specific access controls to a group owner account, the group owner should not have the ability to grant permissions above that assigned to the group. Subsequent accounts should either match the group owner controls or be more restrictive.



9

1.6) Access Control Granularity

1.6.1) Level 1 The service must provide the administrator the ability to distinguish “administrator users” and “regular users”. The “regular users” shall be given authorization to the cloud service capabilities by “administrator users.”

1.6.2) Level 2 The service must provide the administrator the ability to assign users the appropriate granular access control levels based on roles and/or function. The application owner must document a workflow process by which users can request additional access. This request must be verified by the administrator or group owner. This process must be auditable.

1.6.3) Level 3 The service must provide the administrator total control on the creation of granular user access controls, including access control lists for individual applications and users.

2) Auditing

2.1) Logging

2.1.1) Base requirements Company will maintain a central Security Event and Information Management (SEIM) solution, allowing for the storing, collection and parsing of log data. In order to be compatible with the SEIM, the service must

• Adhere to industry log format standards • Have a time service synchronized to a common worldwide time source • Have log data defined in UTC. If this is not possible, the UTC skew must be

documented If the application cannot provide this level of logging, integration with the cloud security monitoring system must be individually reviewed.

2.1.2) Level 1 The service provider must collect the following data

• Application User Logs o Log In / Log Off o Session Creation / Session Termination o Password Change

• Application Audit Logs o User Create / Update / Delete actions o Application Events as defined by the service provider

Logs must be maintained for a minimum of one year, and available by an administrator request. Real-time event logging to the Company SEIM is not required.



10

2.1.3) Level 2 In addition to the requirements defined for Level 1 applications, the service provider must collect the following

• Application User Logs o Failed Login Attempts

• Application Audit Logs o Document or Object Create / Read / Update / Delete actions o Metadata Create / Read / Update / Delete actions

All logs must also include the source IP address of the actor. Logs must be maintained for a minimum of one year, and available through the application web interface. Logs must be exportable into a format accessible by Company’s SEIM tool. Real-time reporting is preferred, but not required.

PaaS/IaaS: The provider must include log data about the physical location of resources, including event logs when those resources change

2.1.4) Level 3 In addition to the requirements defined for Level 1 and Level 2 applications, the service provider must collect the following

• Application User Logs o All Administrative actions performed

• Application Audit Logs o Identifying users and the actions they performed

• Performance Data Logs • Security Event Logs

o Brute Force Attempts • Network Logs

o Geo Location IP Logging o Firewall Deny Logging

• Transaction Logs • Creation and Destruction for system-level objects as required for PCI compliant

applications only

Logs must be exported in real-time to Company’s SEIM. Logs must also be maintained by the service provider for one year and encrypted at rest.

PaaS/IaaS: The provider must also include the Hypervisor Logs.

2.2) Vendor Monitoring, Reporting, and Alerting

2.2.1) Base Requirements The provider must demonstrate to security that monitoring and reporting of infrastructure supporting the instance of the hosted service is being performed.



11

The provider must have a contact and escalation process for alerting of scheduled and unscheduled application downtime. This process will be captured in the application database entry.

2.2.2) Level 1 The provider must demonstrate the ability to be alerted to application downtime of the Company instance within 1 hour of the beginning of the downtime event.

2.2.3) Level 2 The vendor must provide additional availability reporting as required to validate the negotiated Service Level Agreement.

2.2.4) Level 3 The vendor must provide alerting and reporting of unusual events, as defined as being outside of a baseline usage pattern determined by the vendor through analytics of a user’s normal usage patterns.

2.2.5) Notes The application and network monitoring can be performed by a third party partner of the service vendor. In general, monitoring should detect unusual or unauthorized application and network activities, system usage, network usage, port scanning activities, packet sniffing by other tenants, etc.

2.3) Internal Monitoring, Reporting, and Alerting

2.3.1) Base Requirements Our company shall demonstrate the ability to perform security monitoring, defined as the ability to take internal network data, infrastructure data, system action data, and external vulnerability information, to monitor for abnormalities, unauthorized usage, or access. Regulatory compliance, if applicable, must be maintained for all data. The monitoring and alerting may leverage the cloud service provider’s platform and various internal capabilities.

Our company must also monitor and alert on Company-initiated application changes. These changes should be apart of a cloud application / service change management process and these actions logged.

2.3.2) Level 1 Our company shall demonstrate the ability to monitor account logons and account logouts by request or on demand and time availability.

2.3.3) Level 2 Our company shall demonstrate the ability to detect unauthorized account usage and unauthorized data access.

2.3.4) Level 3 Our company must demonstrate the ability to provide comprehensive security monitoring on data residing in the cloud.



12

2.3.5) Notes It is understood that we may have to develop custom tools in order to perform monitoring and compliance.

2.4) Internal Application Database

2.4.1) Base Requirements In order to store critical application information, we will maintain a database of applications that have been reviewed according to the assurance criteria. The database will include the data described below. Both current and pending applications will be registered.

Ownership Data Application Owner Application Support / On-Call Contact Application Service Level Agreement and Recovery Time Objective

Application Data Application SSO Class, as defined in Appendix A Hosted Data Classification, as determined by the application owner At Rest data encryption state

Policy Data Incident notification policy and last review date Backup policy and last review date Account Access Termination Policy and last review date Account Deprovisioning Policy and last review date Business Continuity Runbook and test date Last known Penetration Test / Security Test (3rd Party External)

2.4.2) Level 1 This registration must be validated every 12 months.



3) Business Continuity

3.1) Interoperability and Portability

3.1.1) Level 1 Unstructured data must be able to be exported into a non-proprietary format, either by the user or the service provider. Automated export processes are not required. Databases must be able to be exported into a non-proprietary format, either by the user or the service



13

provider. Automated export processes are not required. Service level agreements must exist to ensure data is available when the Company needs it, preventing a “run-on-the-bank” scenario.

3.1.2) Level 2 Unstructured data files must be able to be exported in bulk into a non-proprietary format by a service user or administrator.

PaaS/IaaS: Services must use a standards-based virtualization format, or allow for Virtual Machine export in OVF format. Service providers must document any non-standard customizations or differences that would impact deploying a Virtual Machine onto a new hypervisor. Any custom APIs developed by the service provider should be abstracted from Company-developed code in order to allow for quick porting of applications to a new service provider.

3.1.3) Level 3 Unstructured data files must be able to be exported in bulk with metadata and security ACLs attached.

3.2) Backup Data Backup is defined as maintaining one or more versions of content in a physically and logically separate system. This data is meant to be quickly accessed to replace content that is damaged, corrupted, or accidentally deleted. Data Replication must not be confused with backup, as replication cannot handle restoration from corrupted data. Recovery time objectives and recovery point objectives described are maximum values - the business may set more stringent RTO and RPO targets based on the value of the data.

3.2.1) Level 1 The business customer is strongly encouraged to define a backup strategy for content. A formal backup strategy is not required.

3.2.2) Level 2 There must be a documented backup policy for all data hosted on a Level 2 system. If the backups are hosted, the backup system must be maintained by a different provider. Steps must be taken to ensure the backup is not hosted on the same PaaS/IaaS infrastructure as the primary data. 14 days of backup must be maintained, with a 24 hour recovery time objective and 24 hour recovery point objective.

Note: Backups hosted on a different cloud infrastructure, but managed by the same vendor meet this requirement. For example, a cloud storage vendor maintains an encrypted content backup on AWS. Because this exists on a different cloud infrastructure from the production system, it meets Level 2 requirements.

3.2.3) Level 3 There must be a documented backup policy for all data hosted on a Level 3 system. In addition to the requirements documented for Level 2 applications, 30 days of backup must



14

be maintained, with a 12 hour recovery time objective, and 24 hour recovery point objective.

3.3) Disaster Recovery Disaster Recovery is defined as maintaining availability of all data managed by a service. Restoring data from a DR system may take longer than restoring from backup, and is typically more involved.

3.3.1) Level 1 A disaster recovery plan is not required for Level 1 applications.

3.3.2) Level 2 A service provider must provide business continuity and disaster recovery documentation for the hosted service. The application owner must provide a business continuity runbook that defines the length of time the system is allowed to be inaccessible before a business continuity event is initiated, the process for restoration, and the ownership of the process. This document must be updated every 6 months and be attached to the application’s registry in the hosted service database.

3.3.3) Level 3 Level 3 vendors should provide a tour of a representative facility that will be hosting Company data, enabling Company to evaluate the physical suitability of the site

• Physical and Environmental Security • Fire Protection • Protection from Natural Disaster • Policy Enforcement

The tour will be attended by • IT specialist • Information Security specialist • Physical Security specialist • Director-level or above stakeholder

In addition to the requirements for a Level 2 application, the Disaster Recovery document must be reviewed every 3 months and be attached to the application’s registry in the hosted service database. The Disaster Recovery strategy must be tested no less than once per year.

4) Data Security

4.1) Response Expectations

4.1.1) Base Requirements The following sections set requirements for the protection of Company data. Vulnerabilities may be found by the Company, the application vendor, or a third party. Once the vulnerability has been disclosed to the vendor, the following service levels are expected



15

• Critical: Remediation on the same day • High: Remediation in 5 business days • Medium: Remediation in 15 business days • Low: Remediation in 30 business days

Generally, vulnerability scoring is performed by the risk assessor, and are based on their scoring criteria. Lacking that, High-risk vulnerabilities can be described as:

• Any bug that allows for circumvention of the authentication mechanism • Any bug that enables disclosure of credential information, including but not limited to:

usernames, passwords, or API tokens • Any bug that allows for an attacker to run arbitrary code, including but not limited to:

SQL injection, Cross-Site Scripting (XSS) Cross-Site Request Forgery (CSRF), and Remote Code Execution

• Any report of the application logging confidential data including but not limited to: confidential data not required for the log's purpose, passwords, or API tokens

• Any bug that affects log data or enables an attacker to destroy existing log data or prevent logging of their actions

We reserve the right to determine vulnerability severity based on internal standards, or vulnerabilities will be classed at a mutually agreed-upon severity.

4.1.2) Level 2 The vendor is expected to be able to disable Company’s instance of the hosted application immediately upon request in response to a vulnerability.

5) Communication Security

5.1) Transport Layer Protection

5.1.1) Base Requirements The cloud service platform shall use Transport Layer Security (TLS) for all user authentication, credential, and data transfer. SSL v3 is to be disabled.

Certificates must not be self signed and come from established and reliable independent CAs.

Strong ciphers must be utilized and key management process should be documented.

5.2) Provider Network Security Testing

5.2.1) Base Requirements The cloud service provider or a reputable third-party shall perform network security penetration testing on the Company hosted instance using an industry-standard methodology and furnish a report. The network traffic generated by Company’s instance should be defensible from tenant port scanning and packet sniffing.



16

5.2.2) Level 1 The network security penetration test must be performed at least annually. An executive summary shall be provided to Company for review.

5.2.3) Level 2 The network security penetration test must be performed at least every 6 months, or after a significant change has been made to the system. An executive summary shall be provided to Company for review, if additional information is needed Company shall make a request.

Company shall have the ability to perform one external network security penetration scan annually and will provide findings to the cloud service provider for response and remediation.

5.2.4) Level 3 The network security penetration test must be performed at least quarterly, or after a significant change has been made to the system. An executive summary and detailed report shall be provided to Company for review.

Company shall have the ability to perform at least one external network security penetration scan annually and will provide findings to the cloud service provider for response and remediation.

5.3) Provider Application Security Testing

5.3.1) Base Requirements The cloud service provider or a reputable third-party shall perform application security penetration testing using an industry-standard methodology and furnish a report.

5.3.2) Level 1 The application security penetration test must be performed at least annually. An executive summary shall be provided to Company for review.

5.3.3) Level 2 The application security penetration test must be performed at least every 6 months, or after a significant change has been made to the system. An executive summary shall be provided to Company for review, if additional information is needed Company shall make a request.

Company shall have the ability to perform an application security penetration assessment annually and provide findings to the cloud service provider for response and remediation.

5.3.4) Level 3 The application security penetration test must be performed at least quarterly, or after a significant change has been made to the system. An executive summary and detailed report shall be provided to Company for review, if additional information is needed Company shall make a request. The cloud service provider shall provide documentation about the software quality assurance and software development lifecycle for the application.



17

Company shall have the ability to perform an application security penetration assessment annually and will provide findings to the cloud service provider for response and remediation.

5.4) Thick-Client or Physical Appliance Security Some hosted applications include software or hardware that must be installed on Company networks in order to support the application. This includes, but is not limited to, desktop sync products, Active Directory sync agents, or display controllers.

5.4.1) Base Requirements The application shall use secure communications to transmit data. User authentication may be performed with an application-specific password managed through the enterprise administration console. A third-party security assessment using an industry-standard methodology of the application must be performed and the results available to Company. If the application is a physical or virtual appliance, it should be placed on a secured subnet where access to other Company resources is not available.

5.4.2) Level 1 No additional client security requirements.

5.4.3) Level 2 No additional client security requirements.

5.4.4) Level 3 The application shall have the ability to perform device pinning, where the administrator has the ability to limit the number and type of devices the end user can connect with. The application shall perform token-based authentication and have the ability to locally log operational and security events.

5.4.5) Notes Internal security may perform penetration testing to determine usage and enterprise risk.

5.5) Mobile Client Security

5.5.1) Base Requirements The mobile client application should use secure communication methods such as SSL/TLS for all data transmission.

5.5.2) Level 1 No additional mobile client security requirements.

5.5.3) Level 2 The mobile client application may create an encrypted directory on the device for the storage and synchronization of files. The mobile client shall leverage a pull-based content setup and synchronization shall be configurable by the administrator. User authentication shall be performed by a token instead of saved username / password.



18

5.5.4) Level 3 The application must have an authentication structure that allows Company to enforce the use of an MDM solution to access data. The mobile client application must also have the option of only allowing the saving of data onto the mobile device if the device is encrypted. The application must also have the ability to manage and remove content from a compromised device.

5.5.5) Notes Internal security may perform penetration testing on the mobile client to determine usage and enterprise risk.

5.6) Data Loss Prevention

5.6.1) Base Requirements The service must employ a firewall that does not permit the application from sending traffic with a source IP or MAC address other than its own.

5.6.2) Level 1 PaaS/IaaS: Volume-level encryption must be available to protect data against snapshot cloning, or protect each piece of content if using Object-based storage.

5.6.3) Level 2 The application should provide the ability to filter requests by IP, enabling Company to limit traffic to trusted networks. The service should have basic Data Loss Prevention mechanisms, such as traffic reporting and alerting of traffic spikes above a set threshold or a provider-determined baseline.

5.6.4) Level 3 The application must provide the ability to filter requests by IP, enabling Company to limit traffic to trusted networks. In addition, the applications must have robust Data Loss Prevention Mechanisms including Database / File Activity Monitoring, traffic and usage baselining, and alerting. If these services cannot be provided by the vendor, the vendor must provide the log information required for Company to develop the baseline and alerting toolset in-house.

5.7) 3rd Party Application Interoperability 3rd Party Application Interoperability is defined as accessory hosted applications that use APIs to act on data hosted by the service provider. An example would be an application that uses Google Drive APIs to store project files in a user’s Drive storage space.

5.7.1) Level 1 There are no additional requirements for Level 1 applications.

5.7.2) Level 2 The system must allow the administrator to control if OAuth or other API access is allowed on a per-application level. The service should provide the administrator the ability to create time sensitive access control criteria for third party applications.



19

Any actions taken by a third party application must be logged. In addition to the standard log data requirements, the log must contain an identifier to the application and the user context the application was authorized under.

5.7.3) Level 3 The system must allow the administrator to control if OAuth or other API access is allowed on a per-application, per-user basis, and restrict types of content from being accessed via API.

5.8) Virtualization

5.8.1) Base Requirements PaaS/Iaas: A virtual machine cannot be moved from a less-trusted environment to a more-trusted environment. The data should be exported and the application built from the ground up on a trusted platform.


5.8.3) Level 2 Virtual machines that host any service should be encrypted at rest.

Paas/IaaS: Any Virtual Machine migration, including vMotion moves, must be logged and captured in the operational log that is transmitted to the Company central log management system.

5.8.4) Level 3 Virtual machines must be encrypted at rest. Mixed-mode (systems that support PCI-protected data and non-PCI protected data on the same hypervisor) are not allowed by any service provider.

PaaS / IaaS: The service provider must host Company’s content on a separate network segment and on a dedicated hypervisor. The service provider must offer a software-defined firewall. If the OS / Application layer is managed by the service provider, they must provide an update / patch cycle document.

5.9) Storage at Rest

5.9.1) Base Requirements The service provider must provide the ability for the Company to store data in an encrypted format if required by privacy regulations such as the EU DPD or SOX.




20


5.9.4) Level 3 The service provider must store all data at rest in an encrypted format. The cloud provider should not have any requirements that would prevent the use of a gateway encryption service or an application to encrypt data before reaching the service.

PaaS/IaaS: Any Virtual Machine “snapshots” or similar capability must be stored on an encrypted file system.

6) Vendor Governance

6.1) Provider Policy and Standards Assurance

6.1.1) Base requirements The service provider must show that an Information Security Management Program (ISMP) has been developed, documented, approved, and implemented that includes administrative, technical, and physical safeguards to protect assets and data from loss, misuse, unauthorized access, disclosure, alteration, and destruction. In addition, change management documentation must exist.

6.1.2) Level 1 Level 1 cloud service provider must have the information security policies described above.

6.1.3) Level 2 The cloud service provider must provide an audit report. The audit report shall be SAS70 Type II, SSAE 16 SOC2, ISAE3402, or similar third party audit report. Level 2 providers should perform the Cloud Security Alliance Cloud Controls Matrix (CMM) self-assessment. These documents will be reviewed by Company annually.

6.1.4) Level 3 Level 3 providers must perform the Cloud Security Alliance Cloud Controls Matrix (CMM) self-assessment. The findings must be made available for annual review. In addition, the implementation of a Level 3 application at Company should be able to pass our PCI audit. The cloud provider must provide a current change management policy document.

6.2) Incident Response

6.2.1) Base Requirements The responding CSIRT team will have the ability to review the service provider’s incident response and triage process. We recommend that service providers leverage industry best practices such as NIST 800-61, the Computer Security Incident Handling Guide.



21

6.2.2) Level 1 No additional Incident Response requirements.

6.2.3) Level 2 The vendor must provide a documented incident response policy including

• Defined point of contact and Out-Of-Band communications channel • Incident definition and notification criteria • Definition of roles & responsibilities during an incident • Specification of post-mortem activities and resolution timelines • Specification of Incident Response testing

6.2.4) Level 3 Through security monitoring of the infrastructure the vendor / provider shall share threat intelligence data with Company Security Team.

7) Brand Reputation

7.1) Contract Considerations

7.1.1) Level 1 • The vendor must include an exit / termination clause if an assessment finds a

vulnerability that is not remediated within the expected timeframe, without penalty • The vendor must agree to provide Company notification of confirmed security

incidents that affect Company’s data (confidential and non-confidential) within 24 hours of their discovery

• The vendor must agree to provide Company notification of warrants, subpoenas, or other legal action that involve Company data (confidential and non-confidential) with appropriate time for Company to react

• The vendor must provide Service Level Agreements for availability, including reputational availability (example: blacklist of IPs due to tenant sending SPAM)

• The vendor must agree to reasonably cooperate in a discovery event

7.1.2) Level 2 • The vendor must agree to Company’s right to audit • The vendor must clearly document any tenant relationships or dependencies • The vendor must provide written attestation that Company data has been removed

when the contract is terminated • If there is a bandwidth, usage, or API cap placed on Company’s usage of the

service, the vendor must lift this cap during Company’s response to litigation

7.1.3) Level 3 • The vendor must provide Company with notification of both known and potential

breaches of any customer’s data. This data may be anonymized.



22

7.2) Discovery

7.2.1) Level 1 Ability to export all data owned or generated by any specific user of the system in any format.

7.2.2) Level 2 Ability to export all data owned or generated by any specific user of the system in a format readily accessible by Company’s eDiscovery platform. Ability to execute a litigation hold of content in-place. Ability to create and remove litigation hold via API.

7.2.3) Level 3 Ability to perform detailed keyword searches and generate output in a format readily accessible by Company’s eDiscovery platform.

7.2.4) Notes The contract should address the temporary bandwidth increase required to pull discovery data. The content should be accessed in a collection of files reasonable in number and size (1,000 10MB PST files for a user covering 2 years would not be reasonable). If the bandwidth is unable to be provided, the cloud provider should provide a solution in which storage can be shipped while maintaining a chain of custody.

7.3) Subpoena

7.3.1) Base Requirements The provider must notify Company in a timely manner if they receive a Subpoena, Warrant, or any other legal request for Company’s data and give Company appropriate time to respond to the request.

7.4) Email Integration

7.4.1) Base Requirements If the service needs to send email that appears to be coming from a Company-managed email address, the provider must support Company’s email security strategy to ensure the message is legitimate. Cloud provider hyperlinked marketing and advertising will not be embedded within email communication.


23

Appendix A: Application SSO Classes Implementations of Single Sign-On can vary significantly between providers, and this variation can have a profound effect on the security benefit provided by the SSO integration. In order to provide a standard method of describing these benefits, the following class structure has been developed. A SSO implementation can be compared against the class descriptions provided in order to determine the security posture provided by the integration.

Class 0

Class 0 applications do not have a SSO integration, and are provided through a Saved-Password mechanism. Using this strategy, the Identity Provider securely stores the user name and password, and feeds it to the app, typically through a browser plugin. This design is easily circumventable so the access logs stored in the Identity Provider should not be considered accurate. Account provisioning and deprovisioning are performed through a secondary channel. Since disabling the account within the Identity Provider does not prevent access to the application, Class 0 applications are preferable if the user may need to access the application after they have terminated employment. An example would be a 401k benefits portal.

Class 1

Class 1 applications provide convenience to the end users, but do not add any application security. These applications support SSO access through the Identity Provider, but allow the user to maintain a separate username / password that can be used through the application's login panel or mobile application. Since the user can access the application directly without going through the Identity Provider, IdP access logs should not be considered accurate. Account provisioning and deprovisioning in this class of application is performed through a secondary channel, either automatically (secure data feed through web API or file transfer), or manually. Since disabling the account in the Identity Provider does not prevent access to the application, the application administrator is responsible for ensuring deprovisioning is performed in a timely manner.

Class 2

Class 2 applications enforce SSO access through an Identity Provider only. The user does not have a separate username / password for the application. Access is granted to the application through IdP-initiated connections, or by passing credentials through a trusted channel to the IdP (delegated authentication). Account provisioning and deprovisioning is performed through a secondary channel, either automatically (secure data feed through web API or file transfer), or manually. Because all access is controlled by the Identity Provider, the application administrator does not have to act quickly to a termination event.

Class 3

Like a Class 2 application, Class 3 applications enforce SSO access through an Identity



24

Provider only. Account provisioning for these applications is performed automatically through the SAML assertion or in real-time by an API integration with the IdP. Account deprovisioning is performed through a secondary channel, preferably through an automated task using an API. Because all access is controlled by the Identity Provider, the application administrator does not have to act quickly to a termination event.

Engineering

Sample Cloud Application Security and Operations Policy [release]