Security Hero Rotating Header Image

Proactive Security Requirements of Breach Notification Laws, (Fri, Apr 24th)

Data Leak Prevention: Proactive Security Requirements of Breach Notification Laws, (Fri, Apr 24th)

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?

Leave a Reply

Your email address will not be published. Required fields are marked *