09
Sep
11

More Requirements That Cannot Be Marked ‘Not Applicable’

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.

Advertisements

2 Responses to “More Requirements That Cannot Be Marked ‘Not Applicable’”


  1. June 2, 2015 at 9:06 AM

    Being an ISA thrown into the PCI fire, I have to learn from everyone’s experiences. You are one of my great resource when I am not sure or lost.

    On requirements cannot be marked as ‘Not Applicable’ (like 1.2.3, 2.1.1 and 4.1.1), read the portion of the ROC FAQ. “Requirements that are deemed to be not applicable to an environment must be verified as such. Using the example of wireless and an organization that does not use wireless technology in any capacity, an assessor could select “N/A” for Requirements 1.2.3, 2.1.1, and 4.1.1, after the assessor confirms that there are no wireless technologies used in their CDE or that connect to their CDE via assessor testing. Once this has been confirmed, the organization may select “N/A” for those specific requirements, and the accompanying reporting must reflect the testing performed to confirm the not applicable status.”

    What is your view? tnx and keep it up.

    • June 2, 2015 at 1:57 PM

      I know what the PCI DSS says, however what we have been told as assessors is a different story. For the four requirements I cite, all QSAs were taught that those could never be marked “NA” for the reasons cited in my post. If the Council has changed their minds on that (not unheard of), then it would be nice if they would tell the QSAs that (also, not unheard of). All I can tell you is that QSACs that have been through the Council’s Quality Assurance review process (AQM) have been marked down when they marked those “NA” and the comment that no wireless was documented or found in the environment. The Council has told us that they must be marked “NA” but should be marked as “Compliant” and then an explanation of the procedures we followed to prove that wireless did not exist.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

September 2011
M T W T F S S
« Aug   Oct »
 1234
567891011
12131415161718
19202122232425
2627282930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,904 other followers


%d bloggers like this: