Posted on Jan 10th, 2013 by Michael Hamelin

A few months ago I read an article by Wendy Nather in Dark Reading about policy exceptions that really resonated with me.  According to 'Nather's Law,' "For every configuration there is an equal and opposite exception." Her point was that because exceptions are a) prevalent and b) directly correlated to risk; understanding how they impact your policy matters - a lot. She is so right.

Firewall and router policies are critical controls that require ongoing management. While there are, of course, valid reasons to create exceptions, they are a part of - and not abstracted from - the overall policy. Lately I've been noticing more and more requests for exceptions in our products for various audits and tests we perform. Many of them sound legitimate and make perfect sense at first approach. But if you have too many exceptions your policy becomes worthless.

Here is the dilemma: As soon as an exception is flagged, when asked how long the exception should remain in place the answer is often "forever". "Then why have the policy in the first place?" I think to myself as I politely grin and nod my head.

From what I have observed, policy exceptions tend to occur because:

  • An organization creates a policy that, in theory, makes total sense (or is required), but in reality is not practical. Regardless, it stays in effect.
  • A well thought out policy cannot be cleanly translated into firewall rules, resulting in the need for constant workarounds (aka exceptions).
  • The policy was based on a requirement that is either no longer current or necessary, but the change in necessity was never conveyed to the firewall team.

If our compliance/operations/security efforts are changing at a rate that our typical firewall engineer, or our business itself, cannot keep up with, then…what have we developed?

A mess, that's what.

So how about we start thinking about some reasonable measurements and tracking our exceptions?

  • If a compliance policy, or control policy, has more than x exceptions it should be flagged.
  • If an exception has been in place for more than x months it should be flagged.
  • If a given firewall rule violates more than x policies it should be flagged.
  • If more than X% of a firewall rule base are exceptions it should be flagged.

That last one is of particular interest to me today, as I saw a client recently with a rule base for his firewall that was around 1000 rules long. When looking at his compliance results for policy and risk he was showing me hundreds of rules he wanted to mark as exceptions. I was puzzled  - almost two thirds of his rule base consisted of exceptions to the compliance policies they were trying to enforce.

WHAT???  Two thirds of the whole policy? Yep…I almost had to walk outside and have cigarette - and I don't smoke!

Bottom line: if your exceptions are out of hand, it's time to rethink your compliance plans or realign operations with compliance.  It is one thing to lose track of how policy aligns with reality, another to not do anything about it.