In 2016, I was convinced that DevSecOps was the way forward for the network defenders of the world to secure its infrastructure and its applications. Two books convinced me that it was so: Gene Kim’s famous novel, The Phoenix Project, and Google’s Site Reliability Engineering. I began telling newbies and veterans alike that in the near future—say four or five years—our infosec teams wouldn’t consist of security experts who dabbled in coding. They would consist of coders who knew a lot about security. The IT teams and infosec teams would combine into this much more robust DevSecOps team that would manage deployments and updates of its infrastructure as code combined with the resiliency required to survive catastrophic outages or material cyber-events.

DevOps and Infosec—Oil and Water

Four years later, I can truthfully say that I was completely wrong. We are no more close to realizing this vision than we were when I first read those two books. Much to my chagrin, the network defender community didn’t embrace the concept. The big reason is that most of us in the network defender community aren’t coders, and it is difficult to build infrastructure as code if you don’t have anybody on the team with that skill set. Don’t get me wrong. There is absolutely a small subset of the network defender community who are brilliant coders. I’m just saying that the bulk of the community is not. And even for those that do code, the DevOps teams use coding tools that the infosec folks aren’t familiar with. They have strange names like Docker, Kubernetes, Puppet and Ansible, and don’t sound anything like the typical infosec languages we prefer to use like Python, JavaScript and PowerShell. The two teams, DevOps and infosec, are living in worlds that don’t readily mix—just like oil and water.

DevSecOps in the SOC

But we have started to see progress in an area that I did not foresee: the Secure Operations Center (SOC). The big problem that SOC teams are facing is the extremely high volume of alerts that they have to review. It is not uncommon to have over a billion alerts show up in the SOC over a period of 90 days. If you are a Fortune 500-size company, it’s even bigger than that.

Security Orchestration, Automation and Response (SOAR) tools started to emerge for SOC use in 2018. These tools purported to solve the telemetry volume problem. Through application programming interfaces (APIs), the SOAR tool can connect to practically any kind of networking equipment and security stack tool deployed on your network, automatically collect telemetry from that device in terms of health and welfare, and security alerts, and provide the SOC team with the ability to easily write code that handles that telemetry in a prescribed way; things like save for the future, delete or escalate to a human for review. This has enormous implications.

Many SOCs are doing this SOAR thing now, and many others are anticipating that they will be soon. They most likely don’t consider the use of SOAR technologies as a DevSecOps function, but it absolutely is— infrastructure as code but for the security infrastructure. And that is the first step. Get the idea of the DevSecOps philosophy into the minds of the infosec teams, that automation will drive everything, that coding is an essential skill for everybody. I may have been wrong about my DevSecOps prediction four years ago, but we might achieve the same goal through another path—through the SOC.

Contributors: