The Council had a Webinar session for QSAs and ISAs on Thursday, December 15. It was a great session, but at only an hour, there were a lot of questions that went unanswered. The following were the more notable discussion topics.
Not Tested
The Council got the message and they are working on new wording for the AOCs as well as some guidance for “Not Tested” and how it can be used and not impact PCI compliance. They expect to have something issued in the first quarter of 2017.
Network Segmentation and Scoping
This was a very hot topic and drew a lot of questions and some useful answers as well as generating a slew of new questions.
We got a definition of “purpose-built controls”. There really is not any change here in what the Council has told QSAs and ISAs in the past regarding segmentation. The bottom line is that “purpose-built controls” are those controls that segment one network from another network. That can be firewall rules, access control lists (ACL) or any other controls that control or limit the communications from one network to another network. I posed a question regarding encryption such as TLS and IPSec as still being a valid segmentation control, but it did not get answered. I am assuming that it still is a valid control given the Council’s statement that nothing has changed, but until we have explicit confirmation, that still is an assumption, not a fact.
The Council answered a number of questions regarding whether or not in-scope devices can be on the same network segment as out of scope devices can co-exist. As usual, we go the “it depends” discussion. The bottom line is that it depends on the threat presented by the out of scope devices to those in-scope. If an organization has lax security controls over all of their networks and devices, then I would be hesitant to allow out of scope devices to be on the same network segment as in-scope devices.
One of the most amazing discussions on this topic was an answer given regarding whether or not a device that has only an outbound connection from the cardholder data environment (CDE) can be considered out of scope. Under the Open PCI Scoping Toolkit, this would be categorized as a 2C system. The Council started out with their stock answer of “it depends” and then clarified that answer. The answer given was that while the system would be in scope because it is connected to the CDE, what requirements it would need to comply with would depend on the risk presented by the system to the CDE. This seemed to give organizations an opportunity to argue a minimization of requirements. I am sure this will result in a lot of arguments between QSAs, ISAs and their assessees in the future.
As a funny aside, the Council mentioned the “three hop rule” and then feigned ignorance as to where it came from. As I pointed out in my post, it was from the 2014 Community Meeting in Orlando.
Not-Listed Encryption Solutions
This guidance is a train wreck and just seems to keep getting worse. The Council gave a lot of answers to questions, but it just seemed like they were digging an ever deeper hole, not filling it in.
The biggest news is that the Non-Listed Encrypted Solution Assessment (NESA) document should be available for review in the first quarter of 2017.
The next biggest news was the Council reconfirming that this is only guidance/recommendations and not some new process that is mandatory. They even made sure to tell everyone attending that QSAs are NOT to hold up an organization’s ROC/SAQ over not having a NESA for their E2EE solution. So if an E2EE solution does not have a NESA, then the fallback based on a lack of guidance from the Council is to preform whatever procedures that the merchant’s acquiring bank recommends.
The purpose of this Information Supplement the Council stated was to provide QSAs, merchants, service providers and banks with the Council’s acceptable way to deal with assessing E2EE solutions. While on its face this statement and rationale makes sense, it does not make sense from the standpoint that the organizations driving the E2EE solutions are the banks and processors that have partnered with the E2EE solution providers. Given that the banks and processors are the same organizations driving PCI compliance of the merchants that consume those E2EE solutions it seems rather odd that they would be questioning what is acceptable for PCI compliance of their approved E2EE solutions.
At the end of the day, it just seems that this NESA process is a solution looking for a problem and that the only problem the process really solves is getting more E2EE solutions to just finish the NESA and validate as a P2PE solution.
Until the banks and processors get behind the NESA process, I see this effort as dead on arrival.
So it sounds like it will be a busy first quarter for the Council.
The Council stated that the slide deck for this session will be posted to the Portal sometime after the first of the year.
PCI Guru 
It was nice to see that the Council (as I interpreted it) acknowledged that they had screwed up regarding the Not Tested guidance. However, instead of choosing the pragmatic solution (allowing the use of “Compliant” even when there are Not Tested responses), they choose the strict formal interpretation, making life difficult for QSAs and customers until they fix the AoC.
The new AoC was promised “shortly” and “in Q1”. Then again, an update to fix problems with the RoC was promised in the “near future”, back in July…
As for the Non-Listed guidance, it seems the Council decided to really put their fist down for P2PE, but missed the swing and only punched the air.
Train wreck is an understatement for the NESA!
All they need to do is replace all the P2PE requirements with PCI DSS requirements for the decrypting end. Done! The PCI SSC needs to stop talking to school teachers and mathematicians. P2PE is 90% process and 10% cryptography.