5 Tips for Complying with the PCI Standard

There are basically two low-cost approaches to the Payment Card Industry Data Security Standard (PCI DSS).

On one hand, an institution that considers the PCI standard a giant compliance headache can choose to slip under the radar for as long as possible, betting that the credit card companies and banks have more important organizations to target than colleges and universities.

On the other, PCI compliance can be seen as a much more prudent path, a chance for the institution to take a proactive step toward upgrading its overall security, especially when it comes to processing credit card transactions.

Simply defined, PCI DSS is a set of requirements put forth by the Payment Card Industry Security Standards Council, designed to ensure that all organizations that process, store or transmit credit card information maintain a secure environment.

The voluntary compliance deadline of July 2010 has long since passed. Institutions should understand that the major payment brands, including American Express, Discover, JCB, Master Card and Visa, may fine a bank anywhere from $5,000 to $100,000 per month for PCI compliance violations. Banks more than likely pass these fines downstream to merchants. In addition, violators can expect banks to either terminate accounts or increase transaction fees. Penalties typically are not made public, but they are known to cost hundreds of thousands of dollars.

At the University of Tulsa, we finally moved forward after the Bank of Oklahoma contacted us two years ago about our PCI compliance plan and we didn't have one in place. Once notified, we recognized that this was an important opportunity to modernize our credit card security.

Before our effort to comply with the PCI specifications, we had no standard system for processing credit cards. Transactions were not encrypted, and too often, the hard drives of local computers at point-of-sale machines stored credit card numbers in Microsoft Word, a spreadsheet or with e-mail.

In essence, there was a separate system for all the myriad ways the university accepted credit cards: The system for processing athletic tickets was separate, as were the systems for processing magazine subscriptions, museum memberships, tuition and room-and-board payments, and purchases of computer equipment. Complex and diverse though all these applications were, we were determined to comply. The following are some best practices we learned from our experience.

Start by meeting with your main stakeholders. Identify what a breach will cost the organization, then evaluate the technical challenges for processing and ­managing credit card payments. ­Remember that the last thing you want at this late date is to get a phone call from a bank asking for the institution's PCI statements and not have a plan in place (or at least one under way). At the ­University of Tulsa, we started by getting all the main players in a room to discuss the issues and identify our business processes. We met with staff from the athletic ticket office, the bursar's office, human resources and two other staffers from IT, along with the university controller.

Develop a strategic plan to address compliance. PCI compliance will entail a dramatic change in the way the organization does business. As part of the process, reevaluate all your relationships with manufacturers. Explain your goals, then based on those discussions and the PCI guidelines, design a step-by-step process for how an electronic transaction will work. The two main processes you'll need to consider are an electronic transaction at a point-of-sale terminal and a purchase made over a university website. Resulting process details may differ slightly depending on whether the process is executed by a patron or by an employee acting on behalf of a patron.

Identify the enabling technologies to reduce scope. Reducing scope means reducing the portion of the university technology infrastructure that is exposed to potential vulnerabilities and subject to compliance review. For starters, we wanted to eliminate the processing, storage and transmittal of clear-text cardholder data. Associated procedures, storage devices and network segments would then be out of scope.

The solution for employee-initiated activity was to encrypt all credit card transactions at the point at which the card is swiped and have a third party (not the university) manage the encryption keys. Under the new system, the credit card numbers are swiped and encrypted by new card readers that are part of a point-of-sale terminal or that are attached to a general-purpose computer. The transactions are then processed and managed by an external gateway processor.

Credit card numbers are no longer entered or stored locally on desktops, so this reduces the chance that someone could hack into our network and steal credit card information. Cardholder data in readable text form no longer travels our network. Perhaps more important, the university is not liable because the encryption keys are managed by a third-party gateway processor and the credit card numbers are not stored on our network.

For web transactions, we designed a standard application programming interface for electronic transactions. Moving forward, any form that handles a credit card over the web must interact with the published API (web service) that the university supports. By agreement, our gateway processor simply will not accept a web transaction from any other source.

As part of the technology piece, we had to choose between point-to-point encryption (P2PE) versus token­ization. In P2PE, the credit card number is encrypted at the source and sent (in our case) to a third-party financial services gateway processor. With tokenization, the credit card number is securely communicated to an external tokenization service. The tokenization serv­ice provider then returns to campus a meaningless "token" placeholder. The token can travel the university network and may end up in unmodified campus processes and databases that previously expected actual cardholder data. However, only our financial services gateway processor can reverse-engineer the token and ­finalize a credit card transaction.

We started with P2PE, which was recognized by the payment card industry earlier than tokenization, and plan to incorporate tokenization where it makes sense. Although both technologies are secure, tokenization offers more flexibility. For example, there was no easy way for us to set up recurring payments with P2PE, while tokenization can easily enable this for our users.

Plan for vulnerability scans. PCI compliance requires all merchants to submit a passing scan test every 90 days, or once a quarter. The scan should identify vulnerabilities in operating systems, services and devices that could be used by hackers to target the organization's private network. Scans must be conducted by certified providers known as Approved Scanning Vendors and should not require the merchant to install any software on their systems or perform denial-of-service attacks.

Do the paperwork. Once everything is in place, it's time to file the Self-Assessment Questionnaire. Don't file the paperwork on your own. You really need the assistance of a consultant that has experience wading through the requirements. We filed our completed SAQ Form C, attesting to our compliance, at the end of 2011. Other than continuing with required vulnerability scanning and evolving compliance requirements, we expect only modest continuing interaction with our bank unless there is an incident.