What does PCI really mean?

One of the frustrations in dealing with the PCI – DSS compliance is the lack of clear definitions. Unfortunately, the ambiguities of the standard make it hard for a retailer to understand different card processing offerings and how it directly affects their security costs. This article tries to relate the industry standard to the various processing options of our Merchant Plus! Retail management software, though the discussion is appropriate for any company accepting credit cards. Most importantly, our goal is to help you improve your network security regardless of the PCI standard.

Perhaps the best way to compare the real cost/benefit of credit card processing is to consider what the bankcard companies “expect/require” of a merchant based on how they process credit cards.  The “SAQ” or Self-Assessment Questionnaire is a document that the bankcard companies require all retailers (really any company) to complete every year if they are accepting credit cards. There are several different questionnaires based on how credit cards are handled; the three that relate to our clients are SAQ B, C or D (hopefully SAQ P2Pe-HW in time). The difference among the questionnaires provides important insights to the main security needs based on how cards are handled.

Download any of the SAQs discussed here.

SAQ B (29 Questions)

The easiest secure level to attain is SAQ B which is based on using imprint machines (the old knuckle busters) or dialup telephone credit card machines over phone lines. Unfortunately, this solution isn’t integrated to Point of Sale: leading to a slower checkout service and increased reconciliation expenses. Credit card data cannot be stored anywhere electronically.

While any telephone repairman can tell you that it is as easy to intercept “dialed” numbers with a few alligator clips on your telephone line, this method is considered the safest because data never passes through a computer network where it can be potentially intercepted by a virus or attack launched from anywhere in the world.

However, if the phone line utilizes Voice over IP (VOIP) technology that uses the network for communications the SAQ C is probably required.

SAQ C (90 Questions)

SAQ C applies to credit card processing when a card number is exposed to an internal network for individual transaction processing.  Credit card data cannot be stored anywhere electronically.

This is the security level for most of our clients and is the basis for our security recommendations for clients as well as the basis for our own business security even though we do not process credit cards.

Why is the Security Council so concerned with networks?

Consider a simple hack called “key logging” (in both hardware and software varieties) which intercepts all keyboard entry and merely looks for credit card numbers and expiration dates and stores them.  The hackers will leave these devices or programs on an unsuspecting retailer’s system until enough cards are captured to sell them on the black market.  Therefore, if a credit card is ever keyed (or swiped) into a computer as a card number, the network must be protected.

At this time, most card processing solutions that can be integrated to the Point of Sale system will require the retailer to satisfy the SAQ C demands.  If the credit card information is encrypted (more on P2Pe later) at all times on the network, the retailer is much safer.

While some might argue that there are “Compensating Controls” when using our newest solutions that include Point to Point Encryption (P2Pe), we believe that the network security requirements of the SAQ C are reasonable basic security guidelines and controls for any business network.

SAQ D (286 Questions)

SAQ D applies to credit card processing when a card number is stored electronically.  Credit card data can be stored electronically, but the security requirements are onerous. For nearly all of our clients, the costs are prohibitive.

This is the most painful security level that adds tens of thousands of dollars annually to a security budget. It requires active penetration testing, intensive security documentation including a daily log of all “guests” (like your software and network support team) access and even back ground checks on all employees.

While it may be obvious that card numbers should never be kept electronically to avoid this level of security, it might not be so obvious that a “Terminal Based” credit card processing solution also keeps the card numbers until the batch is settled.  There are a few Merchant Plus! clients using these solutions such as TSYS – Visanet, Cardnet and several other processing companies.

Our recommendation, as well as Datacap Systems, who develops NETePay, is that Terminal based solutions require an SAQ D.

SAQ P2PE – HW (20 Questions)

The SAQ P2PE-HW is a brand new standard. It’s so new that there are only two pending approved applications.  However, we have included it here to discuss and explain the security benefits of using end to end encryption and tokenization.

Point to Point encryption is a fast evolving technology that minimizes the risk of processing credit cards because the card is read through a separate device where it is encrypted before it is sent across the retailer’s network; only a token is passed to the software to indicate the transaction and whether it is approved or declined.  What is important to understand is that the card number is sent to the Datacap NETePay application which decrypts it before sending it off to the processing network. Therefore,  NETePay must be protected as well.  When using Mercury Payment Systems (MPS), NETePay is running on their servers in the cloud.  This is a huge benefit as security for NETePay is the responsibility of MPS and not the retailer.

We hope and expect that our partners will soon be approved for this level.  But all the benefits of Point to Point encryption are lost if NETePay is running on the retailer’s network as it decrypts and encrypts the message before sending it to the processor.

Credit Card Processing on Mobile devices.

Currently, there are no (ZERO) PCI-DSS Certified solutions for Consumer Grade mobile devices like the iPhone or Android.  This is because the PCI Data Security Council hasn’t yet published a standard.   There is a standard for hardened mobile devices that are dedicated to card processing but they are expensive and can’t be used as a phone, browser or anything else.

Yes, this means that all the Apple stores are not using certified devices as they are using consumer phones.

But this doesn’t necessarily mean they don’t have a secure solution or that it can’t be improved. What we suspect is that the eventual requirements will be based on Point to Point encryption (see this PCI-DSS document). This bodes well for us based on how we’ve positioned ourselves with the latest technologies.

Just remember that every encryption cipher of the past has been broken and all can eventually be hacked.

SAQ Comparison

This stringency of the security requirements for processing credit cards is well represented by the number of questions on each Self-Assessment Questionnaire.

PCI Requirement	SAQ D	SAQ C	SAQ B	SAQ P2Pe  -HW
1: Install and maintain a firewall and router configuration to protect cardholder data	25	8	0	0
2: Do not use vendor-supplied defaults for system passwords and other security parameters	23	10	0	0
3: Protect stored cardholder data	30	11	5	8
4: Encrypt transmission of cardholder data across open, public networks	8	7	1	1
5: Use and regularly update anti-virus software or programs	6	6	0	0
6: Develop and maintain secure systems and applications	31	2	0	0
7: Restrict access to cardholder data by business need to know	7	2	2	0
8: Assign a unique ID to each person with computer access	30	3	0	0
9: Restrict physical access to cardholder data	28	8	9	1
10: Track and monitor all access to network resources and cardholder data	28	0	0	0
11: Regularly test security systems and processes	24	14	0	0
12: Maintain a policy that addresses information security for all personnel	46	19	12	10
Totals	286	90	29	20

Summary

If the card information is exposed on the network even for a brief second, the SAQ C is required. If credit cards are stored electronically, the SAQ D is required.

Point to Point encryption allows for a much safer transport of authorizations without ever exposing the card information between the Point of Sale (using the UIC PP795) and NETePay. If NETePay is hosted by your service provider, such as with Mercury Payment, the card holder information is never exposed to your internal network.  While the specifications still suggest that this encrypted traffic still requires an SAQ C we anticipate newer standards and technologies to continue to ease the burden for our customers. But in the end, we believe that our basic security recommendations (that match our certified procedures for configuring our system for an SAQ C) are sound business security practices and really aren’t as hard to maintain as it initially sounds.

Only a Qualified Security Assessor can provide you an opinion on your company’s compliance, but we hope this article has at least helped frame your understanding of the overall priorities. Feel free to contact us for any questions.