SlideShare a Scribd company logo
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
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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	
  
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
2.4.3)Level 2
This registration must be validated every 6 months.
2.4.4)Level 3
This registration must be validated every 3 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
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.2)Level 1
There are no additional requirements for Level 1 applications.
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.
5.9.2)Level 1
There are no additional requirements for Level 1 applications.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
20
5.9.3)Level 2
There are no additional requirements for Level 2 applications.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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
Sample Cloud Applications Security and Operations Policy
V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International license.
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.

More Related Content

What's hot

Technology Overview - Symantec Data Loss Prevention (DLP)
Technology Overview - Symantec Data Loss Prevention (DLP)Technology Overview - Symantec Data Loss Prevention (DLP)
Technology Overview - Symantec Data Loss Prevention (DLP)
Iftikhar Ali Iqbal
 
Information security management system (isms) overview
Information security management system (isms) overviewInformation security management system (isms) overview
Information security management system (isms) overview
Julia Urbina-Pineda
 
MITRE ATT&CKcon 2.0: Using Threat Intelligence to Focus ATT&CK Activities; Da...
MITRE ATT&CKcon 2.0: Using Threat Intelligence to Focus ATT&CK Activities; Da...MITRE ATT&CKcon 2.0: Using Threat Intelligence to Focus ATT&CK Activities; Da...
MITRE ATT&CKcon 2.0: Using Threat Intelligence to Focus ATT&CK Activities; Da...
MITRE - ATT&CKcon
 
Iso 27001 isms presentation
Iso 27001 isms presentationIso 27001 isms presentation
Iso 27001 isms presentation
Midhun Nirmal
 
Network Security Fundamentals
Network Security FundamentalsNetwork Security Fundamentals
Network Security Fundamentals
Fat-Thing Gabriel-Culley
 
Cyber Threat Intelligence
Cyber Threat IntelligenceCyber Threat Intelligence
Cyber Threat Intelligence
seadeloitte
 
Presentation on iso 27001-2013, Internal Auditing and BCM
Presentation on iso 27001-2013, Internal Auditing and BCMPresentation on iso 27001-2013, Internal Auditing and BCM
Presentation on iso 27001-2013, Internal Auditing and BCM
Shantanu Rai
 
Vulnerability Management
Vulnerability ManagementVulnerability Management
Vulnerability Management
asherad
 
ServiceNow Table Management.pptx
ServiceNow Table Management.pptxServiceNow Table Management.pptx
ServiceNow Table Management.pptx
shahebazshaikh19
 
Threat Modelling - It's not just for developers
Threat Modelling - It's not just for developersThreat Modelling - It's not just for developers
Threat Modelling - It's not just for developers
MITRE ATT&CK
 
Security architecture - Perform a gap analysis
Security architecture - Perform a gap analysisSecurity architecture - Perform a gap analysis
Security architecture - Perform a gap analysis
Carlo Dapino
 
Defence in Depth Architectural Decisions
Defence in Depth Architectural DecisionsDefence in Depth Architectural Decisions
Defence in Depth Architectural Decisions
Peter Rawsthorne
 
Security risk management
Security risk managementSecurity risk management
Security risk management
G Prachi
 
CISSP INFORGRAPH MINDMAP
CISSP INFORGRAPH MINDMAPCISSP INFORGRAPH MINDMAP
CISSP INFORGRAPH MINDMAP
Deepak Kumar (D3)
 
Application Security - Your Success Depends on it
Application Security - Your Success Depends on itApplication Security - Your Success Depends on it
Application Security - Your Success Depends on it
WSO2
 
Information Security
Information SecurityInformation Security
Information Security
Dhilsath Fathima
 
Risk Management Approach to Cyber Security
Risk Management  Approach to Cyber Security Risk Management  Approach to Cyber Security
Risk Management Approach to Cyber Security
Ernest Staats
 
Mapping ATT&CK Techniques to ENGAGE Activities
Mapping ATT&CK Techniques to ENGAGE ActivitiesMapping ATT&CK Techniques to ENGAGE Activities
Mapping ATT&CK Techniques to ENGAGE Activities
MITRE ATT&CK
 
Next-Gen security operation center
Next-Gen security operation centerNext-Gen security operation center
Next-Gen security operation center
Muhammad Sahputra
 
MITRE ATT&CK Updates: State of the ATT&CK (ATT&CKcon 4.0 Edition)
MITRE ATT&CK Updates: State of the ATT&CK (ATT&CKcon 4.0 Edition)MITRE ATT&CK Updates: State of the ATT&CK (ATT&CKcon 4.0 Edition)
MITRE ATT&CK Updates: State of the ATT&CK (ATT&CKcon 4.0 Edition)
MITRE ATT&CK
 

What's hot (20)

Technology Overview - Symantec Data Loss Prevention (DLP)
Technology Overview - Symantec Data Loss Prevention (DLP)Technology Overview - Symantec Data Loss Prevention (DLP)
Technology Overview - Symantec Data Loss Prevention (DLP)
 
Information security management system (isms) overview
Information security management system (isms) overviewInformation security management system (isms) overview
Information security management system (isms) overview
 
MITRE ATT&CKcon 2.0: Using Threat Intelligence to Focus ATT&CK Activities; Da...
MITRE ATT&CKcon 2.0: Using Threat Intelligence to Focus ATT&CK Activities; Da...MITRE ATT&CKcon 2.0: Using Threat Intelligence to Focus ATT&CK Activities; Da...
MITRE ATT&CKcon 2.0: Using Threat Intelligence to Focus ATT&CK Activities; Da...
 
Iso 27001 isms presentation
Iso 27001 isms presentationIso 27001 isms presentation
Iso 27001 isms presentation
 
Network Security Fundamentals
Network Security FundamentalsNetwork Security Fundamentals
Network Security Fundamentals
 
Cyber Threat Intelligence
Cyber Threat IntelligenceCyber Threat Intelligence
Cyber Threat Intelligence
 
Presentation on iso 27001-2013, Internal Auditing and BCM
Presentation on iso 27001-2013, Internal Auditing and BCMPresentation on iso 27001-2013, Internal Auditing and BCM
Presentation on iso 27001-2013, Internal Auditing and BCM
 
Vulnerability Management
Vulnerability ManagementVulnerability Management
Vulnerability Management
 
ServiceNow Table Management.pptx
ServiceNow Table Management.pptxServiceNow Table Management.pptx
ServiceNow Table Management.pptx
 
Threat Modelling - It's not just for developers
Threat Modelling - It's not just for developersThreat Modelling - It's not just for developers
Threat Modelling - It's not just for developers
 
Security architecture - Perform a gap analysis
Security architecture - Perform a gap analysisSecurity architecture - Perform a gap analysis
Security architecture - Perform a gap analysis
 
Defence in Depth Architectural Decisions
Defence in Depth Architectural DecisionsDefence in Depth Architectural Decisions
Defence in Depth Architectural Decisions
 
Security risk management
Security risk managementSecurity risk management
Security risk management
 
CISSP INFORGRAPH MINDMAP
CISSP INFORGRAPH MINDMAPCISSP INFORGRAPH MINDMAP
CISSP INFORGRAPH MINDMAP
 
Application Security - Your Success Depends on it
Application Security - Your Success Depends on itApplication Security - Your Success Depends on it
Application Security - Your Success Depends on it
 
Information Security
Information SecurityInformation Security
Information Security
 
Risk Management Approach to Cyber Security
Risk Management  Approach to Cyber Security Risk Management  Approach to Cyber Security
Risk Management Approach to Cyber Security
 
Mapping ATT&CK Techniques to ENGAGE Activities
Mapping ATT&CK Techniques to ENGAGE ActivitiesMapping ATT&CK Techniques to ENGAGE Activities
Mapping ATT&CK Techniques to ENGAGE Activities
 
Next-Gen security operation center
Next-Gen security operation centerNext-Gen security operation center
Next-Gen security operation center
 
MITRE ATT&CK Updates: State of the ATT&CK (ATT&CKcon 4.0 Edition)
MITRE ATT&CK Updates: State of the ATT&CK (ATT&CKcon 4.0 Edition)MITRE ATT&CK Updates: State of the ATT&CK (ATT&CKcon 4.0 Edition)
MITRE ATT&CK Updates: State of the ATT&CK (ATT&CKcon 4.0 Edition)
 

Similar to Sample Cloud Application Security and Operations Policy [release]

Big data analysis concepts and references by Cloud Security Alliance
Big data analysis concepts and references by Cloud Security AllianceBig data analysis concepts and references by Cloud Security Alliance
Big data analysis concepts and references by Cloud Security Alliance
Information Security Awareness Group
 
TierPoint White Paper_With all due diligence_2015
TierPoint White Paper_With all due diligence_2015TierPoint White Paper_With all due diligence_2015
TierPoint White Paper_With all due diligence_2015
sllongo3
 
With-All-Due-Diligence20150330
With-All-Due-Diligence20150330With-All-Due-Diligence20150330
With-All-Due-Diligence20150330
Jim Kramer
 
Azure 13 effective security controls for iso 27001 compliance
Azure 13 effective security controls for iso 27001 complianceAzure 13 effective security controls for iso 27001 compliance
Azure 13 effective security controls for iso 27001 compliance
Erlinkencana
 
Secure Cloud Hosting.paper
Secure Cloud Hosting.paperSecure Cloud Hosting.paper
Secure Cloud Hosting.paper
jagan339
 
Cloud Security, Standards and Applications
Cloud Security, Standards and ApplicationsCloud Security, Standards and Applications
Cloud Security, Standards and Applications
Dr. Sunil Kr. Pandey
 
Project Deliverable 2 Business Requirements1Project Deliverab.docx
Project Deliverable 2 Business Requirements1Project Deliverab.docxProject Deliverable 2 Business Requirements1Project Deliverab.docx
Project Deliverable 2 Business Requirements1Project Deliverab.docx
wkyra78
 
Cisco 2016 Security Report
Cisco 2016 Security Report Cisco 2016 Security Report
Cisco 2016 Security Report
Steve Fantauzzo
 
Cisco Annual Security Report 2016
Cisco Annual Security Report 2016Cisco Annual Security Report 2016
Cisco Annual Security Report 2016
The Internet of Things
 
Cisco 2016 Annual Security Report
Cisco 2016 Annual Security ReportCisco 2016 Annual Security Report
Cisco 2016 Annual Security Report
James Gachie
 
Cisco asr-2016-160121231711
Cisco asr-2016-160121231711Cisco asr-2016-160121231711
Cisco asr-2016-160121231711
Trainning Educação
 
Cisco Annual Security Report
Cisco Annual Security ReportCisco Annual Security Report
Cisco Annual Security Report
The Internet of Things
 
A Comparative Review on Data Security Challenges in Cloud Computing
A Comparative Review on Data Security Challenges in Cloud ComputingA Comparative Review on Data Security Challenges in Cloud Computing
A Comparative Review on Data Security Challenges in Cloud Computing
IRJET Journal
 
The Federal Information Security Management Act
The Federal Information Security Management ActThe Federal Information Security Management Act
The Federal Information Security Management Act
Michelle Singh
 
IRJET - Multitenancy using Cloud Computing Features
IRJET - Multitenancy using Cloud Computing FeaturesIRJET - Multitenancy using Cloud Computing Features
IRJET - Multitenancy using Cloud Computing Features
IRJET Journal
 
IRJET- A Survey on SaaS-Attacks and Digital Forensic
IRJET-  	  A Survey on SaaS-Attacks and Digital ForensicIRJET-  	  A Survey on SaaS-Attacks and Digital Forensic
IRJET- A Survey on SaaS-Attacks and Digital Forensic
IRJET Journal
 
Trusted Cloud Initiative: Identity Management Research
Trusted Cloud Initiative: Identity Management ResearchTrusted Cloud Initiative: Identity Management Research
Trusted Cloud Initiative: Identity Management Research
guestba832ad
 
A study on_security_and_privacy_issues_o
A study on_security_and_privacy_issues_oA study on_security_and_privacy_issues_o
A study on_security_and_privacy_issues_o
Pradeep Muralidhar
 
Security and Privacy Issues of Cloud Computing; Solutions and Secure Framework
Security and Privacy Issues of Cloud Computing; Solutions and Secure FrameworkSecurity and Privacy Issues of Cloud Computing; Solutions and Secure Framework
Security and Privacy Issues of Cloud Computing; Solutions and Secure Framework
IOSR Journals
 
The Anatomy of a Cloud Security Breach
The Anatomy of a Cloud Security BreachThe Anatomy of a Cloud Security Breach
The Anatomy of a Cloud Security Breach
CloudLock
 

Similar to Sample Cloud Application Security and Operations Policy [release] (20)

Big data analysis concepts and references by Cloud Security Alliance
Big data analysis concepts and references by Cloud Security AllianceBig data analysis concepts and references by Cloud Security Alliance
Big data analysis concepts and references by Cloud Security Alliance
 
TierPoint White Paper_With all due diligence_2015
TierPoint White Paper_With all due diligence_2015TierPoint White Paper_With all due diligence_2015
TierPoint White Paper_With all due diligence_2015
 
With-All-Due-Diligence20150330
With-All-Due-Diligence20150330With-All-Due-Diligence20150330
With-All-Due-Diligence20150330
 
Azure 13 effective security controls for iso 27001 compliance
Azure 13 effective security controls for iso 27001 complianceAzure 13 effective security controls for iso 27001 compliance
Azure 13 effective security controls for iso 27001 compliance
 
Secure Cloud Hosting.paper
Secure Cloud Hosting.paperSecure Cloud Hosting.paper
Secure Cloud Hosting.paper
 
Cloud Security, Standards and Applications
Cloud Security, Standards and ApplicationsCloud Security, Standards and Applications
Cloud Security, Standards and Applications
 
Project Deliverable 2 Business Requirements1Project Deliverab.docx
Project Deliverable 2 Business Requirements1Project Deliverab.docxProject Deliverable 2 Business Requirements1Project Deliverab.docx
Project Deliverable 2 Business Requirements1Project Deliverab.docx
 
Cisco 2016 Security Report
Cisco 2016 Security Report Cisco 2016 Security Report
Cisco 2016 Security Report
 
Cisco Annual Security Report 2016
Cisco Annual Security Report 2016Cisco Annual Security Report 2016
Cisco Annual Security Report 2016
 
Cisco 2016 Annual Security Report
Cisco 2016 Annual Security ReportCisco 2016 Annual Security Report
Cisco 2016 Annual Security Report
 
Cisco asr-2016-160121231711
Cisco asr-2016-160121231711Cisco asr-2016-160121231711
Cisco asr-2016-160121231711
 
Cisco Annual Security Report
Cisco Annual Security ReportCisco Annual Security Report
Cisco Annual Security Report
 
A Comparative Review on Data Security Challenges in Cloud Computing
A Comparative Review on Data Security Challenges in Cloud ComputingA Comparative Review on Data Security Challenges in Cloud Computing
A Comparative Review on Data Security Challenges in Cloud Computing
 
The Federal Information Security Management Act
The Federal Information Security Management ActThe Federal Information Security Management Act
The Federal Information Security Management Act
 
IRJET - Multitenancy using Cloud Computing Features
IRJET - Multitenancy using Cloud Computing FeaturesIRJET - Multitenancy using Cloud Computing Features
IRJET - Multitenancy using Cloud Computing Features
 
IRJET- A Survey on SaaS-Attacks and Digital Forensic
IRJET-  	  A Survey on SaaS-Attacks and Digital ForensicIRJET-  	  A Survey on SaaS-Attacks and Digital Forensic
IRJET- A Survey on SaaS-Attacks and Digital Forensic
 
Trusted Cloud Initiative: Identity Management Research
Trusted Cloud Initiative: Identity Management ResearchTrusted Cloud Initiative: Identity Management Research
Trusted Cloud Initiative: Identity Management Research
 
A study on_security_and_privacy_issues_o
A study on_security_and_privacy_issues_oA study on_security_and_privacy_issues_o
A study on_security_and_privacy_issues_o
 
Security and Privacy Issues of Cloud Computing; Solutions and Secure Framework
Security and Privacy Issues of Cloud Computing; Solutions and Secure FrameworkSecurity and Privacy Issues of Cloud Computing; Solutions and Secure Framework
Security and Privacy Issues of Cloud Computing; Solutions and Secure Framework
 
The Anatomy of a Cloud Security Breach
The Anatomy of a Cloud Security BreachThe Anatomy of a Cloud Security Breach
The Anatomy of a Cloud Security Breach
 

More from LinkedIn

How LinkedIn is Transforming Businesses
How LinkedIn is Transforming BusinessesHow LinkedIn is Transforming Businesses
How LinkedIn is Transforming Businesses
LinkedIn
 
Networking on LinkedIn 101
Networking on LinkedIn 101Networking on LinkedIn 101
Networking on LinkedIn 101
LinkedIn
 
5 تحديثات على ملفك في 5 دقائق
5 تحديثات على ملفك في 5 دقائق5 تحديثات على ملفك في 5 دقائق
5 تحديثات على ملفك في 5 دقائق
LinkedIn
 
5 LinkedIn Profile Updates in 5 Minutes
5 LinkedIn Profile Updates in 5 Minutes5 LinkedIn Profile Updates in 5 Minutes
5 LinkedIn Profile Updates in 5 Minutes
LinkedIn
 
The Student's Guide to LinkedIn
The Student's Guide to LinkedInThe Student's Guide to LinkedIn
The Student's Guide to LinkedIn
LinkedIn
 
The Top Skills That Can Get You Hired in 2017
The Top Skills That Can Get You Hired in 2017The Top Skills That Can Get You Hired in 2017
The Top Skills That Can Get You Hired in 2017
LinkedIn
 
Accelerating LinkedIn’s Vision Through Innovation
Accelerating LinkedIn’s Vision Through InnovationAccelerating LinkedIn’s Vision Through Innovation
Accelerating LinkedIn’s Vision Through Innovation
LinkedIn
 
How To Tell Your #workstory
How To Tell Your #workstoryHow To Tell Your #workstory
How To Tell Your #workstory
LinkedIn
 
LinkedIn Q1 2016 Earnings Call
LinkedIn Q1 2016 Earnings CallLinkedIn Q1 2016 Earnings Call
LinkedIn Q1 2016 Earnings Call
LinkedIn
 
The 2016 LinkedIn Job Search Guide
The 2016 LinkedIn Job Search GuideThe 2016 LinkedIn Job Search Guide
The 2016 LinkedIn Job Search Guide
LinkedIn
 
LinkedIn Q4 2015 Earnings Call
LinkedIn Q4 2015 Earnings CallLinkedIn Q4 2015 Earnings Call
LinkedIn Q4 2015 Earnings Call
LinkedIn
 
Banish The Buzzwords
Banish The BuzzwordsBanish The Buzzwords
Banish The Buzzwords
LinkedIn
 
LinkedIn Bring In Your Parents Day 2015 - Your Parents' Best Career Advice
LinkedIn Bring In Your Parents Day 2015 - Your Parents' Best Career AdviceLinkedIn Bring In Your Parents Day 2015 - Your Parents' Best Career Advice
LinkedIn Bring In Your Parents Day 2015 - Your Parents' Best Career Advice
LinkedIn
 
LinkedIn Q3 2015 Earnings Call
LinkedIn Q3 2015 Earnings CallLinkedIn Q3 2015 Earnings Call
LinkedIn Q3 2015 Earnings Call
LinkedIn
 
LinkedIn Economic Graph Research: Toronto
LinkedIn Economic Graph Research: TorontoLinkedIn Economic Graph Research: Toronto
LinkedIn Economic Graph Research: Toronto
LinkedIn
 
Freelancers Are LinkedIn Power Users [Infographic]
Freelancers Are LinkedIn Power Users [Infographic]Freelancers Are LinkedIn Power Users [Infographic]
Freelancers Are LinkedIn Power Users [Infographic]
LinkedIn
 
Top Industries for Freelancers on LinkedIn [Infographic]
Top Industries for Freelancers on LinkedIn [Infographic]Top Industries for Freelancers on LinkedIn [Infographic]
Top Industries for Freelancers on LinkedIn [Infographic]
LinkedIn
 
LinkedIn Quiz: Which Parent Are You When It Comes to Helping Guide Your Child...
LinkedIn Quiz: Which Parent Are You When It Comes to Helping Guide Your Child...LinkedIn Quiz: Which Parent Are You When It Comes to Helping Guide Your Child...
LinkedIn Quiz: Which Parent Are You When It Comes to Helping Guide Your Child...
LinkedIn
 
LinkedIn Connect to Opportunity™ -- Stories of Discovery
LinkedIn Connect to Opportunity™ -- Stories of DiscoveryLinkedIn Connect to Opportunity™ -- Stories of Discovery
LinkedIn Connect to Opportunity™ -- Stories of Discovery
LinkedIn
 
LinkedIn Q2 2015 Earnings Call
LinkedIn Q2 2015 Earnings CallLinkedIn Q2 2015 Earnings Call
LinkedIn Q2 2015 Earnings Call
LinkedIn
 

More from LinkedIn (20)

How LinkedIn is Transforming Businesses
How LinkedIn is Transforming BusinessesHow LinkedIn is Transforming Businesses
How LinkedIn is Transforming Businesses
 
Networking on LinkedIn 101
Networking on LinkedIn 101Networking on LinkedIn 101
Networking on LinkedIn 101
 
5 تحديثات على ملفك في 5 دقائق
5 تحديثات على ملفك في 5 دقائق5 تحديثات على ملفك في 5 دقائق
5 تحديثات على ملفك في 5 دقائق
 
5 LinkedIn Profile Updates in 5 Minutes
5 LinkedIn Profile Updates in 5 Minutes5 LinkedIn Profile Updates in 5 Minutes
5 LinkedIn Profile Updates in 5 Minutes
 
The Student's Guide to LinkedIn
The Student's Guide to LinkedInThe Student's Guide to LinkedIn
The Student's Guide to LinkedIn
 
The Top Skills That Can Get You Hired in 2017
The Top Skills That Can Get You Hired in 2017The Top Skills That Can Get You Hired in 2017
The Top Skills That Can Get You Hired in 2017
 
Accelerating LinkedIn’s Vision Through Innovation
Accelerating LinkedIn’s Vision Through InnovationAccelerating LinkedIn’s Vision Through Innovation
Accelerating LinkedIn’s Vision Through Innovation
 
How To Tell Your #workstory
How To Tell Your #workstoryHow To Tell Your #workstory
How To Tell Your #workstory
 
LinkedIn Q1 2016 Earnings Call
LinkedIn Q1 2016 Earnings CallLinkedIn Q1 2016 Earnings Call
LinkedIn Q1 2016 Earnings Call
 
The 2016 LinkedIn Job Search Guide
The 2016 LinkedIn Job Search GuideThe 2016 LinkedIn Job Search Guide
The 2016 LinkedIn Job Search Guide
 
LinkedIn Q4 2015 Earnings Call
LinkedIn Q4 2015 Earnings CallLinkedIn Q4 2015 Earnings Call
LinkedIn Q4 2015 Earnings Call
 
Banish The Buzzwords
Banish The BuzzwordsBanish The Buzzwords
Banish The Buzzwords
 
LinkedIn Bring In Your Parents Day 2015 - Your Parents' Best Career Advice
LinkedIn Bring In Your Parents Day 2015 - Your Parents' Best Career AdviceLinkedIn Bring In Your Parents Day 2015 - Your Parents' Best Career Advice
LinkedIn Bring In Your Parents Day 2015 - Your Parents' Best Career Advice
 
LinkedIn Q3 2015 Earnings Call
LinkedIn Q3 2015 Earnings CallLinkedIn Q3 2015 Earnings Call
LinkedIn Q3 2015 Earnings Call
 
LinkedIn Economic Graph Research: Toronto
LinkedIn Economic Graph Research: TorontoLinkedIn Economic Graph Research: Toronto
LinkedIn Economic Graph Research: Toronto
 
Freelancers Are LinkedIn Power Users [Infographic]
Freelancers Are LinkedIn Power Users [Infographic]Freelancers Are LinkedIn Power Users [Infographic]
Freelancers Are LinkedIn Power Users [Infographic]
 
Top Industries for Freelancers on LinkedIn [Infographic]
Top Industries for Freelancers on LinkedIn [Infographic]Top Industries for Freelancers on LinkedIn [Infographic]
Top Industries for Freelancers on LinkedIn [Infographic]
 
LinkedIn Quiz: Which Parent Are You When It Comes to Helping Guide Your Child...
LinkedIn Quiz: Which Parent Are You When It Comes to Helping Guide Your Child...LinkedIn Quiz: Which Parent Are You When It Comes to Helping Guide Your Child...
LinkedIn Quiz: Which Parent Are You When It Comes to Helping Guide Your Child...
 
LinkedIn Connect to Opportunity™ -- Stories of Discovery
LinkedIn Connect to Opportunity™ -- Stories of DiscoveryLinkedIn Connect to Opportunity™ -- Stories of Discovery
LinkedIn Connect to Opportunity™ -- Stories of Discovery
 
LinkedIn Q2 2015 Earnings Call
LinkedIn Q2 2015 Earnings CallLinkedIn Q2 2015 Earnings Call
LinkedIn Q2 2015 Earnings Call
 

Recently uploaded

原版制作(Humboldt毕业证书)柏林大学毕业证学位证一模一样
原版制作(Humboldt毕业证书)柏林大学毕业证学位证一模一样原版制作(Humboldt毕业证书)柏林大学毕业证学位证一模一样
原版制作(Humboldt毕业证书)柏林大学毕业证学位证一模一样
ydzowc
 
5G Radio Network Througput Problem Analysis HCIA.pdf
5G Radio Network Througput Problem Analysis HCIA.pdf5G Radio Network Througput Problem Analysis HCIA.pdf
5G Radio Network Througput Problem Analysis HCIA.pdf
AlvianRamadhani5
 
Mechanical Engineering on AAI Summer Training Report-003.pdf
Mechanical Engineering on AAI Summer Training Report-003.pdfMechanical Engineering on AAI Summer Training Report-003.pdf
Mechanical Engineering on AAI Summer Training Report-003.pdf
21UME003TUSHARDEB
 
Introduction to Computer Networks & OSI MODEL.ppt
Introduction to Computer Networks & OSI MODEL.pptIntroduction to Computer Networks & OSI MODEL.ppt
Introduction to Computer Networks & OSI MODEL.ppt
Dwarkadas J Sanghvi College of Engineering
 
Open Channel Flow: fluid flow with a free surface
Open Channel Flow: fluid flow with a free surfaceOpen Channel Flow: fluid flow with a free surface
Open Channel Flow: fluid flow with a free surface
Indrajeet sahu
 
A high-Speed Communication System is based on the Design of a Bi-NoC Router, ...
A high-Speed Communication System is based on the Design of a Bi-NoC Router, ...A high-Speed Communication System is based on the Design of a Bi-NoC Router, ...
A high-Speed Communication System is based on the Design of a Bi-NoC Router, ...
DharmaBanothu
 
openshift technical overview - Flow of openshift containerisatoin
openshift technical overview - Flow of openshift containerisatoinopenshift technical overview - Flow of openshift containerisatoin
openshift technical overview - Flow of openshift containerisatoin
snaprevwdev
 
Generative AI Use cases applications solutions and implementation.pdf
Generative AI Use cases applications solutions and implementation.pdfGenerative AI Use cases applications solutions and implementation.pdf
Generative AI Use cases applications solutions and implementation.pdf
mahaffeycheryld
 
Determination of Equivalent Circuit parameters and performance characteristic...
Determination of Equivalent Circuit parameters and performance characteristic...Determination of Equivalent Circuit parameters and performance characteristic...
Determination of Equivalent Circuit parameters and performance characteristic...
pvpriya2
 
Blood finder application project report (1).pdf
Blood finder application project report (1).pdfBlood finder application project report (1).pdf
Blood finder application project report (1).pdf
Kamal Acharya
 
FULL STACK PROGRAMMING - Both Front End and Back End
FULL STACK PROGRAMMING - Both Front End and Back EndFULL STACK PROGRAMMING - Both Front End and Back End
FULL STACK PROGRAMMING - Both Front End and Back End
PreethaV16
 
一比一原版(uoft毕业证书)加拿大多伦多大学毕业证如何办理
一比一原版(uoft毕业证书)加拿大多伦多大学毕业证如何办理一比一原版(uoft毕业证书)加拿大多伦多大学毕业证如何办理
一比一原版(uoft毕业证书)加拿大多伦多大学毕业证如何办理
sydezfe
 
Levelised Cost of Hydrogen (LCOH) Calculator Manual
Levelised Cost of Hydrogen  (LCOH) Calculator ManualLevelised Cost of Hydrogen  (LCOH) Calculator Manual
Levelised Cost of Hydrogen (LCOH) Calculator Manual
Massimo Talia
 
OOPS_Lab_Manual - programs using C++ programming language
OOPS_Lab_Manual - programs using C++ programming languageOOPS_Lab_Manual - programs using C++ programming language
OOPS_Lab_Manual - programs using C++ programming language
PreethaV16
 
Null Bangalore | Pentesters Approach to AWS IAM
Null Bangalore | Pentesters Approach to AWS IAMNull Bangalore | Pentesters Approach to AWS IAM
Null Bangalore | Pentesters Approach to AWS IAM
Divyanshu
 
Accident detection system project report.pdf
Accident detection system project report.pdfAccident detection system project report.pdf
Accident detection system project report.pdf
Kamal Acharya
 
This study Examines the Effectiveness of Talent Procurement through the Imple...
This study Examines the Effectiveness of Talent Procurement through the Imple...This study Examines the Effectiveness of Talent Procurement through the Imple...
This study Examines the Effectiveness of Talent Procurement through the Imple...
DharmaBanothu
 
Transformers design and coooling methods
Transformers design and coooling methodsTransformers design and coooling methods
Transformers design and coooling methods
Roger Rozario
 
Unit -II Spectroscopy - EC I B.Tech.pdf
Unit -II Spectroscopy - EC  I B.Tech.pdfUnit -II Spectroscopy - EC  I B.Tech.pdf
Unit -II Spectroscopy - EC I B.Tech.pdf
TeluguBadi
 
Impartiality as per ISO /IEC 17025:2017 Standard
Impartiality as per ISO /IEC 17025:2017 StandardImpartiality as per ISO /IEC 17025:2017 Standard
Impartiality as per ISO /IEC 17025:2017 Standard
MuhammadJazib15
 

Recently uploaded (20)

原版制作(Humboldt毕业证书)柏林大学毕业证学位证一模一样
原版制作(Humboldt毕业证书)柏林大学毕业证学位证一模一样原版制作(Humboldt毕业证书)柏林大学毕业证学位证一模一样
原版制作(Humboldt毕业证书)柏林大学毕业证学位证一模一样
 
5G Radio Network Througput Problem Analysis HCIA.pdf
5G Radio Network Througput Problem Analysis HCIA.pdf5G Radio Network Througput Problem Analysis HCIA.pdf
5G Radio Network Througput Problem Analysis HCIA.pdf
 
Mechanical Engineering on AAI Summer Training Report-003.pdf
Mechanical Engineering on AAI Summer Training Report-003.pdfMechanical Engineering on AAI Summer Training Report-003.pdf
Mechanical Engineering on AAI Summer Training Report-003.pdf
 
Introduction to Computer Networks & OSI MODEL.ppt
Introduction to Computer Networks & OSI MODEL.pptIntroduction to Computer Networks & OSI MODEL.ppt
Introduction to Computer Networks & OSI MODEL.ppt
 
Open Channel Flow: fluid flow with a free surface
Open Channel Flow: fluid flow with a free surfaceOpen Channel Flow: fluid flow with a free surface
Open Channel Flow: fluid flow with a free surface
 
A high-Speed Communication System is based on the Design of a Bi-NoC Router, ...
A high-Speed Communication System is based on the Design of a Bi-NoC Router, ...A high-Speed Communication System is based on the Design of a Bi-NoC Router, ...
A high-Speed Communication System is based on the Design of a Bi-NoC Router, ...
 
openshift technical overview - Flow of openshift containerisatoin
openshift technical overview - Flow of openshift containerisatoinopenshift technical overview - Flow of openshift containerisatoin
openshift technical overview - Flow of openshift containerisatoin
 
Generative AI Use cases applications solutions and implementation.pdf
Generative AI Use cases applications solutions and implementation.pdfGenerative AI Use cases applications solutions and implementation.pdf
Generative AI Use cases applications solutions and implementation.pdf
 
Determination of Equivalent Circuit parameters and performance characteristic...
Determination of Equivalent Circuit parameters and performance characteristic...Determination of Equivalent Circuit parameters and performance characteristic...
Determination of Equivalent Circuit parameters and performance characteristic...
 
Blood finder application project report (1).pdf
Blood finder application project report (1).pdfBlood finder application project report (1).pdf
Blood finder application project report (1).pdf
 
FULL STACK PROGRAMMING - Both Front End and Back End
FULL STACK PROGRAMMING - Both Front End and Back EndFULL STACK PROGRAMMING - Both Front End and Back End
FULL STACK PROGRAMMING - Both Front End and Back End
 
一比一原版(uoft毕业证书)加拿大多伦多大学毕业证如何办理
一比一原版(uoft毕业证书)加拿大多伦多大学毕业证如何办理一比一原版(uoft毕业证书)加拿大多伦多大学毕业证如何办理
一比一原版(uoft毕业证书)加拿大多伦多大学毕业证如何办理
 
Levelised Cost of Hydrogen (LCOH) Calculator Manual
Levelised Cost of Hydrogen  (LCOH) Calculator ManualLevelised Cost of Hydrogen  (LCOH) Calculator Manual
Levelised Cost of Hydrogen (LCOH) Calculator Manual
 
OOPS_Lab_Manual - programs using C++ programming language
OOPS_Lab_Manual - programs using C++ programming languageOOPS_Lab_Manual - programs using C++ programming language
OOPS_Lab_Manual - programs using C++ programming language
 
Null Bangalore | Pentesters Approach to AWS IAM
Null Bangalore | Pentesters Approach to AWS IAMNull Bangalore | Pentesters Approach to AWS IAM
Null Bangalore | Pentesters Approach to AWS IAM
 
Accident detection system project report.pdf
Accident detection system project report.pdfAccident detection system project report.pdf
Accident detection system project report.pdf
 
This study Examines the Effectiveness of Talent Procurement through the Imple...
This study Examines the Effectiveness of Talent Procurement through the Imple...This study Examines the Effectiveness of Talent Procurement through the Imple...
This study Examines the Effectiveness of Talent Procurement through the Imple...
 
Transformers design and coooling methods
Transformers design and coooling methodsTransformers design and coooling methods
Transformers design and coooling methods
 
Unit -II Spectroscopy - EC I B.Tech.pdf
Unit -II Spectroscopy - EC  I B.Tech.pdfUnit -II Spectroscopy - EC  I B.Tech.pdf
Unit -II Spectroscopy - EC I B.Tech.pdf
 
Impartiality as per ISO /IEC 17025:2017 Standard
Impartiality as per ISO /IEC 17025:2017 StandardImpartiality as per ISO /IEC 17025:2017 Standard
Impartiality as per ISO /IEC 17025:2017 Standard
 

Sample Cloud Application Security and Operations Policy [release]

  • 1. 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
  • 2. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. 2.4.3)Level 2 This registration must be validated every 6 months. 2.4.4)Level 3 This registration must be validated every 3 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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.2)Level 1 There are no additional requirements for Level 1 applications. 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. 5.9.2)Level 1 There are no additional requirements for Level 1 applications.
  • 20. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 20 5.9.3)Level 2 There are no additional requirements for Level 2 applications. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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. Sample Cloud Applications Security and Operations Policy V 1.0 ©2015 LinkedIn Corporation. This document is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International license. 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.