PCI

End-To-End Encryption -Wouldn’t It Be Nice?

Since Heartland suffered a data breach (disclosed in January), they’ve become the poster child for end-to-end encryption. This is defined as encrypting card information from the moment it’s swiped until it reaches the card issuer. Of course, there may be some motivation provided by the fact that Heartland plans to sell a proprietary end-to-end encryption system by the end of this year. (Not sure I’d buy it from them!)

It sounds like a perfect solution, until you get into the mechanics. And that’s where the problems begin:

Hardware - Are all POS (Point of Sale) registers going to be able to handle the increased load of CPU cycles to encrypt and decrypt? It seems like all the vendors want you to use their hardware.

Software - Not all POS solutions are the same. What about companies that use registers AND online sales? Plus, there is currently no standard for what kind of encryption should be used. So you must go with a proprietary solution all the way through. How many companies can afford to replace so much materiel?

Location, location, location - Where does the data get stored? Can the database decrypt and re-encrypt? What about Call Centers, Fraud Management, or Marketing? They need to look at the information. Ultimately, where are the encryption keys stored and who/what has access to them?

Of the six vendors offering E2E, all of them require changes to POS systems.

And should this technology be implemented, it will not release businesses from complying with PCI. No, a report will still have to be delivered to the acquiring bank on an annual basis, signed by a C-level executive.

There’s no free lunch, it seems.

Points to Ponder: Reviewing the “SoupNazi” Activities

By now I’m sure you’ve heard that Albert Gonzalez is being charged with the attacks on Hannaford, Heartland, 7-Eleven, etc. In between all the excited reporting, are some points that admins and auditors ought to pay attention to. We ought to ponder how this attack is different from attacks in the past, and why this attack was so successful.

1. Using a “team.” Most of his team have not been captured, residing as they may somewhere overseas. Using a multiple talent set across several different technical approaches increases the chances of success. This is becoming more and more common, especially with ATM break ins.

2. They used SQL-injection attacks. This isn’t new, but all of these folks were having quarterly scans from external vendors as part of PCI compliance. Why didn’t the scans catch the injection vulnerabilities? Makes you want to take another look at the scanning company you may be using, doesn’t it?

3. They broke in via wireless. Anyone still using WEP out there - it’s now trivial to crack the protocol, and someone will certainly do it if you offer it up.

4. There’s a big market for those credit cards and the people that can get to them. Over 130 million cards made him a LOT of money.

And we still don’t know “exactly” how he was caught, do we?

MasterCard Ups the Compliance Quality of PCI DSS

I’ve written before about how the Payment Card Industry’s (PCI) Data Security Standard (DSS) has some loopholes that make it easy to look “compliant” and therefore “secure. In order to comply with the DSS requirments, merchants can do one of three options:
1. their own self-assessment report signed -off on by a C-level management officer;
2. hire auditors to do a self-assessment and report the C-level can sign off on;
3. or hire an independent, PCI-accredited QSA firm to provide an independent assessment and report to their acquiring bank.

Consider that the QSA firm is required to have liability insurance, pay a hefty yearly fee to the Consortium and provide an independent assessment. Chances are the independent firm will work harder to make sure their report is accurate (given the stick that the PCI hangs over their heads of ultimate liability).

It costs merchants a lot more to have the report done independently, and they can’t hide security problems as easily. Just the fact that they have the do-it-yourself option in two out of three doesn’t give me confidence in their reporting. Any time organizations “self-assess,” there can be an enormous opportunity for fraud by the unscrupulous.

Interestingly enough, MasterCard has decided to remove the “self-serve” option from Level 2 vendors by December 31, 2010. Under the new rules, Level 2 merchants must hire a PCI-approved auditor to complete an annual on site data security assessment by Dec. 31, 2010.

Previously, those merchants were only required to complete an annual self-assessment questionnaire in order to comply with MasterCard’s Site Data Protection Program. The Payment Card Industry Data Security Standard (PCI DSS) forms the baseline for MasterCard’s Site Data Protection Program.

Will PCI’s DSS begin requiring it as well? Is this a move to test the waters? I hope so. Even though VISA says it has no plans to do so, the PCI standards board has a lot more power to remove poor QSA’s than try to assess an internal team.

The Tangled Ethics of the Payment Card Industry DSS

I just finished reading an absolutely terrific article from a sister auditor who is now on my short-list of must-reads. She’s got a great name (Gunn) and a killer sense of humor (sorry, I could NOT resist).

“Why Suing Auditors Won’t Solve the Problem”
is worth a read for her point of view on what it’s really like in Audit-Land.

A bank that was impacted by a data breach at a merchant is suing the QSA firm that performed the PCI exam and signed off that the merchant was compliant. They want to recoup the money they lost from replacing all the credit cards to their customers and dealing with related fraud from the breach.

Her point of view presents the difficulties auditors have in providing reports and doing exams, as well as the foibles of various firms.

It’s a painful, but absolutely true description of how clients can respond to auditors when they don’t get the exam results they like - “Throw the bums out, and hire better (meaning cheaper AND more cooperative) ones!” As well as pushing a report documenting problems to the circular file.

What is equally painful is that there are certainly “security auditors” out there who are more than willing to do the “check box” report, collect their check, and hit the door. They are usually the cheapest bidder, by the way.

She makes an interesting point about PCI auditors, however. In order to be compliant, merchants can either do one of three options: their own report, or hire auditors to do a report they can sign off on, or hire an independent, licensed QSA firm to provide an independent report, on their behalf, to their acquiring bank, which until recently did not have to forward the report to the Credit Card Consortium.

Consider that the QSA firm is required to have liability insurance, pay a hefty yearly fee to the Consortium and provide an independent assessment. This requires a firm with pretty deep pockets (a juicy candidate for a lawsuit) and a good skillset of people. Staff of a QSA firm must have at least 10 years of experience and a CISSP running the assessment. As a result, the number of QSA firms is limited to large audit/accounting firms and security companies.

The challenge is that the client they are assessing is also paying their bill. And most of the security companies doing PCI exams also sell security products. Two fundamental conflicts with true independence, don’t you think?

Most merchants tend to do the internal self-exam, where they can manage their own report or hire a firm to do the report they can then sign off on. This means they may hire firms that do not have the same level of experience to get the job done more cheaply. See Eigen’s Rules of Thumb numbers 1 and 6.

The second challenge is that merchants can change the configuration that was tested a week after the QSA firm issues a report.

Perhaps the most fundamental issue is the public’s expectation that PCI compliance = a secure architecture that protects their information. Given that a large percentage of merchants are only partially compliant (meaning that they have met some, but not all, of the requirements and have a plan in place to be compliant at some point soon, i.e., TJMaxx, and we can see how that worked) and most merchants are doing the internal exam, there is generally a recipe for chaos.

Acquiring Banks, of course (meaning those banks who have acquired, and are supposed to manage merchant accounts) are placed in the role of security monitor by the Credit Card Consortium. They also levy fines (the ones handed down by the CCC) and set timeline requirements for PCI compliance.
Can they cut off a merchant who is making the Bank loads of money for not being compliant? Yes. Are they likely to? Probably not.

Consider that if a merchant is not fully compliant, their level of security is below the minimum. Would I want to give that merchant my credit card info? Probably not. The merchant would start to lose business based on that poor reputation, which is why PCI doesn’t publish a list of merchants who are fully compliant.

Confused yet? Me, too. Use cash and checks. Preferably cash.

So what is a poor admin to do? Focus on securing the systems under your purview and documenting your efforts. If you’re doing the job you know you should be doing, sooner or later, when the auditors show up at your door, your efforts will be validated and you can sleep at night.

Storm Clouds Ahead

It seems like every big vendor is pushing for business to “use the cloud.” Only now are we starting to see some questions arise in the general media about how secure cloud computing is.

The short answer is: it’s not. Intrinsically, whoever has physical ownership of your hardware has your data. It’s all very nice to say you will save money by outsourcing, but there are no hard and fast statistics to support that. What you save in outsourcing may come back in the form of increased costs for securing your data outside of your data center.

And you do know, of course, that the Feds can look at your data in that cloud without a warrant, don’t you?

So what CAN you do to save money and justify the “real costs” of keeping your data local to higher management?

First: Explore virtualization - Many organizations have realized enormous hard savings in electricity, storage space, UPS, etc by utilizing Virtual Machines to run their applications. The added bonus is that you can have immediate full backups stored elsewhere. It’s also marvelously easy to test a patch on a virtual machine, without having to worry about breaking something in production.

Second - Re-negotiate contracts - If a vendor isn’t meeting your standards, now is the time to switch. There is an enormous competition going on with this downturn of the economy. IF nothing else, get a better deal than the contracts you have.

There’s quite a bit on the web that can help you justify costs internally. But when the discussion about clouds comes up, make sure you ask the questions needed, such as:

1. How we will provide audit information from the cloud?
2. How do we control access to our data? (This will be the real question, because ultimately, the cloud vendor will control access, not your company. You may be able to control application access, but that does not address the server OS or underlying database controls.)
3. How will we monitor access to our data? Because there is no standard for thin-client computing security, the answers will be all over the map, and usually cost you more money.

The PCI standards council is currently looking at cloud computing with an eye to evaluating the security of credit card data. I’ll be interested to hear what they come up with. In the mean time, consider on of my Rules of Thumb: You can outsource data, but you can’t outsource data responsibility.

If you do find a vendor that says they can help you stay compliant, make sure you understand the contract very, very well. Your job could depend on it. I suspect the cost savings will be small, but it’s worth examining just for comparison’s sake with what your organization is doing now.