Compliance Is Not Security – Busted!

Saturday, September 17, 2011

PCI Guru

Fc152e73692bc3c934d248f639d9e963

You hear this as a common lament from security professionals, “Compliance is not security.” 

This remark has always sounded like a dodge to me.  I suppose the reason I think this is that a majority of the people who seem to utter this phrase always seem to have questionable security practices. 

But since I hear this complaint so much, I thought I should see if these people have a point.  So like Jamie and Adam on Mythbusters, I decided to see if this saying really held water.

The first thing I did was to get the definition for the term ‘compliance’.  From Webster’s dictionary, ‘compliance’ is defined as:

“Conformity in fulfilling official requirements.”

That definition seems to say it all.  If you are conforming to defined requirements, then you are compliant.  Therefore, whether or not an organization is secure comes down to whether or not the requirements they are complying with are deemed adequate to ensure the security of the organization. 

So, it is the standard that is the problem, not the compliance with the standard.  Let us examine the PCI DSS for its completeness in creating a secure environment.

First, the PCI DSS is organized into six domains and twelve requirements.  The six domains are:

  • Build and Maintain a Secure Network
  • Protect Cardholder Data
  • Maintain a Vulnerability Management Program
  • Implement Strong Access Control Measures
  • Regularly Monitor and Test Networks
  • Maintain an Information Security Policy

The naysayers in the group will point to the fact that the PCI DSS seems to be exclusively focused on the security of cardholder data.  While true, I would argue that the following domains are required across an organization’s network to ensure the security of cardholder data.

  • Build and Maintain a Secure Network
  • Maintain a Vulnerability Management Program
  • Implement Strong Access Control Measures
  • Regularly Monitor and Test Networks
  • Maintain an Information Security Policy

So we only lose the second domain of “Protect Cardholder Data” when we focus on the cardholder data aspects.  There are still five of the domains remaining that are relevant to an organization’s entire network.  And even if those are focused on the cardholder data environment, in order to ensure the security of the cardholder data environment, security would have to exist on the other areas of the network not part of the cardholder data environment. 

However, change cardholder data to employee data, contract data, board of director meeting minutes, customer data, product engineering data, and you begin to see that the PCI DSS can provide a framework for all of those sensitive data types as well.  As a result, I would argue that the PCI DSS does offer a reasonable framework for providing security.

Now, just so you know I have not taken a big gulp of the “PCI Kool-Aid.”  Is the PCI DSS the perfect security framework?  Not at all.  For that matter, there is no security framework that has been developed that is 100% perfect.  They all have their own flaws and problems, but for the most part they do an admirable job in securing an organization if properly implemented, monitored and tweaked. 

But let us be clear, there is no such thing as a perfect security framework because as I have said time and again – wait for it – security is not perfect.  For those of you that are implicitly selling security to your management as perfect need to stop it.  You are doing the security profession a disservice and are likely cutting your career short as well.

The real reason I think a lot of security professionals regurgitate the saying; “compliance is not security” is that they are confusing compliance with consistency.  True security requires 100% consistency in the execution of procedures.  However, not all security can be totally automated and some security practices must involve people.  Unfortunately, people are fallible, so 100% consistency is not possible when people are involved. 

Because we know people are fallible, we develop our security practices such that there are layers to protect us from the occasional missteps of people.  Those layers are structured around the control triad of protective controls, detective controls and corrective controls.  I have written on the control triad before, so I will not bother to explain these principles.  Needless to say, if your controls do not have these three components, then you are likely not as secure as you might think.

Because at some point people are involved in any control environment, compliance programs are developed to test an organization’s controls over a period of time to ensure that all standards and procedures are executed all of the time.  Compliance programs use frameworks such as the PCI DSS, SOX, HIPAA and the like to determine what areas to assess and to ensure that the requirements documented in these frameworks are being consistently followed. 

But the key is that controls are assessed over a period of time, usually six to twelve months.  Assesses are required to provide proof over the assessment period to provide that controls are being enforced 100% of the time.

This is an area where the PCI DSS falls short as a lot of the requirements are only assessed as of a given point of time.  Unfortunately, that given point in time can be different for each requirement.  As a result, it is very easy for an organization to be compliant on paper, but not compliant consistently. 

If the PCI SSC could make one change that would improve the PCI assessment process it would be to require assessing organizations over a period of twelve months.  I know of a few QSACs that follow such an approach, but they are few and far between.

The bottom line is that security professionals need drop the “compliance is not security” mantra as long as the framework used addresses all aspects of security.  All of you out there that are hiding behind this saying need to find some other excuse for not securing your organizations. 

“Compliance is not security” is an excuse, and a lame one at that.  Because if you are truly doing your job, then you are complying with some security framework and, therefore, compliance is security.

Myth busted!

Cross-posted from PCI Guru

Possibly Related Articles:
22371
Enterprise Security
Information Security
PCI DSS Compliance Data Loss Prevention QSA Network Security Security
Post Rating I Like this!
Fc152e73692bc3c934d248f639d9e963
PCI Guru I was an admin at one time in my life and I can tell you from the "School of Hard Knocks", your life is thousands of times easier if you are following the rules than if you are trying to go your own way. While I understand your complaints, I can also tell you that when people comply with the policies, standards and procedures, you tend to have significantly fewer outages and screw ups. And since security is all about execution without errors, complying with policies, standards and procedures goes a long way ensuring security.
1316364452
8b5e0b54dfecaa052afa016cd32b9837
Craig S Wright Actually, we presented data on this earlier this year and have another paper later in the year.

There is a sweet-spot. Past a point, increased compliance spend actually reduces security.

Also, compliance aligns in the real world with audit expectations leaving holes in areas that the auditors are not expected to cover.

See:
http://www.springerlink.com/content/dx71317201j5627h/
1316398973
Fc152e73692bc3c934d248f639d9e963
PCI Guru Like anything, you can have too much of a "good" thing.
1317071876
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.