Creating Next-Generation Security Policies for Your Next-Generation Firewalls

Primum non nocere, or ‘first do no harm,’ is the guiding principle for physicians.  It means that whatever the type of treatment or procedure, the patient’s well-being is the primary consideration.  It’s an excellent principle to apply to organizations’ IT infrastructures:  any change or migration project needs careful planning and management to avoid unexpected outages or introducing new vulnerabilities – especially if the migration involves firewalls.

When replacing traditional security gateways with next-generation firewalls (NGFWs), the focus of IT teams is to get everything working exactly as it did before the change.  One way to achieve this, is to systematically go through the existing security policies rule-by-rule, and copy them from the old device to the new NGFW.  This is often a complex task involving thousands of rules and definitions, so using a security policy management solution is a great help.

Copying the rules may require some modifications to their syntax, but essentially it’s a process of converting the ‘source’, ‘destination’, and ‘service’ definitions from the style used by the traditional firewall, to the new.  The result is that the NGFW is implementing the same policies that were previously enforced by the traditional device, with rules are still configured in terms of protocols and ports.

For example, a traditional firewall that allows DNS traffic (which typically runs through UDP Port 53), will have a policy to enable this.  If this policy is migrated across to a NGFW, the organization ends up implementing a ‘Layer 4’ policy, which defines communications simply by port numbers and protocols.  The policy will still work, but it doesn’t take account of the type of application that may be using those ports.

While this approach is good from the perspective of completing the migration and ‘doing no harm,’ it also means that the organization isn’t taking full advantage of the application-aware and granular control capabilities of its new NGFW to further enhance its security.  Put simply, just copying the old rules and policies means the NGFW functions in exactly the same way as the traditional firewall did previously. Continuing the previous example – a NGFW can do much better if configured to allow the DNS application – because it can then verify that the UDP/53 traffic is indeed genuine DNS traffic rather than malicious traffic being forwarded through an open port.

So, once the migration has been completed and the infrastructure is working as it should, it’s then appropriate to start thinking about how to configure the NGFW policies, in order to optimise functionality to gain the full benefit of the NGFW’s features.  There are two broad approaches to doing this.

The first is an incremental approach in which the security team says “our firewall policy is a living, breathing thing, changing weekly, so from a given cut-off date, every new rule we implement or every rule we change will use NGFW syntax, and use application awareness.”  Therefore over time, the security policies will shift from being pure ‘Layer 4’ – defined by ports and protocols – to being ‘Layer 7’, application-centric policies.

The second approach, which is slightly more complex, is to take an intelligent policy tuning approach.  This means working through the existing ‘Layer 4’ rules, and transforming them into ‘Layer 7’ rules.  To do this, the organization’s IT and security teams need to use the NGFW’s reporting capabilities to analyze the logs to identify which applications are using each rule.  For example, the NGFW log may say “Rule 57 allowed a certain type of traffic from source to destination”, and will predict what it believes what application is using the traffic – for example Facebook.

By reviewing these logs over time, security teams can build a picture of which applications use each rule.  They can then replace the rules’ existing Layer 4-derived syntax, with the NGFW application-centric syntax used by that rule.  This means that the policies are tuned over time, taking them from a broad, permissive service-based definition, to a much more specific, application-based definition.

A good security policy management solution is a key asset in this process – automating the collection of the firewall rules and making recommendations on how best to tune them.  It’s also wise to conduct this policy tuning over a period of time, to gain an accurate picture of what applications are being used, by whom and what rules they use, to avoid inadvertently blocking access to infrequently-used applications.

In conclusion, if you’re only using traditional Layer 4 security policies in your NGFW, you won’t be doing any harm, but equally, you won’t be taking full advantage of its application-aware features.  To experience the full security benefits from a migration to NGFWs, you need to migrate to next-generation security policies too.

If you’re attending Palo Alto Networks’ Ignite event in Las Vegas this week, do stop by AlgoSec’s booth #203 to find out more about how AlgoSec can intelligently automate application- and user-aware security policy management.