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)
