PCI DSS V3.0 and Your Parking Business


PCI DSS V3.0 and Your Parking Business

 If there’s one reality we can all agree on in the parking 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 what’s called PCI (Payment Card Industry) Compliance. 
Therefore, it becomes imperative to understand what changes you face today and to build a game plan. With the PCI Data Security Standards (DSS) v3.0 a requirement as of Jan. 1, 2015, and the PCI DSS v3.1 standards required by July 1, 2015, there are several key changes you should be aware of:
Stricter security requirements for point-of-sale (POS) terminals.
Additional requirements for hosted order page (HOP) security.
Stricter scope documentation requirements.
The death of SSL and early TLS -TLS v1.0.
While I am not a PCI qualified security assessor (QSA) — someone certified to assess your environment by PCI DSS 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 the PCI DSS, the standard that deals mostly with physical security, will require you to address the protection of POS terminals. In the parking world, these would be considered your multi-space paystations, 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 walk-throughs 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 (SAQs) 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 (HOP), 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 the 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 the 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 v3.1 was announced in April and addresses the death of SSL and early TLS -TLS v1.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 them 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. 
The Payment Card Industry (PCI) Security Standards Council (SSC) exists in part to evaluate any new technology threats in the industry and to address them by updating and clarifying existing requirements in the PCI DSS 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 a dialogue with your parking systems vendor. Any vendor that has partnered to help you achieve technical security and compliance requirements should be prepared to talk to you about these changes and how they might 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 by 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.
For more information, go to the PCI Security Standards Council website at https://www.pcisecuritystandards.org.
Want to hear more? 
Grant Dawson, Director of IT Operations for T2 Systems, will be hosting a webinar at 2 p.m. EST on Thursday, August 13. Feel free to join in, and he will be happy to answer any questions you may have. You can register at www2.t2systems.com/PCIWebinar.
Article contributed by:
Grant Dawson
Only show results from:

Recent Articles

Send message to

    We use cookies to monitor our website and support our customers. View our Privacy Policy