DevSecOps and Formal Security Programs: Friends or Foes?

Thursday October 05 2017

DevOps is supposed to be fast and efficient. Formal security programs, such as those based ISO 27001, are not typically thought of in those terms. So how can these two work together? Let’s look at the goals of each of these, and how DevSecOps can be achieved.

The goal of DevSecOps is to efficiently embed security processes as part of the collaboration between the Dev and Ops teams. The goal of the security program (using ISO 27001, including control descriptions in ISO 27002 as an example), is to comprehensively define what is needed to address risk in many areas, including areas that are involved in Development and Operations.

Now you may be thinking, wait a minute, I just want to include security testing as part of my DevOps process. Doesn’t that give me what I need for DevSecOps? Well the answer to that is not really, or at least not really good. Think about what you want to address with security, its more than just testing. Yes, you need to test your web applications for vulnerabilities like the OWASP Top Ten, but that is only part of the equation. Most breaches (80 to 90%) are caused by human error that can happen in many places, so shouldn’t that be a consideration too? DevSecOps is a great place to address human error because it covers the lifecycle from design to operations, and each part of the life-cycle has some amount of human involvement where errors might occur, resulting in vulnerabilities that could be exposed.

ISO 27001/2 comes alongside by defining controls you can build into your DevOps processes. These controls include addressing your application vulnerabilities, plus encompass areas such as Role Based Access Control (RBAC), system design, testing (think of security testing as part of your QA testing), deployment and operations, and an auditable, measurable process that shows how well the controls are operating. All of these work together to reduce human error and increase the maturity and effectiveness of your security.

Notice that we have not mentioned automation yet. That is usually the first topic that comes up when DevOps is discussed, but when planning for DevSecOps, the first thing should be to carefully define all your processes and how security fits in, then look at where to apply automation. You will probably find areas that rely on implicit assumptions about trust. These are likely risk areas where you need to apply controls. That’s why defining the process should come first, and then increases in efficiency with automation as needed for each of the parts.

Putting the “Sec” in DevSecOps should be one part of your overall security strategy, and when done right can give a well-defined model to reduce risk and address the human factor in security.

Joe Slone is the Vice President of Global Architecture and Security (CISO) at 1WorldSync. Joe Slone will be speaking at Cyber Security Chicago on DevSecOps and Beyond: A Cybersecurity Journey.