CSA Security Guidance for Critical Areas of Focus in Cloud Computing v4.0
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.0). 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 protected].
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 [email protected], 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.
Peer Review Guidance v4.0
The peer review period has ended. Check back soon for details about the document’s release.