In this portion of our Tokenization Guidance series I want to offer some advice to auditors. I am addressing both internal auditors going through one of the self assessment questionnaires, as well as external auditors validating adherence to PCI requirements. For the most part auditors follow PCI DSS for the systems that process credit card information, just as they always have. But I will discuss how tokenization alters the environment, and how to adjust the investigation process in the select areas where tokenization systems supplants PAN processing. At the end of this paper, I will go section by section through the PCI DSS specification and talk about specifics, but here I just want to provide an overview.

So what does the auditor need to know? How does it change discovery processes? We have already set the ground rules: anywhere PAN data is stored, applications that make tokenization or de-tokenization requests, and all on-premise token servers require thorough analysis. For those systems, here is what to focus on:

  • Interfaces & APIs: At the integration points (APIs and web interfaces) for tokenization and de-tokenization, you need to review security and patch management – regardless of whether the server is in-house or hosted by a third party. The token server vendor should provide the details of which libraries are installed, and how the systems integrate with authentication services. But not every vendor is great with documentation, so ask for this data if they failed to provide it. And merchants need to document all applications that communicate with the token server. This encompasses all communication, including token-for-PAN transactions, de-tokenization requests, and administrative functions.
  • Tokens: You need to know what kind of tokens are in use – each type carries different risks.
  • Token Storage Locations: You need to be aware of where tokens are stored, and merchants need to designate at least one storage location as the ‘master’ record repository to validate token authenticity. In an on-premise solution this is the token server; but for third-party solutions, the vendor needs to keep accurate records within their environment for dispute resolution. This system needs to comply fully with PCI DSS to ensure tokens are not tampered with or swapped.
  • PAN Migration: When a tokenization service or server is deployed for the first time, the existing PAN data must be removed from where it is stored, and replaced with tokens. This can be a difficult process for the merchant and may not be 100% successful! You need to know what the PAN-to-token migration process was like, and review the audit logs to see if there were issues during the replacement process. If you have the capability to distinguish between tokens and real PAN data, audit some of the tokens as a sanity check. If the merchant hired a third party firm – or the vendor – then the service provider supplies the migration report.
  • Authentication: This is key: any attacker will likely target the authentication service, the critical gateway for de-tokenization requests. As with the ‘Interfaces’ point above: pay careful attention to separation of duties, least privilege principle, and limiting the number of applications that can request de-tokenization.
  • Audit Data: Make sure that the token server, as well as any API or application that performs tokenization/de-tokenization, complies with PCI section Requirement 10. This is covered under PCI DSS, but these log files become a central part of your daily review, so this is worth repeating here.
  • Deployment & Architecture: If the token server is in-house or managed on-site you will need to review the deployment and system architecture. You need to understand what happens in the environment if the token server goes down, and how token data is synchronized being multi-site installations. Weaknesses in the communications, synchronization, and recovery processes are all areas of concern; so the merchant and/or vendors must document these facilities and the auditor needs to review.
  • Token Server Key Management: If the token server is in-house or managed on site, you will need to review key management facilities, because every token server encrypts PAN data. Some solutions offer embedded key management while others use external services, but you need to ensure this meets PCI DSS requirements.

For non-tokenization usage, and systems that store tokens but do not communicate with the token server, auditors need to conduct basic checks to ensure the business logic does not allow tokens to be used as currency. Tokens should not be used to initiate financial transactions! Make certain that tokens are merely placeholders or surrogates, and don’t work act as credit card numbers internally. Review select business processes to verify that tokens don’t initiate a business process or act as currency themselves. Repayment scenarios, chargebacks, and other monetary adjustments are good places to check. The token should be a transactional reference – not currency or a credit proxy. These uses lead to fraud; and in the event of a compromised system, might be used to initiate fraudulent payments without credit card numbers.

The depth of these checks varies – merchants filling out self-assessment questionnaires tend to be more liberal in interpreting of the standard than top-tier merchants and the have external auditors combing through their systems. But these audit points are the focus for either group. In the next post, I will provide tables which go point by point through the PCI requirements, noting how tokenization alters PCI DSS checks and scope.

Share: