Sample Cloud Application Security and Operations Policy

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
1
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
Sample Cloud Applications Security and Operations Policy
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
2
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
3
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 The unauthorized disclosure of The unauthorized disclosure of The unauthorized disclosure of
Preserving authorized restrictions information could be expected to information could be expected to information could be expected to
on information access and have a limited adverse effect on have a serious adverse effect on have a severe or catastrophic
disclosure, including means for organizational operations, organizational operations, adverse effect on organizational
protecting personal privacy and organizational assets, or organizational assets, or operations, organizational assets,
proprietary information. individuals. individuals. or individuals.
[44 U.S.C., SEC. 3542]
Integrity The unauthorized modification or The unauthorized modification or The unauthorized modification or
Guarding against improper destruction of information could destruction of information could destruction of information could
information modification or be expected to have a limited be expected to have a serious be expected to have a severe or
destruction, and includes adverse effect on organizational adverse effect on organizational catastrophic adverse effect on
ensuring information non- operations, organizational assets, operations, organizational assets, organizational operations,
repudiation and authenticity. or individuals. or individuals. organizational assets, or
[44 U.S.C., SEC. 3542] individuals.
Availability The disruption of access to or use The disruption of access to or use The disruption of access to or use
Ensuring timely and reliable of information or an information of information or an information of information or an information
access to and use of information. system could be expected to have system could be expected to have system could be expected to have
[44 U.S.C., SEC. 3542] a limited adverse effect on a serious adverse effect on a severe or catastrophic adverse
organizational operations, organizational operations, effect on organizational
organizational assets, or organizational assets, or operations, organizational assets,
individuals. individuals. 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.
4
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
5
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.
6
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.
7
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)

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.
8
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.
9
2.1.3) Level 2
In addition to the requirements defined for Level 1 applications, the service provider must
collect the following
o Failed Login Attempts
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
o All Administrative actions performed
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

The provider must demonstrate to security that monitoring and reporting of infrastructure
supporting the instance of the hosted service is being performed.
10
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

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.
11
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

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.
2.4.3) Level 2
2.4.4) Level 3
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
12
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
13
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
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
14
• 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
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

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.
15
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

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.
16
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.

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

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.
17
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

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.
18
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
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.2) Level 1
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

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.
5.9.2) Level 1
19
5.9.3) Level 2
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

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.
20
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.
21
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
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

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.
22
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
23
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.
24

Sample Cloud Application Security and Operations Policy

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sample Cloud Application Security and Operations Policy

Uploaded by

Copyright:

Available Formats

Sample Cloud Application Security and

This work is licensed under the Creative Commons Attribution-NonCommercial-

Using This Document

- The LinkedIn Cloud Security team

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

1) Authentication and Administration

1.1.1) Base Requirements

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

1.2) Account Provisioning

1.3) Account Access Termination

1.4) Account Deprovisioning

1.5) Roles and Authorization (User Control Consolidation)

1.6) Access Control Granularity

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

2.2) Vendor Monitoring, Reporting, and Alerting

2.3) Internal Monitoring, Reporting, and Alerting

2.4) Internal Application Database

3.3) Disaster Recovery

• Critical: Remediation on the same day

5.2) Provider Network Security Testing

5.3) Provider Application Security Testing

5.4) Thick-Client or Physical Appliance Security

5.4.1) Base Requirements

5.5) Mobile Client Security

5.6) Data Loss Prevention

5.7) 3rd Party Application Interoperability

5.9) Storage at Rest

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

6.2) Incident Response

7.4) Email Integration

You might also like