PCI Compliance Part 2 - Don't lose that credit card data!

Last week I discussed what PCI Compliance is and where it came from. Today we'll look at the details of the PCI Data Security Standards (DSS) and explain what each standard does to protect your clients' cardholder information. If you want to see how well your organization meets these criteria, contact your registration software provider or conduct the self-assessment questionnaire.

Below are the 12 major requirements of PCI Compliance, described in layman's terms.

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
A firewall is an electronic barrier between the outside world (which is dirty) and your data (which is hopefully clean). Computers and servers are like houses with thousands of windows, called "ports". Data can flow in and out of these ports, for example, web browsers typically use port 80 for "http" requests and port 443 for "https" requests. A firewall is like a window shutter - it provides a barrier to traffic flow on the ports that you don't need to use.

Sophisticated firewalls can even close ports to specific types of data and can provide "dual-zone" protection. A dual zone firewall means that you can have one set of protection for your web servers (which must have ports 80 and 443 open to the world in order to deliver web pages) and a second set of more restrictive protection for database servers (which only need to communicate with the web servers and thus can be closed to the rest of the world). The more ports you close or restrict, the tougher it is for bad guys to get in.

It's like the battle for Helm's Deep in Lord of the Rings - Twin Towers. If the orcs get through the outer defenses, then they still have to breach the walls of the keep in order to get to your people. Yeah - it's exactly like that…

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
This requirement is so obvious that it is painful to write, but a surprising number of web servers use blank or system default passwords for their administrator access. Just ask my neighbor, who purchased a Linksys WI-FI router last year and still doesn't know that I get better access on his network from my laundry room than I do on my own network. (Actually, please don't tell my neighbor.)

Protect Cardholder Data

Requirement 3: Protect stored cardholder data
This requirement is really two parts:

1. You can't store certain types of cardholder data at all, e.g. the CVV/CV2 number or PIN or magnetic stripe contents. You can only use that data one time for authentication, and then must remove the data from memory.


2. Any data that you do store (Cardholder name, card number, expiration date, bank information) must be protected.

At Certain, if we need to store the full credit card number, e.g. because the event planner is going to provide it to the hotel for room guarantee purposes, then we first encrypt it using a 128-bit Blowfish cipher. This is a fancy way of saying that even if a malicious user were to get through our firewall and administrator passwords, then instead of seeing credit card numbers like 4111111111111111, they would get encrypted values like "A29D075CA20EF9E892045671ACBED93D8A". This won't do you a lot of good at Amazon.com.

The PCI standard requires the your encryption key, the code which unlocks the encrypted value, to be stored only in temporary memory. That means that we have to enter the code phrase every time we reboot our servers, and there is nowhere on the physical drives that someone could read this key and decrypt the stored credit card numbers. Furthermore, registrants and administrators only see the last 4 digits of the credit card number on their screen (e.g. ******1111) and even the encrypted card information is deleted 90 days after the event ends.

Requirement 4: Encrypt transmission of cardholder data across open, public networks
Most internet users know the difference between "http" pages, which are transmitted in plain text across the Internet from your browser to the server, and "https" pages, which are encrypted by your browser prior to transmission to the server. Whenever we deal with credit card data, we use an "https" connection. This way if someone were to tap into your data lines and read the information passing between your computer and a web server (which is surprisingly easy to do), then they couldn't get any meaningful information.

Secure connections ("https") require the web site to have a secure certificate, which must be renewed periodically. For example, ours comes from Entrust:



Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software
PCI requires companies to have anti-virus software on all servers and personal computers that collect, store, or transmit cardholder data. Modern anti-virus software is continually updated to protect against new viruses, and it scans the computer's files and data traffic for viruses, spyware, adware, and other undesirable programs that might be trying to collect credit card information for a malicious user.

Requirement 6: Develop and maintain secure systems and applications
Requirement 6 means that software vendors must follow processes that maintain their application at the highest level of security, for example:

• Apply all security patches from software companies within 1 month of release


• Subscribe to alert services for newly-discovered vulnerabilities


• Separate development, test, and production environments


• Develop applications within the best practices of the Open Web Security Project


• Have an outside application security firm review code for common wulnerabilities

I'm tired of writing for today, so we'll cover the last 6 requirements next week.

PCI, FACTA, CISP, SDP - Just don't lose those credit card numbers!

No online service wants to read about themselves in the news under the headline "ACME Web 2.0 loses 350,000 credit card numbers". So I felt a shiver of fear last week when a client told me that our registration application was not FACTA compliant. My fear soon turned to anger, after spending the past six months pushing through new development to achieve Level 1 PCI Compliance, after we decided to move beyond CISP without having to implement SDP.

Lost yet? Well, it turns out that the politicians and various credit card companies each tackled the problem of credit card security separately.

Payment Card Industry Data Security Standards

PCI stands for Payment Card Industry - an association that reflects the combined interests of VISA, MasterCard, Discover, American Express, and JCB to promote financial data security standards. Prior to publication of the PCI Data Security Standards in September 2006, each card brand managed their own set of requirements. I first implemented VISA's Cardholder Information Security Program (CISP) in 2001, and Certain had maintained compliance with it ever since. We were about to embark on MasterCard's program (Site Data Protection or SDP) when the PCI Standard was announced, which obviously saved a lot of time and money for online vendors who accept multiple credit card types.

We fall into the "Level 2" category for PCI Compliance, for processors with between 150,000 and six million annual transactions. Nevertheless, we plan to grow and want to be as secure as practical, so we opted to achieve Level 1 compliance.

There are six categories of PCI compliance security standards, with 12 broad requirements. I'll cover these details another day, but if you want to read ahead there's always the PCI Compliance Guide.

FACTA and Your Taxpayer Dollars at Work

While the five major credit card brands were solving the problem of data security in a way that made business's lives easier, in 2003 Congress passed the Fair and Accurate Credit Transactions Act (FACTA), an amendment to the Fair Credit Reporting Act (FCRA).

Section 113 of FACTA (don't follow that link!) took effect in December 2006, three years after the amendment was passed into law.

SEC. 113. TRUNCATION OF CREDIT CARD AND DEBIT CARD ACCOUNT NUMBERS.
Section 605 of the Fair Credit Reporting Act (15 U.S.C. 1681c) is amended by adding at the end the following:
(g) Truncation of Credit Card and Debit Card Numbers.--
(1) In general.--Except as otherwise provided in this subsection, no person that accepts credit cards or debit cards for the transaction of business shall print more than the last 5 digits of the card number or the expiration date upon any receipt provided to the cardholder at the point of the sale or transaction.

However, page 6 of the PCI DSS self-assessment questionnaire says nothing about expiration dates, but it does ask, "Are all but the last four digits of the account number masked when displaying cardholder data?"

I guess Congress thinks they know more than the businesses whose livelihoods depend on the security of cardholder data, but anyway, after our patch this week the transaction on Certain's confirmation page will change from

Richard Borry (Visa ******1266 exp. 10/08)

to

Richard Borry (Visa exp. 10/08)

and as a result we will be compliant with FACTA, PCI, CISP, and SDP.

The Bottom Line

Enough with the acronyms and anti-government over-regulation diatribe. What I hope you learn is that:

1. Professional web software providers care deeply about the security of your credit card data
2. Companies like Certain spend hundreds of thousands of dollars to adhere to the state-of-the-art standards, and to maintain compliance to those standards as they change
3. You do *not* want to deal with this yourself

Ask your software vendor about PCI Compliance, ask to see an independent audit report, and think twice when your IT group says "No problem" about building an in-house system that will handle credit card data online.

APEX Implementation Pilot Program

In last month's APEX TAC meeting, EJ Siwek announced our intention to set up pilot programs between early adoptor trading partners in order to implement the XML standards that we developed with OTA last year.

The objective is to demonstrate the pratical application of XML standards for data exchange within the meetings and group travel industry. The immediate tactics, however, are to build the development framework needed for software programmers to implement the APEX XML standards. This foundation includes:

1. Design a "Test Harness" framework, in order to:
• Validate XML well-formedness
• Validate against OTA XSD schema
• Validate to APEX implementation of OTA XML
2. Build a Test harness for each XSD:
• Request for Proposal (RFP) – Request and Response
• Rooming List – Request and Response
• Event Specification Guide (ESG) – Request and Response
• Functional Setup Order (FSO or BEO in hotel terminology for Banquet Event Order) - Exhibitor and Normal
3. Create an XSLT to transform valid APEX XML into Word / PDF / Excel formats
• RFP – Request or Response
• Rooming List – Request or Response
• ESG (ESG, FSO, FSO – Exhibitor) – Request or Response

As I discussed previously, each company who implements APEX standards will need to build their own translator routine that converts their proprietary data structure into the APEX standard XML format. However, once that is done, all APEX-compliant organizations will be able to share common tools that will allow them to test and validate their translator routines, and convert the XML output into human-readable versions of the standard APEX reports in Word, Excel, or PDF format. This interoperability is the key benefit of becoming APEX compliant.

For the test harness framework, we plan to accomplish the first two tests (XML well-formedness and adherance to OTA XSD standard) by requiring developers to use an editor such as XML Spy that already performs these functions. Developers will have to "self-certify" that they have passed these tests prior to being able to use the final validation test, where they will submit their XML output to our engine for conversion into Word or Excel and comparison to the validation standard. In any case, XML that is not formed properly or does not adhere to the XSD schema likely will fail the third test.

In the next APEX-TAC meeting on February 15, we plan to assign portions of this project to participating companies, with the hope of having something to demonstrate at the quarterly meeting in Ft. Lauderdale in March.