If information security were a colour, it most definitely would be grey. Like life in general, information security is rarely black and white. As an information security consultant, most questions asked of me and my colleagues are answered in the same way: It depends.

That is precisely what is frustrating for many people when they deal with security and privacy - its vagueness and abstractness. People want clear-cut and well-defined answers. Risk, however, rarely is so polite as to allow itself to be answered so discretely.

Many of us run into this particular wall when we deal with auditors. Auditors often deal with security issues in black and white - via checklists. They ask yes or no questions and report their findings. Then the fun begins. I recently incurred the wrath of an auditor when dealing with what he thought was a straightforward question: How many rules should a corporate gateway firewall have? My earnest answer to him was the proverbial "it depends".

Truth be told, I could have made up an answer on the spot, and he would have believed me. If I had replied, "I have found that best practice is that corporate firewalls should have no more than 57 rules," it would have been accepted, and he would have been happy. This clearly would have been a disservice to everyone, however.

But the question remains: How many rules should a firewall have? I will answer that, but first, a bit of preamble: Before a firewall can be audited, there must be something against which it can be audited. As in plotting something on a graph, the axes need x, y and z values. For example, Bob weighs 80 kilograms; is he fat? His weight is x, and y and z are his height and age. The answer? If Bob's height is 155 centimetres and he's 12 years old, he is morbidly obese. If he is 37 years old and 188 centimetres tall, he is in perfect shape.

In firewalls, the y and z on the axes are corporate policies and procedures. Policy is a critical element of operating a firewall effectively and successfully.

Noted security guru Marcus Ranum defines a firewall as "the implementation of your Internet security policy. If you haven't got a security policy, you haven't got a firewall. Instead, you've got a thing that's sort of doing something, but you don't know what it's trying to do because no one has told you what it should do.''

The mythical number of firewall rules

So, what is the number? The answer should be the number that one needs to map one's Internet security policy to one's firewall rulebase. If no Internet connectivity is allowed, there should be just one rule: Any/Any/Deny. However, at a large financial services company with multiple DMZs, VPNs, applications, external service providers, customers, proxies and more, the number of rules easily could exceed 100.

In addition, there are many ways to create a rule depending on the style. Some rules can be quite detailed, others more explicit. SMTP can be mapped to individual mail servers or to a single server.

It is hard to find a statement that a firewall should have no more than X rules. The closest definitive reference one can find is in Building Your Firewall Rulebase, where Lance Spitzner writes that a good rule of thumb is to have no more then 30 rules. With 30 rules, it's relatively easy to understand what is going on. With 30 to 50 rules, things become confusing and the odds grow exponentially that something will be misconfigured. Anything more than 50 rules, and you end up fighting a losing battle.

Once the rule base grows to more than 200 rules, it becomes extremely difficult to figure out data flows. Spitzner concludes that once the rulebase hits the 200 mark, an organization needs to take a serious look at its overall security architecture, not just the firewalls.

It ultimately comes down to the fact that the simpler the rule base the less likely one will be to have any sort of error or misconfiguration. And exactly how many rules should there be? It depends.

Ben Rothke is a senior security consultant with BT INS and the author of Computer Security: 20 Things Every Employee Should Know (McGraw-Hill, 2006). He can be reached at ben.rothke@bt.com.