Why be PCI Compliant?

I've spent three weeks discussing PCI Compliance, but why am I so concerned about protecting financial and personal information? Because there are a lot of bad people in the world, and the Internet has given them access to the more trusting (or "gullible", from their perspective) audience in relatively safe countries like the United States. Here are two recent experiences that could have led to financial loss.

Scam 1: "Please refund my other card"

I heard this story from one of our clients during a recent Performance Analysis.

An attendee registered for a training conference and attempted to use several different credit card numbers to pay for his tuition. (He eventually completed payment with a Visa card.) Weeks later, he sent an email to the event's registration support contact explaining that he would be unable to attend the conference, but that he had recently switched credit cards and would like the refund to be posted to his new credit card number. The support contact decide not to do this, because (1) PCI Compliant systems like Certain Registration don't support this process and (2) the request, combined with the number of failed payment attempts using multiple credit card numbers, "smelled fishy".

Later, the client found out that the Visa card used for tuition payment belonged to a older woman in Arizona, and after piecing this puzzle together, they refunded the full amount to the original card. Our contact notified their corporate security department, who in turn contacted the FBI's Internet Crime Complaint Center (IC3). It turned out that the "attendee" was a Ghana national involved in a fraud operation much larger than this incident. Fortunately for our client, because they listened to their instincts instead of immediately trying to satisfy the attendee's request (and because they were using a PCI compliant system), the investigation could be turned over to the FBI without financial loss for either them or the credit card victim.

Scam 2: "Sorry, but I wrote the check for too much"

The second experience hit closer to home. I recently moved and listed my previous townhouse for rent. I received an email from "Marcus", who informed me that he was placing a colleague in the north Dallas area for a year and would like to rent the house, and would it be okay to pre-pay six months' rent in advance? My suspicion was raised by the poor grammar in his email, but you can't argue too much with cash up front, so I accepted the offer.

Two days later I received a DHL overnight package from Dubai, United Arab Emirates with a cashier's check for $35,300 drawn on JP Morgan Chase Bank in Florida. Great - except that six months rent plus deposit was only $11,200. He then sent me an email stating that he had accidentally cut the check for too large of an amount, but he was not able to change it so could I please cash the check and then wire transfer the difference ($24,100) to his bank in the UAE?

Well, that was the end of the business deal for me, but I have learned that this con is common enough to get it's own FTC warning, and successful enough that the FBI IC3 is only interested in your case if you actually lost money. A few mornings later, I received a phone call from "Marcus" (which showed on my caller ID as originating from a Dubai country code) and from the background noise activity it certainly sounded like he worked in a call center operation as busy as that of any medium-size business in the U.S.



It's a jungle out there

The Internet has brought the world together, but unfortunately much of our world is still the Wild West. Be careful out there, and follow best practices like those of the PCI Standards.

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

Two weeks ago, I discussed what PCI Compliance is and where it came from. Last week, we reviewed the first 6 requirements of the PCI Data Security Standards (DSS). Today we'll finish this series with an explanation of what requirements 7-12 do to protect your clients' cardholder information.

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know

This sounds like a page out of a classic spy novel, but the principle of "need-to-know" is a foundation of good security. Only users who specifically need access to credit card data should have access to the system that contains that data. If a user has access to other parts of the system, then by default they should not have access to unencrypted, sensitive credit card data. Lastly, administrators should grant access to cardholder information only to the minimum number of users who specifically need to see that information for a legitimate business reason that has no alternative.

In Certain Registration, for example, some meeting planners still collect credit card numbers from their attendees in order to "guarantee" their room reservation. These planners need to deliver the unencrypted credit card number to the hotel if the registrant is a "no-show" for the room, thus they have a legitimate business reason to view the full credit card number and their User access can be granted permission to see those numbers. However, all other users will only see the last four digits of the credit card number if they attempt to view the same reports.

In the near future, as more companies adopt PCI compliance, I suspect that no hotels will be willing to receive a list of unencrypted credit card numbers and will thus require room blocks to be guaranteed against the master account. Then the current "legitimate business need" to view these numbers will disappear, and such access can be ended. In this case, the planner can still store the credit card information in encrypted, unreadable format, and they can charge the registrant's card if they are a no-show without any human being able to read the cardholder data.

Requirement 8: Assign a unique ID to each person with computer access

If you are going to restrict access to data via an authentication scheme (such as username/password), then each individual person must have their own authentication. If multiple people share a single username, for example, then the system cannot audit which person made specific actions, only which username made those actions.

In order to make sure that only the intended user has access to a given username / password combination, PCI places multiple restrictions on systems:

• Passwords must be at least 7 characters long, with a combination of alphabetical and numeric characters
• Every 90 days, passwords must be changed and inactive user accounts must be removed
• The user must be authenticated prior to changing or resetting passwords, e.g. by sending a temporary password to the User's email address
• User sessions without activity for 15 minutes must be automatically timed out and require login to re-start

Some of these security requirements, such as the 15-minute timeout rule, can be annoying for users who don't need access to credit card information. Thus our system gives those users the options to adhere to a less restrictive security policy - but they cannot view credit card data. Any user who can view cardholder data must adhere to the PCI guidelines and live with its inconveniences.

Requirement 9: Restrict physical access to cardholder data

PCI requires companies to control physical access to cardholder data; this includes access to the database servers, backup media files (which are often stored offsite), paper hardcopies, etc. Modern Network Operations Centers (NOC), such as ours at NTT Verio, provide this control through 24/7 security, photo-badges with biometric hand scans, individual cages and cabinets, and constant video monitoring.


Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data

PCI requires us to log all activities related to accessing cardholder data, plus all activity related to controlling access to that data. So everytime an Administrator creates a new user with access to cardholder information, we record the action in a log. If a user runs a report with cardholder data, the action (and content of the report) is logged. These logs cannot be deleted by Administrators, and are available online for a year after the action occurred.

Requirement 11: Regularly test security systems and processes

Periodically, security vulnerabilities appear due to new techniques discovered by hackers or researchers or software updates. PCI requires adherants to monitor critical files for changes, scan internal and external network vulnerability quarterly, and perform annual detailed security tests on all systems.

In addition, networks need to have an "Intrusion Detection System" (IDS), which is basically an observation post that watches the data traffic flowing through your network and looks for patterns that indicate malicious data attacks or a security compromise.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

Companies that collect cardholder information must publish written security policies that adhere to PCI compliance. The policy should be known by all employees and contractors, and any outside vendors who receive cardholder information must also be PCI compliant.

Since most data security breeches are caused by internal behavior, all employees who have access to credit card information in bulk format must be screened prior to hiring. For example, we perform credit checks and criminal checks on employees as part of the hiring process.