Over One Million Records Compromised in a Few Weeks

Is there something in the water?

In the past few weeks we have seen over a million records containing personally identifiable information (PII) compromised in data security breaches at Higher Education institutions nationwide.  These are very high profile and damaging breaches.

First we read about the University of Maine being hacked.  That relatively small breach netter somebody 1175 Social Security Nubmers and 435 payment cards.  However, it was followed almost immediately by news that hackers successfully stole 350,000 personal records from the University of North Carolina at Charlotte.

Now during this Memorial Day weekend, we learn that hackers executed a "sophisticated and skilled attack" on the university's systems to grab 654,000 student and alumni records from the University of Nebraska.  The data in that breach included "Social Security numbers, as well as addresses, grades, transcripts, and housing and financial aid information. The database also includes information for alumni as far back as the spring of 1985, as well as for people who applied to the university but did not attend school there.

I doubt there is any relation between these data breaches except for one thing: the schools kept a lot of PII (sometimes including payment cards) and they didn't protect it adequately.  

The unfortunate part of all these situations is that they were and remain unnecessary.  PCI is not perfect, but it is prescriptive.  That is, it gives you rules for protecting all you confidential information, not just payment cards.  I have no insights into any of the data breaches noted above except what I read (which, of course, is always dangerous).  But I wonder if the controllers, foundation and development departments, and others responsible for the data followed some simple rules to protect the data?  

For example:

• Did they restrict access to the data to only those staff with a business need-to-know (PCI Requirement 7)?  
• Did they encrypt the data in the database (Requirement 3)?  
• Was there an effective firewall separating the database from the Internet (Requirement 1)? 
• Did all users have strong passwords, and did they use two-factor authentication when accessing the data remotely (Requirement 8)?  
• And maybe most of all, how effectively were the PII databases segmented from the rest of the university's environment (Requirement "0")?

I don't know if these three breaches are the beginning of a trend.  Hoever, now may be a good time for everyone to look at PCI and what it can do to protect all of your institution's PII and keep you out of the headlines for reasons you really don't want to be there.

Guidance on Mobile POS Devices

The PCI Council has just released some very interesting (and brief, hence the "at a glance" designation) guidance on mobile payment devices and applications.  The document is quite interesting, and I recommend it to everyone who is looking at mobile devices for their campus for what it says and what it hints is coming.  I think that should include about every campus on the planet (and every retailer, too).

The Council acknowledges what we already know, namely that mobile payments are convenient and risky.  Therefore, the plan is to encrypt the card data at the swipe before it gets to the device so the phone is "out of scope."  To keep the phone out of scope, though, you need an "approved" card reader and a P2PE Solution Provider.

Er...an "approved secure card reader"and "P2PE solution provider"?

The problem, of course, is there are precious few (if any) approved card readers, and absolutely no approved P2PE solution providers.  Those P2PE solution providers won't be available until this fall at the earliest.  Nevertheless, the PCI Council has pointed the way forward: forget putting a payment app on your iPhone, iPad, Android, or other device; and forget a card swipe dongle (of any shape or make) unless and/or until it is on the PCI PTS list.  The idea seems to be that any smartphone is going to be too risky for a merchant to use as a POS (or Point of Interaction, POI, in P2PE-speak) device.  

I have to wonder whether the many "sleds" that encrypt card data and are PTS certified would still count.  They should qualify as secure readers, but the problem is they go to the processor, and none of them is "approved" yet.  Darn, just as I was really getting to be a fan of the sleds.

Reading the PCI tea leaves is always risky, but here goes...  I predict that any number of things are going to be focused on P2PE, including mobile payments and a re-thinking of the (famous) PCI Frequently Asked Question 10359.  That is the one that says encrypted data are out of your scope so long as the ability to decrypt exists with a separate entity.  This poor FAQ has been stretched beyond its original intent.  I predict P2PE is going to both (a) be the only -- only! -- way to handle mobile transactions using an i-device, and (b) that the FAQ is going to be re-written to specify the only way to keep encrypted data out of scope is to have an approved P2PE solution.

This whole P2PE situation will be interesting to observe, and I suggest everyone involved with PCI monitor developments closely.  At the recent PCI workshop, we had an outstanding presentation and extended discussion of how to handle the growing business need for mobile payments.  I only wish this document was available earlier.  It begins to bring together so much of what we heard, both on mobile and P2PE.

At the EDUCAUSE Security Professionals Conference this week, I did a half-day session on P2PE and tokenization.  We covered a lot, but we only touched on mobile payments.  I have to admit that I didn't see this coming, but I should have.  It is so logical and completely in line with the direction the PCI Council is going.  That is, that personal smartphones are inherently insecure, so merchants need to keep them out of scope.  We all know that.  Except in this case, it took a little PCI wake-up call for me to get it.

PCI Certification Program for Application Resellers and System Integrators

There is great news for every campus merchant who has a PA-DSS application installed and maintained by a reseller or system integrator.  The PCI Council is launching a training and certification program on PCI standards and the importance of correct implementation and installation of PA-DSS validated applications to make sure that the merchant stays PCI compliant.

The new program - called Qualified Implementer and Reseller, or QIR - is aimed at those implementers and resellers of payment application software.

The program applies to all kinds of PA-DSS applications, from food service to parking lots.  While many of these resellers and integrators are doing an excellent job, some have been challenged with installing and configuring the payment applications securely.  The result in some cases has been a data breach that leaves the merchant in an unfortunate position.

The Council expects to launch this course in mid-summer.  There will be more information coming, so watch this space!  In the meantime, if you use a system reseller or integrator, have a word with them about the QIR program.  They, too, will want to monitor developments.

Tokenization and P2PE at EDUCAUSE

I am excited to again join EDUCAUSE at their 2012 Security Professionals Conference (May 15-17). On Tuesday afternoon May 15, I'll lead a three and one-half hour session (whew!) covering two very important and timely topics: tokenization and point-to-point encryption.

Many schools are exploring and in some cases implementing one or both technologies. Both offer the potential to reduce PCI scope, often significantly. However there are a lot of details in the implementation to get all the benefits you hoped for. This is particularly the case with point-to-point encryption where the standards are and infrastructure are still evolving. In spite of this, many institutions are investing in new POS hardware and processes. During the session we'll take a deep dive into each technology and explore what you need to know to implement either/both successfully at your institution.

I don't know if I or anyone has all the answers, but we'll try to make sure we address as many of the questions as we can.

If these topics are of interest to you or your school, and if you are attending EDUCAUSE's conference (or someone from your institution is attending), I hope you will register for this session. We will address both of these topics briefly at the Treasury Institute's PCI DSS Workshop, but this session will let us delve into each topic in some depth.

Paper Data Breaches Can Be Expensive...and Stupid

Has there ever been a more meaningless, patronizing, and pathetic comment made after a cardholder data security breach than: "We take patients’ [or customers'] information very seriously, and we’re reviewing our policy, and our training procedures to make sure this never happens again?"

According to this report from the Boston Globe, St. Elizabeth's Medical Center is currently notifying more than 6,800 people that they potentially compromised billing information, including credit card numbers and security codes. It happened when documents the hospital planned to shred were removed by a vendor from a building scheduled for demolition. Unfortunately, the papers (or at least some of them) containing the PANs and security codes (and probably names, too) were found blowing across a nearby field.

Where do we even begin to go through the mistakes this institution is reported to have made, none of which is excusable?

Let's start with keeping PAN data on paper records. PCI allows you to do this, but you need to protect the data. Here, the mistake probably was keeping the data in the first place. I'm pretty sure the hospital could live with just keeping the last four digits, but they kept -- and then managed to lose -- the full PAN.

Then, the hospital also reportedly kept the 3-digit security codes. For this, ignorance can no longer be an excuse. PCI explicitly prohibits retaining the security codes. If they are on a paper form, then you have to find a way to physically get rid of them. Sadly, the same helpful people who decided to keep the PAN apparently also decided they should keep the security codes, too.

How did the papers get lost? The hospital hired "certain trusted vendors" to clear out a building and shred the paper. It looks like the vendor took some shortcuts and never bothered shredding all the records. You may have noticed by now that nowhere have I mentioned the name of this third party. The reason is that it does not matter: the breach was the hospital's. Just like with any service provider, a merchant can outsource a function, but they cannot outsource responsibility. Rarely has this principle been more clearly illustrated than in this unfortunate breach.

Maybe the hospital will get lucky and only those few papers blowing through the field were lost. This situation is possible. Regardless, the hospital has to pay to notify all 6,831 patients as well as any other expenses. If there is any good news in this mess, it appears that no medical information was lost, so the hospital faces only fines from the payment brands and not HIPAA-related fines.

The lesson for all your cashier, bursar, auxiliary, medical, parking, and other campus departments on that take cards and keep cardholder data is that they are doing the PCI equivalent of juggling razor blades. The PCI team must challenge why they are keeping the data in the first place. Merchants need to be sure they are not storing any sensitive authentication data like the security codes. Then, merchants have to realize that they cannot dodge responsibility for securing the data at all times, including on the way to the shredder. That low-priced bidder is carrying the institution's reputation (and checkbook!), so merchants need to continue to treat the data as their own (which they are). Lastly, do me a favor and please check your Incident Response Plan so you don't issue the usual pandering press release. Telling your customer/victims how much you value them just sounds too much like the incongruous "your call is important to us" we hear as we enter customer service voice mail hell.

Paper cardholder data can be breached just as easily as electronic cardholder data. This is a good lesson. It may be painfully learned in some cases, but a good lesson nevertheless.

MasterCard Guidance on Hosted Payment Pages

One of the best and most common ways to reduce your PCI scope for ecommerce transactions is to use a hosted payment page using a PCI compliant service provider. But a hosted payment page (sometimes called a hosted order page) is not a silver bullet. It does not cause PCI to go away, but it can reduce your scope and cost of PCI compliance.

Recently MasterCard has published a PCI White Paper: Hosted Payment Pages. That document describes how these hosted payment pages work. Just as importantly, the white paper describes the risks merchants still face even after outsourcing. Two of these are man-in-the-middle (MITM) attacks (where the bad guys come between your site and your hosting provider) and phishing attacks aimed at the cardholder's computer.

MasterCard recommends remediation actions (especially for MITM attacks) including regular external vulnerability scans of your server, keeping current with security patches, and developing your code securely. As a QSA, I find it disappointing that the PCI Council's SAQ A does not require any of these actions. Please don't let that fact keep you from securing your ecommerce sites. The SAQs are a guide. You still need to be secure.

I recommend you download MasterCard's paper. It reinforces the earlier bulletin from Visa Europe that I've mentioned earlier.

Visa Suspends Global Payments

The New York Times reports today that Visa has suspended Global Payments after Friday's reports of a significant data breach. You can find reports of the breach all over the Web (here, here, and here).

If you use Global Payments for your card processing, here are a few things to keep in mind. First, the Visa suspension is temporary, and not permanent (at least, so far). Also, MasterCard has not acted similarly (again, at least so far). Get in touch with your representative and find out what are their plans.

Because Visa has removed Global Payments from their list of service providers does not make your institution non-compliant with PCI. It does, however, reinforce the importance of your having the protections of Requirement 12.8 (especially 12.8.2) in place.

Meanwhile, monitor the Web for further developments. This story broke on Friday, and it has grown over the weekend. It is quite likely more developments will be coming.