I thought it was about time I wrote a blog covering Incident Management. It’s a topic that is absolutely vital to all organisations, yet is often very poorly handled. As there’s so much interesting information around the subject, I’ve split the blog into two parts. This first part will cover the reasons why organisations fail or take too long to identify, respond and recover from incidents. I’ve also included some recommendations on how incident management should be structured. The second part will cover business continuity and disaster recovery elements as incident management is a crucial part of a company’s BCM/DR.
People, processess and technology
Last October I attended a talk by Bruce Schneier on incident response. This was at CyberSecurity Expo in London and I have to say that the whole exhibition was incredibly useful. One of the key themes from his presentation was that the intelligence of attacks from the 90s until now has been rising steadily, to the point where threats, technologies and environments today are massively evolved. Back in the day, everyone used the motto: ‘security is a process, not a product’. This is still correct, but what it lacks now is the human element. One of the points I took from the talk was that people, processes and technology must work together to respond to incidents. All three must always be included. What changes is the ratio of these three being used on the different steps of the incident management process.
People must realise that incidents are not only an IT issue but are also business and process matters. Of course technology can assist in identifying and responding to issues – in fact in today’s world it’s integral to the whole process – but it can never be a 100% replacement for human interaction. The sheer volume of data needing to be analysed for accurate incident management puts off a lot of people, meaning that important flags are often missed. In reality, every alert that is identified must be investigated. If your altering mechanism isn’t appropriately tuned, you’ll find a lot of false positives will consume a lot of valuable time for no benefit. In order for people to drill down and find the root cause, the technology you use must be appropriately configured. This goes hand-in-hand with ensuring your staff have the right skills on how to interpret the data correctly and the processes that underpin the whole lifecycle are apt and up-to-date.
Failure is an option
People who rely only on tools to cover all the steps of the incident response cycle will probably fail. Yes those tools are helpful, but who will do what after something is identified? Every organisation must establish the right communication channels and define roles and responsibilities.
You cannot prevent an incident from happening but you can limit its impact and the time/resources needed to efficiently and effectively respond. Getting the incident management right is the key to success. If you don’t, then the outcome is simple: failure.
Below are the minimum steps I’d set in place for an incident management plan: Prepare, Detect, Respond, Recover, Learn.
- The first and most fundamental step is to create your incident response team and allocate them roles and responsibilities. The document must cover communication and actions to detect, respond and recover from incidents.
- Have you done your risk assessment on your critical assets and processes to assess the business impact?
- What controls have been set in place to mitigate this risk?
- Have different plans/procedures been created for different types of events? One size will probably not fit all.
- Is everyone involved in these plans/procedures aware of their roles, trained appropriately and prepared for incidents?
- Last but not least, and this is one which only a few actually do: have you tested your plan? How do you know that all of the above are working as they should? You need to know what needs improvement.
- Any incident found must be classified and prioritised according its criticality and sensitivity. Also have in mind the impact it can have to the confidentiality, integrity and availability of your assets.
- What assets are involved? Who and what has been impacted? Be prepared and able to respond to multiple incidents at the same time.
- Make a call of the severity of an incident and follow your escalation prodecure. We will cover BC/DR and when to invoke it in the next blog.
- How long does it take to detect a particular incident?
- What are the response measures? Will the incident need to be contained?
- How will the communication plan be set into action?
- How will the incident will be approached and remediated?
- How will you fully recover from the incident?
- Does your plan include further investigation to find the root cause of the incident?
- What have you learned from that particular incident and the process that was followed?
- What went well? What didn’t?
- What could be done to eliminate the likelihood of the incident reoccurring in the future?
- All parties involved in the process must openly discuss concerns and recommendations.
It pays to prepare
As you have hopefully realised, half of the workload and effectiveness is covered in the preparation step. Spend some time to re-structure your incident response management programme now and it will pay dividents in the future. You may have to consider if this can be done in-house, partially in-house or fully outsourced, depending on your skills, resources, time and budget. If you go down the outsourcing route, there are companies who can help you. In every approach taken, the aforementioned steps must be created and communication plans must be clearly defined.
Incident management is a very broad domain: it can be the survival of your business or its undoing.
Coming soon: Part Two.