Prepping? Who wants to prep for incident response?

This particular bit of writing came from a question that I was asked during a speaking engagement recently – paraphrased a bit.

How can a client help the incident team when they’re investigating an incident, or even suspicious activity? 

So, I circulated this to the team, and we tossed around some ideas.

Don’t hesitate to declare an incident – or suspicious event

Most incident responders would rather conduct a quick investigation, and declare a false positive or new but legit activity over attempting to reconstruct an incident that is many days old. We’ve been invoked 20-30 days post-incident, and in some cases even longer. As time passes, the attacker has more of a foothold and it’s more difficult to reconstruct all of their actions quickly.

Create a climate where it is acceptable for technical staff to say – I need help here!

If the technical staff sees an oddity, they may or may not feel confident investigating on their own. Restrictions may involve type of activity, their knowledge level, and their bandwidth in light of other work activities.

In a perfect world, IT staff would be able to say they suspect an incident, triage would be done – internally or externally – and actions would follow depending on the true nature of the event. More often, what we see is punitive. If something happened, someone must have done something wrong! So rather than calling out something at the first sign of what I call “the hinky switch”, the technical staff takes a wait and see approach rather than deal with the potential fallout.

Don’t let this be you, or your organization! Deal with the potential for individuals to cry “the sky is falling” individually. Don’t place blame for simply speaking up, and consider all activity to be an opportunity for improvement.

Know your logs, test your logs

Know what logs you have. Know where they go, and know what the retention policy is. Equally important – know what you do NOT log, and/or do not retain. When the incident team says – we need X – know what you can provide and not provide, and communicate that clearly.

Test your logs, particularly if you have an outsourced service provider. If the contract says X logs are available for Y time, when you do your IR/DR tabletop, test it. Don’t say we’ll get the logs from the provider as specified – actually GET them. Review them. Make sure you got what you expected, the logs are complete, and that the team that handles them can retrieve them in a timely fashion.

Preserve any affected systems in their original state

Pull the network cable, and leave it running if you can. If it’s already been powered off, leave it that way. The incident team may need to acquire an image for forensic purposes.

Document what you did and did not do

Your team will have taken actions while investigating the “what if”. Create a process where this is documented, and share with the incident team. An incident or suspicious activity run book is invaluable here – it will help the team get in the habit of documenting fully and at the time that the activity took place.

Know your desired outcome

This may sound obvious…but it’s really not, if you think about it. What’s the most important thing to your business, based on the incident? Stopping attacker activity? Reviewing egress and seeing what information may have left the premises? Preventing downtime to critical parts of the business, even for the investigation? This answer will be different, and the order of priority will be different, based on your company and the business priorities involved.

The last order of business…how can you make things easier on your company?

• Have a plan for incidents beyond the scope of your team. Have contacts, a retainer if appropriate, and keep that plan and contacts updated
• Conduct realistic IR/DR tabletops. Bring the individuals in. Don’t just talk through the exercises – perform the actions if at all possible. As discussed above with the log retrieval and examination, if your actions have only been tested on paper they may well fail at a critical moment.
• Know your backup staff, and make sure they know their role as well. Many of MSI’s tabletops will remove a critical resource due to accident, illness, etc. When you remove them from participation, their backup will need to step into the breach.
• Treat your IR/DR plan as a living document, and updated processes, procedures, and contacts regularly.

What is missing, that would be on YOUR list? I’d love to hear it – reach out. I’m on Twitter @TheTokenFemale, or lwallace@microsolved.com

If you would like to know more about MicroSolved or its services please send an e-mail to info@microsolved.com or visit microsolved.com.