enStratus has been openly supportive of the efforts of CloudAudit for some time now. Our initial involvement was based on our value proposition as a vendor—leveraging a standard to further governance in the cloud. With the release of the draft specification to the IETF, however, we have become the first customer for CloudAudit.
What is CloudAudit?
CloudAudit provides a common interface and namespace to enable automated auditing of cloud infrastructures with respect to any number of compliance frameworks. A cloud provider exposes their compliance information—either openly or password protected—under a namespace and structure prescribed by CloudAudit. Cloud customers may then automatically query the cloud provider for assertions and supporting documentation for specific controls or entire frameworks.
enStratus as a Tool Vendor
As I mentioned above, our initial interest in CloudAudit was as a tool vendor. enStratus will support CloudAudit by querying the clouds you are using for support of the compliance frameworks you care about. CloudAudit currently defines compliance namespaces for ISO 27002, PCI DSS, COBIT, HIPAA, and NIST 800-53. Furthermore, CloudAudit leverages the work done by the Cloud Security Alliance in cross-mapping between compliance framework controls.
An enStratus customer will be able to view the assertions for any supported namespace (as well as any supporting documentation) from your cloud providers directly from within the enStratus console. We’ll even enable you to establish trust levels of the different assertions and then enable enStratus to make automated decisions about moving workloads among clouds based on compliance requirements.
enStratus as a Cloud Provider
But I'm not talking about the future right now. I'm talking about the present.
As we were going through the process of defining the CloudAudit specification, one of our customers approached us with a security audit. Because of our focus on security and governance, we are constantly working with our customers on security audits. This time, however, we decided to leverage this situation to test out the CloudAudit specification and ultimately make life easier on our customers and ourselves.
As we were finalizing the IETF draft, I therefore went about the task of assembling enStratus responses with respect to the CSA control matrix and building a tool to construct the enStratus CloudAudit namespace for CSA. My objective was to make the process of supporting CloudAudit as simple as:
- Provide responses in a controls spreadsheet for your target compliance framework.
- Assemble all supporting documents in a directory with the spreadsheet.
- Export the spreadsheet as a CSV file.
- Run a tool on the CSV file.
- Zip up the auto-generated directory.
- Unzip it wherever you intend to publish it.
I thus started in the place we always start when a customer wants us to do a self-assessment or audits us: the evil controls spreadsheet. I crafted a controls spreadsheet with the CSA controls and added two columns:
- An assertion column (yes, no, or N/A)
- A support column (file names for supporting documents)
I copied over all supporting documents into the same directory as the spreadsheet. Basically, there’s nothing here any different from the way any security audit starts. The only interesting item is that I’m not actually doing an audit for anyone in particular. I am simply “pre-packing” a response against the CSA controls.
If all you are doing is a self-assessment, you are generally done at this point. If this response is part of an audit, the information generally forms the baseline from which a human auditor executes a formal audit. The CloudAudit objective, however, is automated audit, assertion, assessment, and assurance.
CloudAudit supports automation by defining a namespace into which assertions and supporting documentation live and providing a mechanism for tools to query those assertions and discover the supporting documentation. To be compliant with CloudAudit, the self-assessment data must be distributed into a CloudAudit namespace for my target compliance framework (the CSA controls in this case).
I built a Python tool to read my self-assessment and assemble the response into the CloudAudit namespace. You can download it under the Apache 2.0 License from http://www.cloudaudit.org under the Development section of the web site. This tool reads a CSV export of my response spreadsheet and builds out a complete CloudAudit namespace for my target control and copies all supporting documentation into the appropriate places.
For example, CSA control CO-01 represents compliance audit planning. enStratus asserts that we are compliant with this control and our information systems policies and procedures document supports this assertion. CloudAudit requires information on this control to be housed in the directory .well-known/cloudaudit/org/csa/guidance/CO-01. CloudAudit further requires an index.html for human consumption and a manifest.xml file in Atom format for tool consumption. The Python script created this directory structure, built the index.html and manifest.xml files from templates, and copied the enStratus policies document into the directory.
Once we roll out our next update, any enStratus customer will be able to review enStratus from a self-assessment perspective with respect to the CSA controls directly from inside the enStratus portal. Our next objective is to roll out the ISO 27002 self-assessment.
