Top 10 Reasons the Firewall Guy's Hair is on Fire
Firewalls are a mature technology, right? Most companies have at least one, if not several. And since an established knowledge base exists to tap for issues and PCI DSS 1.1 and 1.2 are pretty clear cut, firewall management shouldn't be much of an issue, right? No one is going to suffer the brunt of managing the significant infrastructure change these regulations are bound to bring more than the security operations team, correct?
Fri, June 26, 2009
CSO — Firewalls are a mature technology, right? Most companies have at least one, if not several. And since an established knowledge base exists to tap for issues and PCI DSS 1.1 and 1.2 are pretty clear cut, firewall management shouldn't be much of an issue, right? No one is going to suffer the brunt of managing the significant infrastructure change these regulations are bound to bring more than the security operations team, correct?
Security: How to Make a Firewall Sandwich
Well, not really.
If your friendly neighborhood firewall guy (or gal) rolls into work late on a Monday morning sleep deprived and grouchy, cut him some slack. Here are some of the most common-yet-nerve-sizzling firewall snafus that have kept many an admin on a Friday-to-Sunday diet of fast food and Red Bull:
[After reading the following list, see what some of your peers are doing to ease job stress in How IT Security Pros Blow Off Steam]
10.) The Saturday-at-midnight policy update process didn't go exactly as planned and he spent the rest of the weekend sorting through a bloated rule base to find out exactly what went wrong, and it ended up to be a slight overlap of rule 847 (meaning, 847 rules deep into the rule base) with rule 73.
9.) The network firewall rule base(s) have become so bloated that likely erroneous, obsolete and overlapping (or "shadowed") rules have caused unneeded risk or degraded hardware performance due to unnecessary processing and hardware drain (Yes, rule bloat is a big enough issue it warrants two of the top-10 spots)
8.) Monday's firewall changes didn't work when the polices were pushed out on Saturday because someone else's changes offset his and he had no idea who might have been making changes, what the change was, or why they made it.
7.) The last firewall guy had his own way of managing changes that is virtually indecipherable to those of everyone else, with no reference to the original request or business unit. And before he quit last month he accidentally cut off access to a mission-critical application when making a change.
6.) Permissive rules (rules with "ANY" and "ACCEPT," or even better, "ANY ANY ACCEPT")? If you want to be on good terms with auditors, then get rid of these. Rest assured, the security implications will soon enough deem them unacceptable. That means rules will need to be more specific and precise -- which could either be really good or really bad, depending on the size and nature of your existing base (see items 9 and 10).
