Immutable Security

Here are the five links that I found interesting for this week:

• The Shadowserver foundation is comprised of a group of volunteer security professionals who gather information about Internet-based crime. One of the more interesting projects is a compilation of how various antivirus vendors fare against 0-day threats. How does your vendor hold up?
• Logs are not much good if you can’t trust them. Maintaining log integrity is vital to a robust incident response process. Here is a great article on how to protect your logs from tampering. It’s not fool-proof, but it can go a long way.
• Information security is a profession that necessitates a solid ethical foundation. Security professionals are often trusted with the most sensitive of data. This presentation, from the Honeynet Project, tackles some of the more thorny situations about performing ethical research.
• Looking for a really awesome way to store and compare your Cisco configs? Rancid, or the Really Awesome New Cisco confIg Differ, may be just the tool for you. It stores Cisco configs in CVS and can let you know something changed. By the way, OSSEC is also capable of something very similar.
• Are you looking to use virtualization in your PCI program? It can be done, but like most technologies, has to be approached carefully. This guide will show you some of the things that need to be considered.

That’s it for today. Have a great weekend!

Yesterday, I wrote a post saying that the lady who cuts my hair needs to comply with 100% of the PCI standard. This was based on my experience in PCI in corporate environments, some of which do not actually store card holder data and are pretty low volume.

Saying that all merchants must adhere to 100% of the entire standard is wrong. The correct statement is that all merchants must adhere to 100% of whichever SAQ Validation Type applies to them. The different validation types do indeed enforce only a small subset of the standard on many merchants, which was pretty much my major beef with PCI.

So, there you have it. PCI does have some reasonable requirements in place, depending on the circumstances of the transaction. I stand corrected.

When I had my hair cut today, I got to thinking about what level of responsibility this small business should have to protect my credit card data. This is not some big chain. It’s one lady with a couple of employees to help out. She knows as much about computers as my Mom, which, no offense to Mom, is not a whole lot. It’s not that she (or Mom) isn’t smart, it’s just that they are ordinary non-computer folks. They have skill sets in different areas, and that does not make them any better or worse than a tech-savvy person.

Although she probably doesn’t even realize it, Lisa (the hair lady) is supposed to comply with PCI. She doesn’t even get a break for just having a card terminal. She has to comply with the entire standard. Some sections will not apply, such as if she does not store the card data, but she doesn’t get a “just the hair lady” break.

I think she should.

Don’t get me wrong, I actually think PCI is one of the best standards out there. Since it is so prescriptive, it doesn’t leave a whole lot of wiggle room for larger companies to justify their way out of it. It absolutely can lead to better security. I have witnessed it. But it is not a one-size-fits-all standard.

It’s unreasonable for merchants like Lisa to be expected to act like companies with security departments and dedicated budgets for lots of fancy controls. So while this may not be the expected position of a security professional, I can’t ignore that little voice in my head that says she should just do what she does well–that is cut hair–and not worry too much about credit card security. PCI is not a law, and the chance of her suffering extensive damage from a credit card breach is small. A few reasonable precautions are all she should have to worry about. Anything else is a design failure of the credit card system and should be addressed there.

Update: Be sure to read the follow-up post where I stand corrected.

Awhile back, I wrote an article for the “Security Catalyst” blog about the economics of data breaches. In the article, I wondered if companies should compensate customers for poor handling of their information, even before a breach. Since companies often roll the dice with poor security, they have little financial incentive to change their behavior unless a breach happens and it hits the bottom line.

Now, Hannaford, who helped to enable the exploitation of millions of credit card numbers by their poor handling of the information, may be forced to compensate the victims.  At issue is whether one’s time and effort to prevent further damage to their identity, is worth compensation.

Previously, a judge ruled that since the banks offered the customer zero-liability protection, the customer wasn’t owed anything by Hannaford. That gave Hannaford some level of protection against costly lawsuits.

However, as the courts are now considering, one’s time may have value. If one is spending time trying to clean up Hannaford’s mess and prevent further harm, then maybe they should be compensated.

I agree that we need strong financial penalties to send the right message to the custodians of our information. Money seems to be the only thing most large corporations understand, so we need to make it more financially preferable to protect the information properly in the first place.

My concern is that we won’t really see improved security because of this. I envision the companies merely passing the breach cost off to consumers as they would an increase in corporate taxes. I’m not confident that they would “get it” and really start to take the responsibility of data custodianship seriously. That takes a conscience and that’s something many large companies lack.

To be fair, I’m also concerned that data breaches in companies who practice security very well would be seen as equivalent to those who shirked their responsibility. I work in the security profession and I’ll be the first to admit that even those who seem to be doing everything right have breaches. All it takes is one missing patch.

In the end, perhaps the solution to work toward is something of a hybrid between financial penalties for poor handling of information–even before a breach–and criminal penalties for the executives who enabled a breach to happen under their leadership. Just as one who is present at a murder scene can be charged as an accessory to a crime, perhaps an executive is also liable for enabling a breach to happen.

Finally, let’s not forget that the criminal who exploited the vulnerability is most at fault. Although the data custodians deserve their fair share of the blame, it takes someone at the other end of the keyboard doing something they shouldn’t be doing for a compromise to happen.