It is a characteristic of InfoSec incidents that their first causes can often set off a chain reaction of things going wrong. Sometimes the biggest damage is not directly connected to the initial hurt, but to shortcomings in the affected organization’s backup plans. For example, if one IT system has been compromised by a single piece of malware, a poorly thought out business continuity plan can result in extended service downtimes while essential systems all have to be taken offline (i.e. so they can be thoroughly checked, disinfected and tested for compromise). This can lose business and clients. Malware authors would doubtless be delighted to hear how their malicious work has caused damage that exceeds anything they had planned. For this reason, just knowing about the technical aspects (and the initial impact) of malware is not enough: additional skills are required to identify all of the risks from any particular piece of malware that shows up in your organization. This is a major question for any incident management model: who is involved in recognizing the complete consequences of a single incident? Failures of incident management usually fall into one of three broad types:
An incident is ignored or is not acted upon in good time An incident is acted upon, but actions taken don’t stop problems (including secondary, unforeseen ones) because the consequences have not been judged accurately An event is acted upon, but the results of actions taken are even more disruptive than the event they are reacting to.
All organizations, in particular medium to large ones, should have formally agreed methods for dealing with incidents. There are various frameworks for incident response (e.g. ISO 27001 and ISO 27035). All usually advocate allocating people to specific roles and responsibilities during incidents, and the setting up of processes for analyzing the issues, containing the resultant problems, eradicating these and then restoring affected services as quickly as possible. Procedures and processes should be kept as simple as possible, and be tested for effectiveness and practicality. Effective testing can be challenging for security professionals, as anyone who has been involved in organizing fire drills will know. But tests do not always have to involve full deployment of people and resources: for instance, having someone with an experienced eye for procedures look overwritten incident handling guidelines can give valuable feedback on any untested process. Not all InfoSec incidents will have an obvious InfoSec origin: InfoSec issues can evolve from other incidents in very short time. For example, the damage of a key data repository through a local or regional natural disaster might affect the availability of an organization’s services in faraway places. Some data is still only held in paper form, with limited possibilities for backup, so damage to a depository of paper records can be particularly challenging. Incident handlers should cultivate good working relations with those in their organization responsible for internal communications. This will help ensure incidents that are often technical in origin are described in everyday terms, for the benefit of all those affected. Remember that this may include customers and other members of the public, so internal communications should be ready to prepare briefings for all of these and, in the most serious incidents, for the press. As well as cultivating good relations within an organization, incident handlers should stay some steps ahead of the next incident by tuning into quality information from trusted sources about InfoSec. In the USA, an excellent example of this is InfraGard, an information sharing partnership between the FBI and private sector representatives of business, academia and other law enforcement agencies. InfraGard participants share information and intelligence to prevent “hostile acts” and ensure that special alerts and lessons learned get passed through its trusted network of committed InfoSec professionals. Incident management procedures must be kept as simple as practicable. At first glance, it can seem like larger organizations have an advantage in their access to InfoSec expertise. But the extra complexity required to effectively manage this expertise can actually lead to delays and confusion, ultimately to more damage. As well as complexity, over-enthusiasm during an incident, where everyone seeks to help, can be just as bad as any failure to respond. Recent lessons show that discipline can be difficult to maintain during a serious incident, even within disciplined organizations, e.g. during the manhunt following the 2013 Boston Marathon bombing, when large numbers of law enforcement officers were drawn in, not all of whom were under the direction of lead agencies. Enthusiasm is understandable and usually to be encouraged. But it can very quickly lead to confusion – and thus error. This can be compounded by a tendency for some professionals to use incidents as opportunities to showcase their knowledge and/or over-analyze problems. Also, high levels of ‘chatter’ among experts can confuse and distract the senior staff with ultimate responsibility for successful outcomes. A lean process in which decisions can be reached quickly should therefore be the aim of any organization creating an incident management system. It is best to build this up from experienced staff with a good knowledge of the whole business of the organization. They should be advised as appropriate by supportive InfoSec people. In all cases, there should be a direct line of communication with the organizations C-suite executives, including legal representatives. In an age where any organization is liable to face some form of cyber-attack, it is necessary to get the drills for managing this inevitability right. Simplicity, knowledge and a good grasp of risk management principles are key ingredients for constructing your own system for managing incidents. Having these should ensure an incident does not turn into a disaster.
