Rules automation puts the “Sec” in DevSecOps

Imagine if safety were an afterthought in automobiles: Manufacturers would create a pristine new car and then hand it off to the safety team…which would bolt airbags onto the dashboard, seatbelts onto the side panels, and bumpers onto both ends. And if they were under a lot of pressure to get the car to dealers as quickly as possible, they might just leave off some of this stuff, ship the car to the dealer, and tell the safety guys to add any remaining safety gear when they have a chance…even if someone is already using the car.

If this sounds preposterous, it isn’t – in fact, it’s exactly how security has fit into the application development process for decades. And with the emergence of Agile and DevOps, the problem has gotten even worse.

Security is still tuned to work at the speed of the old “six-month software release” world, while developers are operating at the breakneck speed of continuous delivery. DevOps is optimized for a world of constant change, while security still views change as a threat. This friction leaves organizations with two undesirable choices: slow down continuous delivery so security can do its work, or just keep pushing out changes and let the security team figure things out on their own.

What is needed is for DevOps to figure out how to embed security into their processes, much in the same way that safety engineers are embedded into automobile manufacturing. Safety equipment is integrated into original product designs in that industry, so our car interiors look perfect, even though they are surrounding us with airbags, and installing those airbags adds a trivial amount of time to the manufacturing process. Imagine if DevOps were able to integrate security in the same fashion? Think “security by design and default.”

Some DevOps organizations are doing just that, moving to a DevSecOps model. In this model, security teams are fully integrated into the DevOps process, where they can embed security functions and controls throughout the application development cycle. This makes security part of the overall DevOps workflow, rather than being a speed bump or an afterthought.

However, team integration can only go so far. In situations requiring intensive manual labor, security can continue to be a road block to DevOps. Writing security rules for application deployments has been one of the more vexing areas of manual labor in attempted DevSecOps initiatives: the application or update is ready to go, but security has to slow things down while it writes the rules for enforcing policy. Historically, this has been a manual “reinventing the wheel” process that is slow and frustrating for the DevOps organization.

However, a new model of “intent-based security” is changing the game for how rules are generated and applied. If security professionals can understand the “intent” of all assets on the network, then they can templatize the rules that need to go along with protecting those assets. Once that is done, rules can be readily applied to any new DevOps deployments. They can even be applied directly by application owners and line-of-business leaders, with security simply guiding the templates that govern access to ensure security intent is not compromised.

Establishing intent is a three-step process:

Inventory and analyze assets: Recursive Network Indexing helps you to have a good understanding of your inventory of assets, and then Traffic Flow Analysis and Access Path Analysis help you to see how these assets are behaving in the context of the network.

Classify communications protocols: There may be particular protocols (e.g., SMB, Telnet) that you never want to see on the network or between certain assets. These can be classified, and if they are spotted on the network, you know that the original security intent was lost. Using this classification, protocols can be paired with assets and a reasonable security profile can be created (e.g., “this asset class is never permitted to use this kind of protocol”).

Overlay context: Business context must be factored into determining security intent. Without context, there are only data points with no knowledge about how they relate to each other.

Once security intent is determined, it is then possible to create the framework for creating and implementing rules templates that translate intent into policy enforcement. Key considerations include:

Compliance: Compliance requirements for each asset must be translated into relevant rules and access controls that conform to the security intent.

Business requirements: As with compliance standards, business goals are written in plain English. With the traditional approach, security and engineering teams would take such business goals and transform these into syntactical strings of rules conforming to a machine’s specific demands. With intent-based security, machine learning does the translation so these teams don’t have to write rules any more – instead, they can be dynamically generated.

Security mandates: Security mandates begin with a particular risk that has been uncovered or was previously underappreciated. When security mandates shift, this shift needs to be translated from intent to implementation.

We can see from these steps that intent is actually an abstraction layer that enables collaboration by both security and non-security personnel to generate and enforce rules without having to undergo a laborious manual rules-writing process. We are rapidly nearing the day when eliminating the friction between DevOps and security will become a requirement, not an option.

The only way to do this will be to move to a model that makes it easy and even desirable for DevOps to embed security into its processes. Self-help and automatically generated security rules will be a major step forward as DevSecOps or its cousins become the standard for enabling secure business.