- Published: 04 April 2013
- Written by NStinchcombe
By Mark Bower, Vice President, Product Management at Voltage Security
The recent stories circulating around the litigation between Genesco and Visa over PCI Compliance and a data breach shine a spotlight on some of the grey areas in PCI DSS.
At the same time, there’s a spotlight on how retailers may misinterpret PCI DSS and what it means to them in reducing risk. The bottom line is that retailers can easily avoid the pain of a breach – and get rid of the PCI DSS challenge in a major way. However, what’s underneath this case hitting the front pages of the popular media?
There are some unusual and conflicting issues around PCI compliance as reported so far, so it’s worth breaking this down for further investigation. As this case unfolds, we will no doubt learn more about what actually happened in this unfortunate data breach, but already there are lessons to be learned and more questions which need answer. Let’s take stock of the events:
1. The breach was in 2010 per the notification records on file to various state attorney generals. Genesco took their breach seriously, and began notification processes - so they were on the right track. However, the breach stemmed from malware infection of servers leading to data compromise.
How did the attackers get in? What was being done to protect cardholder data on these systems? What did they really get?
A big goal of PCI DSS compliance is mitigating risk, not just ticking boxes for compliance sake. The malware risks to servers and POS systems were not new and retailers were being warned about these threats by Visa, MasterCard and many others ever since the TJX incident that shook the retailer industry.
So, with major breaches taking place, especially in retail and the warning bells were ringing loudly, merchants concerned about managing risk and reputation were already taking steps to go beyond PCI DSS with end-to-end encryption of data.
2. PCI DSS isn't perfect - even the PCI council will attest to that. However, it is quite specific. From the breach notifications, it appears that Track 2 data was potentially compromised.
Track 2 data is the "gold" that can be used to create fake cards. It was identified as the data potentially stolen in this particular case. There is a gray area in PCI DSS relating to pre-authorization data. That’s the cardholder data used for authorization of a payment from the payment processor. The actual payment may be settled at the end of the day using the authorization response information and the card data. That’s why post-authorization storage of cardholder data must be protected if stored (per PCI DSS 3.2). However, the tricky part of PCI DSS is that pre-authorization data. PCI DSS mandates the following:
a. 3.2 - Do not store sensitive authentication data after authorization (even if encrypted).
b. 3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere)" and PCI DSS 4.1 " Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks
The assumption is that card payment authorizations are real-time events at payment and therefore there’s absolutely no need to store it as its captured, processed and done with. Perhaps the attackers stole the data in this small window of opportunity – sniffing data as it was read for pre-authorization processes.
In my personal opinion, this is still a big gap in PCI DSS and may be where Genesco is heading with its claims. Perhaps we will find out. The bottom line is that being compliant at one point in time doesn't provide protection against advanced threats. If there is any data in the clear, it's at risk unless it’s encrypted.
So let’s dive in on that small window of opportunity for compromise. Genesco made some unusual claims in this regard, perhaps thinking that by rebooting servers they could reduce risk by “getting rid of data”. That’s not the right way to secure data. Here’s why: most breach investigation reports show that the time from most compromised servers to data being stolen can be as little as a few milliseconds for advanced malware.
Verizon's data breach report for 2012 for instance shows that 10% of overall attacks have the time from attack to compromise as "seconds" while 75% are "minutes.
So with only seconds from attack to theft, the only way to avoid risk is ensure no live data is available to attack in the first place. Claiming that rebooting servers is a strategy to eliminate risk isn’t effective against persistent threats such as malware targeting cardholder data. More importantly, PCI DSS does not recognize rebooting a server as an acceptable method of protecting data from threats or compromise. So strike one against Genesco’s risk mitigation strategy.
There's also something odd about the server logging approach as reported. If reports are to be believed, then logs were overwritten after reboots thus eliminating any information about the breach.
PCI DSS compliance requires log retention. Rebooting the servers which destroys the logs would be an immediate PCI non-compliance - destruction of log files related to cardholder data processes. Maybe the reports are misrepresenting the facts, but if true would be a questionable IT practice.
Strike 2. Lastly, the log files themselves may have been a possible the source of the compromise - if so then that points to another non-compliance - cardholder data was stored in log files too by implication - that's a common mistake, and a very easy target for attackers.
Strike 3. Time will tell as to what really happened. The case is very interesting not only as its challenging the PCI regulation itself and its enforcement, but also to reveal exactly what was stolen, how, when and what measures were put in place to stop it happening again.
$13m is a large fine for a retailer to swallow for sure under any circumstances, but if it turns out that this legal costs are some reasonable fraction of that, and the remediation costs have been significant, then one has to ask the final question - why not apply those funds to stop a similar breach happening again by using data-centric security?
That way your reputation, data, and business risks and PCI compliance costs are dramatically reduced – to almost nothing. www.voltage.com
References:
Reference: original breach notification. http://www.oag.state.md.us/idtheft/Breach%20Notices/ITU-214957.pdf
Verizon 2013 Breach report (not out yet) http://www.verizonenterprise.com/DBIR/2013/?__ct_return=1
2012 report used for this comment: http://www.verizonenterprise.com/resources/reports/rp_data-breach-investigations-report-2012-ebk_en_xg.pdf
See figure 40 for attack timeframes.
