Class based Firewall Policy



In the early 1990’s firewalls were invented to protect organisations by dropping packets based on a predefined security policy consisting of destination IP address and protocol or port, otherwise referred to as a packet filtering system.

Over the years firewalls have evolved to provide an array of security controls, starting with stateful inspection and application layer filtering, evolving to offer threat prevention features such as AV, SSL Inspection and Web filtering. They can also provide secure 2FA VPN solutions for SMEs with advanced logging and reporting functionality.

This is all great, however, at the heart of every firewall remains a manually defined security policy that ultimately determines what traffic is allowed to flow through.


The problem with traditional firewall policies

Both the attitude and implementation towards firewall security policies has not changed since their inception. They continue to be static in nature, requiring human intervention to create their structure, maintain rules and enforce changes.

Within most organisations, firewall policies are seen as shared infrastructure, on the basis that inter-departmental application flows traverse through them. One organisation can operate tens if not hundreds of firewalls, each with a unique security policy. Ownership of the structure and content tends to be a grey area, with security and governance departments offering guidance only as to their structure.

Rules within a given policy tend to be fine grain (one-to-one), interspersed with periodic coarse-grained (one-to-many or many-to-many) rules. As such, they are destined to grow to unmanageable sizes, in some instances thousands of rules.

Needless to say, the larger a policy becomes the harder it is to manage. Large policies pose a risk to operational performance, tending to increase CPU and RAM usage as the number of firewall lookups increase. Similarly, security compliance and governance become a risk with it being harder to identify and manage duplicate and overlapping rules.

Depending on the make and model of firewall, there are tools available that can help identify duplicate rules. Overlapping rules tend to be more subjective and therefore harder to delete. Counter hits are the main mechanism to tidy up redundant rules, however, to alleviate the risk of impacting services, it can take up to 12 months before these rules can be deleted, if at all. Both application owners and change management divisions take a pessimistic attitude when it comes to removing obsolete rules, understandably. The perceived view is that the risk is not worth the reward, in the short term at least. Another view is of kicking the can down the road.

Being an infrastructure service, security policies are not directly revenue generating. As a result, the appetite, funding, and resources needed to maintain and tidy up rules periodically almost never eventuates. Quite simply, until it becomes a realised operational or security risk most firewall security policies are left to their own devices. Except for SDDC and SDN environments with micro segmentation and automation, most organisations or projects neglect the need to delete associated firewall rules when applications are decommissioned. This is the main reason for the existence of redundant rules.

It doesn’t have to be this way…!!

Hopefully you can now appreciate the inevitable onset of issues that can arise from neglected firewall policies. If only there was a way to create a firewall policy that organisations could simply ‘set and forget’. A firewall policy that meets security and compliance obligations but doesn’t require the creation of new rules every time a new application is deployed.

Let me introduce ‘Class Based Firewall Policy’ (otherwise known as CBFP). In some respects, an adaptation of zone-based firewalls, CBFP uses the concept of manually defined classes (rather than zones) to differentiate between objects. It differs somewhat from zone-based firewalls as classes are not associated with logical or physical interfaces. Instead, they are a logical construct that can be used to form a policy structure with pre-defined rules to meet differing security postures.

In its simplest form, CBFP is a set of pre-configured firewall rules permitting flows between security groups and subnets, differentiated by a classification hierarchy. Every time an application is deployed the designer categorises each of the servers based on their security rating. Once the application is deployed, unless there are some bespoke or non-standard flows between application components, no changes to firewall rules are required to UAT and eventually go-live.

Figure 1 provides a graphical representation of what a typical CBFP hierarchy might look like.

Figure 1: Class Based Firewall Policy (example)

It’s important to understand many aspects of a CBFP policy are bespoke and unique to each organisation. For example, the  uncontrolled’ class or zone for company A may house web servers and required HTTPS be permitted from the ‘External’ zone. Company B may house web servers in the ‘Controlled’ zone and not require subdivision of controlled workloads. Similarly, not all organisations will have a need for an isolated zone that’s completely protected from direct external access.

When looking at the real-world implementation of a CBFP policy, one can use firewall objects based on IPv4 address to classify servers or appliances onto a class or zone, by virtue of their security group membership. Perhaps a better implementation, albeit very much dependant on the layer 3 network architecture for each organisation, is to reserve Class C IPv4 subnets to each CBFP classification or zone. This aligns with the goals of CBFP to ‘set and forget’.

Similarly, for SDDC or SDN deployments using micro segmentation,
logical tags can be created and assigned to individual workloads or virtual machines based upon their chosen CBFP classification or zone.

From an operational perspective nothing really changes when
using a CBFP policy. The only noticeable difference will be the reduced number of firewall changes needed. Application design teams however must now be responsible for considering security compliance when correctly classifying applications as part of any new deployment.

Typically, HLD and LLD documents contain a list of TCP/UDP
ports needed to be opened for a new application to function. Either instead or in addition, they will need to assess their risk appetite or acceptable level of risk when it comes to classifying applications, then stipulate the security rating and class (i.e., ‘Controlled’ or ‘Secured’ etc.) for each individual server being deployed. This will ultimately improve time-to-market for projects as designers typically understand applications better than  implementation engineers so by removing them from having to decipher and translate a design into firewall rules achieves this and removes a percentage of risk.

It’s important to highlight, one CBFP policy can be deployed to multiple firewalls within an organisation, both standardising and simplifying a security landscape.

Using the example in Figure 1, below is a high-level layout example
of how a firewall policy could be structured when adopting CBFP policies:

1.     Stealth Rules

  • Deny known threats (i.e., RFC 1918 prefixes inbound
    on perimeter firewall’s)

2.     Infrastructure Rules

  • Permit known infrastructure rules

3.     Application Exemption Rules

  • Permit application exemption flows that are not
    defined within global CBFP rules

4.  USER Class Rules

  • Permit USER to/from USER
  • Permit USER to/from MANAGEMENT rules
  • Permit USER to/from EXTERNAL rules
  • Permit USER to/from UNCONTROLLED rules
  • Deny USER to ANY
  • Deny ANY to USER

5.     UNCONTROLLED Class Rule

  • Permit UNCONTROLLED to/from MANAGEMENT rules
  • Permit UNCONTROLLED to/from EXTERNAL rules
  • Permit UNCONTROLLED to/from USER rules
  • Permit UNCONTROLLED to/from CONTROLLED rules
  • Deny UNCONTROLLED to/from ANY

6.     etc…

Lastly, some things to be aware of…!!

  • Review your governance and compliance controls. It’s important to regulate and ensure the correct classification of workloads and applications into the correct security classification.
  • To avoid some of the pitfalls of a traditional firewall policy, namely the creation of redundant firewall rules, ensure you have an adequate IPAM register that aligns with the list of security objects defined within each firewall policy. This way, when not using a SDN or SDDC environment, every time a server or workload is decommissioned the firewall object will get deleted.