Protecting a Better Internet

While at the RSA Conference, I took an afternoon out to head over to Bsides, where I participated in a panel (video in two parts) looking at the PCI Data Security Standard, and its impact on the industry. The best comment actually came to me in email afterward:

It's worth remembering that, no matter what your opinion of PCI, the simple fact of the panel discussion today says something impressive about the impact the standard has had, and the quality of the industry's response.  Other areas of infosec haven't matured nearly as much, or as quickly.

Far more than any standard to date, PCI has improved the state of security across the board. Some of that is in its simplicity -- the bulk of the control objectives are clearly written, and easy to implement against. Some is in its applicability -- it crosses industries like few other standard. Even more, I think, is in its narrowness. Rather than trying to improve security everywhere (and failing), it focuses on one narrow piece of data, and aims to protect that everywhere.

This isn't to say that PCI is the best we could have. Far from it. But it's the best we have, and we should look at its model and learn for future compliance standards.

Posted by Andy Ellis at 10:58 AM | Permalink

Last week, Anton Chuvakin shared his latest in the "compliance is not security" discussion:

Blabbing "compliance does not equal security" is a secret rite of passage into the League of High Priests of the Arcane Art of Security today. Still, it is often quietly assumed that a well-managed, mature security program, backed up by astute technology purchases and their solid implementation will render compliance "easy" or at least "easier." One of my colleagues also calls it "compliance as a byproduct." So, I was shocked to find out that not everyone agrees...

I think there are two separate issues that Anton is exploring.

The first is that a well-designed security control should aid in compliance. As one of his commenters notes, a good security program considers the regulatory issues; or, more plainly, a good security control considers the compliance auditor as an adversary. If you do not design controls to be auditable, you are building risk into your system (sidebar: what security risks are worse than failing an audit?).

But the second point is more interesting. Most compliance frameworks are written to target the industry standard architectures and designs. What if you are doing something so different that a given control has no parallel in your environment? Example: You have no password authentication in your environment; what do you do about controls that require certain password settings? What if your auditor insists on viewing inapplicable settings?

Then, you have three options:

1. Convince your auditor of the inapplicability of the controls.
2. Create sham controls to satisfy the auditor
3. Find another auditor

Posted by Andy Ellis at 7:14 AM | Permalink

At a conference recently, one of the panelists asserted that the California Disclosure Law (SB-1386) was the worst information security law in memory. I disagree. I think it is the best regulation around information security; even better than GLBA. Most information security regulations are about controls - that is, they specify how one should protect information assets. Sometimes, those are relevant controls - but in practice, every IT environment is a little different, and what works for one environment isn't going to work for another environment.

What SB-1386 has done for the industry is create a very clear cost for an information security breach. Now, companies will, hopefully, think about what controls are relevant for their environment. And maybe, just maybe, that will lead to better security.

Posted by Andy Ellis at 8:23 AM | Permalink