Intent-Based Security: The Next Step for DevOps
A new model is emerging that will give developers the power to implement security themselves based on intent
For decades, application development organizations have cared about two things: speed and quality. These goals have led to new development processes, with DevOps being today’s state-of-the-art methodology for rapid, high-quality development. In recent times, though, an interloper has crashed that party: security. It’s not enough today to simply deploy high-quality applications as quickly as possible. They also must be secure, to avoid adding real estate to the enterprise attack surface and becoming yet another statistic in the data breach epidemic.
This raises a conundrum, because developers historically have been loath to slow their processes to accommodate the time requirements of the security team. This issue has been exacerbated by the cloud, because it has never been easier to deploy and update applications, which further fuels the “need for speed.”
And yet, not incorporating security into the development process is like cutting safety engineers out of the airplane manufacturing process. Retrofitting a post-manufacture Boeing 767 to meet safety regulations would be prohibitively expensive and far less effective than designing safety systems and features into the original product plan. The same dynamic applies to applications—deploying them and then asking the security team to implement the proper controls after the fact is a common practice, and far more expensive and less effective than designing safety into the DevOps process. And yet, when DevOps lives in a world of “continuous development” while security is often stuck in the world of the six-month development cycle, one can understand how this situation has come about.
What is needed is for DevOps to figure out how to embed security into their processes without exacting a delay tax, much in the same way that safety engineers are embedded into aircraft manufacturing. And, some DevOps organizations are doing just that, moving to a DevSecOps model, where security teams are fully integrated into the DevOps process, so 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 roadblock 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 the security team 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. Today, however, a new model is emerging that will give developers the power to implement security themselves, while adhering to “guardrails” established by the security organization. It’s called “intent-based security.”
Implementing Intent
Handing off security implementation to the DevOps team may sound like lunacy to many security professionals. However, “handing off” is a misnomer. It’s more accurate to say that intent-based security gives DevOps self-serve security capabilities. Like other self-serve security functions (password resets, for example), the security team sets the parameters for implementation based on the intent of the application or system, and DevOps implements it as part of their process—making DevSecOps a seamless process.
If security professionals can understand the “intent” of all assets on the network (for example, the intent of a CRM application is to provide access and functionality to salespeople and marketers), then they can templatize the rules that need to go along with protecting those assets. Once that is done, rules can be applied easily to any new DevOps deployment. 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 provide a good understanding of the inventory of assets, and then Traffic Flow Analysis and Access Path Analysis help to establish how these assets are behaving in the context of the network.
Classify communications protocols: There may be particular protocols (e.g., SMB, Telnet) that never should appear on the network or between certain assets. These can be classified, and if they are spotted on the network, it is clear 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. For example, compliance requirements for each asset must be translated into relevant rules and access controls that conform to the security intent. Likewise, business goals must be translated from plain English into syntactical strings of rules. Within the context of intent-based security, machine learning can be used to execute this process, rather than traditional manual methods. This process dynamically generates rules without the intervention—and resulting delays—of engineering and security teams.
And finally, shifts in security mandates need to trigger and automate translation, from intent to implementation. These shifts often arise from previously underappreciated risks being elevated to significance, and they must be addressed as quickly as possible. Using intent to automate the process enables continuous security, even in changing risk landscapes.
The Dawn of DevSecOps
We can see how intent-based security actually creates 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. This is causing a much-needed and long-awaited change in the relationship between DevOps (and its predecessor development organizations) and security. And, with the ever-increasing velocity of DevOps and the ever-expanding attack surface in enterprises, we are nearing the day when eliminating the gaps between DevOps and security is a requirement, not an option.
The only way to achieve this “collaborative future” is 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 DevOps morphs into DevSecOps, and becomes the standard for enabling secure business.
