CSA Security Guidance for Critical Areas of Focus in Cloud Computing v.4
A Stable, Secure baseline for Cloud Operations
The Cloud Security Alliance’s Security Guidance for Critical Areas of Focus in Cloud Computing acts as a practical, actionable roadmap to individuals looking to safely and securely adopt the cloud paradigm.
Since it’s last revision in 2011, the cloud landscape, tools and technologies have changed and so we want to reflect that in an updated version of the CSA Guidance (which would be version 4). New CSA Guidance Domains are now available for review. Domains will be updated frequently, so come back to the site to see the latest domains available for review.
Experts are needed that can invest their time in providing feedback. Although we have a dedicated writing team, this is still a community project. All feedback and edits will be managed via GitHub so that all parts of the process are open and public.
We need your feedback!
The idea is to generate a cleaner and more consistent document than possible by solely relying on working groups to do their own writing, while still reflecting the collective wisdom of the community.
Feedback and edits will be managed via GitHub and Google Docs so that all parts of the process are open and public. Feedback submitted via Google Docs follows the CSA standard operating procedure for review periods.
You don't need to use any special command-line GitHub tools for this project. GitHub's web interface will allow you to read documents, provide feedback, and participate. But feel free to use git tools if you know how.
How to use GitHub to provide feedback
- Issues are the best way to add comments. The authors can read and respond to them directly. When leaving an issue. please list the line number for the start of any specific section you are commenting on.
- Pull requests are for edits. We can't respond to all pull requests because our only options are to ignore a pull or merge the changes. For consistency's sake, it is very hard to accept pull requests directly. All pull requests will be reviewed, some will be merged, and those we cannot directly merge will be treated as an issue/comment and closed. This is just a practical necessity, considering how many people will eventually be providing feedback.
For writing we are using the Markdown text format. If you want to edit and send pull requests you will need to learn Markdown (fortunately it's incredibly simple). GitHub renders Markdown directly, so unless you are actually editing content you won't need to learn it.
All feedback will be public. This is essential for maintaining the independence and objectivity of this project. Even if you know any of the authors or CSA staff, please don't email private feedback, which will be ignored.
We will do our absolute best to respond to all feedback (with the exception of pull requests, which we will review), but depending on volume we may need to combine feedback (and we understand some feedback will be contradictory).
For questions or feedback, contact email@example.com.
The project process
We will have a separate file for each domain in the Guidance.
For each domain, we will first publish a detailed outline with expected changes, and then drafts. Domains will be open for feedback the entire time, but may be closed temporarily during specific writing phases (e.g., after we collect comments on the outline, the author may close feedback as they develop the first draft).
For each domain, there will be an outline, first draft, and near-final draft.
The exception is Domain 1. We skipped the outline for that and went straight to the first draft to set a writing tone for the rest of the project.
The near-final drafts will be pulled from GitHub and converted into Word, with updated graphics, for final publication.
If you have any questions or general comments, please let us know either here or through email to firstname.lastname@example.org, and thank you for your help.
Editing and style notes
All images should be placed in /images and named with the section they appear in, followed by a dash, followed by an enumerator. e.g. "1.1.2-1.png" for the first image in the directory. Please use standard Markdown image embedding.
Links should be referenced, not inline. Each link should be sequentially ordered. This makes things easier to read (look at Domain 1 for formatting examples -- it's easy). If links start getting out of order, feel free to use "1.1" or similar to neaten things up.
Images will be redone by a graphics team before publication, so don't worry about having them look consistent.
Domain 1: Cloud Computing Concepts and Architectures
Domain 1 covers Cloud Computing Concepts and Architecture and it provides the conceptual framework for the rest of CSA’s guidance. The domain describes and defines cloud computing, sets our baseline terminology and details the overall logical and architectural frameworks used in the rest of the document.
Domain 2: Governance and Enterprise Risk Management
The ability of an organization to govern and measure enterprise risk introduced by cloud computing. Items such as legal precedence for agreement breaches, ability of user organizations to adequately assess risk of a cloud provider, responsibility to protect sensitive data when both user and provider may be at fault, and how international boundaries may affect these issues.
Domain 3: Legal Issues: Contracts and Electronic Discovery
Potential legal issues when using cloud computing. Issues touched on in this section include protection requirements for information and computer systems, security breach disclosure laws, regulatory requirements, privacy requirements, international laws, etc.
Domain 4: Compliance and Audit Management
Maintaining and proving compliance when using cloud computing. Issues dealing with evaluating how cloud computing affects compliance with internal security policies, as well as various compliance requirements (regulatory, legislative, and otherwise) are discussed here. This domain includes some direction on proving compliance during an audit.
Domain 5: Data Governance
Governing data that is placed in the cloud. Items surrounding the identification and control of data in the cloud, as well as compensating controls that can be used to deal with the loss of physical control when moving data to the cloud, are discussed here. Other items, such as who is responsible for data confidentiality, integrity, and availability are mentioned.
Domain 6: Management Plane and Business Continuity
Securing the management plane and administrative interfaces used when accessing the cloud, including both web consoles and APIs. Ensuring business continuity for cloud deployments.
Domain 7: Infrastructure Security
Core cloud infrastructure security, including networking, workload security, and hybrid cloud considerations. This domain also includes security fundamentals for private clouds.
Domain 8: Virtualization and Containers
Security for hypervisors, containers, and Software Defined Networks.
Domain 9: Incident Response
Proper and adequate incident detection, response, notification, and remediation. This attempts to address items that should be in place at both provider and user levels to enable proper incident handling and forensics. This domain will help you understand the complexities the cloud brings to your current incident-handling program.
Domain 10: Application Security
Securing application software that is running on or being developed in the cloud. This includes items such as whether it’s appropriate to migrate or design an application to run in the cloud, and if so, what type of cloud platform is most appropriate (SaaS, PaaS, or IaaS).
Domain 11: Data Security and Encryption
Implementing data security and encryption, and ensuring scalable key management.
Domain 12: Identity, Entitlement, and Access Management
Managing identities and leveraging directory services to provide access control. The focus is on issues encountered when extending an organization’s identity into the cloud. This section provides insight into assessing an organization’s readiness to conduct cloud-based Identity, Entitlement, and Access Management (IdEA).
Domain 13: Security as a Service
Providing third party facilitated security assurance, incident management, compliance attestation, and identity and access oversight.
Domain 14: Related Technologies
Established and emerging technologies with a close relationship to cloud computing, including Big Data, Internet of Things, and mobile computing.