How Not to Respond to a Security Incident

Published: 2011-02-01
Last Updated: 2011-02-01 05:22:46 UTC
by Lenny Zeltser (Version: 1)
3 comment(s)

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 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 attempt to hire the entity who notified you of the breach to assist with incident response, unless there's truly no one else qualified for the job. They might not be responsible for the breach, but it's best to control the situation where you might 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 diary Incident 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:

-- Lenny Zeltser

Lenny Zeltser leads a security consulting team and teaches how to analyze and combat malware. He is active on Twitter and recently launched a security blog.



3 comment(s)


I consider the whole site dodgy. Why did (*/ ) exist up until this point? There was another file called (*/ ). They're both gone now, but it makes me wonder if this issue is really a cover up for this problem.
Forgot the google cache:

As it says, this particular file and most likely ringtones.txt existed up until the 28th, and says these files have been visible for 5+ years.
Lenny - I generally agree, except that not all third-party notifications are done by those that you've most excellently labeled as "ambulance chasers". In the course of large investigations, an IR company may learn of other compromised entities. There's an ethical dilemma here - should they inform the other entities of the breach, or not?
I'd contend that the IR company should make the notification - leaving the pwned on the side of the road is never a good idea. But, if the compromised entities were to be encouraged to use another IR company, there would be little business incentive to make the notification.

I do agree that if someone who is not a respected IR company makes the notification, or if the notification is done after "penetration testing not authorized by the compromised entity"[1], the victim should definitely seek counsel elsewhere. But, if a respected IR outfit is doing good by informing a victim that may not even know they've been had, there's no reason the business end of things shouldn't follow.

Anyway, great take on the PoF incident. Definitely matches most of my thoughts on the whole mess.

[1] I call this illegal hacking, but there are some who call it business development...

Diary Archives