More on Payment Card Security Compliance

All merchants, including consumer cooperatives, must and should meet the Payment Card Industry Data Security Standard (PCI DSS) if they wish to accept credit cards as a form of payment.

At the Wedge Co-op, over two-thirds of our sales, in total dollars, are tendered with credit cards. When we received notification that we had to be compliant with the PCI standard if we wished to continue receiving payment in credit cards, it became critical for us to take a good long look at the implications.

The huddle under the looming clouds
One afternoon our finance manager and I sat down to talk about what it all meant. To what end were we being asked to do this? Was it to satisfy the PCI Security Standard Council, so that we can continue doing business? Was it to protect our business if something happened, such as massive card holder data theft should our network become compromised? That had already happened to other organizations. What was the intention behind maintaining the standard in the first place?

It soon became clear to us that the most important consideration, whether we were PCI compliant or not, was to run a secure operation for our customers. If all transactions were secure, and there were no mishaps for any of our customers when they used their credit cards, then nothing else mattered. That was the bottom line, and that was the ultimate intent of the standard: no mishaps.

Easier said than done. The decision was not that we become PCI compliant, but to make us as secure as possible. PCI compliance, whatever that entailed, was secondary. As it turned out, it was not just a matter of imposing rules and hardening firewalls. It involved cultivating security awareness for the organization as a whole, and maintaining a level of vigilance for those immediately responsible. All of that would go beyond credit card data processing, and somehow, in that process, we also would become PCI compliant.

Those immediately responsible turned out to be the information technology (IT) team. The finance manager, who would hear no end of it from our customers should anything happened, placed her trust in the IT team, and off we went.

We started by plowing through the compliance requirements. Having read them, we set them aside and asked ourselves: What does it mean to have a secure environment for credit card processing for our customers, and what could we do to bring it about?

The main concern with card holder data security is data theft, which invariably means unauthorized intrusions. No network on Earth is immune to the risk of intrusion. There is a famous saying, “The only secure system is one that is unplugged, turned off, and in a locked room.” Hand in hand with the impossibility of completely securing any system is the “ease of use” issue. The more secure a system is, the more cumbersome it necessarily becomes. At what point does a business suffer from the operational and administrative overhead of imposing strict security? On the one hand, ensuring that no mishap should happen to our customers is a basic, non-negotiable service that we must provide. On the other hand, we must strike a balance between using the system and unplugging it and locking it up in a vault.

Battening down the hatches
As with all things, we have to manage our risk, and we made some basic decisions.

• We will not store any electronic card-holder data at the Wedge, so that there would be nothing to steal.
• To that end, our system will act merely as a conduit where card-holder data is passed, in encrypted form, from the card reader directly to the card processor.
• We will separate and isolate that part of our network where that process takes place and apply what measures we need to prevent intrusions to the isolated network.

We already knew we were not collecting card-holder data and that data transmission was encrypted because, as we have developed our own point-of-sales system (IS4C), we ourselves wrote the source code that controlled the behavior of our credit card processing system to the specifications of our credit card processor. We did have to comb through our databases to delete all previously collected card data, left over from earlier times. That included going through our files in our backup archives, long forgotten except to the grizzled few who remembered the good old days. Where files were already burned onto CDs, we revived the data from them, deleted what we had to, burned new CDs and shredded the old ones. It was a thorough housecleaning, and we came out of it with all card-holder data gone. Or so we thought.

To isolate the front-end network, we made it a separate segment, or a subnet, beyond which none of the point-of-sales computers could be accessed. The separation was not merely in the network address, but was a physical one as well. This meant all the hardware, the cabling and the equipment were separated as if the front end were in a different building. It was all the more separated because we were already using a dedicated Internet connection with a different Internet service provider to handle our credit card transactions. Even the cables going out of the building were on a separate network.

Of particular importance was the issue of wireless access. Wireless is like a Trojan horse. Once a wireless device is turned on inside the building, it can potentially be accessed from anywhere by another wireless device within the range of its signals. From there, an intruder could hop onto the wired network, and security would be compromised. Wireless devices are now in general use, and many of these devices have become a necessary part of any operation in any organization. Intrusions and theft by means of wireless connection have, in turn, become prevalent. Wireless in any form is automatically assumed to be insecure. With that in mind, we took the opportunity to ensure that there were no wireless elements in our front-end network.

After the network was isolated, the securing of the network became twofold: securing access to the network as a whole and securing each element (computer) on the network. For the network as a whole, this meant establishing firewall and network routing rules while securing each computer. This process involved the following:

• Establish internal access control for the computers themselves.
• Eliminate extraneous services and close nonessential ports on the computers.
• Establish internal access control for essential services on the computer, including, most importantly, access control for any kind of database management system.
• Establish access control for the point-of-sales application (IS4C) running on the computer.
• Protect against vulnerability with up-to-date security patches and antivirus software.

All these happened to be things that had to be done regardless of PCI compliance.

Meanwhile, the nature of credit card processing using computers requires that the computers be connected to an external credit card processor via the Internet. The processor, in turn, needs to be able to access those computers in order for transactions to be completed successfully. Front-end computers are, therefore, exposed to the world, regardless of how well they are controlled from within. That in turn means, firstly, firewall and routing rules for external connection to the Internet must be established, and secondly, the firewall itself, because it is the most exposed part of the network, also has to be secured. Securing the firewall, as a computer in itself, then proved to be an important piece.

Prepare to repel boarders—independent audit
When we thought we had all the hatches battened down, we contacted a number of PCI-compliance assessors approved by our credit card processor to get a sense of what else we needed to do. Security assessors offer a wide range of services. For the right compensation, they would dispatch a team of network professionals to an organization to help design its security system. But we were unable to afford the “right compensation,” which ran to five figures.

The assessor we decided on required a description and a schematic drawing of our entire computer network, not just the front end. Based on what they gleaned from the information we provided on the work already done, on the nature of how credit cards were processed at the Wedge and the volume of sales, they considered it adequate that we undergo two things: an external vulnerability scan and our completing the PCI “SAQ”—or the PCI DSS Self-Assessment Questionnaire—to their satisfaction.

The vulnerability scan was to be scheduled once every three months, conducted by remote access to the exposed parts of our system via the Internet. There were four “risk categories”: informational, low, medium and high. The discovery of a single vulnerability in the medium or high range would automatically mean non-compliance. The scanning, heralded by an email notification, took over 24 hours. Subsequently, we requested additional scans.

At the end of each requested scan we got a detailed report as to how exposed and vulnerable we were on the Internet, with known solutions listed as to how to deal with any problems. The scanning activities included repeated attempts to access and breach the firewall. While monitoring and somewhat alarmed by what we could see of the attacks as they unfolded, we did not, of course, take steps to interfere. The main purpose was not to pass the test, but to have someone else discover what we ourselves could not, and to be made secure in the process.

Self-reflection
Completing the SAQ proved to be a lengthy project. One failed answer meant noncompliance, but this was a voluntary exercise. No one was there to insist on how we answered the questions, and it was obvious what the right answers were supposed to be. The point of the SAQ was to educate us on what a security baseline should look like, and making a good faith effort to complete the assessment correctly meant arriving at that baseline. Each question posed a task, and sometimes a challenge. Belatedly, we were reminded that:

*Card-holder information is not stored in electronic form only. It could also exist on credit card slips, and those were considered “storage media.” A system had to be put in place to store, control access to and ultimately dispose of the slips.

• Security strategy had to be formalized with responsibilities assigned to specific individuals.
• A formal security policy had to be drawn up and posted.

We did not do all of that in one day, and we did not merely do what was required so that we could pass. Whether the requirements were intended for us or not, we huddled, discussed, took steps and improved security. What the PCI DSS requirements made us do was to take a good look at our system and operating procedures, and get started in doing it on an ongoing basis.

Compliance
The day came when we received our PCI DSS compliance letter. We noticed at the bottom that it was valid only for 90 days. In 90 days, the world would have changed, our network would have spread, with new computers added, new software installed, new processes established, new patches out, new viruses found. The IT team will re-convene, reboot, and it will all begin anew.

For more information on PCI compliance, the website for the PCI ­Security Standard Council can be found at: www.pcisecuritystandards.org .