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 
se·cu·ri·ty
/siˈkyo͝oritē/
Noun
The state of being free from danger or threat.
The safety of a state or organization against criminal activity such as terrorism, theft, or espionage: “national security”.
Your argument… in no way,shape or form addresses security or how “compliance” provides/supports it.
Please go back to the dictionary and try again.
Obviously, you did not read this post or you would have gotten the point. If you are complying with any security framework, then you are more secure than people who are not complying with a framework. That is because the frameworks are the product of the knowledge of a group going through similar problems and what they learned. If you are trying to do this on your own, then you do not have the benefit of the knowledge of the group.
Basically what you are imply is that frameworks are worthless. If that’s the case, let’s see how long you last on your lonesome without any benefit of any outside information. No reading of security blogs, even this one, no vendor security announcements, no CERT alerts, or access any frameworks such as PCI DSS/ISO 27K/HIPAA/etc. Good luck and God’s speed.
Yes, I’m kind of crabby today because of welding that is going on in our building that is filling my office with the stench of a bad electrical fire or toner burning in a copier. I have a roaring headache and I am really in no mood for people trying to be cute. So I apologize ahead of time for taking it out on your comment.
How silly! Heartland payment systems was compliant. Citibank was compliant. Compliance is having managers justify and interpret statements as they deem necessary to cover their collective behinds while not spending money on expensive cost centers like training and logging. Your argument is specious because, as you yourself point out, setting compliance guidelines leaves their interpretation open by people whose interests lie in other areas than security. In fact, when security people point out the fallacies to those with different agendas, they are chastised (or fired). So the compliance guidelines do not dictate the results of an audit, the people managing the process dictate the result – whether accurate or not. QED.
What you point out is a flaw in the PCI assessment process. If it were done correctly, there would be testing done for all requirements over the entire time frame of the assessment. Unfortunately, such an assessment would not necessarily reveal every potential issue regarding compliance.
Even then, security is not perfect. So, even a company deemed compliant can have a screw up and end up non-compliant and breached.
I’ve been milling about trying to come up with a mature, professional response to this. I’ve lost interest in doing so, so allow me to simply say, “what a colossal load of idiotic tripe, top to bottom”.
-most of “PCI” is crafted not by philanthropic members of “the security community”, but by vendors with something to sell you. Invent a standard that requires software you sell, fabricate market demand over night
-centralization of compliance standards fails intellectual honesty for the above reason, AND most certainly does hinder flexibility that would otherwise yield real, tangible, verifiable improvements in security
-centralization of compliance standards wastes efforts in delivering real improvements to security profile, as much time is dedicated to meeting the requirement of a blindly ticked box. With finite time and resources, you’re stuck dedicating time to meeting bureaucratically-driven legal obligations rather than real, useful deliverables, that would genuinely improve your security profile.
Having a few key pointers is fine, having a basic checklist is fine, but any security professional worth his salt can readily go into any PCI-compliant organization, point out why a number of the things they’re doing are completely worthless, of no benefit, or even a detriment in the real world, things they’re powerless to remedy because compliance standard dictates it needs to be done this way. But hey, who needs real, sensible disk encryption policies, at least you have endpoint-based antivirus (which has been useless since ~2003) installed on every machine!
Let me audit your audit, and there will be tears.
The point of ISO 27K, PCI DSS and the like are to share the experience of security professionals so that all of us do not have to learn the hard way. These standards are not developed in a vacuum, they are developed by security practitioners from around the world that come together to provide input. Yes, that includes vendors, but it also includes personnel from large consumers of the vendors’ products.
I am sorry that you see all of the compliance programs as ticking off a box, but that is what you get when you send a non-technical person out to do an assessment. What do you expect? You’d be no better at conducting a financial audit.
What you need to do is to stop hiring QSACs that have no experience managing a network, let alone securing one. There are such QSACs out there, but you have to actively seek them out.
I believe your conclusion is slightly wrong, as I’d never say that compliance is security, but rather say that security implies compliance. Please don’t get me wrong, as I am sure many of us don’t use the “compliance isn’t security” as an excuse but as a reminder that we always need to get better. To only comply with a framework doesn’t grants security. It is security which allows you to comply.
While I would like to agree with you, in my experience, the “compliance is not security” statement is more a dodge than a reminder. Those security professionals that run the best operations never bring up compliance as an issue, so I have to believe that you are right for those of us that truly understand our jobs.
I like this article. While I’ve certainly sat in the compliance != security camp for a long time what I’m going on about is taking a security standard, like PCI DSS, off the shelf, complying to it and then thinking your job is done.
Every company needs to develop a security policy and controls framework specific to their business. This should incorporate all those good things like threat modelling, risk management, corporate culture and, of course, external regulatory requirements. By all means base your homegrown on something “industry standard” like ISO27001 but ultimately you should end up with something unique, which, if complied with 100% gives your company “security”.
Two last points about “security”:
1) “Security” means as defined by your business, usually the sweet spot between cost to implement and potential loss.
2) This sweet spot, your company’s “security” is a moving target so, like PCIGuru says, the processes you’ve laid down to manage risk and threats need to be efficient and working, 100% of the time.
You brought up some very important points that are implicit in any discussion about security. Thank you.
You’re definitely poking lots of feathers recently! 🙂
Despite your piece above, I still strongly hold to the saying, “Compliance is not security,” and have to respectfully disagree with your points above. I don’t think you can argue otherwise, unless you change the assumptions and align compliance and overall security exactly. Unfortunately, no commonly defined “compliance” checklist meets that.
PCI DSS efforts are notorious for haggling over driving down the scope such that you only need compliance over a subset of the environment. Real security would cover the entire thing. I totally agree with your related points there! But anyone other than *real* security geeks will have an incomplete notion of what “compliance” is. Saying compliance is security will lead my CEO to think passing PCI DSS is enough, when it never will be as long as it’s just looking at CHD.
Compliance contributes to security, and with security you (probably) have compliance, but I can’t ever reasonably say, “Compliance is security.”
And this doesn’t mean I assume “security” is perfect or the end result is perfect. Just that it will almost always be a larger value than just compliance to any framework/checklist alone.
Regardless of the security program you follow, if you comply with that program, you are likely more secure than if you were not following any program. If you take the PCI DSS and apply it across the board to all your systems, you are more secure than if you used nothing. The point of all security programs is to leverage the knowledge and experience of others that are further into the security process than most to provide guidance to the rest of us. At the end of the day, pick your program, comply with that program and you will be more secure than you were. What you are arguing about is how you prove you are more secure and that can be a very subjective measure even though more and more literature is available to quantify and measure security.
Yes, the PCI-DSS is imperfect and the interpretation of the requirements is inconsistently subjective from security professionals to QSAs to compliance officers. Throw in a myriad of systems, applications, OSs and infinite ways to do business to make PCI compliance very interesting …
Security frameworks are like that because of the many different ways organizations can solve problems and achieve the same results. If frameworks totally dictated solutions with no flexibility, i.e., only Checkpoint firewalls, Cisco routers and switches, Microsoft Windows Server and Java applications for example, then people would complain that they had no flexibility and could not be creative and differentiate themselves from their competitors.
How an organization complies with whatever relevant security framework is always going to be subjective if the framework does not explicitly dictate solutions. As a result, what you view as subjective is actually applying the requirements to a particular organization’s environment and culture. Yes, there are going to be requirements where the subjectivity is removed such as with 8.5, but there are other requirements where there must be flexibility such as with requirements 1 and 2 where many vendors and solutions can come into play in a myriad of configurations but all ending up at a secure solution.
I have never heard the phrase “compliance is not security”, but have heard, and even used, being compliant does not necessarily make things secure. There are times when an implementation is far more secure than what is called for in a set of security requirements that may be non-compliant to those same security requirements. What frustrates me is when compliance is held at a higher level of importance over security. This is usually due to the fact that those measuring compliance are not security professionals and simply rely on a check list to sign off that all is in order and “secure”.
One of my favorite quotes is, “In theory, there is no difference between theory and practice. But in practice, there is.” In theory, there is no difference between compliance and security. But in practice, there is. So PCI would be a fine framework for the management teams of organizations who are earnest about mitigating information technology risks. However, too often the management teams simply go for the absolute minimum, taking a “check box” mentality. So it’s not the theory that’s the problem, but too often the practice.
My favorite quote is, “In theory, theory works.” But as you accurately point out, it is when security is put into practice is where the trouble starts. And troubles can get even worse when people are added into the mix.
Yes, there are plenty of frameworks out there to choose from. The point I am trying to get across is that if you are not complying with any framework, you are not going to be secure. Therefore, compliance with a security framework really does mean security.