“It depends upon what the meaning of the word ‘is’ is. If ‘is’ means ‘is and never has been’ that’s one thing – if it means ‘there is none’, that was a completely true statement.” –President of The United States of America, William Clinton
It has been an interesting time as the December 31, 2014 deadline approaches and version 2 of the PCI DSS comes to its end of life. I have started to notice that there are a lot of security professionals and others that are closet lawyers based on the discussions I have had with some of you regarding compliance with the PCI DSS.
The first thing I want to remind people of is that if you do not want to comply with one or more of the PCI DSS requirements, all you have to do is write a position paper defining for each requirement you find onerous, why it is not relevant or not applicable for your environment and get your management and acquiring bank to sign off on that paper. But stop wasting your QSA’s or ISA’s time with your arguments. It is not that we do not care, but without such approval from your management and acquiring bank, QSAs and ISAs cannot let you off the hook for any requirement.
With that said, the first lawyerly argument we are dealing with these days revolves around the December deadline. We continue to get into arguments over what the deadline actually means.
It appears that the PCI SSC and card brands’ repeatedly saying that version 2 is done as of December 31, 2014 was not clear enough for some of you. And further clarifications from them that any reports submitted after that date must be under version 3 are also apparently too much for some of you to handle. I do not know how there could be any misinterpretation of ‘DEADLINE’, ‘DONE’ or “AFTER THAT DATE’ but apparently, there are a lot of people out in the world that do not understand such words and phrases. Then there are the amazing contortions that some people will go to in a twisted dance to the death to get around this deadline.
Where have you been? How could you have missed this deadline? It has been known since the PCI SSC announced their change when standard updates would be issued back with the release of the PCI DSS v2 more than three years ago. But even assuming you were not involved back then, the PCI SSC announced the deadline over a year ago with the release of PCI DSS v3. Either way, it certainly should not have been a surprise as there has been plenty of warning.
But then do not take this out on your QSA. QSAs are just the messenger in this process and had nothing to do with setting the deadline. The PCI SSC and the card brands set that deadline. You have a problem with the deadline, complain to them. But if you are willing to listen, I can save you that discussion. They will politely tell you the deadline is the deadline. You are out of luck. If you do not like that answer, then stop taking credit/debit cards for payment for your organization’s goods and services.
The next lawyerly argument is around the June 30, 2015 deadlines for requirements 6.5.10, 8.5.1, 9.9, 11.3 and 12.9. Again, it is as though these dates were kept from you, which they were not. I even wrote a post about these requirements titled ‘Coming Attractions’ back in September 2013.
For those that are calendar challenged, June 30, 2015 is practically just around the corner in business terms. If you had years to get ready for the PCI DSS v3, what makes you think that you can just turn something on in a year and a half? Yet we continually see people arguing that until that date, they are not going to address any of these requirements. All as though, like a light switch, something magical will occur on July 1, 2015 that will meet those requirements.
For merchants, requirements 9.9 and 11.3 are going to be huge issues particularly for those of you with large networks and lots of retail outlets. If you have not gotten started on these requirements now, there is no way you will be compliant with these requirements by July 1. Both of these require thought, planning and training. They cannot just be started overnight resulting in compliance.
For requirement 11.3, the new approach required for penetration testing is resulting in vulnerabilities being uncovered. Organizations that did not want to get caught flat footed are finding that their network segmentation is not as segmented as they once believed. They are also finding new “old” vulnerabilities because of these network segmentation issues. The bottom line is that these early adopters are scrambling to address their penetration testing issues. In some cases ACLs need to be adjusted, but I have a few that have found they need to re-architect their networks in order to get back to compliance. Obviously the latter is not an overnight kind of fix.
Requirement 9.9 is all about ensuring the security of points of interaction (POI) as card terminals are referred. Because of all of the POI tampering and hacks that have occurred, the Council has added the requirements in 9.9 to minimize that threat. The biggest problems early adopters are running into is getting their retail management and cashiers trained so that they understand the threats and know how to deal with those threats. This requires creating new procedures for daily or more often inventorying of the POIs and visually inspecting them to ensure they have not been tampered with. Companies are rolling out serialized security tape that must be applied to the seams of POIs so that any opening of the case can be visually determined. Locking cradles are being installed for every POI to secure them to the counter. Let alone implementing those new procedures for doing at least daily inspections and what to do if you suspect tampering and how to inform corporate of potential issues. Again, not something that just happens and works day one.
For service providers, besides 11.3, requirement 8.5.1 is going to be their biggest issue. This requires the service provider to use different remote access credentials for every customer. This is in response to the breaches that occurred at a number of restaurants in Louisiana a few years ago as well as more recent breaches.
The problem that early adopters of 8.5.1 are finding is that implementing enterprise-wide credential vaults is not as simple as it appears. The biggest impact with these implementations is that service providers start missing their service level agreements (SLA). Missing SLAs typically costs money. So these service providers are not only incurring the costs related to implementing the credential vault solution, but they are suffering SLA issues that just pile on the injuries.
But the final straw is all of the people that closely parse the PCI DSS and only the DSS. You saw this with some of the questions asked at the latest Community Meeting. You also see it in the questions I get on this blog and the prospects and I clients I deal with daily. These people are hunting for a way to get around complying with a particular requirement.
This occurs because people only read the DSS and not the Glossary, information supplements and other documents provided by the Council. At least with v3 of the DSS the Council included the Guidance for each of the requirements. Not that adding Guidance makes a whole lot of difference based on the arguments laid out by some people. The Council could do us all a favor if they generally published the Reporting Template with all of the other documents. Not so much that people would necessarily read it, but it would give QSAs and ISAs more ammunition to use when these discussions come up.
Successful security professionals understand the purpose of security frameworks. These frameworks are meant to share the collective knowledge and lessons learned regarding security with everyone so that everyone can have a leg up and know ways of detecting and mitigating threats. Successful security professionals use these frameworks to get things done, not waste their time developing scholarly legal arguments or twisting the English language as to why they do not need to meet some security requirement. They put their heads down, review the frameworks, develop plans to implement the changes necessary to improve security, work the plan and deliver results. Do those plans always meet requirement deadline dates? Not always, but they are close or as close as they can get given other business issues.
The bottom line is that security professionals are not lawyers and good security professionals certainly do not sound like lawyers. But if you constantly find yourself sounding like a lawyer digging so deep to split legal hairs, in my very humble opinion, you really need to re-examine your career or lack thereof. I say lack thereof because, in my experience, security professionals that operate like lawyers do not have long careers. They move around a lot because once people realize that they cannot deliver, they are forced to move on. Eventually a reputation is developed and after that point these people end up forced to find a new career because the security community knows their modus operandi.
PCI Guru 
I read this post and started to smirk. I’m not a QSA or ISA but I was hired by my current client to help IT remediate systems and applications and get things ready for PCI DSS v2.0 (they hired a QSA to do the assessment) this year and then PCI DSS 3.0 for next year. The funny part is that my client is a state Judiciary. Lawyers everywhere and an internal IT staff that can’t agree on the definition of database.
It is their money; they either protect if from fraud, waste and abuse or suffer. No lawyer is needed to realize that sincere compliance helps and evasion does not work as well.
Either a firm uses standards inspired to reduce fraud, waste and abuse or they refuse. There is no deadline, there is only changes in the damage rates. First from the attacker populations themselves by exploitation of vulnerability unresolved. Second, more excessive fines from the Credit Card Acquirers themselves when lack of compliance if found to be compounding an instance of exploitation.
Standards that can change a firms actuarial experience of harm toward the less often or less worse side of the scale benefit from good use of compliance. Mitigating controls that can meet or beat the experience of mitigated fraud, waste and abuse rates will generally be received favorably by the Acquirer; but the QSA must warn the client that any such project that plans on accepted Mitigating controls is at risk.
When all the checks cross in the mail, the business that does not comply will pay more per each Incident than those that do comply. It their business, their customers and their privilege to process with Payment Cards that is at risk. In an avoidable Information Security Incident, somehow, “I told you so.”, just does not cut it.
Present the risk, describe the Mitigation Lifecycle risks, get sign off that management knew and preserve it, just in case a true event occurs and the firm likes pretending all else on the planet are responsible except themselves.
If a person likes Parachute dives, it can be cool; yet, some die of it. Corporate and Career Ending Moves are possible if one has no wish for PCI compliance. Worse still, even if one is compliant, Target really did smoke 61 million dollars in direct traceable cash — go read their corporate 10K statement if you do not believe me.
I find it somewhat amusing that you are perplexed about entities not understanding the notion of deadline when so many of them are relying on Operating Systems that are months/years past their end of support. But then, they have been (seemingly) allowed to get away with this, so why not push other deadlines? I see this as an industry/culture problem.
Before you throw merchants using old OSes under the bus, remember not all merchants are Fortune 1000 entities. 98% of them have less than 10 employees and have bought a solution from a VAR that told them a line of BS on how long they would get out of that solution. Now they are stuck with Windows XP or older and cannot upgrade without incurring costs that they cannot afford. And then the advice people are getting is faulty as well. I had a QSA tell someone that their XP Embedded was out of support when it is not because the application vendor had bought the extended support for their customers which is good through 1/12/2016.
That said, the DSS does not stop an organization from using end of life OSes. It just makes it a real project to come up with the controls necessary to protect such an OS.
I was at the QSA training in Berlin last week (redoing my QSA badge – long story – changing jobs and badge expiring) – the trainer specifically stated (and we asked him to repeat it) that if your client starts a v2 assessment this year and continues into 2015 they can still submit the RoC assessed against v2. However the client must be compliant with all v3 requirements regardless (if that makes sense?). So when you say it seems very clear, the Council may not actually be helping itself here 🙂
As I always like to say, “In theory, theory works.”
The Council can say whatever they want to say, however the card brands are saying something different. In the end, if your acquiring bank agrees, you can do exactly what you want. However, for those merchants and service providers that connect directly to Visa and/or MasterCard, the deadline is the deadline.
I don’t think you would necessarily need to throw all the assessment work out. But if I started a v2.0 assessment this year that ran into 2015 I would transfer the findings to the v3.0 reporting template or SAQ, adjusting reporting requirements as needed, and then test any new requirements.
By the way, PCIGuru, I really loved this: “Successful security professionals use these frameworks to get things done, not waste their time developing scholarly legal arguments or twisting the English language as to why they do not need to meet some security requirement.”
What are even worse are the merchants who believe they are both lawyers and security professions, lacking credentials and experience in both. Those types abound in higher ed. Sometimes I just have to say, “Sorry dude. Your PhD is in geography.”
Mean Gene