Avivah LitanI was a bit taken aback yesterday when I heard that the much ballyhooed “end-to-end encryption” solution being promoted by payment processors as THE solution for PCI compliance has already been cracked. (Refer to ”Where does End-to-End Encryption for PCI End?” G00170703).
I should have expected it.
In this case, malware enters a retailer’s card reader where it poses as card transactions which are then dutifully encrypted and transmitted as part of the encrypted payment data stream to the payment processor. It is then dutifully decrypted by the processor, and then temporarily stored in the processor’s system. I’m not sure if the malware can be successfully transmitted to the payment card networks (e.g. VisaNet) as part of the payment stream. Probably (hopefully) not since presumably the malware bytes do not conform to the payment authorization data format standard that the card networks accept.
The lessons here are important ones:
- End-to-end encryption (which should actually be called point-to-point encryption) is by no means a panacea. A lot can go wrong from key mismanagement to transaction corruption.
- The lack of standards in this area is going to make it hard to keep the systems up to date. Instead of one standard way of responding to increasing security threats, each vendor will respond differently.
- Encrypted data streams can obviously not be inspected for threats and malicious software. That is clearly a major downside here.
- A layered security approach is always important. I’m a big believer in pattern recognition that detects abnormal activity of any kind.
Category: Uncategorized Tags:
3 responses so far ↓
1 Sam Curry May 7, 2010 at 4:36 pm
Great insight here Avivah — I agree with all your lessons. I’d add another takeaway and have an “answer” for your rhetorical question.
The other lesson for me is that it is always a content and an arms race. All of security winds up a content race because there is an intelligent opponent, and they have an interest in breaking in. This isn’t a source for despair, it just says that our jobs in security aren’t about building the perfect defense — it’s about the ongoing, continual art, science and business of doing defense.
The answer to your rhetorical question, in my opinion, is that there is no end. It’s a false question really: the answer is that there is “no end” and “no solution”. We are in the business of improving the way we respond and decision loops and of innovatively driving up the cost to break something, while the bad guys seek to drive it down.
2 Avivah Litan May 10, 2010 at 4:14 pm
Hi Sam,
Just wondering if the costs of ‘e-to-e’ encryption are higher than potential benefits, given that it’s already been ‘broken.’ Certainly I’m an advocate of a layered approach – just wondering at this point if this layer is a good idea.
Thoughts?
Hope all is well,
Avivah
3 Lucas Zaichkowsky May 17, 2010 at 9:56 pm
It is a shame the some have marketed end to end encryption as a magic pill, lending to these kind of posts. But this news shouldn’t be sensationalized beyond what it really is.
The reality is that end to end encryption implemented in a PCI DSS compliant fashion greatly reduces the surface attack area to whatever is outside of the encryption and decryption endpoints in a card data flow. Visa has issued guidance available to the public on their web site. The PCI SSC is supposedly readying official guidance that represents all the card brands.
“malware enters a retailer’s card reader where it poses as card transactions”
Sounds like someone is sending malicious data (e.g. SQLi) embedded in track data on cards or in fabricated transactions being sent without talking to the card reader, then receiving end isn’t performing input validation.
The company acting as the decryption endpoint is handling plain text card data on behalf of the merchant. They are required to be PCI DSS compliant as a Service Provider. They can be hacked if they don’t follow PCI DSS compliance requirements as I’d imagine this report is providing an example of.
PCI DSS requirement 6.3 says to “Develop software applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices, and incorporate information security throughout the software development life cycle.”
PCI DSS requirement 6.3.1.1 specifically requires testing “Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.)”
PCI DSS requirement 6.3.7 requires a security code review be “reviewed by individuals other then the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices.”
Sounds like they weren’t really maintaining PCI DSS compliance, even if they were recently validated. Lesson learned? I sure hope so.
Now think about the other incidents where a Service Provider was breached. End to end encryption will still decrypt at the payment processor as the furthest point of decryption. Going all the way thru to the thousands of issuing banks would require a complete overhaul. So end result is that I sure hope Service Providers understand security and PCI DSS for the sake of their own business and the payment processing industry as a whole.
When a merchant is using tamper resistant peripherals that encrypt card data in the peripheral and send that to a third party acting as the decryption endpoint, they are safe from having “that card data” stolen from their systems.
However, merchants still need to search everywhere to find card data outside of that one secure card acceptance solution. They need to consider other common entry points such as keyed in cards and soon, mobile card acceptance. They need to hunt for legacy card data and legacy systems they’re not thinking of. If they’re doing e-commerce, it’s impractical to convince every consumer to buy an encrypting peripheral. However, they can shift the PCI requirements and liability to another Service Provider that offers Hosted Payments. They might have third parties taking orders for them. They are also Service Providers if they’re touching the card data in plain text. If merchants get plain text card data out of their systems and shift any remaining liability to the Service Provider, PCI requirements for them as a merchant are greatly reduced.
Once they’ve removed all the card data from their systems, there are still some PCI DSS requirements that pertain to them. Following the really short PCI SAQ B tells them what to do. A few of those requirements can be marked as not applicable. 12.8 and its four requirements spell out how merchants need to perform due-diligence making sure the Service Providers they use are compliant. It even requires that the merchant get written agreements from the Service Providers about PCI DSS compliance and liability. In the event a Service Provider is breached and loses merchant card data, the merchant will now be in a golden position. The Service Provider is the one responsible for protecting card data and the liability if they’re hacked. See the PCI SSC FAQ article http://bit.ly/acCIG8
If you have a merchant account, all this information applies to you directly. The fines and bad press from a compromise can be devastating. If you’re a developer or reseller of integrated payment processing solutions, consider all the blame and lawsuits that can be placed on you by compromised merchants. Then there’s the bad PR if you don’t settle out of court quietly. Get in contact with someone that really gets it and wants to help you reduce your PCI scope. Dealing with PCI on your own is difficult. I can be found at http://twitter.com/PCIpartner or visit the processor I work for on the web at http://www.MercuryPay.com