Is DevOps a Threat to Compliance?
‘Traditionally, DevOps has been viewed as a risk by InfoSec teams,’ says Andres Wallgren at TechBeacon, ‘with its increased velocity of software releases seen as a threat to governance and security and regulatory controls.’
DevOps has its roots in the Agile Movement. It advocates that Development and Operations teams should work hand-in-hand to accelerate software delivery, increase business agility and reduce time-to-market.
George V. Hulme at CSO talks about typical security controls and QA checks being at risk of breaking down (for instance code change approvals and segregation of duties) – and says: ‘That’s why DevOps efforts can run into a wall with security teams and when the auditors start asking questions.’
It’s a fairly common view that DevOps and Regulatory Compliance are incompatible. After all, DevOpspromotes the rapid and frequent delivery of software, while Compliance is all about painstaking oversight of the change management process. No wonder DevOps enthusiasts often view Compliance as a serious drag on their creativity, and compliance teams see DevOps enthusiasts as dare-devil drag-racers.
The Wild West
The finance and healthcare industries face the heaviest regulatory burden. Yet, almost all organisations these days are subject to various government or industry regulations. For instance, all e-commerce businesses have to comply with the rules defined in the PCI-DSS regulations. That makes them reluctant to embrace DevOps and its philosophy of frequent changes at high speed.
‘One of the biggest concerns DevOps organizations fear,’ writes Tony Bradley at DevOps, ‘is that compliance and audit will create a “Wild West” ecosystem where everyone has access to all production systems and data.’
The reality in mature DevOps environments is that no one is granted direct access to production systems, and that every change is made through a central change management automation system with exacting version control. Automation helps to ensure consistent execution of compliant practices, and automation is a central tenet of DevOps. In other words, audit and compliance teams should regard DevOps as friend not foe.
Anders Wallgren makes the point that ‘many of the practices that come with DevOps, such as automation, emphasis on testing, fast feedback loops, improved visibility, collaboration, consistent release practices, and more, are fertile ground for integrating security and audit capability as a built-in component of your DevOps processes.’
He adds that by creating systems that are consistent, traceable and repeatable, ‘you ensure that your environment is reproducible, traceable and that you know who accessed it and when.’
Compliance and ‘The Five Ws’
Who and When are just two of the usual 5 questions asked by auditors:
- Who did that?
- What happened?
- When did it happen?
- Where did it happen?
- Why did it happen?
Auditors often ask an extra question: How did it happen? It’s usually left out because it spoils the neat symmetry of the basic 5. Typical questions in IT software environments tend to be:
- Who made this change to the application?
- Why did you move this dataset? Where did you move it from?
- Why was this change rolled back? What caused that?
A comprehensive DevOps automation platform will capture all of this data routinely, as it promotes software through the delivery pipeline from development through to production. This means you’ll always be able to find the answers to these questions. This is a huge step forward, and an advanced DevOps automation platform can actually simplify compliance reporting.
In fact, DevOps can play a vital role in streamlining compliance initiatives, and provide far more rapid feedback on compliance breaches than were possible under the traditional ‘Waterfall’ system of large and infrequent software releases.
Automated processes are consistent and repeatable, and deliver predictable outcomes. Since DevOps spans your delivery pipeline from development to operation, it makes it easy to trace all changes from development to release, changes that can be automatically logged and documented. This makes the job of auditors much easier and simplifies compliance all round.
If you’re using an advanced DevOps automation platform such as EnvironMint, it will provide ready access to a lot of detailed information that has been automatically logged in a separate repository for audit and quality assurance.
‘That, in effect, becomes your audit trail, your security log, and your compliance report,’ says Andres Wallgren, ‘all produced automatically, with no manual intervention or requirement to spend hours backtracking your processes and actions to produce the report.’
Faster Response Times
When you discover an application or database vulnerability, DevOps shortens your response time, because it gives you the means to develop, test, and deploy your patch much more quickly. The process is further simplified by the precise tracking that DevOps automation platforms provide of the state of your applications, environments, and stages in the pipeline.
This makes it much easier to identify which version of an application is deployed on which environment, including all the components in its stack. In turn that information makes it easy to pinpoint the component of the application that must be patched and to roll out your update, using the deployment process that is built into your DevOps delivery pipeline.
Policy as Code
The biggest challenge is how to express those compliance requirements in a form that can be coded. ‘By using something like Chef for instance, we’re able to specify a particular policy in a way that is automatable,’ writes Justin Arbuckle at DevOps. ‘In a way that we know is always going to be implemented every single time.’
Justin raises another challenge for large enterprises: ‘ knowing what you want to put in infrastructure as code.’ Treating infrastructure like software is part of the DevOps mindset, since that code can be managed with the same tools and processes used by development and operations teams. That’s why Infrastructure as Code is sometimes referred to as ‘programmable infrastructure.’
Describing your IaC (Infrastructure as Code) using DevOps tools lets you deliver software more reliably since configurations are consistently tested, shared and promoted across all your environments, from Development through Test to Production. The question is: how many compliance checks should you build into your delivery pipeline?
We could be talking about hundreds with entirely new systems, so it pays to focus on the vital checks. What is helpful here is that these tests are additive or complementary. One test might check which ports are open, while another checks which applications need access to them. This helps you build up a complete picture, by looking at a process from several different angles at the same time.
Compliance in the Cloud
The cloud holds additional challenges for corporate compliance, given the ease and speed of provisioning resources there. ‘Luckily, some smart folks looked at the possibilities of automating infrastructure and software deployments together as one,’ says Mike Kavis at the Virtualization Practice, ‘and at how agile we could become if we could control and automate the entire SDLC, and hence the DevOps movement was born to pull us out of all that chaos.’
First of all, you need to determine which applications and data sets can and cannot be staged on different infrastructures – on-premise, private/public cloud or a hybrid. For example, you might want to make absolutely sure that your customer database cannot be moved to a public cloud environment to ensure maximum security and privacy. Using IaC principles, you can build infrastructure provisioning rules into your code so that your delivery pipeline will automatically block the move of applications or data to ‘off-limits’ platforms.
In hybrid environments, it’s common for different stages of the SDLC to operate on different infrastructures. Again, you can ensure that security and compliance are consistently addressed using IaC, and build them into the policies that make up your continuous validation process. Similar complications arise in software development, which we explore in more detail in How to Achieve Consistency On-Premise, in the Cloud and Both.
Compliance is Boring
‘I’ll admit that security and compliance are not the most exciting topics,’ says Shridhar Mittal at DevOps. ‘If application development were a meal, they’d be the pile of lima beans you have to eat before you get to the dessert that is innovative feature development.’
If security and compliance are necessary evils, and DevOps helps to build them into the SDLC though automation, then DevOps is a good way to reduce the time you spend on the boring jobs and increase what you spend on the things you love. The by-product is that your applications will be secure and compliant when they reach production.
The best way to make sure that applications are secure by design is to incorporate security and compliance in the earliest stages of the SDLC. It beats the old way of waiting for your software to go into production before testing it for vulnerabilities.
It’s Cool Under the Covers
‘As the DevOps movement continues to grow and the adoption of quality and automation initiatives continues to attract fans,’ writes Mike Kavis at the Virtalization Practice, ‘we finally are starting to get a taste of governance that does not taste like week old leftovers. If you were to take a poll, you would find that DevOps is cool, governance is not. But under the covers, DevOps is enforcing standards, quality, automation, culture transformation, proactive monitoring, and all of the things that we have been trying to govern all along.’
‘Teams often follow human nature and take the path of least resistance,’ says Chris Haddad at DevOps Zone. Since DevOps automates so many processes and activities, it reduces the dependence on manual tasks and the chance of human error. DevOps can make ‘the right thing to do the easy thing to do,’ as Chris puts it. That’s music to the ears of auditors.