SC Magazine put out a good article last week entitled Beyond the Checkbox: PCI DSS. The article cover new revisions in the Payment Card Industry (PCI) security standard (Data Security Standard DSS).
The point of the article is something I've been saying for years... That we can simply treat security regulatory standards as checklists. It's not about just meeting the minimum requirements. It's about integrating the standards into your security program.
Now, I'm not completely dismissing checklists. In fact, I think they have some great places within your program. For example: server build checklists; server hardening checklists, and; an SDLC checklist. I'm a big fan of the CIS checklists for hardened configurations. I also like a standardized secure engineering process (or SDLC) with specific steps.
As I've discussed here in the past, one size does not fit all. While we can all share our processes, it's critical to tailor any process or checklist to your environment.
But here's my main point... Compliance does not equal Security!
We can have compliance but not have security. If we implement only a minimum security regulatory standard, focusing only on the particular data type (like credit card data for PCI), then an organization can easily meet the minimum standard but still not have a comprehensive security program nor defense-in-depth.
So, does compliance have its place. I think it does. First of all, over the years organizations have not done an adequate job of securing data on their own. So, at least in the US, the government had to step in. I'd prefer it if we could have self-regulated this issue, but that opportunity is long gone.
There is a second benefit to compliance regulations... they can help us justify our security programs. Sometimes you need a good regulatory standard to get the attention of senior management. Sometimes that's what is needed to get funding. And then, when you have their attention and you have some funding, the key is... what will you do with it? When you have the interest of senior management, that is the time to promote your holistic security program. When you get funding, that is the time to build your holistic program. When you tailor your program, based on sound security principles, to your unique organization - you can have compliance as a by-product.
If you have a strong, holistic security program, you will achieve compliance. Security will imply Compliance. But Compliance does not imply security.
Discuss! How do you use compliance to advance your security initiatives?
No comments:
Post a Comment