Compliance Leads to Security Breaches

Tuesday, September 28, 2010

Robb Reck


Maturing from Compliance to Security

How IT’s compliance mindset would look in another setting:

"Waiter, there’s a fly in my soup!” - patron
“Let me take care of that for your sir” – waiter, as he reaches into the soup to remove the fly
“Well, the soup looks fine now. Thank you.” – patron, as he digs in

In the world of Information Security, compliance rules with an iron fist. For InfoSec professionals in the health care industry, data must be stored and secured according to HIPAA guidelines.

For those in finance, GLBA rules. For those who handle credit card info, PCI-DSS is in charge. For all public companies, SOX is king. The specific rules for these industries differ but the consequence of failure to comply is the same across them all.

If you do not follow the InfoSec rules for your industry you will start by receiving fines, in the end you will be put out of business.

InfoSec professionals can make a very nice career for themselves by becoming well versed on the specifics of a data protection regulation. Companies spend billions of dollars a year to achieve compliance with the standards governing them. Certainly nobody can blame them for striving to achieve compliance. We cannot do business without it.

But does compliance mean we’re secure?

The most high profile hacks in recent history were performed against PCI compliant systems. The Heartland fiasco was performed against a company who could put their check in the correct box on a PCI checklist.

That didn’t prevent the breach. Nor the countless others before and since. So what were these companies doing wrong?

When you set your goal at “achieving compliance” whether it’s to PCI, HIPAA, ISO27001 or any other standard, you are settling for "good enough.” You are using someone else’s bare minimum standard for acceptability as your end goal.

Compliance will never bring security. No checklist or audit, regardless of how many agencies approve it, can account for all the ways vulnerabilities can strike in your specific environment.

No governing body can foresee the ways your organization will need to defend itself in the future. As long as compliance is your end goal, security will never be achieved. Much like the fly in the soup, your organization may look clean, but that’s where it will end.

Compliance forces you to permanently work in a reactive mode. While the main objectives for our industry standard regulations do not change often, the specific checklist items that auditors are looking for frequently do.

As auditors start adding new requirements to their lists you are continually forced to react and build, or buy, bolt-on solutions that will get you through yet another audit finding, but can’t get to the heart of your vulnerabilities.

Finally, compliance leads to security breaches. When an organization aims for compliance rather than security, vulnerabilities are the eventual outcome. Data protection standards are notoriously slow in incorporating new safeguards to defend against new hacker techniques.

Those who do the bare minimum to achieve compliance will be among the first to become victims of new zero-day attacks.

Organizations who focus on security will inherently achieve compliance. If you consider security throughout a systems’ lifecycle, continually run risk assessments internally (formal or informal) and allocate sufficient resources to security initiatives, compliance to regulations is not a challenge. Drive security into systems as early and as integrally as possible.

Just as we won’t settle for having the fly removed from our soup, we should not settle for security policies that just get us through an audit successfully.

Cross-posted from Enterprise InfoSec Blog from Robb Reck.

Possibly Related Articles:
Post Rating I Like this!
Ray Tan Security is far more than compliance, of course, compliance rules leads to security.
Robb Reck Ray, thanks for your comment. My position is that a compliance-focused company is going to be much less secure than a security-focused company. Compliance does not bring about security, but security does bring about compliance.
Susan V. James And lets don't forget that compliance auditors themselves may not be the greatest when it comes to assessing whether the controls you've put in place are adequate to meet the compliance objective. Many times, they lack sufficient technical expertise to accurately evaluate the technical implementation of controls.
Robb Reck That's another interesting point Susan. Additionally, auditors are often very ROI and cost oriented, and security threats are very difficult to monetize. Since it's much easier to determine the financial impact of missing a compliance requirement (SOX/PCI fines), those are more likely to get the attention. Non-compliance security issues are likely to be given very low priority, or canceled altogether.
Jamie Adams @Susan... I am so glad you brought up the point about some auditors lacking technical expertise. Many sysadmins spend a lot of time explaining false-positives to auditors. Settings that may be deprecated or different but the guidelines want the older one. It gets frustrating explaining or proving that the APPROPRIATE security is in place.
Mark Gardner As a Compliance Auditor I feel I have to respond!

Firstly you guys need some new Auditors!!! On the three years thing Lance, we are recertified to ISO27001 every 3 years but face surveillance visits every 6 months, the longest I've heard is 12 months.

Compliance Standards are not the issue when it comes to breaches. That is an excuse and a convenient one at that. I can only really speak about ISO27001, as that's my area.

ISO27001 for example says you need an Access Control policy - it does not tell you what that should be. ISO27002, is guidance - it is not prescriptive as to the ACP you put in place. You can do it the way of 27002 but let's be honest, how many techies are going to have a copy of the standard open when they are building their AD domain?

I audit against the standard, I'm not there to build an ACP, I want to see you have one for sure, and documented etc, but it is down to the experts in the field to design, test and build the infrastructure.

So if you're building for compliance you have an ACP, the devil in the detail comes down to Security Architects. I may advise on way things could be improved (for example disable accounts rather than delete to preserve Audit trails), but you cannot dictate on such a short time frame how things would be built.

For what it's worth the best practice process we use is that we have a two person Audit team consisting of a Compliance resource and a technical resource so that we can fully and appropriately assess the security risks with the audited asset(s).

As I have said in other posts I have written on here - compliance is everywhere not just for Audit. A breach of the ACP, is a breach of compliance - you create the rules.
Susan V. James There is also the option of doing implementation audits - having auditing oversight at the pre-implementation stages of the SDLC. However, that does require two separate teams of auditors, because those who participate in the pre-imp can not also perform compliance auditing - impartiality would be compromised.
Katie Weaver-Johnson Great points by all, but I wanted to add something to Mark's comment about the compliance standards being "guidance" and not prescriptive.

I completely agree with this point; most standards and requirements are just the blueprints for your security program; it is up to your organization to build in your individual-level requirements, security features, programs, etc. and communicate your requirements to your employees, staff, third-parties, etc. Just checking off the boxes on your audit or assessment definitely does not equal security, but building a comprehensive program will help you ensure ongoing compliance.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.