In parts 1 and 2 of this blog series, I presented the types of risks of data breaches and the components of a successful Incident Response plan.  In this article I'd first like to present some of the issues most often present in incident response plans. These are based on my personal field experience conducting security assessments, audits and reviews over the past few years.

1) The absence of a document plan (OK this one's obvious, but WAY more than the majority of the banks I've reviewed are in this boat)

2) The over-reliance on IT staff to conduct incident response (read: bull in a china shop)

3) No knowledge of evidence preservation and chain of custody

4) Ignorance of data breach notification requirements from regulations and standards like PCI DSS and state laws

5) Lack of clear roles, responsibilities, accountability, consistency, due dilligence

6) Lack of consideration of the various types of attackers, their methods, anti-forensics, ways they covertly "set up shop", pivot to other machines, use multiple attack vectors and exploits, escalate priveleges and access, and use smoke screens while quietly steal data

Now, taking a look at just data breach notification laws, here are some of the factors to consider when determining whom to notifiy:

• What type of information was compromised (SSN, account number, name?)
• How many records were compromised?  Is this below the requirement for notification?
• Was the information encrypted at the time of the breach? Did the attacker also have the keys to decrypt?
• Was the information electronic, paper or other when it was compromised? Does it matter?
• Is there actual or just suspicion of ID Theft or abuse?  Which is required for notification?
• What if the account holder or individual isn't a resident of this state?  Does it matter?
• Who must be notified? (customers, card brands, credit bureaus, state attorneys general if residential, etc.),
• Can we as an institution define and then make a claim a "no risk of harm” to avoid notification?
• Who pays for the notification costs?

This concludes my 3-part blog series on incident response.  If you feel any of this has been helpful, informative, entertaining or otherwise, please leave a comment.  The content of these articles, like the rest of my blog posts, are solely mine and not necessarily those of my employer or any other entity.  Yours will be treated the same. 

And by the way, the BankIT Program incorporates most if not all these thoughts in its approach to Information Security and Incident Response.  The program includes a section for IR policies, procedures, documentation, and testing, with templates for each being added with each release.  If you're interested in knowing more about our IR plan, how to incorporate it into your own ISP, or how to start fresh with a cohesive master Information Security Program, just contact us through our website.  Cheers!