Ensuring your authentication tools are PCI DSS 3.2 compliant
The deadline to comply 
with the Payment Card Industry Data Security Standard (PCI DSS) is upon is. With February 2, 2018 looming, organizations that handle branded credit cards from the major card providers are scrambling to determine what is required and how to get there. The Gemalto authentication team hosted a webinar to go over PCI DSS 3.2, and highlight what is new.
Requirement 8.3 is especially interesting to our aAuthentication team because it focuses on multi-factor authentication for any personnel with administrative access into the cardholder data environment. This used to include just those accessing remotely, but now the requirement reaches inside the company’s own network. After our presentation, we had several questions from attendees who were not aware of this new requirement, or simply didn’t understand it. That is an ongoing challenge enterprise IT faces when treading the waters of regulations and ensuring compliance.
In larger organizations that handle huge volumes of transactions, an external Qualified Security Assessor will create a Report on Compliance. But for smaller organizations that handle smaller transaction volumes, Self-Assessment Questionnaire (SAQ) is used. This validation tool is used to help businesses authenticate and prove their compliance with the PCI DSS. There are multiple versions of the SAQ to meet different situations. Another question we had from some attendees is whether 3.2 now requires multi-factor authentication for the SAQ. The answer is, it depends. For SAQ A (used by merchants who have outsourced their card data functions to validated third parties), multi-factor authentication is necessary, but for SAQ B (for merchants who process cardholder data through imprint machines or standalone, dial-out terminals) multi-factor is not a requirement. The SAQs and corresponding requirements and instructions can be found on the PCI Security Standards Council document library.
A final question from the webinar was about certificates and whether they are considered a good solution for multi-factor authentication. The answer is yes. Certificate-based, or PKI (public key infrastructure) authentication provides multi-factor security using the certificates stored on a chip. This can be provided in many different form factors including smart cards, micro SD cards, USB tokens, etc. Because PCI DSS has a requirement for physical access, a converged badge solution is a good option. Requirement 9 says: Restrict physical access to cardholder data. Physical Access can be addressed with certificate-based smart cards with dual physical and logic access (multi-factor authentication).
Smart cards can be integrated with various building access technologies in order to function as both an employee’s physical and digital ID. The same smart card that is used for network and computer security can be personalized and printed with a picture to function as an employee’s ID badge. Contact cards can be fitted with a magnetic stripe or RF proximity technology, the card can also be used for door access systems. The same is true for smart cards with NFC technology. These cards
offer contactless interface, compatible with the NFC standard already widely used by smartphones and tablets. Smart ID badges can be issued using the same technology that issues standard ID badges today; existing badge printers would simply need to be upgraded to accept the smart card chip.
Wrapping up
Authentication and access management solutions, come in many shapes and sizes, including cloud access management, PKI, certificate-based authentication, one-time password authentication, identity federation, complete lifecycle management and auditing tools. We hope you watch the replay of our webinar, PCI DSS 3.2 Are You Ready and find helpful information about planning your authentication needs for PCI DSS.
For more information on PCI DSS requirements, including encryption and monitoring, please visit our PCI DSS compliance web site.
