Putting the ‘Ops’ in DevSecOps: Why It’s Hard and How to Do It
By now, you’ve almost certainly heard about DevSecOps. You understand why baking security into DevOps leads to more secure software delivery.
Yet, despite all of the attention that DevSecOps is now rightly enjoying, it can be easy to overlook one key dimension of DevSecOps: the Ops part.
If you don’t give Ops enough love when developing your DevSecOps strategy, you risk shooting yourself in the foot. Here’s why, along with tips on how to ensure that your DevSecOps processes extend properly into Ops.
A Brief Definition of DevSecOps
Put simply, DevSecOps refers to a software delivery strategy that makes security as integral to the delivery process as development and IT Ops. According to the DevSecOps mindset, not only should security considerations factor into every stage of application delivery, but the various groups involved in application delivery also should understand and be prepared to help address security needs, even if security is not their specialty.
The DevSecOps concept originated in an effort to extend DevOps thinking (which emphasizes seamless collaboration between developers and IT Ops teams) to security, and to break security out of the silo that traditionally cordoned security practices off from the application delivery process.
Why Ops is the Hardest Part of DevSecOps
When it comes to implementing DevSecOps, it tends to be more difficult to integrate security into the Ops part of the software delivery process than into the Dev part.
After all, when it comes to designing and writing code, it’s easy enough to help developers take security into consideration without stepping on their toes or disrupting their standard operating procedures. To bring security to the development part of the delivery pipeline, then, you need simply to teach your developers about security best practices, and ensure that they are working closely with security engineers.
But it is trickier to integrate the work that Ops engineers do and the work that security engineers perform without creating a clash between the two groups. Traditionally, Ops engineers spend much of their time monitoring software in production environments and looking for anomalies (such as a spike in CPU usage or unusual levels of memory consumption) that could signal a problem. When they detect an anomaly like this, their natural tendency is to assume that it’s the result of an infrastructure problem or software misconfiguration. Security breaches are not their first thought.
Security engineers think about anomalies in the opposite way. To them, anything that is out of the ordinary should be treated as a potential breach (or attempted breach) above all else.
This means that to get Ops engineers to help mitigate security issues as effectively as they address software stability and performance problems, you need to teach them to rethink the way they analyze environments. Security engineers, too, need to learn to take a different, broader approach to the way they interpret data from application environments.
The conundrum described above is part of the reason why DevSecOps is so important. If you leave IT Ops engineers and security engineers out of sync with each other, you’re at risk of having them operate at cross purposes, getting in each other’s way and not doing a good job of either securing or managing software.
Giving Ops the Security Visibility It Needs
That’s the challenge with the Ops part of DevSecOps. What’s the solution?
In a word, visibility. When your Ops team has the tools and skills that it needs to recognize security problems as readily as it detects stability and performance issues, your engineers can address both types of needs effectively.
Achieving the right level of security visibility for Ops engineers requires automating security monitoring and analytics as much as possible. Your Ops engineers may not be security experts, but with the right tools, they can effectively find and interpret security-related anomalies, and distinguish them from other types of incidents.
Security visibility for Ops also means deploying monitoring tools that can establish dynamic baselines. There may be no such thing as normal in your application environments, especially if you deploy software using dynamic technologies such as containers and microservices. For that reason, your tools need to be able to establish what constitutes a normal operating baseline at any given moment, and recognize how that baseline changes along with environmental factors. Without the ability to establish dynamic baselines, it becomes very difficult to determine what is a real anomaly, and what is a legitimate resource scale-up or service shut-down.
Teaching your Ops teams to use security tools toward this end also requires some education, of course. But that’s why DevSecOps means your security engineers should be working closely with your Ops team at all times. When you have the right tools in place and security engineers who can explain how to use them, teaching your Ops team to take a security-minded approach to software management is eminently doable.
