The Emergence of The 3 Towers: DevSecOps

13 May 2016 The Emergence of The 3 Towers: DevSecOps

I had the opportunity to attend AWS bootcamp in Sydney a couple of weeks ago. The session I chose to attend was entitled “Securing Cloud Workloads with DevOps Automation”. There were many interesting concepts discussed, all hinging around the new term ‘DevSecOps’. In this post, I’d like to talk about what this is and how it relates to traditional DevOps.

DevOps

It’s probably best to start by revisiting exactly what ‘DevOps’ means.

DevOps stemmed from the merging of two major fields- Development and Operations. In the not-too-distant past, it was also known as “Agile Systems Administration” or “Agile Operations”, and therefore can be seen as an outgrowth of Agile practices.

“Dev” covers the research and design, programming and testing of software. “Ops” is a blanket term for systems administrators, release engineers, database administrators, network engineers and other support-based roles.

Back in the day, when IT was just finding its feet, the Dev side was thought of as being the creators and the Ops side was thought of as being the maintainers. The lack of efficiency in partitioning these two individual streams was the core driver behind merging them.

The formalisation of DevOps as a discipline has increased efficiency in both development and operations work, by encouraging parties from both sides to work as one team throughout the product lifecycle.

Competing Forces

From the perspective of a business, having two separate teams created competing forces by assigning different responsibilities to developers and operations staff. These competing forces were a significant cause of delay in the achievement of business goals, especially in an increasingly agile world.

Software development has significantly progressed over the last few years, as the IT community has shifted from traditional waterfall methods to ‘lean’ and ‘agile’ processes. This shift has improved the way in which the application lifecycle is managed. Whereas we used to think about delivering software as part of an application lifecycle, we now regard delivery as being a much more continuous process.

To achieve this, changes had to be made at multiple levels of the process.

Initially, agile practices –  for example, managing smaller, incremental releases of the product instead of large monolithic releases – had to be adopted. Agile methodologies increased the frequency of builds, testing and deployments. To support this, a DevOps mindset had to be in place to maximise automation opportunities.

Indeed, continuous delivery is such a time-critical process that automating tasks becomes a significant factor. Fortunately, cloud technologies are particularly well suited to this automation. For example, consider this diagram showing how AWS can fit into a continuous delivery lifecycle:

We’ll return to this diagram shortly.

Security

As business demand for DevOps, agile and cloud services grows, security has become a major concerning factor. Indeed, traditional security processes have become a major roadblock to continuous delivery pipelines, as they need considerable amount of time to prepare and action.

In the past, security-related activities started once a system had been deployed into some sort of protected environment. Then, its security vulnerabilities could be determined by penetration testers and security staff. Next, defects were corrected by business operators before the system was released into the wild.

This approach required only a limited set of skills, and generally didn’t affect a system’s broader development cycle. But a process designed this way only worked well when the pace of change was that of a traditional waterfall processes.

However, once we introduced rapid iteration, operating security this way became flawed and created inherent risks within the system.

In today’s world, we know that it is almost impossible for a security team to add any real value to the development cycle at the end. If a security team makes any major alterations to the system at that stage, it may cause major delays in system delivery dates.

In a continuous delivery environment, releases are very frequent. The creation process becomes faster and faster, and it becomes more and more difficult to apply traditional security practices to the life cycle.

DevSecOps

To resolve this issue, we have to make security a first-class citizen within the DevOps world. It has to become a service that lends a hand to business operators, supplying them with tools, processes and people to help with security decision-making throughout the development lifecycle.

To achieve this, security engineers form part of a ‘DevSecOps team’, helping to ensure that every release is secure. DevSecOps engineers are trained to develop processes and tools that continuously probe for security defects before attackers might discover them and bring the system down.

Taking the DevOps cloud environment that we introduced earlier, here’s how we might augment it to include security-related practices:

DevSecOps is a mindset that leads the IT industry towards a more secure future. Security must be a concern every part of the business, and every process that is being used. By introducing tools to discover flaws, defects and security exploits, and running those tools continuously though the entire development lifecycle, we maximise or our chance of having a secure and exploit-free product.

Conclusion

Like development and operations, security now forms a critical part of any IT business. However, there is a natural tension between the goals of each of these streams.

Developers and operations people have already developed techniques for working together to navigate rapid change – collectively, we call this the practice ‘DevOps’. Security specialists need to join this union and learn to make security a key part of agile processes. Key to this is measurement, rapid feedback and automation – all techniques that DevOps has already mastered.