Skip to content ↓ | Skip to navigation ↓

Recently, the State of California released their “Data Breach Report 2012,” which chronicles last year’s data breaches affecting 25 million California citizens.

Reading through the report, there are a lot of numbers to digest but a few things stood out for me:


1. Breaches aren’t just about hackers

It’s true that 55% of the breaches were a result of malicious outsiders and insiders.  But what makes up the other 45%?

The second largest category was physical loss (documents, storage media, and hardware like laptops), which accounted for 27% of the breaches. This means there were some big weaknesses in hanging on to things that were sensitive or valuable.

This could be improved through training, better tracking of assets, and (in my opinion, at least) taking a hard look at who has custody of what data and whether that is appropriate.

The third category, making up 18% of the breaches, is made up of procedural problems.  This is where either sloppiness or naiveté plays a big role – people either transfer information to another party in an insecure way, or forget to render the information unusable when they toss it out.

2. Logical security may not be logical

No, I’m not trying to be funny.  In the report, a lot of things were included in that 55% of the world called “Logical.”  For example, 23 of the compromises grouped under “Logical” were due to credit card skimming devices on a point-of-sale terminal – is that really a Logical Security incident?

Sure, it’s theft of logical data but a skimmer sounds more like a physical issue from my perspective.

What Can We Learn From This Report?

There were some good takeaways presented in the report, such as moving toward mandatory encryption laws, reviewing and tightening security controls, training employees and contractors, and things like that.

Those are all very good recommendations. I think there are some other lessons to be learned, as well:

Organizations must take responsibility for data and information protection from an “end-to-end” perspective.

  • Ensure you understand where information is stored, how it moves around through your processes, who has access to it, and so forth throughout the entire life cycle.
    • This includes applications that process the data, collection devices, inter-application communication, transfer of information to 3rd parties for any purpose, and things like that.
    • If you use 3rd-party processors or services, make sure you understand how they will secure your data and what security controls they have in place.
  • Once you understand all of this, implement security controls to make sure things don’t fall through the cracks.
    • For example, put in safeguards to protect the physical aspects of information security, such as making sure collection devices haven’t been tampered with, that any physical copies of the data are secure throughout their life cycles, and (if appropriate) that all information is discarded in a secure manner.
    • Add supervisory controls (aka ‘checks and balances’) to make sure that things are double-checked at critical handoffs so that things don’t ‘leak’ accidentally or turn into inadvertent data spills.
    • Audit the information you collect and find out if it is all truly necessary.  I’ve seen organizations that collect a lot of information “just in case” without knowing how (or whether) it will be used.  If you don’t need it, why burden the organization with protecting it?
  • Help the users become more secure.
    • Inform them about the security measures you’ve implemented (at a high level, at least) to help them understand why it important to practice due care with their own information.
    • Increase the chances of success by doing input validation, enforcing complex password rules, enabling multi-factor authentication, and making sure passwords are protected (salted hashes, if you please).
    • Don’t send out plain-text credentials, account information, or other sensitive data via email.
    • Use https: for your websites by default, and switch to https: even if the user types http: themselves

That list just scratches the surface but, hopefully, you get the idea.  I’ve had a lot of success in doing a “paper trace” of processes by diagramming out all of the steps in the process, who the players are, what systems & applications are involved, etc.

Once you have it diagrammed out, take example transactions and walk through the process to make sure you aren’t missing any steps.

Next turn on your “think like a hacker” brain and start thinking about ways you could compromise your own systems, see if there are any opportunities to grab information “in the clear,” and so forth.  You may be surprised at what you come up with.

If you’ve read the report (or have any lessons of your own), I’d love to hear any additional thoughts.


Related Articles:


P.S. Have you met John Powers, supernatural CISO?