Brian McGann talks PARCS security!
You Must Comply! Here’s How…Brian McGann talks PARCS Security! (as featured in the March 2015 edition of Parking Today)
Congratulations on your new parking system. You got funding. You went through the RFP process. Questions were asked and answered. You looked at features; you looked at security. You insisted the PARCS system be audited for PCI-DSS compliance – and that’s what you got, because you confirmed it on the official PCI web site. Now it’s time to relax and let the system do its job, right?
Sorry, no. The audit the vendor undertook was most likely a PA-DSS (Payment Application Data Security Standard) Validation. In simple terms, that means the system is capable of being utilized in a compliant and secure manner. Unfortunately, it’s probably also capable of being run in a reckless and insecure manner.
So what must you do? First, every PA-DSS application has an Implementation Guide. You may occasionally hear this document described as being internal and proprietary. It is not! Be certain you have been provided this Guide and be sure that the system was installed per its instruction. The QSA (Qualified Security Assessor) that validated the system only tested what’s in the Guide.
Sometimes the vendor will want to install the system deviating from the Implementation Guide. Reasons could include improved function, or lower installation or operating cost. They should provide a clearly stated and justified plan to maintain the same or higher level of security. Your decision then is to insist upon the audited solution, or to accept the alternate. An option is to have the plan reviewed by a QSA or other security expert.
Once installation is complete, then you must run the system securely and compliantly. How is that done? Relax – the PCI-DSS authors are pleased to provide you a “simple” 300-part answer to that question. That’s the approximate number of individual sub-requirements in the latest PCI-DSS V3.0. There is however a more reasonable proxy for your answer – that is the SAQ (Self-Assessment Questionnaire).
Unless you are a very large organization, or have been breached recently, an SAQ is the document that will be required annually by your Merchant Acquirer to prove your PCI compliance. The owner, operator, or another entity may have the direct relationship with the Acquirer, but regardless, the system as installed at your facility will determine what PCI rules are in scope and hence the particular SAQ that will be required. The V3.0 SAQ – now in nine flavors – has a varying number of questions/requirements.
Keep in mind that more requirements translates to a larger compliance burden. SAQ A and A-EP are for e-commerce, only; B and B-IP are for stoneage facilities using knuckle-busters or stand-alone terminals. C-VT only allows typed card numbers; no readers. None of these are suitable for a modern parking facility. SAQ-C, with 139 questions, requires a high degree of network segmentation and no storage of cardholder data among its requirements. A modern PARCS system might conceivably be designed, installed and operated to meet the requirements allowing use of SAQ-C if the rules are carefully followed and resulting inconveniences can be tolerated.
Good news – the most onerous SAQ is the SAQ-SP and your facility will almost certainly not need to use this one. A Service Provider is an entity and system that facilitates other systems in their payment processing. More good news can be found if your vendor has installed a system that has completely implemented a PCI-validated P2PE (Point-to-Point Encryption) solution. This means your PARCS equipment has a tamper-resistant card reader that sends strongly encrypted card data directly to the payment processor without it ever being decrypted along the way. Using some possibly oversimplified arithmetic, with only 35 questions, you may think of your compliance burden as being only about 10% of the total.
But what if P2PE is only partially deployed? Previous versions of the SAQ would guide you to the “worst case” SAQ. The latest SAQ V3.0 may provide relief for a partially-deployed P2PE system. Now, you may be allowed to fill out separate SAQ’s for your differing payment channels. It is, however, questionable whether filling out multiple SAQ’s will save you any time and obligation.
If your system cannot meet the requirements of any other SAQ, you’re left to complete the 326 questions/requirements of the SAQ-D. This is major task that will require PCI expertise. Numerous new and modified policies and procedures should be expected. Who will be responsible for checking the daily logs from your IDS/IPS (Intrusion Detection/Protection System)? How about your quarterly Vulnerability Scans? Or your annual Penetration Tests? Who is responsible to see that systems are patched with security updates or that departed employee credentials are removed?
You may determine that some of the 326 are not applicable, but you’ll still have to do a worksheet for each explaining why. Many companies facing an SAQ-D, will bring in expert assistance, whether a QSA or other security expert. You might wonder how this could be better. One option would be to put a virtual fence around the payment processing and hire someone else to run it. Assuming this is technically and financially possible, be aware that in a breach no one will care that you had attempted to wash your hands of the responsibility. You will own it.
Other options can come from the PARCS vendors. They can (and some do) provide an audited Service Provider system. In a system of this type, some part of the payments operation is moved to a server hosted on the Internet. Note that audited (i.e. Level-1) Service Providers are listed on the Card Association web sites (e.g. VISA, MasterCard) rather than the PCI-SSC site. The important thing to know is exactly what that does for your compliance burden. A shorthand answer to that is had by asking what SAQ version you’ll have to do.
When considering a PARCS system, you need to know that the system will be installed securely and can be run with an acceptable burden of PCI compliance. See that the Implementation Guide is followed and investigate and approve any changes. Then, know your PCI compliance burden by asking what SAQ version to expect.
Brian McGann can be reached by clicking here.