In this third chapter of my “Ticking Time Bomb” series, I’d like to explore how existing approaches to cloud security create problems with an emerging but important security discipline called DevSecOps. If you’d like get caught up, you can check out my first chapters on cost challenges here and scale challenges here. There will be a forthcoming and final chapter that addresses issues of complexity.
DevSecOps, or Development, Security, and Operations, is an extension of the DevOps practice that incorporates security into every stage of the CI/CD process. It is both an approach as well as a set of tools and practices that enables tight collaboration between security teams and DevOps teams. It is also a cultural mindset built around communication, transformation, and shared responsibility.
I hosted Mohamed Ghassen, Sr. Security Architect at SAP, on a recent Altitude podcast, and he does a fantastic job of unpacking the benefits of the “secure by design” approach of DevSecOps and discusses why this approach is so necessary for modern cloud applications.
In short, DevSecOps is critical in cloud because unlike the data center, cloud environments are constantly changing and growing at a rapid pace. Security practices and policies must be both endemic and dynamic. You can check out the entire episode here.
The Challenges with DevSecOps
While DevSecOps sounds great in theory, it is difficult for many enterprises to implement in practice. Security pros are not usually skilled up with DevOps tools, and conversely, DevOps pros are not familiar with enterprise security systems. For these teams to collaborate effectively, business leaders need to embrace new solutions that use abstraction as a method for creating a shared policy model that both sides can understand.
One of the biggest challenges security engineers face while working with developers is trying to turn network security policy – a rather static convention – into a templated system that supports automation, the life-blood of the cloud application lifecycle. Said differently, CI/CD pipelines make conventional security very difficult, because security teams don’t know how a given policy will work until the application is deployed into the network. Additionally, existing firewall policy management is allergic to agile development frameworks. What security teams need is a way for DevOps pros to introduce and test the efficacy of a given policy before deployment, then make this process repeatable.
Developers know how their application is architected and behaves but are not responsible for testing these requirements against the actual firewall behavior that results. For example, a developer knows that her middleware needs to accept inbound API calls from the front end, make backend calls to a private database, and replicate data to a cloud SaaS service, but she doesn’t know the exact path the calls will take across the network, nor how many security devices are responsible for the traffic in-between. When she tests the code in her lab, all the calls work, but is she confident that they will work when she deploys the changes into production behind the firewall?
The Value of Strategic Abstraction
This is where abstraction becomes so important. What the developer needs is a symbolic map that links the current policy state of the network to the design and behaviors of the application. If the front end needs to send API calls to the middleware, then she should be able to test this function against a variable called WEB-API-PROD which contains, in abstracted form, the required policy of the production network as configured by security.
Conversely, the security team does not need to know how, when, or where this application will be deployed. The team just needs the assurance that when it is tested, deployed, or changed, it will fall under the policy as described by WEB-API-PROD, which carries with it all the requirements for network access, compliance, logging, and auditing. Furthermore, if the application environment changes or grows, the WEB-API-PROD policy should follow it.
For this system to work and scale correctly, it must support the following three elements:
- Attributed-based security
- Global automation
- Dynamic policy mapping
Let’s discuss these elements one at a time.
Attributed-based security means that the cloud-native objects that comprise a modern cloud application, such virtual machines, VPCs/VNets, subnets, PaaS instances, etc., must be understood and organized through some sort of API-driven mark-up language. In cloud, tags are conventionally used as attributes here, either the native object tags that the provider supplies, custom tags, or some combination of these things. Tags are realized through key:value pairings and accessed via cloud-native platform APIs.
The important thing here is that IP addresses are no longer used as the attribute; in cloud, IP addresses are problematic due to reuse, lifespan, and obfuscation. Developers think deeply about their applications based on the role, function, or state of the various components. They rarely (if ever) think about their applications based on the IP address of the network underneath. Many security platforms in cloud still use IPs as the common identifier to map network security policy to an application. The risks and difficulties of this approach in a DevSecOps context are self-evident.
Global automation means that these tags are set as parameters in standardized templates that are used deploy and maintain application environments. In a DevSecOps motion, security teams and developers should collaborate on which tags are blessed for a given template, and which templates are blessed for QA, pre-production, production and so forth. The developers will understand the application calls, and the security engineers will understand the policy requirements.
This gives developers the opportunity to introduce security policy as a parameter-based value in their CI/CD pipeline, and it gives security engineers the ability to enforce policy as part of an agile framework. When the code is tested, it will have the necessary policy embedded into the lifecycle management system before the changes hit the production network. Errors and issues with policy can be detected by developers, and security engineers can help to adjust the policy prior to any product deployment. This is one of the key advantages of DevSecOps.
Dynamic policy mapping means that the cloud security platform that discovers the attribute-based tags keeps an accurate inventory of each paired object and can enforce security policy at various levels of the network and application stack. For this to work correctly, the enforcement engine must be embedded in the network data path, capable of security policy orchestration at the level of the cloud service provider (CSP), or both in combination. In this way, as application environments are deployed, scaled, or deleted, the policy enforcement will automatically follow along.
The important thing here is cloud security teams are freed from having to gate each step of the CI/CD processes to apply policy correctly. The network, and all the relevant objects that reside within, have been abstracted into a common framework that allows for collaboration, app-centric thought, automation, and increased agility.
Of course, there will need to be an initial mapping of a given set of policies as they apply to certain tags. As security engineers and developers work together, they can discover what application components are involved, the type of traffic they will generate, and which policies need to be applied. The whole point is that no one needs to think about the network anymore – this is the job of the platform itself.
Where Do We Go from Here?
I had a fun and informative discussion about the emerging field of asset-based security with Toby Foss, Dr. of Network Operations at Informatica, and Chris McHenry, Head of Security at Aviatrix during a recent Altitude podcast. We spent a lot of time examining why cloud networks and agile processes make traditional security in cloud so difficult, then discussed how a distributed systems security platform, coupled with a DevSecOps approach, can lead to greater success for both security teams and developers alike. That episode, entitled “Can We Achieve Distributed Security at Scale in Cloud?” can be found in full here.
Regardless of your role, if you are interested in exploring DevSecOps for your business, I encourage you look at the Aviatrix Distributed Cloud Firewall. It uses attribute-based security, cloud orchestration, distributed network enforcement, and automation to create an intuitive, agile framework which enables close collaboration between security and DevOps teams during the entire CI/CD process.
We’re also glad to discuss strategies for implementing DevSecOps in your organization and how Aviatrix can help. Let’s set up a time to talk.
