Incident response is one of those things you really hope you’ll never have to use, but know you will. Or at least you should know! Even with the best security, there will come a day when you are up to your eyes in chaos. Either a live security incident or, worse still, picking up the pieces after a breach.
This has stood out a couple of times recently. Someone appears to have breached the US Central Intelligence Agency and, at the opposite end of the spectrum, a small business in the UK looks seriously hacked. Two events which, although unrelated, show that whoever you are, security events are inevitable. Equally inevitable, some will turn into a full blown incident. At this point you realise you have either planned and prepared properly or suffer the consequences.
The UK angle – SME hacked
Chiltern Seeds is a UK based, family run business offering seeds and plants with a personal touch from a small team. They have a web presence which enables them to service customers across the UK. From the available information, they didn’t cut corners. A custom built website supports customers. Payments go to a dedicated provider. Good web practices.
All of this is good stuff. It isn’t enough to guarantee never having an incident though.
At the end of February, they suffered a web outage, followed over the next few days with customers (and curiously some non-customers) getting a very well phrased phishing email. This took them to a page trying to steal payment card information. Details of this stage of the incident are online and well worth reading.
This is a terrible situation for any business, especially a small one who is unlikely to have a dedicated incident response (IR) team. The problem is that this is fairly common. Equally common is the lack of IR preparation. This is where “bad” gets worse. No preparation basically means no real incident response.
There is more pain for Chiltern Seeds with IR work happening in the public domain. Customers (admittedly tech savvy ones) are looking into the incident and drawing conclusions. Customers are challenging the claims made by Chiltern Seeds and for a time at least, they have lost control of the narrative. A bad situation is at risk of spiralling out of control.
IR is there to stop this.
Incident Response – do better!
This post cant cover every possible situation or every possible response scenario. If we tried, it would still fail because IR has to align to your business. However, there are principles to follow.
Plan. Then plan. And then plan some more.
First of all, if you take no other action, come up with an incident response plan. Decide right now what you will do if bad things happen. Don’t try to plan for every possible incident, just plan for high level events. Involve key stakeholders are ensure everyone has an idea of what to do. This is essential if you don’t want to panic when something goes wrong in the middle of the night.
Examples of high level events you should plan for:
- Denial of service attack on your websites
- Malicious software or unusual code on your sites
- Customers reporting suspicious activity
- Unusual events on your firewall or web proxy
- Phishing emails
A fundamental rule is that more planning leads to a better response. There is no escaping this. Accept it and plan.
Scan and Monitor
Your incident response plan is useless if it never triggers. This is more important than you might imagine. If you don’t know you’ve been hacked, you cant respond to it. Additionally, if you only find out about an incident from your customers, it is way too late.
You fix this problem by creating awareness. This includes scanning, logging and, most importantly, analysing the data. However you do this doesn’t matter, just do it. Some key considerations are:
- Learn what your customer facing website code should look like and scan for changes
- Monitor the traffic going through your firewall
- Monitor changes on your PCs, Databases and code repositories
- Scan for vulnerabilities and missing patches
- Scan for sensitive data in the wrong place (such as a PHP include with DB login credentials stored in the root of your webserver)
Respond to the incident at a speed you can manage.
When the inevitable happens, you have to take action. This is where your planning earns its money. Don’t allow the stress and uncertainty of the incident to make you take action before you are ready. One major mistake from the 2015 TalkTalk hack was engaging with the media faster than the incident response teams could gather information. This meant that the message to the public was often confusing and contradictory.
It is vital to engage with the media and your customers quickly. But it is more important to do it accurately. If your message is slow, people will complain. A constantly changing message will create confusion. However, if your message is wrong, it can be catastrophic.
The important thing to remember is that the better you plan, the better your incident response will be. If you want to communicate fast and often, your plan must support it.
Incident Response Matters. Take it seriously.
That is the crucial message here. No matter the size of your organisation, if you have computers or a website, something bad will happen. Don’t be surprised when it does, because you know you need an incident response plan.