Implementing Intent-based Network Security (IBNS) Takes Planning, Consideration, and Incremental Implementation
Over the last few months I’ve written about a number of technologies impacting cybersecurity and how in a perhaps idealistic world these security systems can all interact with each other, share information about the devices in our networks, and take mitigating actions, as required. So where does that leave us for improving our overall approach to information security as it relates to rapidly evolving networked systems?
Ultimately it’s all about information – our ability to automatically and effectively determine what’s new, what’s important, and what’s unusual, regardless of where across the distributed network it exists. A term I’ve started hearing recently that I like refers to this as intent-based network security (IBNS.)
What do we mean by this term? In short, intent-based network security is the process of applying analytics to the information generated by all of the deployed security devices on a network. Individual security solutions are already capable of delivering significant amounts of independent, unrelated data. As we build out homogenous, interconnected security fabrics, however, we can begin to correlate the enormous amounts of information being generated. This integration is the secret sauce to IBNS, as it allows us to reduce these informatics mountains into molehills, which allows us to automatically refine security in real time as our network and threat landscapes change.
Another thing that such an integrated approach will hopefully result in is a consistent method for correlating and organizing this information with such things as common naming, reliable data, effectively ranking threats, etc.
This is only the first step. Before we can do anything with respect to implementing IBNS, we really need a way to understand and define which data is important, and have a consistent, universal method for describing it.
There are two very different methods of looking at IBNS.
The first is from the perspective of the business owner or the person responsible for security policy. This person needs to be able to simply define or update business intent, and the security policy and related infrastructure needs to interpret that information and automatically implement a reasonable and sufficient response. For example, security policies should be able to automatically limit systems to the information and services that they should have access to. Of course, this requires us to be more exact in our network designs. If we continue with the Wild West free-for-all approach to networks that we’ve been using, the challenge, of course, will be that much larger.
The second, and newer method involves rethinking how we solve the security problem. A key component of building an integrated and responsive security fabric is to implement security tools that can automatically assess and determine if a system is performing activities that are normal or intended – hence the emergence of a set of security practices referred to as intent-based. Again, a somewhat simplified description of such an approach is that it is able to address and automatically respond to the following question: Is the system doing things that are likely intended by that user on that system or not?
There are many things that need to go into creating a system that can truly be defined as providing intent-based network security:
• Knowing what the system is from a physical perspective (platform/OS)
• Knowing what the system is normally used for
• Knowing what the system has historically done
• Knowing what the system is doing now
• Knowing who is currently using the system
• Knowing when the system changes
As we deploy security more holistically, our ability to understand and observe in real time the activity of a system is improved significantly over a traditionally isolated, perimeter-only security deployment.
The migration to virtual systems and containers, in particular, also makes the ability to implement intent-based network security more straightforward, as the number of things that a given system are expected (intended) to do is reduced and they become simpler and more granular.
A similar concept can be applied to Internet of Things (IoT) systems, as they typically only have a very limited set of behaviors and/or intended communications. Understanding these should allow us to observe changes away from this behavior. For example, PoS systems normally only communicate to a handful of systems within a corporate environment or within a given region. If all of a sudden those same end systems begin communicating to other remote geographies, then that behavior is worth initially preventing and launching a subsequent investigation.
Consider a typical retail bank branch – there is normally a lot of intent-based security applied at the physical level; the tellers, ATMs, and offices are usually well separated. If you’re waiting to meet someone regarding a loan or similar transaction that occurs in an office, that waiting area is usually well away from the tellers (your intent is obvious, you’re waiting for someone in an office). The general area around the tellers and ATMs are also usually well covered by obvious security cameras. The days of the tellers having a drawer full of cash are also long gone, as the cash is all locked up in a secure area and dispensed as needed. I would consider all of these to be intent-based security, albeit related to the physical world.
To apply the same, effective strategy to our networks, we will need to rethink how we plan, design, organize, and implement our network architecture. Here are some things to consider as you determine whether your enterprise infrastructure is equipped for transitioning to an intent-based network security strategy:
• Understand the devices in your network that contain critical data, what they do, where they are, why they are there, what applications are authorized to run on them, and which other devices are allowed to interact with them
• Understand (or attempt to) the types of devices that your end users are using and how they normally behave
• Implement systems that can make use of dynamic data when creating security enforcement policies (the days of static 5-tuple rules are hopefully rapidly fading)
Implementing IBNS cannot be achieved by deploying a couple of devices or platforms over a long weekend. It takes planning, consideration, and incremental implementation. However, the end result will be worth it, if for no other reason than continuing to drive our old, statically configured, never up to date, high-maintenance firewall deployment methodology to the verge of extinction.
There is one other thing we’ll have to leave behind, and that is the IDS style approach to information analytics that is part of most SIEM based solutions. In order to handle the amount of data required for IBNS, we need to implement the next generation of SIEM technologies combined with live threat feeds, such as that provided by the recently expanded, and now independent, Cyber Threat Alliance. When working together, an integrated security system will be able to see and correlate information collected from every corner of our constantly evolving networks, determine intent, and automatically recognize and respond when something seems amiss.