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

   I'm calling this part 2, but it's really the third in a series covering the consumer and enterprise sides of incidents and breaches.  This is always an important infosec topic, but the recent highly publicized issues effecting Target, Neiman Marcus and, as we're told, 3 other organizations to be named later brings this to the forefront.

   Many say that it's not a question of if we will suffer a breach, but when and how we will suffer a breach.  And yet there are organizations that consider this an optional capability.

   Last time we talked about the first two parts of the Incident Management program: Prevention and Planning/Preparation.

   Next is:
Communication. So these groups know their roles:

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.

Beyond the Checklist - Compliance v. Security

   SC Magazine put out a good article last week entitled Beyond the Checkbox: PCI DSS.  The article cover new revisions in the Payment Card Industry (PCI) security standard (Data Security Standard DSS).

   The point of the article is something I've been saying for years... That we can simply treat security regulatory standards as checklists.  It's not about just meeting the minimum requirements.  It's about integrating the standards into your security program.

   Now, I'm not completely dismissing checklists.  In fact, I think they have some great places within your program.  For example: server build checklists; server hardening checklists, and; an SDLC checklist.  I'm a big fan of the CIS checklists for hardened configurations.  I also like a standardized secure engineering process (or SDLC) with specific steps.

   As I've discussed here in the past, one size does not fit all.  While we can all share our processes, it's critical to tailor any process or checklist to your environment.

   But here's my main point... Compliance does not equal Security!

Stuff I Say - Iterative Improvement

   This is yet another in my "Stuff I Say" series of posts.  I like to think about concepts of security management, though these ideas can certainly be applied to IT management (and management in general).  The themes of these posts are both things I think about and things I actually say.

   We've all got an incredible amount of work to do.  Most organizations have too many projects and ongoing development work, as well as too many existing and legacy tech assets to secure.  There are not enough resources to go around and the shortage of talent has been discussed in the tech media.  Prioritization is always a challenge.

   Security professionals have a difficult job.  Protecting individual and corporate data, and systems and networks is complex and often not well defined.  We don't really know when we've got it "right" (if there is a right), but we often find out the hard way when we've got it wrong!

   So, when faced with a new project, some security groups want to try to do everything at once.  We can't boil the ocean... but we have to start somewhere.  Some call it baby steps. Some call it putting one foot in front of the other.  I call it Iterative Improvement.