This is the first in a series of articles that aim to help organisations build and maintain their information security incident management and response capability.
With the exception of a few organisations, it seems that the effort put into establishing an information security incident management and response capability is limited to developing a documented process. Most do the bare minimum required to tick the “has an incident response process” box, with little to no regard about how effective the process is. That’s why very few organisations actually detect information security (or cyber security if you prefer) incidents in a timely manner, and fewer still are able to handle and resolve them in an efficient and effect way to minimise the impact.
In many instances the effectiveness of an organisation’s incident management and response is due to the skills and dedication of a limited number of individuals. Typically, they have not received any formal incident response training and the process they are expected to follow is so complicated and unwieldy that it sits on the shelf and collects dust, only to be dusted off for the next audit cycle.
Most technical teams are tangled up in day-to-day operations where “incidents” are viewed within the ITIL context: “an unplanned interruption to an IT Service or a reduction in the Quality of an IT Service”. Security incidents go unnoticed because technical teams do not recognise that an incident has occurred if it does not interrupt or reduce the quality of a service.
Let’s consider a ransomware incident as they are fairly common these days because they provide a lucrative revenue stream for cyber criminals. Do members of your service desk and operations teams know what the indicators are of this type of event? What should they be looking for? Do they know what to do when a user reports that their corporate device is displaying a lock screen demanding a ransom? Do they know how to recover from the incident? Or how to make sure that the incident is contained and other devices or data are not affected?
If this all seems intimidating, I wonder how you would feel if I ask if you have a documented process with roles, responsibilities and authorities clearly defined? Does everyone know their role within the process? How prepared is your communications team to make a statement about an incident to the media? What about your communication with management and other stakeholders? How do you provide Senior Management with an appropriate level of assurance that your process is effective?
It is clearly too wide-ranging for me to address all of these challenges in one article. Therefore, I will be publishing a series of articles to that will discuss how you can develop and maintain an effective incident management and response capability within your organisation. Although there are a lot of material freely available online on this topic, I will provide practical advice based on my real-world experience working at a CERT and running CSIRTs.
In the next episode I will discuss what constitutes an information security incident, and the difference between incident management, handling and response.