Analyse 'any' and 'all' overuse for security

Calum MacLeod sees a connection between a million English words and IT security

MacLeod: There is too much generalisation in IT security

Apparently we have hit the million word mark in English, according to some US organisation that monitors such things.

Most of you will probably be inclined to make some disparaging remark about Americans and the English language but that just goes to show that there’s probably about 990,000 useless words in our language.

According to the BBC, a fluent speaker may have a vocabulary of 20,000 to 40,000 words – yet most of us survive with a few thousand or, if you’re a certain celebrity chef, just one.

Now, another daily language phenomenon is generalisations. The problem being that we make such, partly because we are unable or unwilling to obtain all of the information we would need to make accurate statements about people.

For example, it is not true that all Scots drink whisky and wear kilts. Yet 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 some kind of expert.

I happen to belong to that group of ‘all Scots’ who hate ‘any’ form of whisky.

We seem to have carried our love for unnecessary words and generalisations into the IT security world.

Look at any firewall configuration and you are likely to find hundreds of rules that are either unused or expired.

Additionally, rules are often 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 also 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 – like with English – is virtually impossible.

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.

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.

In many cases, firewall administrators are not able to accurately analyse rule bases because they do not understand who requested a service and what they are connecting to.

And they fear they may make changes that disrupt business-critical applications. Cleaning up or migrating a rule base – especially between two different products – is complex.

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.

Often, rules are too general – so rules with ‘deny’ will be found all over the configuration along with those too-general rules.

Creating a new rule base without ordering your rules based on use means you inherit the same performance issues, since the most used rules may be at the bottom of the rule base. New rules are frequently just added to the bottom.

Rule usage is not the only issue. Just because a rule is heavily used does not mean that it goes to the top. Designers need to consider not only the use but also the organisational risk and business continuity policies.

This adds to the complexity, making it almost impossible to carry out manually.
Rule bases themselves are often too general. Very often, rules are defined with ‘any’ for outbound traffic and sometimes even for services.

This means high-risk services can be used and, too often, users have access to risky destinations and services. In other words, firewall administrators should avoid the use of ‘any’.

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 searching for a word in the dictionary by the word's definition!

Often, firewall configuration is the same. You know what it should do but you just can’t find where it does it.

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

You’ll save yourself a lot of frustration, or ‘a feeling of dissatisfaction, often accompanied by anxiety or depression, resulting from unfulfilled needs or unresolved problems’.

Calum Macleod is regional manager for Tufin Technologies