Staying In Business

Despite the dreadful events of September 11 last year, thousands of UK financial services companies still have no business continuity plans in place to keep their businesses running in the event of a terrorist attack or other major disaster, warns Tony Barker

You might think that the attack on the World Trade Center would have driven home the need for effective recovery plans. However, while a small number of the larger UK financial services organisations have made comprehensive plans, according to the Financial Services Authority (FSA) up to 40% of the approximately 11,000 firms it regulates have no back up arrangements at all. To be ready for all eventualities, the FSA has demanded that firms 'up their game' in establishing robust plans to cope with disruptions to operations.

Although most insurers and banks have contingency plans to cope with fire or power failures, the issue of information security – including disaster recovery, application availability and data security – have become more urgent since the September 11 attacks. The fact that many organisations have yet to implement even basic continuity plans is disturbing, and poses a significant risk to the financial services industry as a whole.

Drawing on experiences when the World Trade Center was attacked, my own company has learnt valuable lessons. One of the simplest is that an information security programme that was good on September 10 2001 would be equally good today.

A good security programme
A good information security programme must be based on a risk management model such as the one shown below. The stages of the model, and the actions to be taken at each stage represent, in the main, common sense and logic.

Protect > Detect >React > Recover and Revise The issues that need to be considered within these headings are very broad, and range from the obvious to the obscure. Many firms have inadequate resources to achieve a comprehensive and embedded information security process. Hence they turn to specialist companies to help them achieve it.

Some of the issues that need to be considered at each stage of the model are these:

Protect: Patch the holes. The most common and readily handled issue is to fix already known software security weaknesses by applying patches.

Configuration or implementation errors that may not be immediately apparent also need to be identified and put right. For example, some developers have a habit of setting up a 'secret entrance' within software that allows them easy access to the source code. Unfortunately, the hacking community often finds a way in through such entrances, with potentially disastrous results.

Another action is to ensure that the perimeter protection of firewalls, routers and other devices are adequate for the job. This is particularly important where systems can be accessed by other companies or by the general public.

Detect: Know what is happening on your network. Relying upon an intrusion detection process alone is not enough. Despite the high profile given to cybercrime, the greatest danger to most organisations comes from within, not from the outside. Even then not all damaging incidents are malicious; some are caused by genuine mistakes by staff.

Consequently, it pays to set up a constant and thorough monitoring process, looking out for both intentional and non-intentional misuse of critical systems.

React: Speed may not always be of the essence. Once an incident has been detected, the next steps are to determine its severity and mitigate the impact. The nature of the incident should determine the speed with which it is tackled. Not all types will require the same degree of attention.

Speed can be expensive, so response times need to be matched with the seriousness of an incident and built into the security protocols.

Recover and revise: Start a regular assessment programme. There are a number of good vulnerability assessment tools on the market, and some are even free. The primary objective following a security incident will be for the business to recover by making the system operational again. But this needs to be done in a structured, planned way, so as to avoid creating secondary problems. The recovery process needs to be incorporated into the security programme.

In addition, it will be necessary to revise the programme to prevent further similar incidents occurring. This may involve an adjustment in technology, in process, in the awareness and performance of people, or in any combination of these factors.

Developing a programme
A good security programme will ultimately hinge upon the attention given to three areas: processes, technology and people.

As well as calling upon the expertise and experience of specialist companies, there are two international standards in force that provide useful guidance and a reference against which to measure performance. These are ISO 17799 and ISO15408.