Bob Russo: Breached!

There is a brief article that I found on CardNotPresent.com where Bob Russo, outgoing general manager of the PCI Security Standards Council, describes an incident where he was robbed (really burglarized but everyone misuses "robbed" – pet peeves of mine). Bob uses this story to illustrate how PCI-compliant companies are breached.

Before reading my punchline, please read the article: Bob Russo: Breached!

Stop. Go back; you didn't really read it…

Ok, anyone notice something missing from Bob’s story? Immediately following the police investigation the DA (DA playing the part of the card brands) didn’t levy fines for PCI non-compliance. His HOA (HOA playing the part of an acquirer) didn't kick him out for not properly securing the premises. He was not required by various states (cameo appearance, playing the part of themselves) to send out breach notifications to all the contacts stored on his laptop. He didn't make headline news with "Russo Exposes PII!" Lastly, he was not hit with one or more class action lawsuits for the stolen Personally Identifiable Information before the ink had a chance to dry on the police report.

Hmmm… I wonder if my name and email address was contained in his contact list.

Earth to Media, Earth to Media, Come in Media…

Target breached, and EMV would have done nothing to prevent it. Period! I realize there are a lot of EMV fans out there stating differently, but please reference people that really know EMV -- its advantages and its limitations -- before releasing propaganda pieces painting EMV as the silver bullet it is not and calling it news.

What EMV cannot do: EMV does not protect the PAN, expiration dates, CVV2 or even PINs in anyway. While information as to whether or not PINs were stolen in the Target breach is sketchy, all the other information was stolen and EMV does not protect any of this.

What EMV can do: EMV is very good at preventing the stolen information from being used to create forged cards to be used for card-present (swiped) purchases, but if history repeats itself, the stolen information will primarily be used for card-not-present (ecommerce) purchases. Until EMV and/or the card brands address card-not-present purchases, EMV is nothing more than a one legged stool.

Dog Pile!!!

I've done it again. You can see my latest rant Dog Pile!!! that conveys some of my, let’s say “passionate” thoughts on placing more burden on merchants for breaches. Enjoy.

Cybertheft Crackdown My Butt

I've read several stories of late flaunting some high profile cases where it seemed law enforcement and judges were finally cracking down on cybercrimes and cybertheft. I thought we finally made the turn and were prosecuting the perpetrators (hackers) of these crimes the way they should have been prosecuted all along. Then I read this today: http://www.bankinfosecurity.com/rbs-worldpay-sentence-too-light-a-5058/op-1

In a nutshell, the mastermind of the RBS WorldPay hack, where $9 million was pilfered from U.S. bank accounts, was sentenced to 30 months in prison and ordered to pay $89,000 in restitutions. Let's see, $89,000+30 months for $9 million, that comes out to a $297,000 per month. That's a pretty good payoff. I understand that he had accomplices' so he did not pocket the entire $9 million; but many wannabe hackers reading this will see it as $9 million for 30 months. This sends a strong message: Cybercrime pays!

Until sentences are large enough to discourage the crime, nothing will change: More money will need to be spent for cyber security -- more hacking -- more money -- more hacking -- and so on…

Global Payments Breach Growing

The latest reports I read are that the Global Payments breach started in January 2011 -- more than a year earlier than initially thought. To me the story here is that during this timeframe Global Payments went through at least two onsite PCI audits and neither caught the breach in progress. Since Visa and MasterCard were so quick on pulling Global Payment's PCI certification, should they not also pull the QSA's certification(s) as well? I'm not sure if there were more than one QSA involved nor am I certain who it was -- but that does not really matter as my next post will describe. I am currently writing a post on the usefulness of PCI, or lack thereof. Stay tuned...

Pondering the Possibilities

Currently the PCI SSC is pondering the possibility of including language that would exclude encrypted cardholder data from the merchants PCI scope if, and only if, the merchant does not have access to the encryption keys used in the process. This is to make it easier for end-to-end encryption (E2EE) solution providers to promote their wares. Security wise, I think this would be a mistake.

I've argued many times on different forums about how tokens (provided they are "true" tokens that are not derived from the PAN) and tokenization are more secure than E2EE data -- format preserving or otherwise. E2EE proponents almost always quotes some report that states a brute force attack on the encrypted data will take umpteen million years of CPU time to crack. There are a few problems with this argument. For starters, I imagine similar arguments were being made back in the single DES days; but then CPU speeds increased exponentially and umpteen million years of CPU time became months, then weeks, then days, and eventually minutes. Another issue is the potential for a yet to be discovered inherent vulnerability in the encryption algorithm or key hashing; SSL1 comes to mind, as well as MD5.

A final issue with the "umpteen million years to crack " argument is that this assumes a brute force attack. If the key is ever compromised by any means -- yes, a brute force attack is one means, but also poor key storage, memory sniffers, disgruntled ex-employee, etc. -- the encrypted data is vulnerable.

Ponder this:

1. PCI SSC adopts some form of language that removes E2EE data from PCI scope. 
2. One or more middle men handle this E2EE data between the starting end point and the final end point: POS application, merchant LAN, Internet service provider, routers, gateway, processor(assuming the gateway is not the end point), etc. 
3. One or more of these middle men log all this E2EE data in the clear -- since E2EE data is already encrypted, this data is out of PCI scope and therefore has no requirement for additional encryption, data retention periods, etc.
4. Everything works securely and flawlessly for weeks, months or years.
5. The E2EE key is compromised by whatever means (brute force, encryption algorithm vulnerability, disgruntled employee, whatever).

While the key was cracked or acquired outside the scope of the merchant, how will this play out for the merchant or any of the middle men in #2 above if it is determined that the source of the breached data was the logs containing the out-of-scope E2EE data?

Now with true tokenization, tokens cannot be cracked; no keys, no possibility of inherent tokenization algorithm vulnerability (assuming true tokenization where the token is not derived PAN). Any middle men storing or logging tokens could and should be removed from the liability equation provided they never touched the real cardholder data.

I hope the PCI SSC carefully consider this issue in it's entirety before adding any out-of-scope wording for encrypted data.

Heartland Lawsuit Dismissed - Secure Enough

A lawsuit initiated by shareholders against Heartland Payment Systems was dismissed on Monday. The judge ruled that the plaintiffs didn't prove their case that Heartland lied about their security measures that were in place. The story can be found on the StorefrontBacktalk blog "Heartland Lawsuit Dismissed, 'Insufficient Evidence' Of Weak Security."

There is a very interesting quote by the judge on the third page of this article: "The fact that a company has suffered a security breach does not demonstrate that the company did not ‘place significant emphasis on maintaining a high level of security.’ It is equally plausible that Heartland did place a high emphasis on security but that the Company’s security systems were nonetheless overcome..." Juxtapose this statement to comments from Adrian Phillips, Visa International’s Deputy Chief Enterprise Risk Officer and Regional Head of Risk for North America: "No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach. In all cases, forensic investigations have concluded that compliance deficiencies have been a major contributor to the breach." I go further in stating that when push comes to shove, in one way or another, all breaches will be found to be compliance failures. Not because companies are ignoring PCI, but because the fact that PCI is so all-encompassing that it's impossible to be in compliance 100% of the time. Hackers are like terrorist in the fact that hackers only need to be successful one time whereas merchants need to be secure 100% of the time.

The reason I found this interesting is that it appears that the judge in this case is distinguishing between security and compliance, and rightfully so. I think "best effort" is what is missing with PCI, at least in terms of compliance. There should be some "best effort" allowances otherwise some unscrupulous stakeholders in the industry will view PCI as nothing more than a revenue generation scheme upon a breach (a breach, cool, free money!). Unfortunately, I think there are some in the industry already treating breaches this way.

Now that there is precedence separating security from compliance, will this change the landscape? Or will it just change the wording of the plaintiff's complaints; instead of "did not do all they could to be secure," you might see "did not do all they could to be compliant."

Who Breached Me?

In my last posting "Yet Another...", I wrote about a breach notification from Network Solutions, a payment service provider. Soon after the original posting, Evan Schuman from StoreFrontBacktalk.com pointed me to the actual notification, which prompted a correction to my posting. While my initial ire was based on false assumptions, the final notification letter to consumers still included the merchant name even though Network Solutions was the entity breached and the service provider was accepting the blame.

During this discussion we had a brief debate about whether or not the merchant name should have appeared in the notification. This discussion gave me an idea to have a simple sparring session debating our different points of view using a simple 100 word or less argument for, argument against, rebuttal for, rebuttal against format. Before we begin, I want to thank Evan for participating and spending the time to put his viewpoint down. Here is the final result:

Should the merchant's name appear in breach notifications if the breach occurs upstream from the merchant and beyond the merchant's control?

ARGUMENT FOR the Merchant Name Appearing in the Notification - The retailer's name needs to be on that notification letter for two reasons. First, consumers only know the retailer's name. Give them a letter that doesn't say something they recognize and it will be thrown out. Secondly, a small retailer will be inclined to go with the lowest cost service. If they don't feel some pain if that service screws up, proper choices will never happen. This will insure that retailers make the best available choices, balancing cost versus security. Breach letters aren't supposed to be fun, but can be functional. Some good can be served.

REBUTTAL to Argument FOR the Merchant Name Appearing in the Notification - Consumers do need to know their card number was compromised but the merchant's name does not need to appear for the consumer to take notice. A notification from the consumer's bank is more credible than from TransUnion, the merchant or the provider that was breached. Second, price does not guarantee security. Case in point, Network Solutions is not known as the low price leader yet they were breached and their name appears in Visa's Global List of PCI DSS Validated Service Providers. This list should be of some value to the merchant beyond "you're required to use one of these." The card brands cannot expect the average merchant to spend days vetting providers.

ARGUMENT AGAINST the Merchant Name Appearing in the Notification - The card brands dictate that merchants must be PCI compliant and to be PCI compliant, merchants must use PCI compliant practices, applications and service providers. Visa publishes a Global List of PCI DSS Validated Service Providers. Since merchants are required to use vendors from this list, the card brands should provide some form of safe harbor, even if it's nothing more than not disclosing the merchant's name in the event that the service provider is breached. The card brands shouldn't expect all merchant to physically tour and spend days vetting these providers; the card brands should have done this when preparing the list. The merchant should not have their brand tarnished due to a security breach completely beyond the control of the merchant.

REBUTTAL to Argument AGAINST the Merchant Name Appearing in the Notification - The Safe Harbor concept is a wonderful theory, but in payment security, it doesn't exist, never has existed and truly can never exist. Retailers normally (the Network Solutions situation is the exception) have tremendous day-to-day influence on security, in the same way that a car can pass a state safety inspection but that doesn't mean the driver won't remove his brakes the day after the inspection. Given the influence a retailer has day-to-day, the merchant must assume responsibility. Besides, the breach letter needs to notify in a meaningful way.

Based on the arguments and rebuttals presented here, hopefully you can decide for yourself where you stand. My guess is your stance will be determined by whether you are looking at the issue from the merchant's perspective or the consumer's perspective. Either way, hopefully this gives you insight to the other side of the argument.

That was fun. I enjoyed sparring with Evan and I hope he enjoyed it as well. I'm sure this argument/rebuttal format will be used again to debate other issues. Until next time...

Yet another...

Yet another big name breach -- or is it?
Yet another PCI compliant provider breached -- or was it?
Yet another reason PCI compliance needs an overhaul -- or does it?

On July 27th, it was learned that Network Solutions was breached and 574,000'ish customer records were possibly compromised. Network Solutions supplies payment services, among other things, to thousands of small merchants and is a big name. The full details of the breach, the how's and why's are not yet known as the investigations are still ongoing (and may never be known by the public, but that's another story). The fact Network Solutions was breached does not really surprise me because I know there is no such thing as absolute 100% security and the next breach is just waiting for a name to be associated with it.

Big name?

What caught my eye here was how Network Solution informed the consumers. In an effort to comply with the tangled mess of privacy reporting laws, Network Solutions contracted TransUnion to notify the end-user consumers or cardholders. But instead of saying "we're Network Solutions, we take security seriously but unfortunately...", they sent a letter opening with "TransUnion is contacting you at the request of XYZ Merchant..." where "XYZ Merchant" was a merchant that Network Solution was providing payment services for. To me, this is pure slime intended to protect Network Solutions' brand name at the expense of the merchants they serve. The merchant did not have to be mentioned at all, Network Solutions was breached, not the merchant.
I stand corrected. My original ire was based on feedback from affected merchants about the Network Solutions notification letter sent by TransUnion. Reading the complaints, I got the impression that Network Solutions was hiding their brand name behind that of the merchants. After the original blog posting, Evan Schuman (from StorefrontBacktalk) linked me the proposed notification that the merchants were discussing. In the notification, Network Solutions was clearly taking the blame so as the famous Saturday Night Live line goes -- ...never mind.

Compliant?

Who really cares? According to Visa, "no PCI compliant organization has ever been breached." So it's fait accompli that Network Solutions was not PCI compliant. To me, this means one thing: PCI compliance is not truly attainable.

I never can seem to harp on this enough: Focus on security as PCI compliance is a myth. Reduce your risk profile to reduce the chance of a breach. If you are harder to breach than the guy next door, chances are your name will not be associated with the next breach and compliance will never come into play (after all, if you are breached, it will be determined that you were not compliant).

PCI Overhaul?

PCI is a great list of best practices and it should be used as just that, best practices. The card brands should stop trying to use a list of best practices as definition of black or white, secure or insecure, compliant or non-compliant. Since security is never 100%, Visa's quote highlights the biggest flaw: equating compliance to security.

Since the card brands have essentially stated that only non-compliant companies are breached, I think the whole "compliance" factor should be removed. Instead, simply state, "companies that are breached and found to be not taking prudent steps to secure the data or negligent, will be fined." The PCI Best Practices can be used when deciding prudent or negligent. But I don't expect to see anything simple like this anytime soon. After all, there is too much money to be made by the card brands and banks if they stay focused on compliance.

References:
StorefrontBacktalk: Network Solutions Data Breach Hits 574,000 Consumers
CNET: Network Solutions Breached For 574,000 E-Commerce Account Records

Do as I Say, Not as I Do

The latest breach involving Heartland Payment Systems is all the buzz. Some are surprised and/or appalled “yet another high profile breach.” Others question the timing of the announcement theorizing some public relations attempt to hide the announcement within the presidential anointment, oops, inauguration ceremony. What caught my eye is the latest campaign: Heartland CEO Calls For Industry Cooperation To Fight Cyber Criminals And Adoption Of End-To-End Encryption. While I agree with end-to-end encryption, I feel this is nothing more than a case of “do as I say, not as I do.”

My issue is the last paragraph of the above linked press release: “For the past year, Carr (Robert O. Carr, Heartland’s founder, chairman and CEO) has been a strong advocate for industry adoption of end-to-end encryption — which protects data at rest as well as data in motion — as an improved and safer standard of payments security. While he believes this technology does not wholly exist on any payments platform today, Heartland has been working to develop this solution and is more committed than ever to deploying it as quickly as possible.”

The technology already exists, just not in the terms that Carr may be implying. I think Carr is referring to chip cards of one sort or another, but there is nothing stopping a company from doing end-to-end encryption within their own network. While PCI does not currently require end-to-end encryption within a LAN, PCI is meant to be a “minimum” security standard – it is not a be-all, end-all blueprint for secure payments.

I try not to advertise for Shift4 within my blog, but Shift4 internally does end-to-end encryption within its network. The weakest point in the whole chain is the final hop to the bank or processor (which we have compensating controls in place to isolate and minimize the exposure at these points – but this is beyond the scope of this rant). Here, I would argue side-by-side with Carr to force all banks and processors to require application layer encryption at this hand-off point instead of solely relying on VPN encryption. Shore up the weakness of this layer, problem solved provided that the banks and processors internally do end-to-end encryption and you don’t have to wait for PCI rule change, nor do you have to toss out the baby with the bath water by switching to chip cards.

Switching to chip cards may solve some issues, but viewing chip cards as a panacea, I feel, will be a big and extremely costly mistake for merchants if other layers in the end-to-end data path are ignored. If merchants think PCI is expensive now, wait until they need to purchase and deploy all new hardware and fork out the POS software upgrade fees required to support this new hardware platform.