Security always fails at some point. No matter what you do, the bad guys will eventually manage to get past something. Sadly, this is inevitable. The best employee screening program in the world will fail and you will employ someone who does you harm. The best firewall in the world will have a vulnerability that a hacker can exploit. This doesnt mean you shouldnt put any security measures in place – why make it easy for the bad people? – but it does mean you should have some idea of what you will do when things go wrong.
In security, this is normally termed an “incident” and there are as many ways of running an “incident management” situation (also termed “incident response”, “security incident” etc) as there are people. A discussion of how incidents should be managed and some common themes will be the subject of a future post.
In this post, we will look at one of the most overlooked aspects of “incident management” – the investigation.
Taking a very high level approach the overall incident process is triggered when your monitoring (or sometimes a customer or external agency) informs you that a security incident has taken place. This is the “detection phase.”
With most incidents, you will have to take some immediate measures to close the gap and prevent the incident continuing. This can take many forms – for example, if an employee is stealing from you then you can suspend them, if a firewall is breached you can close the ports and so on. This is the “respond” phase.
Once the critical parts of the incident are over, and you are no longer reacting to a changing situation, it is time to investigate what happened. Some people will suggest trying to investigate as part of the response, but in our experience this is doomed to failure as the pressures of a changing situation make cloud the issue. Without clarity, any investigation is wasted.
As is so often the case, you should have your investigation policy and process well documented in advance. It is important that whoever is dealing (responding) with the incident is aware of the the requirements for the investigation. A good example of this is that if your investigation policy involves capturing evidence in a forensically sound manner, the responders have to act in a way that complies with this. It is both frustrating and a bit embarrassing for your investigation to realise the responders have destroyed the evidence.
A security investigation has one aim and that is to determine what led to the security breach. Security investigations should not be “witch hunts” and should not set out with a view of finding someone to blame. Many organisations lay claim to having a no-blame culture, only to turn every investigation into a hunt for someone to blame.
If your staff do not trust the investigators, if they feel that some one will be punished as a result of the findings, if they feel that it is being used to find a scapegoat, then you will not get the correct answers required to achieve the aim.
Remember, if your investigation is not able to determine the cause of the breach properly it is a total waste of time and effort. It must be carried out in a methodical, objective manner, free from any influences within your organisation. Done properly, an investigation is the single best method you can use to reduce the chance of future security breaches. Investigate badly and not only will the risk remain, but you may even create new ones.
Once the investigation is complete, you should have a clear understanding of what process failed and allowed the breach which will give a clear indication of what needs to be done to remediate the problem and prevent future occurrences (the next stage of the cycle).
As a last point – keep in mind that not all failures leading to security breaches are deliberate. You may discover that a previously well documented process has a flaw no one had noticed before, so simply fix it and move on – remember, security is not about blame, it is about solving the problem.
If, for some reason, you feel that your own staff are not perfectly suited for incident investigation – or you want the ability to rely on independent opinions – then consider bringing in external consultancy work for this stage of the security management process. This has the advantage of being more cost effective than having dedicated investigators on your payroll 365 days of the year and, by having a fresh pair of eyes, you know the investigators will not be caught up in existing organisational politics.
In the unlikely situation you need to investigate something involving a senior member of your organisation, or even a popular manager, it is nearly always best to use external help. This avoids issues of favoritism or the risk that undue influence is being applied.
If you want to know more, or discuss the security services provided by Halkyn Consulting such as security investigations and training for your investigation teams, then get in touch.