‘Ask a Security Professional’ recently received the following query and felt that this may be of interest to our readers.
By Judith Clark, QSA Consultant
This query relates specifically to virtual credit cards or pre-paid credit cards and the sending of unprotected, clear-text sensitive authentication data to the cardholder’s registered mobile number via SMS (text message). For example, to send the cardholder a reminder of their PIN (for physical cards only) or card security code (CVC2/CVV2).
The question posed is: Is transmission of an element of SAD in clear text over public networks prohibited and if so, which requirement of PCI DSS v3.2 prohibits it, if the full card number (Primary Account Number, PAN) is not being transmitted as part of the same message?
The flippant answer to this is ‘Of course you can’t send unprotected SAD over an open, public network’. However, it’s not actually as simple to pinpoint where the PCI DSS prohibits this practice as you may think. The PCI DSS is very prescriptive about the security requirements that apply when transmitting or sending cardholder data (for which PAN is the defining factor) or full card numbers (PAN) over public networks:
4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks
4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.).
These requirements, which would prevent the sending of unprotected, clear text PAN via SMS are not explicit in stating that these requirements also apply to the transmission or sending of SAD. This seems strange as the PCI DSS does set out some strict requirements that apply specifically to SAD, e.g. 3.2 Do not store sensitive authentication data after authorization (even if encrypted). This could indicate simple oversight or a deliberate omission of the inclusion of SAD in requirements 4.1 and 4.2.
The term Account Data is used in the PCI DSS to refer to cardholder data and SAD together; therefore, it could be surmised that if the PCI SSC intended these requirements to apply to both PAN and SAD, the PCI DSS would have specified Account Data. However, the PCI DSS guidance on Requirement 4 includes the statement ‘Sensitive information must be encrypted during transmission over public networks’. Moreover, this page on the PCI Council’s website states ‘everything at the end of a red arrow is sensitive cardholder data’:
The implication therefore is that the intent of PCI DSS requirements 4.1 and 4.2 is the protection of all sensitive Account Data when transmitted or sent over public networks. In addition, early in 2015 at least one card brand issued their own guidance to clarify that merchants processing only CVV2 data must protect that CVV2 when sent or received over open, public networks, in accordance with PCI DSS requirement 4.1.
So, what is our conclusion? On strict interpretation of the applicable PCI DSS requirements, a PIN or CVC2/CVV2 may be transmitted in clear-text via SMS and over public networks, if that message does not include the PAN. However, given previous card brand guidance and the intent of the PCI DSS, it seems reasonable to assume that SAD should be treated and protected as PAN when sent or transmitted using end user messaging technologies. It is recommended that entities wishing to issue clear text PIN and CVC2/CVV2 to cardholders in this way seek the views of, and up to date guidance from, the card brands.
Perhaps future releases of the PCI DSS can clarify or more explicitly define the applicability (or not) of requirements currently specified only for cardholder data or PAN?
Our panel of Security Professionals want your questions! If you have a query then please send us an email and we’ll answer it in a future issue. All submissions will be published anonymously.