As a QSA, we hear this comment all of the time.
“PCI is all about compliance, not security.”
The implication being that the person talking is interested in actually securing their environment not just being PCI compliant.
Yet as the conversation goes on, we get into esoteric discussions regarding scope and how scope can be minimized. Not necessarily a bad thing, but as these discussions continue, an underlying theme becomes apparent.
This conversation eventually leads to the QSA asking, “What are your drivers that are making you so concerned about minimizing scope?”
The inevitable answer is, “Because, we want to minimize the cost of and/or difficulty in implementing (in no particular order) information security, increasing information security personnel, how many devices we vulnerability scan and penetration test, critical file management tools, anti-virus licenses, devices needing log aggregation and analysis, [insert your security tool/product/device/appliance/widget here].”
It is at that point it becomes painfully obvious that the organization is not at all interested in security. In fact, they do not give a damn about security. Their only interest is in checking off the PCI compliance box and moving on to the next annoying compliance checkbox on their list.
I am sure a lot of you are questioning, “How can you be saying this?”
Because, if the organization were truly interested in security, all of the things they mention in their minimization discussion would already be installed in their production environment, if not QA and test environments. That is right. They would already be installed and not just on the PCI in-scope stuff. It would already be installed everywhere in those environments.
Why?
Because all of these security tools and methods are part and parcel of a basic information security program that follows information security “best practices”. They are not special to PCI, they are required for any successful information security program such as HIPAA, FFIEC, FISMA, HITRUST, etc.
People seem to think that the PCI SSC and the card brands came up with the PCI DSS requirements by arbitrarily pulling the requirements out of thin air. In fact, I have had people insinuate that the PCI standards are just there for the banks to be mean to merchants and extract more money from them.
But in actuality, the PCI standards come from a lot of recognized sources including the US National Institute of Standards and Technology (NIST) security standards and guidance, US Department of Defense (DoD) security standards and guidance, as well as “lessons learned” from the card brands’ cardholder data breach forensic examinations and working with information security professionals sharing their knowledge of what are the minimum, basic “best practices” required to secure data.
But the key words here are ‘minimum’ and ‘basic’.
Because guess what? If you want true security (remember that thing you supposedly wanted when we started), then you have to go beyond the PCI DSS requirements. Hear that people? If you want true security, your organization must go BEYOND the PCI DSS requirements. Organizations are complaining about doing the basics. Imagine what their complaints would be like if they had to do true security? They would be throwing a tantrum that would be easily heard around the world.
Want actual proof that organizations are not doing the basics?
Read the Verizon Data Breach Investigation Report (DBIR) or any of the dozens of data breach reports issued annually by forensic analysis firms. They all read the same; year after year after nauseating year. Organizations cannot consistently execute even the basic security requirements specified in any security standard. Even more disheartening is the fact that it is the same vulnerabilities and mistakes that are the root cause of the vast majority of breaches.
QSAs still get complaints from organizations about the PCI DSS being too difficult and costly to implement and maintain. Yet these same organizations have the gall to say that PCI is NOT about security.
So, before you go and tell your QSA that PCI is all about compliance, think long and hard about that remark and why you are saying it. Odds are you are saying it to look good, make a good impression with your QSA, show them that you are a true security professional and that your organization wants to be secure.
Think again. The truth will eventually come out. One way or another.
PCI Guru 
> If you want true security (remember that thing you supposedly wanted when we started), then you have to go beyond the PCI DSS requirements.
I agree. And that is the approach that I have taken in developing the CDE architecture with my clients.
But I’ve met a QSA who can’t see beyond the PCI DSS check boxes and who seems (my opinion) technically imcompetent when assessing the controls (e.g. RACF on a z/OS mainframe). When your QSA doesn’t understand how a browser redirect work or that encrypting card holder data BEFORE it’s stored in the database renders it unreadable by the DBA, you have a QSA more concerned with checking a compliance box than one concerned with security.
Hi PCI Guru,
Not sure if this is the right place but i’ve got a question about HPKP, a lot of big organisations like Amazon, Ebay etc don’t seem to be outputting the header. However Qualys are coming back to me at the moment saying that it’s a PCI fail. Whats your thought’s on this?
Is this simply a case of these organisations not caring or is it Qualys classifying the severity level of the header incorrectly.
Thanks
HTTP Public Key Pinning (HPKP) in theory was designed for secure use of TLS. But in practice has not always been implemented in ways that are considered secure. See this for the issues with HPKP – https://www.thesslstore.com/blog/industry-experts-say-dont-use-key-pinning-hpkp/. My guess is that Qualys and possibly other vulnerability scanners are looking at the implementation under these criteria and flagging those that they believe have errors in their implementation. I have yet to see such an error flagged in any of my clients’ scanning results, so this could also be something new that is just being flagged.
I could not disagree more. There are many organizations out here where the cost of implementing all the controls is cost prohibitive. Many organizations thus opt out of the risk by reducing the scope.
I do agree that the risk that can’t be opted out from should be enforced with everything PCI requires and then some.
Simply because an org wants to reduce the scope does not mean that they don’t care about security. If anything, these organizations are risk aware.
While I understand your comment, I would also tell you that the controls you claim are not relevant are the very controls that will keep your organization safe. They are the basics of information security. You may not like their costs and difficulty to implement, but they should all be in an organization’s network if they are operating a production environment and want to ensure security. There are open source solutions to a lot of controls as well as innovative ways to approach the controls without excessive costs, but in some cases there will be operational and manpower costs to getting “free” tools working at the same level as the commercial tools. And sometimes those costs are almost the same. This is the dilemma today with organizations and their IT. The basic cost to having IT is sometimes more than what an organization is willing to spend but should be spending. It is in those cases where management needs to understand that they are likely at high risk of a data breach or compromise that could destroy the business. They can accept that risk, but then they do not get to complain when it all comes crashing down due to a compromise.
I am in agreement with Javi. The controls may be ubiquitous for an SMB or Enterprise and should be deployed in a homogeneous manner across the business however the difference between achieving PCI compliance and alignment with regulatory or statutory standards is night and day. this is due directly to the compliance nature of PCI and the risk-based nature of other standards. The level of management needed on a PCI-eligible control is far more labour intensive and costly than an equivalent regulatory control. Consequently, limiting PCI scope through appropriate means like segmentation eases the burden on the Enterprise. QSA nit-pick to the point of splitting hairs when examining controls and their alignment with the PCI control objectives. Why shouldn’t the assessed entity also argue scope to the Nth degree??
No different than all of the safety devices now required on an automobile. I’ve read that those add at least 30%+ to the cost of a vehicle. Would you feel better if those costs were all the security tools were added into your cost of each piece of technology? The government seems to be heading that way.
Preaching my favorite sermon!