By Renee Smith

Data breaches are a constant worry for any business that accepts credit card payments. Over the past decade breaches have become increasingly common, and some of the world’s best known companies, including Home Depot, Target, and TJX, have been the targets of sophisticated attacks through which millions of customers have had their personal and credit data compromised. The sad reality of modern life is that any type of personal or financial data that is obtained electronically and transmitted or stored online is potentially at risk. 

The parking industry is not immune to this risk. In fact, now that credit card payment is the dominant and preferred form of payment at most parking facilities, parking owners and operators—both public and private—must be particularly vigilant about protecting customers’ financial data.

The credit card industry, through the Payment Card Industry Security Standards Council (PCI SSC), established a framework to help merchants (including parking owners and operators) protect data. The Council has established the Payment Card Industry Data Security Standard (PCI DSS), which is a set of requirements designed to assure that all companies that process, store, or transmit credit card information maintain a secure environment.

On April 28, 2016 PCI SSC released PCI DSS version 3.2, which replaces version 3.1, to address a growing number of threats to customer payment information. This version becomes effective on February 1, 2018. On May 27, 2016, PCI SSC released PA DSS version 3.2, which becomes effective on June 1, 2016. Until their respective effective dates, parking owners and operators should look to these standards as best practices that can help protect their organizations and their patrons.

What do the newest details of PCI DSS v 3.2 adherence entail? Organizations are subject to two significant new requirements. First, they will need to implement a change control process. Second, Multi-factor Authentication (MFA) must be put in place for all personnel with administrative Cardholder Data Environment (CDE) access. The majority of changes to PA-DSS 3.2 are intended to support those changes in PCI DSS 3.2.

Service providers are also subject to a number of new requirements. These include documenting descriptions of their cryptographic architecture; detecting and reporting on failures of critical security control systems; completing penetration testing for segmentation controls; assigning responsibility to protect cardholder data and create a PCI DSS compliance program. Additionally, software developers must attend secure coding training at least annually. Finally, quarterly reviews must be scheduled to ensure that security and operational procedures are being followed.

Why Is PCI Important?

Clearly, achieving PCI compliance will require a great deal of strategic planning, as well as significant investment on the parts of parking owners and operators, as well as their technology providers. Nonetheless, PCI is important to the parking industry because credit card transactions are convenient for parkers, not to mention owners and operators. In fact, they are so convenient that they have become the preferred method of payment for owners, operators, and parkers alike. Every parking owner or operator with a merchant account to process credit cards must be PCI compliant by February 1, 2018. If PCI compliance standards aren’t met, penalties and fines will range from $5,000 to $500,000. Clearly there is a financial incentive for compliance.

Additionally, if any data breaches occur they can lead to the merchant account being terminated, eliminating the ability of the owner or operator to accept credit cards. For many facilities, losing the ability to accept credit cards would be devastating.

A data breach can also lead to a facility or its owner being blacklisted from opening a new merchant account. MasterCard maintains a database of businesses (and their owners) whose credit card privileges have been terminated for specific reasons. That list, which is known as the TMF (Terminated Merchant File) or MATCH (Member Alert To Control High Risk), is used by acquiring banks to screen potential applicants for new merchant accounts. Merchants who are placed on the list must serve a five year sentence before being removed from it.

A third penalty for non-compliance has wider reaching implications. The cost of negative publicity, which damages the organization’s brand, reputation, and accumulated goodwill, is incalculable. High profile data breaches are widely remembered long after they occur.

Where to Start

An important initial step in determining how to proceed is to establish your organization’s “level,” which is based on the number of annual transactions or whether there have been prior data breaches. After determining the level, an annual on-site or self-assessment audit may be required. For large merchants, a 2010 study found that the average annual cost for a PCI DSS audit can approach $225,000, plus fees such as operating and staff costs. For smaller organizations, however, PCI DSS compliance costs start at just a few hundred dollars a year.

Another important preliminary step for PCI DSS compliance is defining the scope of the cardholder data environment (CDE). All In-Scope technology, people, and processes need to be examined, including internal firewalls, segmentation systems, virtual machines and components, network components (such as switches, routers, firewalls, and wireless access points), servers for the Web, applications, databases, email systems, DNS, and all internal and external applications that handle cardholder data or provide administrative functionality with the CDE. Considering how expansive this list can become, it’s easy to appreciate the value of limiting your compliance scope.

Cardholder data is a particularly important element of PCI compliance. The PCI SSC defines cardholder data as the full Primary Account Number (PAN) or the full PAN along with any of the following: cardholder name, expiration date, or service code. Sensitive Authentication Data includes security-related information, such as card validation codes used to authenticate cardholders, including CCV and PIN numbers. Payment Applications that have access to cardholder data should be validated pursuant to Payment Application Data Security Standard (PA-DSS).

Limiting Compliance Scope

While the merchant is always subject to PCI DSS, there are ways to limit the compliance scope for purposes of PCI. For an existing network, common segmentation tools include placing the parking system behind a firewall with an access control list or network switch hardware. Alternatively, a new network (modem/router) may be installed for the parking system. Generally the goal is to move software and system components to be Out-Of-Scope. In implementing their solutions, parking operators may wish to implement or upgrade to solutions with end-to-end encryption (E2EE) or point-to-point encryption (P2PE) certified solutions. For purposes of this article, we’ll leave firewalls, switches, and network creation up to your IT guys.

In parking systems, in addition to the management software and parking kiosks, many parking systems also incorporate items such as intercoms, video cameras, and access control components. To reduce scope, many owners and operators move those components to a LAN that is segmented from the parking management system. When this network segmentation is properly configured, items that are properly segmented should be considered to be Out-Of-Scope.

Another way to reduce PCI scope is through use of encryption. E2EE is more of a general technology term that describes the ability to encrypt from endpoint to endpoint. For a parking kiosk, if encryption happens at the credit card reader head, and then deciphered by the merchant or payment gateway, this is an example of E2EE in parking. The key, however, to determining whether payment software is subject to PA DSS or Out-Of-Scope is understanding who has the ability to access and view cardholder data. Encrypted cardholder data is only considered to be Out-Of-Scope “if, and only if, it is validated (for example, by a QSA or ISA) that the entity in possession of the encrypted data does not have access to the clear text cardholder data or the encryption process, nor do they have the ability to decrypt the encrypted data.”  PCI SCC FAQ #1086. If you, your software vendor, or another third party have access to and can decipher the encrypted cardholder data, it is In-Scope for PA-DSS.

P2PE, a subset of E2EE, is an official PCI certification that involves numerous additional safeguards that must be confirmed by a QSA auditor. First, the merchant may not be a manager of the encryption keys – all key management must be done by a third party. P2P2 solutions are certified with specific point of interaction (POI) or PIN transaction security (PTS) devices that incorporate tamper resistant features. Additionally, further safeguards exist around the chain of custody of hardware (including shipping in pre-serialized, counterfeit-resistant, tamper-evident packaging, then storing such devices in such packaging until key injection).

Organizations with any questions or concerns about scope should turn to a Qualified Security Assessor to clarify both scope and the organization’s responsibilities. Ultimately, it makes sense for owners and operators to explore ways to reduce the scope of PCI DSS compliance by shrinking the footprint where cardholder data is located throughout their organization. By reducing the scope, owners and operators can dramatically lower the cost and anxiety of a data breach revealing sensitive cardholder data and increase the chance of PCI DSS compliance.

Common Issues

When it comes to PCI, parking presents unique challenges because credit card payments are accepted in a variety of ways. Parking facilities accept payments at attended stations, unattended stations, via fax, email, and on-line. One common variable is the software utilized for payment processing, which could be at a cashier, at a walk-up pay station, or online.

To determine the Cardholder Data Environment, the merchant should request a diagram of the flow of cardholder data. The technology environment should be segmented and restricted to authorized users (physical access, LAN, and WAN) and protected by a firewall, and software security patches for this environment should be regularly updated. Anti-virus, malware detection should be enabled on CDE devices, and the Payment Application should provide logging of access to the environment and send automated alerts in the event of credit card processing issues or system errors. The owner or operator will need to determine if Store and Forward (SAF) is offered by the software vendor, and if enabled, what maximum dollar amount and timeframe will be permitted to be authorized when an Internet connection is not available to process real-time credit cards.

On the physical side, owners and operators should physically inspect cardholders and PIN devices routinely to ensure that no skimming devices have been placed on the readers to steal the cardholder information, including the full magnetic stripe data. Process and procedure should be reviewed regularly with personnel. If a parking office accepts monthly parking renewals via fax, phone, or email, additional physical and technology PCI-DSS compliance requirements apply for each scenario.

What about EMV?

PCI’s goal is to protect cardholder data that is processed, stored, or transmitted by merchants. EMV’s goal is to ensure security of chip-based payments and requires certification between EMV-capable hardware and the processor. EMV provides an additional level of authentication at the point of sale that reduces the chance of fraud, but even so, owners and operators are still required to ensure PCI compliance of their CDE.

Implementing EMV certified hardware reduces the PCI scope by ensuring that neither the merchant nor the software vendor has access to the encrypted cardholder data. Ultimately, while it doesn’t reduce parking owners’ and operators’ PCI overall responsibilities, EMV likely will reduce the CDE by utilizing E2EE and eventually P2PE. Additionally, this technology provides the maximum amount of protection for owners and operators, as well as their patrons who pay for parking with credit cards.

Closer Than You May Think

Parking owners and operators across Canada are breathing a sigh of relief over the postponement of implementation of the PCI DSS requirements from this month to February of 2018. Compliance is going to require extraordinary changes in the way parking organizations manage their credit card payment systems, and the extra 18 months should provide enough wiggle room to develop and implement effective programs and systems. Still, those 18 months are going to pass quickly, and the task promises to be time-consuming and complicated. Owners and operators have no time to waste when it comes to becoming PCI compliant.

Renee Smith, JD, MBA is president and CTO of Parking BOXX, a leading provider of parking equipment and parking systems. She can be reached at r@parkingboxx.com.
SHARE IT:

Commenting area

  1. Phares Sekalala October 26, 2016 at 1:08 am · · Reply

    Hello Renne,
    Hope this message finds you well.
    I read your article in the CPA website about the “Parking and Payment Card Industry Standards – PCI Compliance”
    My firm is a registered QSA company and would readily be available to help out Parking owners and operators across Canada especially around
    a) PCI Education and knowledge sharing
    b) PCI Readiness
    c) PCI Compliance Certification

    Thank you.
    Phares Sekalala QSA
    PKS Compliance LLP
    204-588-8313

  2. “On April 28, 2016 PCI SSC released PCI DSS version 3.2, which replaces version 3.1, to address a growing number of threats to customer payment information. This version becomes effective on February 1, 2018. ” — Incorrect. Version 3.2 is in effect now and 3.1 has been retired

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>