Finding out that your organization’s computer defenses has been breached is a stressful experience. Many are unprepared to deal with such situations, and some have a false sense of security as the result of impractical incident response plans.
Having read about the recent PlentyofFish.com security incident, as described by its founder and a more measured perspective from Brian Krebs, I was inspired to create this short list of what not to do when responding to a security incident:
Don’t drive the incident response (IR) team to work for several days without sleep. People’s ability to conduct cognitive tasks is severely diminished when they are sleep-deprived. You may need to pull a one-nighter initially, but after that, stagger people’s response tasks so they can get some rest.
Don’t make rush decisions when deciding upon the initial incident response steps. It is OK to take some time to assess the situation before taking action to avoid making mistakes. Of course, you need to balance this with waiting too long before making decisions regarding the next steps.
Don’t immediately attribute the source of the breach to people, companies or countries without conducting a thorough investigation. In particular, don’t assume that the entity who notified you of the breach of a vulnerable condition is the entity responsible for the incident.
Don’t hire the entity who notified you of the breach to assist with incident response, unless there’s no one else qualified for the job. They might not be responsible for the breach, but it’s best to avoid the situation where you might later accuse them of extortion. Also, there’s no reason to encourage ambulance-chasing practices.
For more recommendations on what not to do when someone reports an incident, as well as for tips on what to avoid doing when reporting an incident, see our earlier diaryIncident Reporting – Liston’s How-To Guide.
In addition, here are a few Emergency Incident Response steps from Mandiant, which are a good starting point for responding to a security incident. I also put together a few incident response cheat sheets:
Initial Security Incident Questionnaire for Responders
Network DDoS Incident Response Cheat Sheet
Security Incident Survey Cheat Sheet for Server Administrators
Critical Log Review Checklist for Security Incidents
– Lenny Zeltser
Lenny Zeltser leads a security consulting team and teaches how toanalyzeandcombatmalware. He is activeon Twitterand recently launched asecurity blog.
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
View full post on SANS Internet Storm Center, InfoCON: green
