“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.
