Apparently we have hit the million word mark in English, according to some American organsation that monitors such things. Now I know that most of you will probably be inclined to make some disparaging remark about Americans and the English language but it just goes to show that there’s probably about nine hundred and ninety thousand useless words in the language.

According to the BBC, a fluent speaker may have a vocabulary between 20-40,000 words and most of us survive with a few thousand, or if you’re a certain celebrity chef, one’s enough!

Now apart from the fact that there are probably hundreds of thousands of words that are never used, another phenomenon in our daily use of language is generalisations.

The problem with generalisations is that we make statements that will include “any and all”, either because we are unable or unwilling to obtain all of the information we would need to make accurate judgements about people.

For example, it is not true that all Scots drink whisky and wear kilts. Everywhere I go it seems that as soon as someone discovers my heritage they launch into their Scottish whisky tour stories and start discussing the merits of “Glenwhatever” as if I’m supposed to be some kind of expert. I happen to belong to that group of “all Scots” who hate the “any” form of the stuff! Also I discovered that Germans categorise all cars with a Dutch registration as a menace on the road – I’m looking for the bumper sticker that says “I’m not Dutch”!

So what, you may ask, does this have to do with firewalls and IT security? Well actually we seem to have carried our love for unnecessary words and generalisations into the world of IT security. Look at any firewall configuration and you are likely to find hundreds of rules that are either unused or expired. In many cases rules are in the wrong place or out of context, like the restaurant menu in the North of England that said “our prices have went up” – although they did manage to spell gâteau and pâté correctly!

We do love using generalisations in our rule bases. It is simply much easier to put an “any and all” rule in because we are unable or unwilling to obtain all of the information we would need to create an accurate rule.

But to ask anyone to simply analyse a firewall rule base to select what is actually necessary and to remove all the generalisations is virtually an impossible task. I was recently told by a small financial organisation that they had spent six months, with specialist outside help, trying to analyse their firewall rule bases before migrating from one firewall vendor to another. And the result? At the end of the exercise they said that they just simply copied a large part of the rule base because no one could actually figure out what the rules did.

The problem is that in many cases firewall administrators are not able to accurately analyse rule bases because they have no understanding of who requested a service and what they are connecting to. What's more, they are afraid that they may make changes that result in disruption to business critical applications.

Here are some of the challenges to expect:

  1. Cleaning up or migrating a rule base - This is very complex, especially if it’s between two different products. Firstly it requires a thorough analysis of what traffic is actually accepted. In reality a firewall configuration should consist of traffic specifically allowed and all other traffic should be blocked. The problem very often is that rules are too general so that rules with “deny” will be found all over the configuration along with rules that are just to general
  2. Rule usage analysis - Creating a new rule base without ordering your rules based on usage means that you inherit the same performance issues since frequently the most used rules are at the bottom of the rule base since new rules are frequently just added to the bottom. But rule usage alone is not the only issue.
  3. Risk and Business Continuity Compliance - Just because a rule is heavily used does not mean that by default it goes to the top. Designers need to consider not only the usage but also the organizational risk policy and the business continuity policy. And this adds to the complexity, which makes it an almost impossible task to carry out manually.
  4. Controlling Permissions - And finally rule bases are frequently too general. Very often rules are defined with “Any” for outbound traffic and sometimes even for services. This means that high-risk services can be used and that too often users have access to destinations and services that are risky. In other words firewall administrators should avoid the use of “Any”.

The bottom line is that it is as impractical to expect someone to generate a firewall policy from an existing firewall as it would be to expect someone with limited language skills to translate a document from English to another language.

Without the necessary policy generator tools it becomes an impossible exercise. You might as well try and learn the dictionary. Try looking for a word in the dictionary based on knowing the definition! Very often your firewall configuration is the same – you know what it should do but you just can’t find where it does it.

So unless you’re looking to limit your language skills to the level of a celebrity chef, my advice is that you look seriously into getting hold of the right tools to automatically generate your firewall policies.

You’ll save yourself a lot of frustration which in case you’re wondering what it means is “a feeling of dissatisfaction, often accompanied by anxiety or depression, resulting from unfulfilled needs or unresolved problems.” – In other words what you get from trying to generate your firewall policy manually!