The DevOps Audit Defense Toolkit
Information Security and Compliance will often freak out when they see DevOps practices being used in large, complex organizations.
It doesn’t have to be this way
The absence of traditional controls such as segregation of duty, change approval processes, and annual SDLC approval stage-gates may result in uncomfortable conversations, inappropriate requests for control evidence that doesn’t actually exist, and, in the worst case, audit findings and the spotlight from senior management.
As DevOps practitioners, we must deal with auditors and Information Security, and our challenge is to show that we have built an effective control environment in our DevOps value stream that can prevent bad things from happening, as well as being able to quickly detect and correct issues when they do occur. In fact, if we do our jobs well, we may even be able to convince everyone that our control environment is even more secure than a typical non-DevOps environment.
However, making this argument effectively to auditors and Information Security is difficult.
Learn how to bridge the gap
We all know that the best-known DevOps work patterns may seem contrarian and counterintuitive: deploying smaller code and environment changes more frequently, relying more on peer review instead external change approvals, automation of most (if not all) of production deployments, performing testing as part of our daily work instead of at the end of the project, and so forth.
And that’s what the DevOps Audit Defense Toolkit is for. Written by Jeff Gallimore, James DeLuccia, Gene Kim, and Byron Miller, the Toolkit provides information for how to bridge the gap between organizations adopting DevOps practices and their auditors who have the responsibility of assessing whether the organization is mitigating risk adequately.
What’s in the Toolkit?
The document walks auditors through a top-down, risk-based approach of a fictitious organization (Parts Unlimited from The Phoenix Project, in fact!), showing the business objectives and risks that jeopardize them; reliance upon technology; the controls to prevent, detect, and correct; and how we evidence that those controls are working.
We expect that Dev, Test, Ops, as well as Audit and Information Security will use the Toolkit to make scoping decisions, design their control environments, as well serve as an example of how audits can be planned and executed to ensure those controls are operating as designed.
We believe the Toolkit to be consistent with the spirit and intent of the various compliance regimes we use as examples, including the PCI DSS, SOX, FedRAMP, and others. To join the ongoing discussion, check out the Google+ community.