DevOps is now being met by the OpsDev movement, which some say is just NetOps with SDN thrown in. But what of our old friend, security? SecDevOps (or is it DevSecOps) just doesn’t roll off the tongue like any of the aforementioned movements in automation and infrastructure-as-code. The cynic in me feels like this digital transformation is once again trying to bolt security on after the fact, having learned nothing from 20 years shoehorning security into physical data centers. Dashboard visualizations and python scripts will no more save us than blinky lights in a rack, but integrating security policy and controls into DevOps process has great potential in finally having security built-in from the start.
In previous columns, I’ve written about security being the missing link in Software Defined Networking (SDN) and security service chaining. Each of these articles explored the possibilities of applying more adaptive security controls which are able to react more dynamically to changing threats. While programmable, API-driven security policy sounds promising, there’s the distinct problem that change controls are already the single biggest problem for security in traditional infrastructure. In many organizations, the process for feeding vulnerability findings back into actionable security policy are already lacking. In many cases, the security infrastructure has available APIs which are left unused.
How will SecDevOps bridge these gaps in both process and policy?
Embracing SecDevOps as a component of a larger DevOps culture and philosophy enables us to seek out tools and skills that would leverage existing API opportunities and drive decisions toward a more fully-integrated approach to SDN. These new skills and tools may even be an extension of existing practices. For example, many infosec organizations employ taps and bypass switches to gain visibility with minimum disruption to the network infrastructure. SDN further enables this same practice and behavior, and SecDevOps would help automate and orchestrate any needed changes in the security service chains. The security service chains can be neatly defined based on multiple criteria, of which one basic example could be source IP reputation and geolocation. Static rules that allow or deny based 5-tuple access control lists (ACLs), defined by source IP and port, destination IP and port, and protocol are complex, brittle, and lacking in specificity. Imagine instead being able to define the depth of security inspection based on who the user is, where in the world they are coming from, and the reputation of that endpoint.
The latter approach is truly risk-oriented, applying more and deeper security controls and countermeasures based on what is known about the context of the connection. However, this benefit is just the tip of the SecDevOps iceberg. Digging deeper, there are opportunities such as those described by Dinis Cruz in his (evolving) book SecDevOps Risk Workflow. In the book and his excellent OWASP talk, digs deeper into how we might scan and feed found vulnerabilities back into the development and AppSec processes we already have in place. The difference from existing processes is that automation and orchestration reduce errors and time it takes to integrate that feedback.
Cloud and virtualization have enabled us to treat the entire infrastructure as a fungible asset. If something breaks down or fails due to a change, don’t troubleshoot, just nuke-and-pave from the last working template. That same fungible nature of these new software-defined infrastructures can enable us to continuously test and improve our security posture by defining new paths and policies based on risk and emerging threats, and quickly falling back in the instance of a false positive or other misstep in the deployment of new security controls and countermeasures. We will need to develop and acquire new skills to take full advantage of these opportunities presented by SecDevOps. The good news is that an organization has already embraced (or begun to embrace) DevOps will have people ready and willing to share their experiences in transitioning to a new and more dynamic way of managing the infrastructure.
As a Senior Security Solutions Architect at F5 Networks, Brian McHenry focuses on web application and network security. McHenry acts as a liaison between customers and F5 product teams, providing a hands-on, real-world perspective. He is a regular contributor on InformationSecurityBuzz.com, a co-founder of BSidesNYC, and a speaker at AppSecUSA, BC Aware Day, GoSec Montreal, and the Central Ohio Infosec Summit, among others. Prior to joining F5 in 2008, McHenry, a self-described IT generalist, held leadership positions within a variety of technology organizations, ranging from startups to major financial services firms.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.