In the August 2011 issue of the PCI SSC’s Assessor Update, there is an article titled ‘Checking for SAD’, with SAD meaning sensitive authentication data. In this article, the PCI SSC is telling QSAs that PCI DSS requirements 3.2.1, 3.2.2 and 3.2.3 cannot be marked as ‘Not Applicable’. These are in addition to PCI DSS requirements 1.2.3 and 11.1 that I earlier wrote about being unable to mark as ‘Not Applicable’.
To refresh everyone’s memory, the PCI DSS requirements in question are as follows.
3.2.1 For a sample of system components, examine data sources, including but not limited to the following, and verify that the full contents of any track from the magnetic stripe on the back of card or equivalent data on a chip are not stored under any circumstance
3.2.2 For a sample of system components, examine data sources, including but not limited to the following, and verify that the three-digit or four-digit card-verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored under any circumstance
3.2.3 For a sample of system components, examine data sources, including but not limited to the following and verify that PINs and encrypted PIN blocks are not stored under any circumstance
The rationale being used by the PCI SSC for not allowing these requirements to be not applicable is as follows.
”These requirements are a fundamental part of the Standards and each review must fully account for all Sensitive Authentication Data (SAD) that may enter the assessed environment or application.”
I have been hearing comments from QSAs questioning the relevance of this clarification in outsourced environments or environments totally operated through bank-owned terminals and networks. My interpretation of why the PCI SSC is clarifying these requirements is to ensure that QSAs are confirming that outsourced environments truly are out of scope.
The QSAs complaining the most seem to be those that conduct assessments in Asia and Australia. In these parts of the world, the banks own the terminals and operate the networks that the terminals connect. As a result, cardholder data never comes into contact with the merchant’s systems.
What I am sure concerns the PCI SSC is the fact that the merchant’s POS system can have a serial or USB connection to the bank-owned terminal. While the serial/USB connection can provide the bank-owned terminals network access and the POS with cardholder data, in Asia and Australia, this connection is for the transfer of the total of the receipt to the terminal from the POS and the passing of the acceptance or decline of the charge from the terminal to the POS. What I am sure concerns the PCI SSC is, what, if anything, did the QSA do to confirm that the connection only did just that?
However, I can also understand the position some QSAs’ are taking questioning this clarification. Particularly in those situations where there is no connection between the POS and bank-owned terminal and the terminal’s network, not an uncommon condition in Asia and Australia. It is in those situations that I would have to say there is a strong argument to allow for a ‘Not Applicable’ with an explanation that the terminal is bank owned and does not connect to the merchant’s network or POS.
Just another topic for discussion at the Community Meeting.
UPDATE: At the 2011 PCI Community Meeting, this was discussed and clarified by the PCI SSC. What is expected is that the QSA will discuss the steps that the QSA took to determine that this was ‘Not Applicable’ but they do not want these requirements marked ‘Not Applicable’. Their rationale is that a QSA would have to have conducted some sort of assessment procedures to determine that these requirements are ‘Not Applicable’ and those procedures are what they want documented.
If you want to have a chat about how POS systems work in Aus, come have a chat to me during the Community Meeting