Developing an incident response process: Using scenarios

I’ve been working with a client recently on incident response, and was reminded how useful it can be to use scenarios to develop your process. I have long been an advocate of testing earlier in the development of an incident response plan – come up with a draft process, get all the relevant people round the table and then test it. Table top exercises like this are very useful. However, you can actually use this approach to develop the plan from scratch if you are struggling to get started. This is especially useful if you don’t have a dedicated security ops team, and the response is spread across individuals in different teams (potentially in different locations). This is not an uncommon scenario, and it is difficult for one person to get a grip on who has what capability and what steps they might take to resolve an incident.

At a workshop I was running last week we used the example of a phishing email. We walked through how it might get reported (to a phishing mailbox, by phone, and a variety of other means including people coming to the desk), and what steps the analyst would take. In this case our exercise highlighted quickly how the response would vary depending on the individual who received the report. It also demonstrated some of the different capabilities that the different responders had access to – the virtual team being made of admins and support staff from different parts of IT. You can use this method to;

• see what capabilities and knowledge you have in house
• make others aware of this too, so they know what support they can draw on
• build a harmonious response process

Pick relatively simple scenarios to begin with;

•  Phishing emails. Work through what happens when a user reports an email which they haven’t opened, vs a scenario where they clicked on a link or opened an attachment
• Lost laptop, USB device, phone etc. Again, the decision tree can cover unencrypted and encrypted devices.

Walking through these scenarios can allow you to build repeatable steps for specific incidents, and generic response processes working up to dealing with a incident with signifiant impact.

My recommendations to start with are to focus on damage limitation to start with – build processes that quickly lead to the decision about whether further response is required. For example, with the phishing email if the user hasn’t opened it, and it clearly is suspect, just delete it, check who else it was sent to and delete it from their mailboxes too, and move on. When the team and processes are more mature (and you have more resource) you can start doing things like generating your own threat intelligence. But don’t try and run before you can walk.

As always, if you have questions please get in touch! Find us on twitter, or use the contact form.

Thanks for reading

Rob