In the last few years, DevOps has had a surge in adoption as organizations recognize the impact the set of practices can have between IT operations and development functions. By working together instead of in silos, developers and IT operations fuse together the elegance of application development alongside the functional deployment to infrastructure as code, a process forever synonymous with agility and scale.
DevOps practices and agile methodologies combined with the readily available and feature-rich services from hyperscalers bring fast-to-market capabilities and have given birth to a whole new generation of companies operating solely in the cloud.
But there was an unintended consequence. The combination of highly-automated toolchains and the power to continuously develop, test, and release became a nightmare for security teams. Laborious threat assessments and vulnerability tests, which are the cornerstone of security operations, often took place independent of the development cycle. DevOps culture pushed software innovation faster, but security testing could simply not keep up with the increased pace of feature creation and code release.
Nonetheless, the collaborative framework for DevOps started to expand with application and infrastructure security specifically in mind. Automated testing evolved to include security checkpoints baked into the release process and executed alongside the functional unit tests. Developers started to design applications with security testing baked into the continuous integration and delivery pipelines. As a result, the DevOps toolbox expanded to include security-oriented integrations with functions like SIEMS and SOCs. With the recognition that security partnerships were essential for success, “DevSecOps” was born.
It is easy to see the association between applications and servers/containers and the security layers which permeate through them. However, what about the network? What role do network administrators play in the DevSecOps process? In my experience, very little. Typically, flat networks meant that network operations had little to do when launching new internal applications. Even new external applications -- especially those moving to the cloud -- could all be scripted, or made available through load balancers often independently managed by applications teams.
The world needs DevNetSecOps
Would the three-legged stool ever evolve to a four-legged stool? Or a three-headed chimera to a four-headed one? Is there a need for a DevNetSecOps paradigm? Absolutely.
The castle-and-moat security and the traditional hub-and-spoke network designs are eroding. Traditional flat networks, even those with highly segmented VLANs are vulnerable to attack. Sophisticated malware traverses the ironically named trusted networks, laterally moving through objects internally and penetrating deeply across physical and cloud environments alike.
Zero trust answers this problem by putting identity at the heart of a zero-trust platform, restricting vertical and lateral movement. Embedding authentication and validating users against business policy prior to a connection ever being established ensures that users only have visibility to authorized applications. The wider application catalog is dark to them and they are unable to browse the network.
Companies are now rushing to adopt zero trust for securing access to their applications. As a result, network administrators are increasingly becoming much more involved in the upper layers of the OSI stack and have a greater awareness of user behavior, identity, and application entitlement.
Internationally renowned security technologist and author Bruce Schneier and RSA Security described an extension to the OSI model to recognize the importance of the user in the technology stack definition: Layers 8-10. Administrators like to use the term "layer 8 issue" when it comes to errors caused by a user. These are most notably users who do not master the handling of IT technology well enough from the admins' point of view and who make avoidable mistakes.
Setting aside the obvious chuckles and imagery conjured by the layer-8 association, zero trust is shining a light on the importance of this layer and the users themselves. Zero trust moves away from a protective layer just around the network to one that envelops an individual, shifting the focus of brokering connectivity within an IP range or clusters of interconnected network segments to that of a single person. A decade ago, IT professionals would have fallen off their chairs if you had asked them to regulate connectivity on a per-user basis. But that is exactly what zero trust accomplishes.
This seismic shift in the connectivity paradigm means that application developers need to adapt their test and release processes to recognize zero trust or risk of becoming blocked. Building strong partnerships with network professionals and leveraging APIs within zero trust platforms can restore the balance as it has done with security teams in the past.
In this way, it is perhaps not completely unreasonable to deem DevNetSecOps as a realistic upgrade for DevOps teams of the future. Like it or not, zero trust will replace antiquated castle-and-moat security as the dominant secure connectivity exchange. The positioning of network teams and their role in the release chain will undoubtedly need to evolve.
What to read next
Succeeding with a perimeter-less, multi-cloud environment
Simplifying Security: Automation is the Way Forward with ZPA