Are You a "Target"? - Incident Managment (part 1)

   It seems that every few days we get additional news about the Target breach.  There has been plenty posted about this including articles here, here and here.  And, unfortunately for my colleagues at Target, I don't think we heard the last on this.

   Last time I talked about the consumer side of the issue, and how individuals should protect themselves from the effects of an information breach.  Today we'll look at the corporate side... Incident Management.

   Incident Management is a critical part of any information security program.  I don't think there's any governance framework that doesn't include this important topic.  I'm a fan of the way NIST lays this out in SP800-61, with a few modifications.

   In boxing and martial arts, the saying goes: the best way to avoid getting hit is to not be there.
  Similarly, the best way to avoid a breach is to assure your systems are secure.  Of course, we know that is not possible.  As defenders, we are challenged to protect all systems and data against all attack and disclosure methods.  Attackers only need find one way in.  And, of course, one mistake can undermine our efforts.

   So the first part of a solid Incident Management program is:

Prevention.  This means having:

• An Information Security leader - placed at a high enough level in the organization.
• An Information Security program - because one person can't do it alone.
• Security strategic and tactical plans - you need know where you're going.
• A process to build security in - because bolted on just doesn't work.
• Asset and situational awareness - you need to know what you've got and what's going on.
• Periodic risk assessments - to help identify potential problems.
• Logging and SIEM - to help you know what's going on and correlate information.
• Continuous monitoring - for the ongoing view.
• A knowledge of what is normal - so you know when things aren't.
• A risk management approach - to help you to put resources where they are needed most.

   This is a lot, and it's not easy.  All of these items should be part of your long term strategic plan and road map.  Create that plan and start... then get better with iterative improvement.

   Next is:
Planning and Preparation.  There are a number of pieces here:

• Threat modeling - to help you think about what might go wrong.  There are some fun ways to do this including the card games Elevation of Privilege and Cntl-Alt-Hack.  Pull a team together and brainstorm.  Get creative.  You'll be surprised what you can find out.
• Event classification - the words "incident" and "breach" are loaded terms.  And the use of either can have statutory implications.  I like to handle this in two ways.  First, the terms Event, Investigation, Incident and Breach should be defined in your Information Policy.  Next, put in place procedures that specify who can declare an Incident or Breach.  Typically this should be a collaboration between Security and Privacy.
• CIRT/CERT - the security team can't, and shouldn't, handle investigations alone.  You don't want to wait for a problem before you figure out what areas and functions you'll need to help. 
• Exercise - Don't wait for an actual problem to occur before you review, and even test, your plans.
• Communication - This is a key that is often overlooked.  Connect with senior management and execs.  Find out what concerns them.  Connect with legal, marketing and communication.  Find out what channels already exist for contacting customers, partners, affiliates, the media and law enforcement.  If channels don't exist then partner with these areas and create them.  As we'll discuss later, one of the biggest failures of breached organization is in communications.

   Those steps set the table so we are prepared to respond to problems.  Next time I will talk about the Response and After Action processes.

   Are there any additional or different steps you use in your program?