EMV in transit connects public transport to (global) payment schemes, providing great ease-of-use benefits to the commuter.
However, because such solutions inherently process payment card data, it is a requirement that Public Transport Operators (PTOs) implementing such ‘pay-at-gate’ solutions must be Payment Card Industry Data Security Standard (PCI DSS) compliant. This is true even if the gates do not directly process payments, but ‘only’ collect card data for later processing.
Compliance with PCI DSS is assessed by a Qualified Security Assessor (QSA) by means of an audit. Although PCI DSS compliance is a mature process for many organizations, EMV in transit can present new challenges and bring new parties into scope of PCI compliance.
This, in turn, can lead to more issues being raised during an audit, or perhaps in the worst case compromise and expose payment card data, leading to a potentially costly and brand-damaging breach.
To make sure that an audit runs smoothly, and achieves the twin goals of compliance and security of your payment infrastructure, it is crucial to ensure that the QSA you select to perform your audit is experienced and knowledgeable in the intricacies and interaction of the various PCI standards as well as EMV and pay-at-gate operations.
Additionally, you should clearly document your existing processes and systems that involve payment card data, to both help you understand the areas of compliance for your system, and assist your QSA in understanding these areas during an audit.
Typically, there are two general means to ease the auditing process:
- Limit the scope of the PCI DSS audit.
- Use components that can be implemented in a PCI DSS compliant manner.
But how do you apply these means to an EMV in transit environment? How do you achieve your compliance and security goals in the most efficient way?
Limiting PCI DSS scope
The PCI DSS audit considers not only technology, but also people and processes. An important concept within PCI DSS is the Cardholder Data Environment (CDE), which includes all systems, people and processes where cardholder data is involved. On top of the CDE, any system that could affect the security of the CDE also falls within the scope of the PCI DSS audit.
EMV in transit implementations should therefore focus on limiting the CDE as much as possible and restrict cardholder data to those systems that process it:
- The card acceptance mechanisms (including pay-at-gate readers)
- The PTO (or transit scheme) payment back-office system, to modify the value of the transactions to the actual travel fare and forward them to the system of their acquiring bank
- The customer support system, to identify customer travels using their card or primary account number (PAN)
Other systems may require transaction data as well. For example, journey reconstruction requires an identifier to link check-in transactions with check-out transactions. For fare calculation, identifiers need to be linked to products or, in the case of fare caps, linked to previous journeys.
Instead of using the PAN as an identifier, these systems could utilize tokenized or hashed PANs to assist with limiting scope. Into the future EMV is introducing the concept of a ‘PAR’ – Payment Account Reference – that is designed to be used as a PAN substitute for just such situations, however PAR use is currently limited and a functional transit system cannot assume that such a value will be present at this time.
To ensure that the scope of PCI DSS is as small as possible, the CDE and any systems that may impact their security (such as remote management systems) should be separated from other systems of the PTO. This can be achieved by network segmentation, as shown in the example in Figure 1.
Using PCI compliant components and solutions
Another way to reduce the impact of a PCI DSS audit is to make use of components and solutions that are already compliant with some of the PCI standards.
This of course includes PCI DSS, but also other PCI standards, and it is therefore important to understand to which PCI programs a chosen solution complies with and how this may affect the audit.
When a vendor of any particular payment product advertises ‘PCI compliance’, you should ask which PCI program specifically it is compliant to, and how that compliance has been validated.
PCI PIN Transaction Security (PCI PTS) can apply to any device which accepts PCI card data. However, only devices that accept PIN are required to comply with PCI PTS and therefore, many transit terminals, such as pay-at-gate acceptors, are not mandated to be PCI PTS compliant. Despite this, some terminals may comply with the non-PIN section of this standard, which concerns the “Secure Reading and Exchange of Data” (SRED).
Purchasing SRED compliant terminals ensures that (non-PIN) sensitive card data can be processed securely by the device, and output in an encrypted form that protects the confidentiality of this data. A list of PCI PTS compliant products is maintained by PCI itself, and each listing can be selected to identify if a solution is SRED compliant (as shown in the example below):
Often such devices will be approved as an ‘SCR’, or Secure Card Reader, although SRED compliance may also be applied to other PTS device types. It is important to review the Security Policy of such devices, and perhaps seek advice on their secure use, as the encrypting mode of operation may need to be ‘setup’ correctly. Because of this complexity, systems using SRED compliant terminals for reducing PCI DSS scope must be properly vetted by a special assessor – approved under the PCI Point-to-Point Encryption (PCI P2PE) program.
The PCI P2PE program assures that the cardholder data is sufficiently protected when it is transmitted from the terminal to the back-office. This allows for any infrastructure where the (encrypted) data passes through to be essentially considered out of scope for PCI DSS.
It is important to understand, however, that assessment of the components and overall P2PE solution is still required for P2PE compliance – so the choice of the right technology providers and partners is vital to gain the best value of any scope reduction.
Processes that involve the terminals such as device management and vulnerability management are within the scope of PCI DSS as well. If the vendor has demonstrated that their solution can be implemented in compliance with PCI DSS, they will have already defined these processes. PTOs should integrate these processes into their day to day operations to provide clear evidence for PCI DSS compliance to the QSA.
Another notable PCI program is PA DSS, which concerns payment application software in contrast to PCI PTS which focuses on the hardware and firmware of card accepting systems. Payment Application Data Security Standard (PA DSS) is commonly applied to off the shelf software products and facilitates – but does not inherently provide or replace – PCI DSS compliance.
Commonly, the payment application will already be part of the terminal that a vendor will provide. In that case, the vendor is responsible for the correct integration of the application, which is another reason for PTOs to select vendors that use PCI compliant building blocks, and seek to ensure that their contractual agreements with third parties correctly and fully assigns each area of PCI compliance to the right parties.
Of course, it is possible to fulfill an audit with components that have not demonstrated any PCI compliance before, but this can introduce both complexities in the assessment as well as introducing risk of non-compliance.
As such, both PTOs and vendors benefit from components that can be demonstrably implemented in ways that are compliant to the various PCI standards, with the ultimate goal of easing the burden of demonstrating PCI DSS compliance during an on-site audit.
Conclusion
Implementations of EMV in transit must be compliant to the Payment Card Industry Data Security Standard (PCI DSS), and will likely be subject to an on-site PCI DSS audit by an approved Qualified Security Assessor (QSA). Besides clearly documenting their processes and systems and actively supporting the QSA, the best way to facilitate the PCI DSS audit is to limit its scope by keeping the Cardholder Data Environment (CDE) small and segmenting it as much as possible from other systems.
In addition, components that have demonstrated to be implemented in compliance with PCI can save both vendors as well as Public Transport Operators (PTOs) a lot of headache, and solutions that are able to comply with the PCI Point-to-Point Encryption (PCI P2PE) requirements should be carefully considered as an option to greatly reduce the overall compliance process.
