Did you check your conference goodies?
This year I went to the RSA to have lunch with some friends.
It was nice to get together with some other SANS ISC friends too, as Johannes, Marc and Lenny.
Good to see them again. Also while visiting the expo, something occurred to me. Some booths were giving away pen-drives with promotional material. It is easy to imagine that the booth was always crowded.
So, to get your pen drive you just put your business card and pick your pendrive among several over the table and go away...cool...
I don’t like people scanning my badge or using my business card to send me offers later, so , previously, I went to some other booths, collected a bunch of business card from sales people (they love to give them away...:) ) and went to the 'pen-drive booth' to get mine...:)
If I have a malicious intent, I would go to some other place, plug my new pen-drive, load an autorun-kind of malware, or fill it wth malicious PDFs and return it to the crowded booth table full of pen-drives...And I would be able to do it several times...
An average user would get it, plug in his computer and happily install it and be p0wned…
-----------------------------------------------------------------
Pedro Bueno ( pbueno // isc. sans. org)
http://twitter.com/besecure
SANS Internet Storm Center Winner of RSA Social Security Award for Best Technical Blog
We've been informed that we have won the Best Technical Blog award (though we'd dispute that we're actually a blog :) this year from the RSA Social Security awards. We'd like to thank you for not only nominating us, but for your continued support of our efforts, for reading our work and contributing to DShield and sending information in of interest. That said, we aren't done evolving and continuing to improve the services we provide. That said:
What can we do to improve our services?
What would you like to see added?
Is there something we are doing that we should stop?
Let us know your feedback!
--
John Bambenek / bambenek \at\ gmail /dot/ com
Data Leak Prevention: Proactive Security Requirements of Breach Notification Laws
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
Comments