The Danger Of Assuming Perfection
Written by Evan SchumanIn last week’s lead story, PCI Columnist Walter Conway wrote a hard-hitting column questioning whether–under very limited circumstances–carelessly used encryption might actually weaken a retailer’s data security. In security circles, it’s heresy to question encryption and, predictably, the emotional reaction to the column was intense.
It’s not often that people challenge our technical conclusions while simultaneously questioning the marital status of our mothers. The column suffered from one key technical error, questioning how easy it would be to extract clues to an encryption key if you encrypted the short payment card expiration date field. Walt admitted that error–and explained the context–in his column this week. (By the way, if anyone else wants to yell us at, this week has a column from Frank Hayes that questions the very premise of security passwords. Gluttons for punishment we be, a rare breed of journalistic masochists.) But there’s a bigger issue at play here, a long-standing technology frustration beneath the emotions.
The fundamental challenge to Walt’s column is that the security holes described are irrelevant for any system that is properly protected with professionally managed cryptography. As a practical matter, I think that’s a fair point. The attacks Walt described can be thwarted by the proper defenses. But how many retail systems are protected by such properly managed systems?
There are only so many fully trained cryptographers and, by definition, not all of them are the best. If there are only a handful on an IT team, it stands to reason they are being supervised by people who know far less about cryptography than they do. With the workload piling on, isn’t possible that some cryptographers may cut corners, knowing that no one else on the team would notice?
The point is, it’s dangerous for senior IT managers to make security–or any other technology–decisions based on the premise that all security implementations are done flawlessly. For such an assumption to be valid, that perfect work must be performed by every team member (and, potentially, their predecessors), along with the coders from every partner in the supply chain, including, of course, payment processors.
Walt’s original premise was that encrypting short fields–especially ones that are relatively easy to guess–is unnecessary and that it’s asking for trouble. Why do it? Why not make decisions based on the belief that everything may not be perfectly crafted?
This issue isn’t merely one of encryption. In last month’s eight-day-long set of uptime headaches for American Eagle Outfitters, the problem turned out to involve an IBM team, a remarkably unlikely set of concurrent server failures and a disaster recovery site that had not been properly maintained. Do you honestly think that no one at IBM cut a few corners? After all, what are the odds of both servers dying at the same time? “That disaster recovery won’t likely be needed, so who will notice if we don’t keep on top of it? We’ll get to it next week.”
Server log manual reviews are another area where IT staff will often, little by little, cut back on time spent–especially as the holiday rush kicks in and every IT staffer is needed 24×7. Remember this golden oldie: TJX’s IT team didn’t notice Gonzalez’s team moving 80 gigabytes of data out the door. Or this classic from Wal-Mart: An account for a former employee was left active, thus allowing the thieves to use it repeatedly for–wait for it–17 months.
What if Wal-Mart had assumed this ploy couldn’t work against the company because accounts are always terminated as soon as an employee leaves? “See? It says so right here in the manual.” Or, what if TJX felt invulnerable to a Gonzalez type assault because someone was paid to monitor the logs?
The encryption scenario Walt painted may not have worked in a cryptographically perfect environment. In the real world, though, if it was me, I’d stop encrypting short easily guessed fields. But that’s just me.
-Marc
August 26th, 2010 at 9:35 am
Not to be mean, but you’re thinking like a business manager here. A manager will say “here’s our task, we got 98% of it done, so we’ll call that a win.” And that’s a great and pragmatic way to run a business.
But security has to be 100% perfect, all the time. You can’t build 98% of a castle wall and expect to keep out 98% of the barbarians. Settling for a second-rate cryptographic solution is the same thing, but because you don’t understand the problem, you can’t see that the walls don’t actually encircle the entire castle.
Security professionals understand this, too. They know there may be unseen gaps in protection, which is why they recommend defense in depth. You stop the intruders at the firewalls, and place IDP appliances on the network, and require long passwords, and all that extra stuff that keeps out the first 98% of bad guys.
Even poorly implemented encryption would stop most bad guys who got that far. But if you’re serious, you have to have it done absolutely right. That’s why the heavy lifting of cryptography should be designed once by the PCI, publicly reviewed, and a standard should be implemented external to all the retailer’s systems. We know 7 million merchants will never get it right. We even know a measurable fraction of those merchants are themselves infiltrated by criminal organizations who would steal cardholder info. We have to get the need to design crypto systems out of their hands.
August 26th, 2010 at 1:43 pm
Why was there an “emotional reaction” to Walt’s incorrect comments? You saw this reaction because every time an incorrect comment like this is made it makes the life of people who design and build secure systems more difficult. This wastes both time and money.
I’m certain that there are vendors out there who are now spending lots of time and effort with either customers or prospects trying to explain why it’s really OK to encrypt small fields even though an article on this website said that it’s not.
So in security circles it’s not really heresy to question the security of encryption. What does get people very upset are comments that don’t tell the entire truth and end up inaccurately claiming that encryption is weak in some way.
Vendors have to deal with misinformation like this frequently, and there are clearly costs involved when they do. Let’s not forget that that’s money that could be spent on more useful things: new products, enhancements to existing products, etc.
August 27th, 2010 at 2:40 pm
I do not see why people take it so personally. I tend to agree with Walt in that the keys should be able to be decrypted relatively easy. Yes sure certain constants have to be met first (such as having the background to do encryption, having access to the data in the first place and other items).
Since all algorithms are based on a mathematical equation it stands to reason like the simple problem (y+100=900) what is Y it would be somewhat similar for cryptography in its standard form. (Data + Cipher = CipherText) if you know or can estimate the data (exp. date) and you can get access to the encrypted data (CipherText) wouldnt it stand to reason that you could figure out the Cipher. Sure it may not be easy for everyone but we shouldnt fault the author for saying it isnt easy….Like the first reader said it best, security has to be 100%. While I think that is impossible you need to have what you use setup in the best way possible for your usage, and you must know what mitigated risk you have introduced into the mix.
I personally think it would be somewhat commonsense to not set up the data like this to encrypt small fields. If you have an online bank account would you choose a 4 digit password to protect it? It is also like LMHash passwords in Windows under 16 characters are relatively easy to hack…is that Walts fault too?
The problem with security today is that most people look at it the wrong way.
1) They only look at the bare minimum to get by and not the object of the security and what it is to protect.
2) They often look at it based on cost and if fines will be imposed (PCI). Look at Heartland they were PCI compliant yet still got hacked.
3) They do not use common sense. DONT PICK A SIMPLE PASSWORD (or in this case a 4 digit number to encrypt).
4) It (security) is governed these days by to many non-technical managers, as well as countless PCI this — HIPAA that — SAS70 like compliance programs that are backed here and there by different companies and the overall drive is not security it is revenue. Why not have a national or global standard for security across the board and a certification process that is in place with it. This way everyone in the security space is on a level playing field with everyone else and securing the data will be the objective and we will all be on the same winning team in the end?
September 2nd, 2010 at 11:53 am
CF,
I suggest you read about Kerckhoff’s Law. I’d recommend you start there and revisit your security principles.
There’s a very good wikipedia article on it. This will help you understand some of the fundamental flaws in your reasoning and your concept of “estimating” a key or encrypted data in algorithms like AES etc , which certainly is not close to possible – thats an established fact.