Cloud Security Alliance publishes guidelines to bridge compliance and DevOps

The challenge of baking security compliance activities into software development is well-known – compliance teams want controls in place, but many DevOps engineers believe that the proof is in the code, not in the process or in its documentation.

Although DevSecOps practices can help to bridge compliance and development and improve overall security while reducing the effort to validate compliance with security objectives, they can vary across organisations and industries.

To address the gap between compliance and development, the Cloud Security Alliance (CSA) recently published a report that provides guidelines to help organisations translate compliance objectives into security measures and identify where security controls can be embedded, automated, measured and tested.

The report is the third in a series of reports detailing the six focus areas critical to integrating DevSecOps into an organisation.

“The increasing speed and frequency of deployments in application development today mandates a solution that is both efficient and more automated, but without compromising security and quality,” said Roupe Sahans, the report’s lead author.

In its paper, CSA grouped its guidelines into three main areas – assessments to gauge maturity and effectiveness in DevSecOps processes and controls; having the appropriate mindset in DevSecOps transformation; and tools to implement security controls and measures.

In assessing software deployment processes, the CSA stressed the need to have shared responsibility with cloud service providers in implementing security controls: “When an organisation maps compliance goals to security requirements, it is critical to understand the cloud customer’s responsibility given their choice of solutions and technologies.”

Security tools, it added, must align with technologies such as containers, virtual machines and the configuration state of cloud platforms. Organisations and their cloud suppliers should also agree on and document their shared responsibilities in a service level agreement.

As for tooling, CSA called for organisations to embrace infrastructure as-code to eliminate manual provisioning of infrastructure. They can do so through services such as AWS Cloud Formation or capabilities from the likes of Chef, Ansible and Terraform, paving the way for automation, version control and governance.

Organisations can also establish guardrails to constantly monitor software deployments to ensure alignment with their goals and objectives, including compliance. These guardrails can be represented as high-level rules with detective and preventive policies.

Guardrails may be implemented as a means of compliance reporting, such as the number of machines running approved operating systems (OSes), or as remedies to non-compliance, such as shutting down machines running unapproved OSes.

With a tendency to address risk directly through tooling, organisations can easily overlook the importance of having the appropriate mindset in DevSecOps transformation. CSA defines mindset as the ways to bring security teams and software developers closer together.

These could be activities such as “value stream mapping” that identifies teams, lead times, and process times to understand how an idea eventually leads to a customer outcome. This will provide an opportunity to identify security involvement through manual and automated activities.

Compliance objectives could also be packaged into security measures for developers to consume and implement, while methods to track and maintain control of developer activities while not hindering productivity could be adopted.