Most organizations are faced with some form of compliance requirements.
Whether you're talking about the healthcare vertical, the payment card industry, banking, some Frankenstein's amalgamation of those, or something entirely different - it's clear compliance is a necessary evil on the budgets of an overwhelming percentage of our employers.
It's odd then, that in the several years I've been working directly with CISOs and business security leaders, no one ever seems to "get to" a state of compliance. It seems like everyone always has outstanding issues they'll be remediating this year, waiting on the next audit to find out where the next deficiencies are to be fixed.
In a twist of timing, my friend James Costello (@n0b0d4) on Twitter coincidentally made a comment about a treadmill covered in clothes... which immediately lit that proverbial light bulb over my head.
How many organizations out there (and subsequently their Information Security professional employees) feel like they're on a treadmill (or the "compliance hamster wheel of pain" to make the point more visually) when it comes to compliance?
No matter how hard you work at fixing last year's deficiencies, the auditors find new stuff this year and once again "meeting compliance goals" is the 2012 project. Not again!
The problem with compliance that many of us IT Security professionals are rallying around is that it's different based on the auditing agency. The goals are always a moving target, regulations change from year to year, and arguably never actually more secure than when you started. Does any of this sound familiar?
Getting off the compliance hamster wheel of pain isn't a trivial endeavor - heck in some organizations it may not even seem possible. There is hope...
You've probably heard people say "If you're secure, you're probably compliant," but like most of us, thought it was much easier said than implemented. In fact, you can't just tell a PCI auditor "Hey, we're secure, go away" right? (I know some of you wish you could, though.)
So what can you do? I have seen successful reverse-mapping of security program items against aggregated compliance requirements work brilliantly in the past. Let me give you a quick example of how that works.
Say your organization is subject to HIPAA and PCI-DSS compliance regulations. You have a security program in place and a relatively good set of security policies - so how do you avoid being the hamster? You start by listing out your compliance requirements for the business year. So for FY12 you will need to be PCI-DSS and HIPAA compliant, check.
You then have someone mull through the compliance documents and pull out things that overlap, or are similar enough and place them into operational and advisory security buckets.
Once that's done, you simply map those against your existing security program and controls/policies - and see where you have compliance requirements that don't have a friend on the program side. That's where you're deficient.
Odds are, you can usually close out multiple compliance requirements across multiple requirements regulations by doing something singular in a security program. Performing software security audits during various phases of your SDLC solves many compliance requirements across many regulations... and that's just an example.
Yes, it takes time. No, it's not simple. Yes, it is tedious and difficult and someone will have to draw the short straw... but ask yourself - is the alternative of being a hamster a better alternative?
Cross-posted from Following the White Rabbit