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. Assessees are required to provide proof over the assessment period to prove 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!
PCI Guru 