When Jody Brazil first launched FireMon, it was out of necessity to log firewall policy changes in order to prevent unintended access. Over twenty years on, some of the same policy-driven firewall misconfigurations are still pervasive, especially with today’s increasingly complex – and sometimes poor – cybersecurity postures.

“Whether it’s the source of the problem or not, the firewall often receives a finger point when there’s an outage,” FireMon VP of Technology Alliances, Tim Woods, said. When the firewall is to blame, it’s often a firewall misconfiguration that provides attackers with unintended access.

“Bad actors use automation to scan the internet and continuously test for misconfigurations,” Woods said. “They rely on overly permissive rules that can provide an easy avenue to exploit.”

Often, rules are temporarily unrestricted or “opened up” to allow access for acceptable business purposes, such as deploying a new application to employees. An admin might open firewall restrictions to allow that application privileges.

“The genuine intent is to come back later and tighten that rule up,” Woods said. “The problem is, 15 other priorities pop up, and they don’t go back and correct that rule.”

It looks like everything is working, but the admin has left an opening for bad actors to exploit.

Woods was kind enough to elaborate on four different types of firewall misconfigurations that can lead to an overly permissive environment.

1. Hardware Decommission

Say an admin created a firewall access rule for a specific marketing server and that server is then decommissioned. Unfortunately, they failed to remove the associated firewall access rule that is now no longer needed. Instead, the rule becomes stagnant. Fast forward to a month later, a colleague reuses the old server’s IP to stand up a new device, and the stagnant rule “wakes up,” and ultimately provides inadvertent network access to unintended resources.

2. Duplicate Rules

Duplicate rules are exactly as they sound, they represent a duplicate of an existing logical access path.  They don’t immediately constitute a dire issue, but over time, as duplicate rules build-up, they contribute unnecessary complexity to a security enforcement policy.

3. Shadowed Firewall Rules

A shadowed rule is like a duplicate rule, but instead provides the opposite action. So, you have one rule that’s allowing access and another denying access. A firewall administrator manually reviewing a security policy could potentially misinterpret the policy’s true behavior. They see the deny rule but miss the allow rule somewhere above it. So essentially the “shadowed” rule is never observed.

“That’s a technical mistake,” Woods said. “You get rules that can overlap, or you get a rule that’s stuck at the bottom.” The admin might not know where to put the rule within a policy, so they default to the bottom, Woods said, without realizing that a similar or conflicting rule is being used at a higher level. The policy rule behavior then becomes easy to misinterpret.

 4. Policy Bloat

“It’s not uncommon for enterprise companies to have 30-40% of a firewall policy go unused,” Woods said.

Where 20 years ago there were 200-300 lines of rules, today’s policies can contain 10,000 to 100,000 lines. Multiply that by the total number of firewalls, and the sheer volume of rules can become unwieldy.  Much of the policy bloat is an aggregation of unused, duplicate, shadowed and overly permissive rules.  This bloat degrades the overall hygiene of a security enforcement policy.

Along with the above reasons, there has also been a fragmentation of security responsibilities in recent years in which organizations no longer maintain a centralized security focus.

Where there was once a central security team to manage all controls, there are now business owners, stake holders, devops, security cloud teams and IT security taking responsibility for deploying security controls when launching applications, workloads and resources. In today’s larger “hybrid enterprise” landscapes, we find security responsibility can be a gray area, Woods said.

“We’re often not singing from a single sheet of music anymore,” Woods said. “And these silos, this fragmentation that has happened creates security gaps.”

As time goes on, the complexity gap gets wider. As the volume of rules goes up, unused, redundant and overly permissive rules increase, too.

The wider that gap becomes, the higher the probability of human error creeping into the equation, and the higher the probability of misconfigurations taking place and causing an impact to the system, Woods said.

To get ahead of misconfiguration issues, Woods suggests using a network security policy management solution that identifies and provides labels to all firewall policy changes.

“There’s one question that needs to be answered every time a change takes place,” Woods said, “And that question is, ‘do that change that just occurred on my network do harm? Yes or no.’”

In other words, did the policy change have a negative impact on your organization’s security posture? Labeling complexity ultimately assists in reducing it, Woods said. The ability to analyze change when it takes place provides visibility. But a human admin can’t keep up with the sheer volume of alerts. That’s where a purpose-built automation platform provides cover. Every time a change happens, the application will compare it to the old rule, create a record of the change, and run assessments against the rule in context of the policy.

Firewall misconfigurations happen for several reasons. FireMon’s Tim Woods identified four common causes of misconfigurations, and then added some context around the complexity staffing of security staffing that may lead to these types of configuration mistakes. Finally, to solve for firewall policy misconfigurations, Woods recommended a purpose-built network security policy management platform that can automate visibility and analysis of all firewall policy changes.