Data Leak Prevention: Proactive Security Requirements of Breach Notification Laws

Published: 2009-04-24
Last Updated: 2009-04-24 02:12:26 UTC
by John Bambenek (Version: 2)
1 comment(s)

I'm beginning to prepare for a talk I plan to give at SANSFIRE 09 on Data Leak Prevention. The talk will basically cover both lost of trade secrets and the loss of NPI (covered seperately because the risk profiles are different). As part of the research I've been looking at breach notification laws of the various states (which also seem to be used as models for other countries).  The particular interest I have is in the proactive requirements that the laws seem to imply and exactly what that means.  First, breach notification laws are written to require businesses to report the potential acquisition of NPI (non-public information) by unauthorized entities.  The define NPI as basically being name plus any of the following (sorry, this is US-centric but what follows applies anywhere):

  • National Identification Number (or you may euphamestically refer to it as a Social Security Number)
  • Driver's License Number
  • Financial Account number (whatever information is required to commit fraud, and in some cases, just the number)
  • Medical information
  • Health insurance information

To clarify, financial account number could be a bank account number (with routing number), credit card number, or debit card number.  Some states require whatever requisite PIN there may be (not applicable with bank account numbers), some states require just the financial account number. If that information is compromised, a notification needs to be sent to consumers in a timely basis.  This makes sense because the company won't be the victim of fraud, the consumer will be.  So the regulation is efficient because it deals with counteracting an externalizing incentive (a little love for those economists out there who get what I just said.)  The notification part is pretty straight forward, that's not what I'm talking about here.

The laws also require both an information security program (undefined) and "reasonable security measures" to prevent the acquisition of NPI data.  This part, at least in the law, is almost intentionally "squishy". While it is probably best that legislators don't spell out technical controls in detail in statute, it makes the task of compliance a bit harder.  However, there are a couple of breach notification enforcement actions that spell out at least what the FTC and the various state Attorney Generals believe "reasonable security measures" include, and it's safe to assume that they will approach future breaches with the same, if not more stringent, standard.  What appears to be what they define as reasonable security measures are:

  • Use of encryption with data at rest and in transit, both within and outside the organization
  • Limiting access to wireless networks
  • Use of strong passwords (and multiple passwords) for administrators to access systems and networks
  • Limit access of internal systems to the internet
  • Employ measures to detect and prevent unauthorized access
  • Conduct security investigations, as appropriate
  • Patching and Updating of anti-virus
  • Requiring periodic changes to passwords
  • Locking accounts after too many failed attempts at logging in
  • Storing credentials in insecure formats (i.e. cookies in the clear)
  • Use of secure transit for credentials (i.e. HTTPS / SSH)
  • Forbidding sharing of accounts
  • Regular assessment of networks and applications for security vulnerabilities
  • Implementing defenses to well known attacks
  • Inventory of NPI data stored, on what servers, for what purposes
  • Secure deletion of NPI once it is no longer needed

Those seem to be the explicit requirements laid out by the FTC, at least when they enforced breach notification against TJC and Seisint last year.  If I were called to testify as to what "reasonable security" was, I would likely include:

  • Seperation of duties required to access NPI (i.e. the requestor cannot simply look, needs someone from another team)
  • All access should be monitored (when feasible)
  • Ideally a seperate environment for NPI data repositories
  • Strong authentication to access NPI or for systems where NPI access is possible (i.e. controlled "root"/"administrator" access)
  • For non-recurring transactions (i.e. one-time), financial account information is redacted once money changes hands
  • Any accessor of information needs a true need-to-know to get information (i.e. do they really need to see the entire CC number)

California has published some general here. What are your thoughts?  What's reasonable security precautions?  Do you have data leak preventions tools and how are they working for you?

--
John Bambenek
bambenek /at/ gmail \dot\ com

1 comment(s)

Comments

One thing people may not realize is that the new Massachusetts law covers paper and electronic records. It also says that a name in conjunction with an account number WITH OR WITHOUT the PIN to access the account is confidential data. That means you have a notification-required breach if you do something as easy as mail a monthly statement to the wrong person because your automatic sorter messed up.

Older laws allowed financial institutions an "out" from the state laws if they were in compliance with their federal regulator's requirements (which pretty much do not exist). Newer state laws have eliminated that loophole mandating that at least the state government get notified. I have a feeling a lot of financial institution breaches used the older loophole to stay quiet.

Diary Archives