3 Ambiguities in One Simple Rule: How to Stop Writing Firewall Rules and Start Controlling Network Security Based on Your Actual Intent

Take a look at this ultra-simple firewall rule list below. 

It’s very easy to interpret, right? 10.0.0.7 is apparently a web server and we want anyone, anywhere to be able to browse it. But even this ruleset leaves room for ambiguity when you try to infer the intent. If you built the rules you could state the intent because of lots of other information, context and circumstances of which you’re aware but which are hardly stated in the rule. Someone else taking a look at this rule for the first time might have many questions:

• Is 10.0.0.7 actually a web server? It could be anything else that uses the http protocol. Like a REST API endpoint or any network connected device administered via browser like a sprinkler system.
• By source ALL do we really mean anyone/anywhere? Maybe “outside’ of the firewall is already a limited access network and we mean only devices on that network. Do we mean to also include anyone beyond who can access the outside network based on its own inbound routing rules?
• Is it really the literal IP address 10.0.0.7 that we want to allow access to? Or is it the particular system/device assigned that address? What if it’s address Is changed? What if the system is decommissioned and that address assigned to a completely different system? What if a 2^nd or 3^rd system of the same time is added?

As you can see there’s a big difference between intent and the rules used to implement intent. This disparity widens at an accelerating rate as you add more rules. Today it’s common to deal with thousands of rules per firewall and organizations have scores, hundreds or even thousands of firewalls.

As networks grow, new technologies are implemented and turnover in staff occurs, we quickly end up with a massive firewall policy that no one understands. We know it’s outdated, probably insecure and we’re afraid to change it.

In this real training for free webinar, we will examine intent-based security and how to apply it to firewall policy and management.

The process starts with discovering the resources, assets, rules, and controls that are currently in action. A goal for securing a given application can be discerned by looking deeply into the rules we have. It’s a matter of gathering evidence, sifting through the competing signals, and deriving the security intent from an inferential connection with the existing rules and controls. Our security infrastructures are loaded with these controls; there is no shortage of rules to examine to find the intent lurking there within the documentation. We’ll examine 3 quantitative methods:

• Recursive Network Indexing (what nodes and connections are there),
• Traffic Flow Analysis (how they are communicating)
• Access Path Analysis (how they could communicate)

Now we can deduce security intent. Beginning with the assets we look at their behavior and relationship to other assets. Example: “This 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 rule base have a new character and aspect. They reveal to me the statistically likely intent originally planned. That conclusion comes from traffic flow analysis. But perhaps access path analysis reveals rules that allow a completely different protocol and source network to access this server. Is that intentional for supporting some type of here-to-fore unobserved traffic – such as communications with a disaster recovery site? If so, intent needs to be updated or a to-do item added for the later remediation phase.

We’ll also discuss overlaying context which is never completely captured by the previous information gathering activities.

Next, it’s time to translate security intention into appropriate rules and controls that will determine what can happen in the OSI model from Layer 2 up to Layer 7. This includes taking into account compliance and business requirements. 

Our sponsor, FireMon, has pioneered this process for getting from a mass of unintelligible firewall rules to an intent-based policy as well as a lifecycle for managing it going forward. More importantly they have the technology to automate both activities which Tim Woods will briefly show you in this real training for free event.