Experts weigh in on ISACA ‘DevOps Practitioner Considerations’

Checklists alone don’t help organizations function better or be more secure. For businesses interested in actually functioning better or being more secure, though, a set of guidelines provides a framework–a solid foundation that lets them track things and make sure they’re at least heading in the right direction.

ISACA recently published its DevOps Practitioner Considerations, which provides a framework for security controls in a DevOps environment. I wrote an analysis of the 10 key controls ISACA spells out and spoke with some DevOps experts about what the ISACA guidelines really mean:

The DevOps revolution is transforming the methods and pace of software development. ISACA, an independent, nonprofit organization dedicated to developing and implementing industry-leading security practices, recently created new guidelines for DevOps controls: “DevOps Practitioner Considerations.”

Business value bolstered

The ISACA guidelines recognize the business value of DevOps but stress that there are assurance, governance, and security factors that need to be considered. “This guidance outlines these considerations: the risk of DevOps (in adoption and non-adoption), controls that can help mitigate key risk areas, and specific actions that practitioners can take to ensure that the benefits of DevOps are realized while potential risk is mitigated.”

First, let’s break down each of the 10 key controls outlined in the ISACA document:

1. Automated software scanning

In order to keep up with the more rapid release cycle of a DevOps environment, ISACA recommends an automated scan to find security configuration issues in code. The ISACA document directs auditors to observe that some sort of application code scanning tool is in place and to examine log files or other evidence to prove scans are taking place.

2. Automated vulnerability scanning

In addition to code scanning, automated vulnerability scanning is also recommended. The document recognizes how DevOps platforms such as Chef or Puppet automate configuration management and may introduce changes and vulnerabilities dynamically in the environment. The idea is to trigger some sort of automated vulnerability scan as a part of the release process.

3. Web application firewall

Either of the automated scans may discover issues that need to be mitigated but aren’t severe enough to warrant an urgent response. A firewall or some equivalent security filter between the application server and the outside world can provide adequate temporary protection while underlying issues are addressed.

4. Developer application security training

Training developers on secure coding techniques and how to avoid common vulnerabilities and security configuration issues is an important and valuable security control—albeit one that isn’t unique to DevOps. ISACA auditors are asked to assess developer security training and review evidence that developers have attended or participated in appropriate training.

Read the rest of the breakdown along with insight and commentary from DevOps experts at TechBeacon: A detailed analysis of ISACA’s 10 key DevOps controls.