In our last blog, we talked about what exactly intent-based network security (IBNS) is – and the first step to getting started, i.e. mapping.
Here, we’re going to discuss the next steps: deduction, declaration and translation of said intent.
Deduction of Security Intent
This is a three-step process:
- Begin with assets
- Classify communications protocols
- 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 webserver 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 to 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.
And, ah-ha! That’s going to be our next post. See you next week.
In the meantime, download our eBook on intent-based network security if you want to understand the full ecosystem of what you need to do to stop writing rules and start commanding intent.