Sponsors

Crashing Cars and Firewall Management – a similar chain reaction

by Calum Macleod | posted on 03 April 2009


With all the doom and gloom of the past few months and billions of whatever currency you like being poured into the economy I have to report on a ray of hope. I think my son may have hit on the solution completely inadvertently. He’s not a renowned economist, just an honest, hard working car mechanic.

Having written off the fifth car in the last three years - although credit where it’s due, this time it was his fiancée that managed it - not only is he trying to save the motor industry single handedly but at the same time his insurance premiums have reached a level where he may be also saving the financial sector.

On top of that, out of sympathy I’ve had to break open the family reserves and help finance car number six - which of course means that what money I had left is now circulating.

This does have quite a lot to do with IT, surprisingly - because his latest accident triggered a chain reaction of the sort that we’re all too familiar with in firewall management.

Firstly there was his lack of Risk Assessment (when, according to his fiancée, “a woman driver decided to stop on orange”) with the result that she ploughed into the back of the car. Mind you had the mechanic bothered fixing his brakes, as everyone was telling him to do, it all might still have been avoided!And as is so often the case in IT security, improper risk assessment can have disastrous consequences. Not enforcing information security policies or firewall policies can very often result in failed audits, and network breaches, etc.

Secondly it had major business continuity impact. Having no car meant his having to borrow somebody else’s. Everybody was affected. A very common problem in many organisations is the impact on day to day business because of errors being made in translating service requests into structured firewall changes ,or failing to adhere to information security policy, or placing firewall rules were they should not be, brings everything to a grinding halt.

Thirdly the failure to deal with the risk resulted in a problem, with the result that the financial impact on the family organisation was significant. I’m not saying the accident would not have happened but had the brakes been working it might have resulted in what became a “write-off” being no more than a small dent.

Bottom line failure to deal with the risk in order to save money eventually ended up costing a lot more than it should have.

So what should you do?

1. Use Automated Risk Assessment Tools – Fix The Brakes!

One of the key reasons why Risk Assessment is not done is simply that it is extremely time consuming if it is done manually. When I ask companies the question, the responses vary from “we have never done” a risk assessment to "so far we’ve gotten away with it because the auditors have never asked!"

Additionally it is surprising - even among financial institutions - that auditors are not addressing this problem.

This is likely to be due to the fact that they do not know what to look for. Relying on specialist consultancy companies to do this job for you can also be a very hit and miss affair because you are at the mercy of a consultant who may or may not have the necessary skills to do this. And if they haven’t got the right tools the chances are they’re no better than anyone else.

The only effective way to really assess if your firewalls are protected is to use tools that are able to examine your firewall configuration based on known best practices. Additionally, the better tools allow the firewall administrator to address new vulnerabilities in real time. Since this process is fully automated it takes the manual, subjective approach away from this task and it ensures that you can analyze in minutes what would normally take weeks or months to do manually. And this has to be a continuing process.

2. Communicate with the business and know what are your business critical applications

Maybe not surprisingly, many IT administrators and firewall administrators do not know which applications are business critical. The result frequently is that rules are left in firewalls because no one dares touch them, which in turn results in poor firewall performance. The alternate situation (one that also often occurs) is that rules or services are removed because they do not appear to be used. Again the problem is often due to the fact that manual processes are used to examine usage and very often services can be unused for months simply because the applications that use them are not run on a regular basis even though they may be business critical.

Again the only effective way to ensure you avoid these mishaps is to use technology.

Firewall Policy Management technology allows an organisation to define business critical applications so that any changes which impact these applications can be identified quickly. In fact some tools allow you to model scenarios before making changes. The modeling allows you to identify if a change will impact business continuity so that you can avoid making the errors in the first place.

Another key use of FPM tools is being able to translate business requests into actual changes. In a recent meeting a customer told me that they spent two days trying to activate a service for a client because they were not able to identify that changes were required on two firewalls to enable the service. An FPM tool that provides “What If” capability will ensure that all necessary changes are shown before implementation is necessary.

Rule Usage analysis is also a major problem without the proper tools. Administrators can very often take days to analyse a single rule because as rules move in the rule base without automated tracking tools, it is virtually impossible to follow the rules and their contents in a large rule base.

Choosing to deal with the risk or leaving it in the hope that it doesn’t happen to you is a choice you make. Not dealing with it is hoping that your colleagues don’t make mistakes. So like my son, if you’re going to let somebody else “drive” your firewall, you’d better be sure that the “brakes” are working

Tufin is exhibiting at Infosecurity Europe 2009 on Stand J96, on 28th – 30th April at Earl’s Court, London. The event provides an unrivalled free education programme, exhibitors showcasing new and emerging technologies and offering practical and professional expertise. For further information please visit www.infosec.co.uk
To contact Calum Macleod please email
calum.macleod@tufin.com


Technorati tags:   
Learner drivers shouldn't control firewalls - You can discuss this article on our discussion board.

Calum Macleod is Regional Manager, Tufin Technologies