Embracing Security Intent

Embracing Security Intent and IBNS

What is IBNS, and what are its advantages? 

Intent-based network security (hereafter “IBNS”) helps with several areas that are of top concern for enterprise security leaders:

  • Software-defined networking
  • New application deployment
  • Moving applications across platforms (e.g. on-prem, cloud, virtual, containers)
  • Orchestrating policies to fit the network need

It does this by decoupling intent from implementation.

In this model, intent becomes the bedrock of policies and controls, and implementation serves as the device-specific enforcement of the declared security goal.

Basically, you are navigating to a place that’s much less about writing rules and much more about automating processes rooted in the desired intent of a device or path.

Obviously, this is a large undertaking for any organization, because it’s drastically different from current-state thinking. In reality, though, intent has always been the bedrock of data protection.

The question becomes how do you turn an intention into something that’s technically enforceable.

How to Turn Intent into Enforcement

Deduction of Security Intent

This is a three-step process:

  1. Begin with assets
  2. Classify communications protocols
  3. Overlay context

Begin with 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.

Example: “This web server has historically only received traffic from these sources, only on these protocols, and only under these circumstances.” Now, all the rules in my network’s rulebase have a new character and aspect. They reveal to you the statistically likely intent that was originally planned.

Classify communications protocols: There can be particular protocols (e.g. SMB, Telnet), that we never want to see on our network or between certain assets. We can classify these and determine if those protocols are in current operation. When spotted, we now know that the original security intent was lost.

Using this classification, we can pair the protocols with the assets and judge their history in context of a reasonable security profile for the asset, i.e. “this asset class is never permitted to use this kind of protocol.” If you then see that protocol in use with the asset in question, you have the photographic negative of the security intent.

Overlay context: When deducing the existing security intent, we need context. Without this context, we simply have data points plopped down on a screen without any real knowledge of how they relate.

Declaration of Security Intent

Take a look at this quote from the SANS Institute’s David Jarmon:

It is important to first define what a security policy means with regard to an organization, or in other words, how much security is needed.  A security policy should be designed around the critical [assets] that are identified. An effective security program is not event-driven; it is a life cycle approach that calls for a continuous “hands and eyes” approach.  A security program will only be successful if continuous risk reviews start the life cycle.

Yep. Identify the assets, remain asset-centric when designing policy, determine the whole life cycle and constantly examine risks. When this is the guiding principle, any security team can easily see the process as something they practice every day.

Once we have determined what our security intent should be (our global, declarative policy), then we have the opportunity to remove our hands from the keyboard, stop writing rules and start commanding intent to every stitch of the enterprise network. To do this, we must start with translating that intent.

Translation of Security Intent

There are multiple factors that go into this algorithm, including but not limited to compliance standards, business requirement, and security mandates.

Compliance: Compliance standards – regulatory and internal – are written in human language, not code. To reach a state of intent-based security, we must translate the desired compliance requirements into relevant rules and access controls that conform to the security intent.

Business requirements: As with compliance standards, these business goals are written in plain English. In the old method, 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, we use the machine learning to do the translation. You’re literally not writing rules anymore.

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

FireMon’s Policy Compute Engine serves as the machine translator to your security intent. This helps organizations realize intent-based security by offloading the grind of constructing the rules to machines and leaving the strategic thinking to the humans who do it best. Now that we have our intentions codified and machines obeying those intentions by translating to the right rules, we are ready to automate our implementation.

This blog was brought to you by our partner, FireMon. FireMon has been at the forefront of the security management category, delivering first-ever functionality such as firewall behavior testing, workflow integration, traffic flow analysis and rule recertification.  They are a sponsor of our annual Camp Secure Sense 2018 and will be presenting on Day 2 at 11:30 am.

Head on over to the registration page to discover other thought leadership presentations exclusive to Camp Secure Sense here.

With only 26 days left, and a few spots open for InfoSec leaders, we encourage you to register ASAP.