Defending DevOps

DevOps is all about collaboration between operations teams and development teams. And the increase in collaboration should help enterprises to become more agile, eliminate waste, and automate, while also creating a more reliable infrastructure. It’s about rapidly iterating, continuously improving, and being more competitive.

[Agile doesn’t (necessarily) mean fragile]

And, as “”Dev” and “Ops” start working more closely together, some of the typical security controls and QA checks are at risk of breaking down, such as code change approvals and segregation of duty for certain operations. That’s why DevOps efforts can run into a wall with security teams and when the auditors start asking questions.

We covered a number of aspects of DevOps and security in our story Rugged DevOps: In search of the defensible infrastructure. Now, we’re going to take a look at DevOps and Audit.

Earlier this month, the initial review draft of the DevOps Audit Defense Toolkit was released. This toolkit aims to provide authoritative guidance on how DevOps organizations and auditors should consider conducting audits. According to its authors’ vision, the DevOps Audit Defense Toolkit will accomplish this by defining how organizations can better understand risks based on their business objectives, and correctly scope and substantiate the effectiveness of their regulatory controls.

To get an understanding of the DevOps Audit Defense Toolkit, we reached out to its authors—James DeLuccia, senior manager, advisory, EY; Jeff Gallimore, partner at Excella Consulting; Gene Kim, founder and former CTO at Tripwire and an author of The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win; Jeff Gallimore, co-founder at IT services firm Excella Consulting; and Byron Miller, systems engineer at Luminex Corporation.

“When organizations actually embark upon this [DevOps] journey, probably the number one obstacle they encounter is that their ’compliance guys will never let us do this,’” says Kim.

It’s not a surprise that enterprises moving toward DevOps encounter this. Audit requirements are unavoidable in regulated industries, and most organizations fall under some regulatory regime that oversees IT security: the Health Insurance Portability and Accountability Act, the Payment Card Industry Data Security Standard, Statement on Standards for Attestation Engagements (SSAE) No. 16, the Sarbanes-Oxley Act, FedRAMP, or any of a multitude of others. Auditors have a lot of responsibility when they are attesting to the controls a company has in place, so their concerns are valid when they start hearing about significant changes that affect regulatory controls.

[Rugged DevOps: In search of the defensible infrastructure]

Gallimore explains that enterprises moving toward DevOps practices often run into trouble when trying to apply “traditional” controls to their new practices. “It’s a very frustrating, painful — and potentially costly — experience if they can’t bridge the gap between what they’re doing (and why) and what will satisfy the auditors. If the enterprise doesn’t understand what the auditor is looking for and why, and the auditor doesn’t understand the new DevOps practices of the enterprise and their value, the auditor and the enterprise just talk past each other with neither one understanding the perspective of the other,” says Gallimore.

Obviously, this is not a situation that will drive many good outcomes. “This not only leads to misunderstandings between enterprises and their auditors, but also to audit recommendations and enterprise actions that are less effective or even counterproductive,” Gallimore adds.

What does all of this potentially mean when it’s audit time? “DevOps does not change a typical audit; instead, it changes the complete governance strategy of the business, starting at the entity level controls (governance; think COSO Cube) down through the control procedures (think change control monitoring),” says DeLuccia. “For the DevOps approach to succeed and achieved longevity, the expansion of the ideas must integrate with the business decisioning, internal audit, and information security.”

When the audit starts, that means that the traditional control procedures need to be updated or replaced by controls that take into account the increase in automation. “DevOps areas that are audited (successfully and pleasantly) are ones where the control objectives, procedures, and processes reflect the DevOps integration, automation, and tooling,” says DeLuccia.

The DevOps Audit Defense Toolkit helps enterprises better achieve that through improving communications among DevOps practitioners and auditors and helps auditors better understand IT, and its objection/response format helps IT to better understand and prepare for the auditor as their controls change. “The defense kit helps the enterprise understand ‘audit speak,’ including the language of risks, control objectives, and controls, and the auditing mindset generally. In this way, the enterprise can communicate to the auditor that it understands what the auditor is looking for and present relevant information in a context that will make sense to the auditors,” says Gallimore.

The DevOps Audit Defense Toolkit also helps the auditors to understand the perspective of IT and DevOps practices in more detail, Miller explains. That means seeing the “line-of-sight from the risks for the enterprise, to how the enterprise is mitigating those risks, to the evidence the enterprise uses to prove that its controls are effective at mitigating the risks,” Miller adds.

[How security can add value to DevOps]

The defense kit’s “objection/response” form helps IT teams learn how to better communicate that line of sight. “It lists typical auditor objections and concerns, explains what those objections mean and where they come from, and then presents a detailed DevOps-oriented response the enterprise can present to the auditor to satisfy the objection,” says Gallimore.

The DevOps Audit Defense Toolkit, still under draft, should be complete in coming months and the document can be accessed here.