Incident Response

Today's blog post is based on a presentation I gave to the Scottish OWASP chapter around using security testers as part of your incident response approach.

The talk focused on the different skills and opportunities that using non-forensic based teams can bring to the party in dealing with a security incident and where you really need to use forensic based teams.

The highlights being:

Incident Response -

1. Key question to ask at the beginning of any incident is

"Is this likely to go to court or involve law enforcement?"

If there is any possible outcome that turns this question in to a yes then you have no choice but to use an approach that meets the evidential handling requirements of the local legal jurisdiction of the incident. Within the UK the foundations for this approach have been documented by the Association of Chief Police Officers (ACPO) and serve to ensure that evidence handling, investigation practices and supporting activity are carried out legally.

The following show the four high level principles set out by ACPO :-

Principle 1:
No action taken by law enforcement agencies or their
agents should change data held on a computer or storage
media which may subsequently be relied upon in court.
Principle 2:
In circumstances where a person finds it necessary
to access original data held on a computer or on storage
media, that person must be competent to do so and be
able to give evidence explaining the relevance and the
implications of their actions.
Principle 3:
An audit trail or other record of all processes applied
to computer-based electronic evidence should be created
and preserved. An independent third party should be able
to examine those processes and achieve the same result.
Principle 4:
The person in charge of the investigation (the case
officer) has overall responsibility for ensuring that the
law and these principles are adhered to.

Basically, if you get involved in such an incident then make sure you work with forensically trained teams, be it internally resources or in partnering with a specialist service provider.


2. In terms of basics for incident response, well PPPPPP! That's Prior Planning Prevents P$£& Poor Performance!
Make sure you have a documented approach to incident management, defined roles and responsibilities and that you have tested it all out prior to dealing with your first incident! Otherwise it is unlikely to go well. A few pointers that I have picked up over the years to aid this are -

3. Use IS specialists to provide advice and guidance to the incident group and not have them running the incident. This approach enables your specialist to be just that, the specialist.

4. If the incident is in response to an event that could impact the business being able to meet its objectives (say, make money?) then it should be the business representative that makes the final decision (based upon sound advice and guidance from the specialists). Too many times I have been involved in incident calls where the business rep has looked to offload the decision making on to techies.

5. If you are dealing with a complex issue that requires both technical teams and business focused teams to be working, think about splitting the two teams in to focused indecent groups and have a link person that delivers messages between them. This enables the noise and chatter that is generated to be compartmentalised, the business team do not need to know how specific lines of code are going to be updated to stop that SQL injection attack and the technical teams don't need to be listening to the business managers talking about media statements and legal advice. This approach lets each team focus on the key issues that they will have to deal with.

6. Have a dedicated (for the period of the incident) resource to manage incident calls, take notes and track actions. There is nothing worse than sitting on a call for three hours to reconvene later on to find out that no one has actually done anything! This approach also helps to establish a time-line for the incident and will enable a more effective post incident review to be conducted.

7. If you are not having to go down the forensic route, it could be useful to engage the services of your friendly hackers (we call them security testers) to provide their expertise.

Security testers enjoy problem solving, they can generally code (which is very useful when managing large amounts of data) and they have an innate understanding of exploits and the reality of what can be achieved by hackers. This insight can go along way to gaining an understanding of what has happened, the risk exposure to the business and in highlighting potential options for recovery.

Your friendly hacker is also very good at testing any fix to see if this successfully mitigates the exposure or to conducted targeted assurance tests to understand if you are vulnerable to the same issue in other areas of your organisation.


In summary, you can gain a huge amount of advantage through the use of security testers as part of your incident response approach.

However, remember that sound forensic practices need to be use in cases that will involve the local law enforcement or courts! Given the choice of putting a forensic engineer in front of the courts or a pale, caffeine addicted hacker I will choose the forensics engineer every time. :-)