SECTION 2.10
Case Study 2 – A Secure Transport Payment Service

As the WCA began researching feasibility of the concept and discovered that there were far more cyber security factors to consider than they had originally anticipated. Payment card issuers would now be significant stakeholders in the local transport system, and they have many cyber security requirements, notably the Payment Card Industry Data Security Standard (PCI DSS).

The WCA already had some relationship with the payment card industry and PCI DSS. For example, they accept payment of council tax by credit card. However, this is relatively small volume, and only around 100,000 card payments are processed by the WCA each year. But now, the card transactions of some 45m annual journeys will be processed by the authority. This will re-categorise the authority under PCI DSS from Level 3 to Level 1, introducing new cyber security requirements.

Until now, the authority was required to complete a self-assessment questionnaire (SAQ) and perform periodic vulnerability scans (note: see security testing annex). At Level 1, it becomes necessary to have the security of the authority assessed annually by a qualified security assessor and may be subject to external audit. The authority would also need to undergo annual penetration testing- a significant step above vulnerability scanning in both cost and complexity. Furthermore, the closer the authority is to the transaction processing, the more intensive the PCI DSS security requirements become. For example, if the user uses authority-managed hardware to make their payment, the authority is seen as primarily responsible for the security of the transaction. If, for example, the user uses their smartphone to pay the authority via a third-party payment portal such as PayPal or Square, then the payment portal and the user take on greater responsibility.

Thus, an authority like this one needs to consider cyber security impacts when conceptualising the solution. The WCA could opt for a smart card or app solution. Users could top up and buy tickets online and pay via a third-party payment portal. Then the authority would primarily need to focus on the security of the smart card or ticketing app, which is less regulated than contactless EMV. However, this two-step top-up and spend process is not as seamless as contactless EMV.

Regardless of the chosen solution, many authorities may find it more advantageous to outsource operation of the customer-facing fare system to avoid the complexities of becoming a major financial transaction processor. There are several suppliers working in this space.

The WCA ultimately decided to introduce contactless EMV. When defining the system, the authority considered the threats facing the system and the security goals. Protecting the availability of both the card readers and the back-end processing would be necessary to process payments and thus critical to the financial success of the local transport network. Protecting the confidentiality of payment card information and the privacy of the user would also be important. The system would also need to detect cards being used fraudulently and block them. The authority maintains a high level of liability according to the UK Finance Contactless Transit EMV Framework.

Card Scanner Threats

To protect the confidentiality of payment card data, good practice is for the card reader to be capable of point-to-point encryption from the reader to the back-end processing server. Furthermore, the integrity of the scanner needs to be protected. A compromised scanner may skim data and make it available to malicious parties. Organised crime groups are well known to target card readers, and there have been undisclosed reports of such groups targeting contactless transit EMV scanners. There is a risk of these scanners being tampered with or their sensitive data disclosed in the supply chain. For this reason, the WCA mandated a chain of custody for the scanners. There is tracking of which stakeholder has custody of the scanner at any given time, and each stakeholder must adhere to policies around the management of the hardware and data.

Transport System Usage Data Processing Threats

The scanner and its interface is not the only area where security is a consideration. One of the benefits of modern digital fares is the ability to collect detailed usage data. However, user privacy must be protected. Whether using smart cards, apps or contactless EMV, the authority has the capability to inadvertently collect personally identifiable data. This data must be encrypted and access to it must be restricted until it can be anonymised. Like the ANPR data mentioned in Case Study 1, disclosure of this data can lead to GDPR fines of up to £18m. Thus, the system must be architected to anonymise the data securely, and only the anonymised data should be made available to authority staff and third-parties to analyse.

User Account Portal Threats

The travelling public will manage their interactions with the WCA fare system through a web portal or an app. This introduces further security considerations and once again puts the WCA in the position of collecting sensitive data. In order to download receipts and check journey history, the user needs to link oneself to the personally-identifiable data generated by their journeys. Generally, this means entering the account number of the payment card used in order to query the journeys made with that card. To protect privacy, it needs to be verified that the person making the query is genuinely the cardholder. But in order to do this, the portal needs to take a level of information equivalent to making a payment transaction. So, in effect, the authority also needs to manage this portal to PCI DSS standard.

Once the user has an account set up with their personal data, their account needs to be protected.

Transport for London Oyster Web Portal Cyber-Attack

In 2019, Transport for London’s (TfL) Oyster contactless EMV web portal was attacked by cyber-criminals. This was a credential stuffing attack, where an automated script was used to rapidly login to large numbers of accounts using stolen passwords. Once logged in, the script would scrape all personal data. TfL’s web portal lacked any security controls to detect and prevent automated access attempts. As a result of the attack, TfL was forced to take the web portal offline for months. This caused significant inconvenience to users and generated a large amount of unnecessary calls and emails to TfL support. Business travellers could not generate receipts for expense claims and travellers could not handle refunds online. Today, TfL has mitigating controls in place such as “CAPCHA”.

Transport Payment System Service Providers

When procuring services from transport payment system service providers, authorities should look for suppliers that comply with standards including:

• Payment Card Industry Data Security Standard (PCI DSS)
• ISO 27001
• IEC 62443  (for payment systems that are physically integrated with an OT system, such as a tram)

Transport Payment System Product Vendors

When procuring system components such as card scanner hardware or relevant transport payment system software packages, authorities should look for products that comply with standards such as:

• Payment Card Industry Data Security Standard (PCI DSS)
• EMVCo Specification (specifications set by the industry body related to contactless payment cards managed by the major card issuers)
• ISO/IEC 7816 (international standards related to smart card, contactless card and mobile device-based virtual cards)
• ISO/IEC 14443 (international standards related to contactless cards)
• GlobalPlatform Card Specification (industry standard related to the secure management of multiple applications on a smart card or smert card-like device)