If there’s one reality we can all agree on in the industry today it’s this: When you’re in the business of parking, you’re in the business of taking credit cards. When you’re in the business of taking credit cards, you’re also in the business of PCI Compliance.
Therefore, it becomes imperative to understand what changes you face today and to build a game plan. With PCI DSS 3.0 now a requirement as of January 1, 2015, and PCI DSS 3.1 standards just announced and required by July 1, 2015, there are several key changes you should be aware of:
· Stricter security requirements for POS terminals
· Additional requirements for Hosted Order Page security
· Stricter scope documentation requirements
· The death of SSL and early TLS -TLS 1.0
While I am not a PCI QSA (Qualified Security Assessor) (someone that is certified to assess your environment by PCI DSS standards and provide a report to the Security Standards Council) or a member of the PCI Security Council, I arrived at these interpretations after significant research for my organization.
Stricter Security Requirements for POS Terminals
Changes in requirement 9 of PCI DSS, the standard that deals mostly with physical security, will require you to address the protection of point-of-sale (POS) terminals. In the parking world, these would be considered your multi-space pay stations, pay-on-foot/APS devices, in-lane devices, or cashier stations as well as in-office payment devices. Often, your QSA will be looking to see if you have a program in place to monitor and detect tampering. Depending on your needs or environment this could be as simple as documented daily walkthroughs to inspect your devices—or as sophisticated as true automated tamper sensors on equipment.
Additional Requirements for Hosted Order Page Security
The introduction of the new Self-Assessment Questionnaires (SAQ) for electronic merchants could very well affect your ecommerce site as well. For example, if your payment site has relied on what is called in the ecommerce industry a “Hosted Order Page” where you redirect customers credit card data to a server located at a payment processor or gateway, you may have to answer additional questions about security and even go as far as to run quarterly scans against a server that otherwise may not have been considered in scope for PCI DSS. Simply put, it’s likely the words “my vendor handles the payments for my website” will no longer end the discussion with your assessor or your processor.
Stricter Scope Documentation Requirements
Your “scope” is about to come under a lot more scrutiny. One of the things we’re seeing more and more of is assessors challenging where the scope of PCI DSS begins and ends for an organization. In other words, you’ll have to prove that systems that handle credit cards aren’t connected in any viable way to systems that aren’t under the same level of scrutiny, otherwise known as “out of scope” systems. There’s a lot of ways to accomplish this, but the majority of it will come from documentation of everything you have in your environment, and then working backwards to prove what is connected to what, and how. It can seem like an easy task at first, but when you stop to really think about all the systems in your enterprise or operation – it can become very daunting, so an early start on documentation is a good idea.
The Death of SSL and Early TLS -TLS 1.0
PCI 3.1 was announced in April and addresses the death of SSL and early TLS -TLS 1.0. Both are encryption technologies used for online communication that have been proven to be vulnerable to known attacks. Many vendors use this technology, and even some large banks still leverage it extensively. The level of exposure differs on each implementation of the technology, but vendors using these technologies should have a plan in place to get off of these older encryption mechanisms by June 30, 2016. The intricacies of this go deeper than this article will allow, but suffice to say if your system has any component that communicates outbound to the Internet (and almost all payment processing systems do) you should be reaching out proactively to your vendor to make sure you understand what their plan is, as many are affected. You’ll need to be able to articulate this plan and what it means to your operation later to your own assessor so that he or she is aware that your vendor is actively engaged.
Summary
The Payment Card Industry (PCI) Security Standards Council (SSC) exists in part to evaluate any new technology threats in the industry and address them by updating and clarifying existing requirements in PCI DSS (Data Security Standard) to help merchants and service providers address them. While it can often seem like a burden to merchants, the reality is that the requirements are almost always designed to protect the merchant and the consumer from likely fraud and financial loss.
So what to do if all of this seems so overwhelming? Start dialogue with your parking systems vendor. Any vendor who has partnered to help you achieve technical security and compliance requirements should be prepared to talk to you about these changes and how they may affect your implementation or systems. Additionally, there’s been a lot of buzz in the industry generated lately with the idea of systems that can achieve even further limitation of your scope of liability – either by offsetting the handling of credit cards as much as possible to a registered Service Provider, or changing the merchant of record completely – moving sometimes to a more transactional model. All of these, and possibly more, are possibilities that you should be addressing with your parking systems vendor.
The landscape of compliance is rapidly changing, and these new requirements will likely get more and more stringent. My expectation is that the rate of change on security requirements will simply continue to grow exponentially. After all, it’s the one strategy left to keep one step ahead of the bad guys.
The content of this post was published in the July issue of Parking Technology Today.