When Moving to DevOps, Security Can Enhance the Ride

DevOps and continuous integration and deployment efforts boost productivity and agility, but it’s crucial that security moves along with the journey.

DevOps and continuous integration and continuous deployment methodologies are taking hold in enterprises everywhere – and those that do so are clearly more effective and efficient. If you’re not convinced of that, have a look at Puppet Labs’ State of DevOps survey for this year, and last, which found that DevOps organizations are deploying code 30 times faster and with half as many failures as non-DevOps enterprises.

Those DevOps outcomes, because of their focus on steady improvement through continuous collaboration and rapid iterations, are exactly what organizations are hoping to achieve. And from that, they reap a more agile and competitive enterprise.

Getting there is neither easy nor a straight line. Many organizational, technological, and security hurdles must be met to succeed.

In this post, we will look at a number of the most common security challenges.

It’s important to note that when talking about DevOps, security is a legitimate concern. As developers and operations teams start working more closely and quickly together, many of the typical security controls and quality assurance checks are significantly affected, or break down altogether. That’s why DevOps efforts often are met by major resistance with security teams.

The security dangers are twofold and both are consequential.

#1: The first is that security controls that have been in place for years won’t make the transition to DevOps. But pre-DevOps security processes don’t have to be left behind if they are scripted and automated. This means that when software performance and quality checks are automated, security scripts need to be included in that process – to check for poor software programming as well as anti-malware and related tests.

This is often easier said than done. It requires developers, Quality Assurance (QA), and security teams to access identical test environments to the production environment, as well as a sophisticated continuous integration pipeline. Also, the testing tools must be built, calibrated, maintained, and used just right – or security and compliance checks will break down.

#2: This brings us to the second danger. If the processes and security checks aren’t done well manually within an organization, the situation will only be made worse when automation is layered onto the development and operations management processes. That’s why it is important to put as much thought and effort into optimizing these processes as possible before building out any automated security and QA testing.

However, the news is not all bad. When done right, DevOps can actually help to greatly simplify security efforts.

For instance, when deploying to one’s continuous integration pipeline in units of code or application, sprints must be completed enough so that they can be comprehensively tested for security defects before the code is deployed. And, the fact is that integrating security and quality checks early into development is the “brass ring” when it comes to application security best practices.

Security isn’t the only enterprise control function that is transformed by DevOps; audit processes are, too. As you can imagine, when security teams flip out with automation, many auditors and regulators go apoplectic. And, the more enterprises I interview regarding their DevOps practices, the more I learn that security generally isn’t the top barrier to DevOps; internal and external auditors often are.

While not every organization will run into heavy regulatory hurdles, most do today. And if not today, there probably is a new regulation on the horizon that will have an impact on how IT processes are examined – perhaps a government agency or a large customer requiring heightened audits as part of its third-party security checks into your due diligence.

This is not a trivial responsibility for the auditors. The auditors have a lot of responsibility and pressure when they attest to the controls a company has in place, so their concerns are valid when they start hearing about significant changes that affect regulatory controls.

With all of this in mind, I recently interviewed the authors of the DevOps Audit Defense Toolkit (Toolkit is available here), which aims to help enterprises improve communications among DevOps practitioners and auditors, as well as to help auditors better understand IT, including the language of risks, control objectives, controls, and the auditing mindset.

The idea is to help IT teams communicate to their auditors about their controls so that the auditor understands how automated tests and controls, change logs, and other oversights put into place in the continuous integration and continuous deployment pipelines are all working together. And, when done right, just as security is improved in many aspects, so can regulatory controls be.

This is a fascinating twist: while DevOps, and continuous integration/delivery methodologies strain traditional security and audit processes, when done right it’s possible that these IT disciplines not only make certain that these organizations are maintaining their security and regulatory compliance levels but also improving upon these efforts in the very same way that DevOps and continuous IT improve agility.