I was recently reminded that we are in year three of the current PCI DSS version. According to the PCI SSC’s standard lifecycle, that means the Council is starting to work on version 4 of the PCI DSS and PA-DSS.
So what is coming in version 4 of the PCI DSS? The Guru and his fellow PCI Wizards have some thoughts.
Business As Usual
I have written about this before. Everyone is betting that business as usual (BAU) will make its official appearance in the next version of the PCI DSS. If the past is any indication, BAU will most likely be a “best practice” until June 30, 2018 and then required thereafter.
For those that have forgotten, BAU was introduced as a concept with v3 of the PCI DSS. Pages 13 and 14 of the PCI DSS discuss the concept of BAU. The idea being to get organizations to integrate certain requirements of the PCI DSS into their organizational procedures to better ensure the security of cardholder data (CHD).
When BAU was first discussed back in 2013, I was able to identify at least 213 requirements that could be considered as BAU requirements (277 if you include Appendix A). Samples of BAU requirements include:
- 1.2.a Examine diagram(s) and observe network configurations to verify that a current network diagram exists and that it documents all connections to the cardholder data environment, including any wireless networks,
- 2.2.b Identify any enabled insecure services, daemons, or protocols and interview personnel to verify they are justified per documented configuration standards,
- 1.a Examine the data-retention and disposal policies, procedures and processes,
- 1 For a sample of system components including all operating system types commonly affected by malicious software, verify that anti-virus software is deployed if applicable anti-virus technology exists,
- 6.3.b Observe processes and interview personnel to verify that follow-up to exceptions and anomalies is performed,
- 2.1.a Review the scan reports and verify that four quarterly internal scans occurred in the most recent 12-month period, and
- 8.1 Verify that a list of service providers is maintained.
Essentially, all the prospective BAU requirements are those that have some sort of timing involved for evaluating them.
Not only will adding in BAU be at issue, but I am guessing that the Council will probably reduce their use of the words “periodic” and “periodically” in the next version of the DSS. That is because with BAU they will likely begin to recommend actual minimum time frames for conducting these procedures. Known timings in v3 include annually, quarterly, daily, whenever changes occur and my personal favorite, whenever “significant” changes occur. Which means it will be all the more important for organizations to define what a “significant” change means in their environment.
But the introduction of BAU will likely not totally wipe out the use of “periodic” in the DSS. As a result, organizations will still have to define for those requirements that use “periodic” or “periodically” what the period is based on their risk assessment.
The bottom line is that if you have not been thinking ahead you need to get thinking ahead as to how BAU is going to impact your organization.
New with v3 was the addition of requirement 9.9 which focuses on managing the risks to the card terminal or point of interaction (POI). Originally dismissed by most organizations as an annoyance, recent events with Safeway, other merchants and ATMs, security of the POI has come into laser-like focus. And with more and more merchants implementing point-to-point encryption (P2PE) or end-to-end encryption (E2EE), the security of the POI becomes all the more important as it is the only device that remains in-scope for the merchant. It is believed that with all of the issues with POI that have occurred, the Council will focus on beefing up 9.9 to address these higher risks by defining review schedules.
The first requirement that merchants need to deal with much better than they have is 9.9.1 which addresses maintaining an accurate inventory of POI. If a merchant has not implemented P2PE/E2EE, then the risk that a POI is swapped out for one that has been tampered with is extremely high. Tampering of POI is typically done such that the POI does not appear to have been tampered with such as installing a USB drive to collect data or installing revised software in the POI.
The quickest and easiest way to identify swapped out POI is to periodically review your POI inventory and make sure that all the serial numbers of those POI in use are the same as the numbers on your inventory. If they are not, then you should take that POI out of service and get a trustworthy one from your transaction processor.
Another control that you should use is tamper proof tape over the seams of the POI. If someone opens the POI, the tape will be torn and it should be obvious that the POI has been tampered with.
Earlier I distinguished merchant that have implemented P2PE/E2EE from those that have not implemented it. So what, if anything, should merchants with P2PE/E2EE implemented be doing? P2PE/E2EE solutions require the injection of an initial key into the terminal as well as recording a device number. If any of that information changes, the POI will not work. So if the terminal is swapped out, it will not work without the processor properly configuring the POI. This does not mean that the merchant does not have to manage their POI inventory, it just means that reviewing that inventory does not need to occur as often.
So how often should POI be reviewed against inventory? For merchants that have not implemented P2PE/E2EE, I would recommend no less than weekly. However, I do have clients that review their POI at every manager shift change. These are clients that have had POI swapped out and/or tampered with. Merchants that have implemented P2PE/E2EE should review their POI inventory at least semi-annually if not quarterly.
The next area that will likely be enhanced is requirement 9.9.2 which addresses the inspection of devices. I would anticipate that merchants will now be required to develop detailed procedures for the examination of POI by their retail management and cashiers.
But unlike with 9.9.1, this will not be broken down by those merchants that have and have not implemented P2PE/E2EE. Why? Because of terminal overlays that can be placed on top of certain POI and go unnoticed. These overlays can collect CHD regardless of whether P2PE/E2EE is implemented. As a result, examination of POI will likely be required to be done daily if not more often based on the assessed risk.
For merchants that have implemented E2EE, they may need to have to do an additional check depending on where E2EE is implemented. If the E2EE solution does not encrypt at the POI, then these merchants will also have to examine their point of sale (POS) in addition to their POI in order to comply with 9.9.2. One of the big reasons for this is because of Target style breaches where a memory scraper was used to obtain CHD because encryption was done at the POS, not the POI, and the connection between POI and POS was in clear text.
For merchants that use integrated keyboard card readers or USB card readers, there are other schemes such as keyboard loggers, USB adapters and other attacks that focus on the POS for obtaining CHD. For those merchants, they will also need to be doing daily inspections of their POS systems to ensure that equipment that does not belong is quickly identified.
The final requirement that will likely see changes is with 9.9.3 which is all about training retail personnel in the procedures of protecting the POI. With all of the changes to 9.9.1 and 9.9.2, you had to know that training would also have to change.
The biggest change will be the mandatory training. Yes, it was mandatory before, but with the focus on tampering with POI, training of retail staff will be very important. Why? Because they are the people on the front line and would be the ones most likely to notice something not right with their work area.
In order for these people to notice things out of order, they need to be trained, trained often and trained repeatedly. This is why security awareness training is so frustrating for security professionals is that it takes more than just one session every year to be effective. That and the fact that not everyone catches on at the same time with the same amount of training and there will be some people that never catch on.
The bottom line here is that your retail personnel will need to be drilled regularly on POI and POS security. How you choose to accomplish that training effort is up to your organization. But doing little or no training will not be an option.
The obvious change here will be the integration of the new deadlines for SSL and early TLS.
That said, the Council may actually provide some additional changes in section 4 regarding secure communication over TLS. In addition, by the time v4 of the PCI DSS is released, TLS v1.3 will likely be an official standard so changes in that regard may also be included.
Finally, I am sure there will be the usual wording and clarification changes that have come with every prior release.
Depending on any breaches that occur in the next few months, there may be some additional surprises in v4 to address the vulnerabilities identified by those breaches.
So there you have it. Start getting ready for the new PCI DSS v4 that will show up around November 2016.