I remember being at one of the early PCI Community Meetings and someone from the PCI SSC promised that the PCI DSS would be periodically updated to reflect changing business conditions as well as changing threats. Here we are more than a decade later, and we have version 3.2 of the DSS, but it has been changed more for changes in threats and very little for business.
Their rationale was that they wanted to minimize the number of compensating control worksheets (CCW) that would be needed for the majority of organizations. This was in response to v1 of the PCI DSS that required that data encryption keys change annually. Most large merchants who were participating organizations (PO) complained that it was taking six months to a year or more to encrypt their transaction databases and files. Requiring annual key changes would leave those databases and files at risk because they would always be in a state of perpetual decryption/encryption. As a result, almost everyone had a CCW for that requirement. So, the Council changed the requirement to require the changing of encryption keys when they were believed to be compromised or if one or more persons who know the keys leave the company or change roles.
The reason I bring this up is that I have been dealing with financial institutions and their PCI compliance issues for the last few years. If there is anything more frustrating, it is trying to apply a standard written for merchants to organizations that are not merchants. It seems like every time I turn around; a requirement needs a CCW, particularly when concerning requirement 3.4.
I am sure the Council will point to requirement 3.2 as their token change that took into account issuers. But that does nothing for the other requirements that financial institutions struggle. The biggest reason a lot of the PCI requirements are a struggle is that financial institutions are in the business of; surprise, surprise; processing, storing and transmitting cardholder data. That IS their business. 3.2 was a great change for issuers, but a lot of the rest of the PCI DSS is a huge pain for a financial institution without a lot of CCWs and the blessings of the requisite card brand(s).
Let us look at a few requirements where CCWs are needed when assessing an FI.
3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) – this can be very problematic for financial institutions. The reason is that while they can encrypt or tokenize the data, they also need to decrypt/detokenize it as well. In a lot of cases, they need to do those operations quickly and very often. It is not that the FIs do not want to protect the information, it is just that they have some unique issues in meeting PCI requirements.
The best example of this situation is debit cards. Debit cards must be tied to a demand deposit account (DDA) such as a checking or savings account. That means somewhere there must be a mapping of the debit card into the core application system. But to process transactions from the card networks when customers use their cards, the PAN must be decrypted/de-tokenized so that the payment can be approved or declined. This decryption/de-tokenization process needs to meet a timing standard, so adding to the processing time is usually not an option. As a result, it is not unusual to find that the PAN to DDA mapping file is not encrypted or tokenized.
6.4.3 Production data (live PANs) are not used for testing or development – when part of your business is all about processing, storing and transmitting sensitive authentication data (SAD) and/or cardholder data (CHD), using a few card brand test accounts like a merchant would use for testing is not going to work. Particularly when you are testing with one of the card brands to certify your application. In those instances, the FI and brands are going to demand the use of a large and varied set of PANs to ensure that systems are functioning properly. The only way to do that is with live data from production.
3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization
3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization
3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization. – requirement 3.2 addresses that issuers that have a business reason to retain sensitive authentication data (SAD) can retain it. However, 3.2.1, 3.2.2 and 3.2.3 say that all of this data cannot be stored right after authorization. These requirements then go on to say the QSA must inspect incoming transaction data, log data, databases, etc. Well, guess what? The incoming transaction data always has SAD in it of some form because the FI has to authorize the transaction. As I said earlier, databases can have it because of the speed required to authorize. This is the FIs’ business, yet the standard does not recognize this fact.
The bottom line is that the PCI DSS does not reflect the realities of financial institutions. As a result, FIs require numerous CCWs to meet the PCI DSS requirements. As I stated at the beginning, the Council promised that they would address such issues to make CCWs the exception not the rule. Well, here we are, and in the FI world CCWs are commonplace. And as we move forward, it will be FIs that will be the focus of the standard, not merchants. Merchants will very soon be out of the payment card data business altogether with the exception of their POI. So, it only makes sense to adapt the PCI DSS to securing FIs.
We have separate PCI DSS and AOC documents for service providers. Maybe we need separate such documents in addition to revised requirements for financial institutions?
Seems like a good discussion topic to bring up at the upcoming Community Meeting.
PCI Guru 
Another issue is that unlike merchants, probably 50% or more of a retail bank’s employees need access to card data because, guess what, customers with card issues want to walk into a branch and have some deal with it. Segmentation cannot help in an environment where the people being kept away from card numbers are less than the people who need access.
Please don’t suggest having separate people or departments to handle card issues unless you also think it’s a good idea for merchants to have two register lines, one for cash and one for cards. And let’s not even talk about the fact that it’s 2017 and some mainframes still don’t have encryption at rest or how when a card brand sends out the list of “hot cards” you have to enter the full number to find who has it.
Hence the use of virtual desktop (VDI) solutions to minimize scope. Easier to deal with a Category 2x system in a branch than a Category 1.
Not to completely change the subject, but do you think the brands will approve CCWs from the processors and gateways for allowing early TLS sessions on their interfaces after 30 June 2018? The Council, in their infinite wisdom, is shifting merchant-caused vulnerabilities to the processors and gateways because of this little nugget in DSS v3.2, Appendix A2, “POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS, may continue using these as a security control after June 30, 2018.”
That’s all fine and dandy for the merchants’ compliance programs, but that means the processors and gateways must continue to allow early TLS on their interfaces beyond 30 June 2018 at which time they will fail their ASV scans. Now we have a situation where the Council is requiring the processors and gateways to accept all the risk of allowing early TLS connections because of the merchants’ security shortcomings. Do the processors and gateways get a free pass on ASV scans?
That is the least of my concerns. The bigger concern is the processor and gateway server systems will remain vulnerable to early TLS attacks well beyond 30 June 2018. This is not a processor problem to solve because they’ve been offering TLS 1.2 connections for years.
This is an acquirer problem to solve. Here’s why. They have been giving their merchants a free pass since 30 June 2016. The process was simple and painless for the merchants. All they had to do was submit a Risk Mitigation and Migration Plan to their acquirer. And as long as they can convince their acquirers their systems are not “susceptible to any known exploits for SSL and early TLS,” they can use early TLS beyond 30 June 2018.
This is a travesty and a train wreck coming. The only entity that is empowered to get 100% of their merchants to stop using early TLS is the acquirers. I would never give the merchants a free pass beyond 30 June 2018 and THE ACQUIRERS SHOULD BE PENALIZED FOR GIVING THEIR MERCHANTS A FREE PASS SINCE 30 JUNE 2016.
From a QSA perspective, how is the Council going to advise QSAs when assessing processors and gateways that are allowing early TLS on their interfaces beyond 30 June 2018? Time will tell, but my sense is the revenue loss next July will be material across the payments industry if the processors and gateways cut off early TLS.
Train wreck coming!
All good points that should be discussed in Orlando.
The only good news on this front is that the SSL man-in-the-middle attack is much, much easier to execute on an internal network than a public network.
Many terminal-based payment applications tunnel a simple messaging protocol known as SPDH through SSL/TLS to a payment gateway and don’t support the functionality needed to effectively mount a padding oracle attack. Specifically, most payment terminals do not support the following:
– The ability to easily switch between servers or to connect in parallel with multiple servers
which is a vector for malware.
– The ability to run arbitrary active content such as JavaScript or Java to run malware to
automate the generation of known messages needed for these attacks.
– Message headers or cookies which are used to control the formatting of the known plain text
messages needed for these attacks.
– Long running SSL sessions which are needed to support the large numbers of packet replays
needed to break the encryption.
The opportunities for the introduction of chosen plain text into a payment terminal application are very limited. The only inputs available are the payment cards themselves, the PIN pad keyboard, and some data elements received from connected POS applications. Additionally, virtually all of these vectors must be accompanied by an interaction with the PIN pad and would not practically allow for the large numbers of replays required to break the encryption.
It’s not all doom and gloom as you paint.
Hi, Jeff
No doom and gloom for the merchants.
Troy attended the open portion of our PPISC meeting two weeks ago at the FS-ISAC Fall Summit in Baltimore.
I brought this point up with him. The merchants get a free pass that is written into the book, but there is no black and white free pass for processors. He said, in no uncertain terms, the free pass for the so-called “specialized POS systems” also extends to processors and that we should work with our ASVs. My point was our interfaces will continue to be vulnerable to SWEET32, BEAST, POODLE, etc. Right.
We have already alerted our customer-base that we’re ripping out TLS 1.0 during the last week of June 2018.
I see that FirstData is doing so on 15 February. I spoke with Rick Van Luvender/FDC at the PPISC meeting and he said they will continue to allow the special POS traffic in.
Stephen Ames, CISA, CISSP
Senior Director, Security Compliance
Shift4 Corporation
1491 Center Crossing Road
Las Vegas, NV 89144-7047
702.597.2480 ext. 46700
fax 702.597.2499
http://www.shift4.com
sames@shift4.com
facebook.com/shift4corp
twitter.com/shift4corp
linkedin.com/companies/shift4-corporation
shift4.com/blog
Shift4 Corporation Copyright and Confidentiality Statement
The information contained in this electronic mail message may be proprietary to, confidential to, privileged information of, and/or the copyright of the Shift4 Corporation. It may be controlled in part or in full by contracted relationship and/or non-disclosure documentation. It is intended solely for the addressee(s). ACCESS BY ANY OTHER PARTY IS UNAUTHORIZED AND STRICTLY FORBIDDEN. The sender does not waive any related rights and obligations. If this message (or any attachments contained therein) has been sent to your organization in error, or have been otherwise intercepted, please do not review, distribute, or copy contents. Please reply to the sender that “A MESSAGE WAS RECEIVED IN ERROR” and then please delete the message including all related attachments from all (where applicable) email transfer agents, message stores, email gateways, email scanning systems, and/or logging systems.