Encryption Is Security Theater
Last night I was talking with a certain analyst from a large company that we’ve all heard from and we got into a discussion about most security people not understanding encryption at all, to the point that it is assumed to be a cure-all. In fact, with the exception of encrypting data at rest (and in many cases not even then), use of encryption serves as nothing more than providing a false sense of security.
This is particularly true in the case SSL. SSL is probably the most deployed, least useful security technology since tin foil underwear. Gene Spafford (as usual) put it best years ago, and nothing has changed:
“Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench.”
Take a look through the various breach databases. Is there a single case where the breach could have been prevented by the use of transport level encryption? I have yet to find one.
But what about CA1386 and it’s brethren? Or PCI? They mandate encryption. PCI dropped the requirement with the move to 1.1 so clearly they didn’t see any real benefit of it. As for CA1386 and the like, although use of encryption does provide one with a get out of jail free card, all of the practical ways of applying encryption to online systems means that hacking the server means you have access to either the encryption keys or that the database is already decrypted for use.
Which brings us to data at rest. Encryption is only as good as the password/passphrase that protects the keys. Users are notoriously bad at selecting good passwords. This combined with the fact that the more popular disk encryption programs automatically decrypt the data for you on the basis of your login credentials (EFS, Bitlocker, FileVault, etc) so in many cases again one actually isn’t that well protected. On the plus side, tools like PGP, BitLocker and others are well suited for protecting data at rest when they are separated from their keys. Particularly USB drives and the like.
So when doing a risk assessment, please don’t assume something is secure because it uses encryption and please don’t assume that whatever issues there are can be fixed by adding encryption. After all it is just security theater.
[Edit: Corrected a typo. Thanks Gavin.]
Passwords are a quaint notion.
Of course, if you attach your securid fob to your laptop bag, and use the serial number on the back of the fob as your PIN, you may not have gained much.
There’s only so much you can do to prevent theft, I guess.
“SSL is probably the most deployed, least useful security technology since tin foil underwear.”
I have to disagree with you on this one. Certainly many criticisms can be made of SSL (IanG will be here in a minute), but SSL has generally removed mass MITM sniffing as an attack against Internet web-transactions. Without SSL we’d see many more of those types of attack. I’m not sure how you can argue otherwise on this point, but I await your reply.
“SSL is probably the most deployed, least useful security technology since tin foil underwear”
A rather sensationalist statement. Having secure transport is a must. The next step is of course encrypting the data at rest as you say, but without transport encryption in the first place, you’ve got nothing.
Gav
p.s. “I have yet yo find one” “SSL is probably the most deployed, least useful security technology since tin foil underwear”
A rather sensationalist statement. Having secure transport is a must. The next step is of course encrypting the data at rest as you say, but without transport encryption in the first place, you’ve got nothing.
Gav
p.s. “I have yet yo find one” ”
@Mr. X
Without SSL we’d see many more of those types of attack. I’m not sure how you can argue otherwise on this point, but I await your reply.
Well for starters, why bother sniffing when you can just hack the server directly and gather the data that way, it’s far easier regardless of SSL or not. Also talk to the folks at Qualys and other similar companies and ask them what percentage of SSL servers still have SSLv2 enabled?
My point was really that people deploy SSL and think that they are secure so don’t look any deeper into their software or their architecture. So what you are left with is an insecure server with a 128bit security blanket.
@Gavin
Having secure transport is a must. The next step is of course encrypting the data at rest as you say, but without transport encryption in the first place, you’ve got nothing.
I don’t disagree. However SSL is not necessarily the correct mechanism for securing that data nor is transportation over the internet necessarily the correct first thing to worry about. It doesn’t matter if that data is secure if the repository isn’t. I’d much rather see a seriously hardened box and transporting data in the clear then vice-versa.
Our assessment of the risks to data is completely off kilter from the realities of what we face and use of things like SSL but not properly hardening hosts is a prime example of this.
“Well for starters, why bother sniffing when you can just hack the server directly and gather the data that way, it’s far easier regardless of SSL or not.”
Sorry to disagree again 🙂
Look at it from the perspective of the attacker. An attacker can either A) sit on a backbone somewhere snarfing thousands of transactions (which without SSL would provide a very high level of success in stealing credentials), or b) attempt to compromise each remote server. Economically, and in terms of the risk to the attacker, option A is far easier and much more attractive.
Encryption of data at rest is only ever a physical control. I cannot repeat that enough. On its own encryption doesn’t protect you from anything except the guy who would otherwise come into your server room and walk off with your disk. Even then it’s only a deterrent. Most encryption can be broken with time and processing power, so if the information was valuable enough, ‘the guy’ would still walk off with it.
You need good access controls, key management and user controls to make encryption worthwhile. Now that encryption is being built into things as a matter of course, I think we’re going to see a lot more problems of the nature you are talking of, it is a good reminder to everyone to be more vigilant. Maybe the commenters could stop their navel gazing for a moment and look at the bigger picture. I think this is a good article which makes some good points, and people here have chosen to pick holes without considering that you may be talking from experience.
(However a small point for the uninitiated reading this: when you say “PCI dropped the requirement…” you are just talking about SSL yes? Card numbers still most definitely need to be encrypted in transit, but I know you know this…)
Beware, the blogging community are picky b@*%@rds, no matter how relevant your idea.
Are CA1386 and SB1386 synonyms? Or related in what way, if any?
Citing the frequency of different types of attacks is a weird sort of circular argument. You see fewer traffic-sniffing attacks than host-breaching attacks precisely because SSL is easy to deploy and widely used.
If SSL were truly “security theater”, then dropping it wouldn’t make any difference to the actual attacks. That’s completely wrong — if traffic encryption were dropped (no HTTPS, no SMTP SSL, etc) I bet you’d see a huge increase in traffic-sniffing attacks.
Gene Spafford’s quote about the armored car is actually much more accurate than this post. 🙂 Encrypting traffic is not theater. It’s a real security step and an important one. It’s just that it’s what you might call “necessary but not sufficient”.
@Arthur
“However SSL is not necessarily the correct mechanism for securing that data nor is transportation over the internet necessarily the correct first thing to worry about.”
What do you think would be preferable to SSL/TLS for securing transport ?
I agree with what you are saying, as with anything in security, it’s a multi-faceted approach. I don’t think there is much point in discussing which is more important though, securing transport or resting point. Either way, both need to be done.
Or of course, alternate systems put in place, such as zero knowledge proofs, blind signatures, etc. .A decent privacy enhancing identity management system would be the ideal.
I was intending on commenting on encryption at rest, but it seems that ‘anonymous’ beat me to the punch. I would like to add that one way we attempted to communicate encryption at rest as a purely physical control was to discuss with them the idea of administrative trust. We asked them whether they trusted the data owner/custodian. If they said yes, we would reply “Great, now let’s move on to other controls”. If they said no, we said “Great, now let’s move on to other controls”. Yes, we told them that if you don’t trust them with your data, you trust them implicitly by allowing them to manage it. Encryption does not protect the information from these classes. Nor does it protect the information when access via normal data paths. A sound access control strategy was always our primary recommendation when groups were interested in “real” security and not a comfortable illusion. We managed to have success in our organization with this approach. Of course it wasn’t as crass-sounding as I’ve made it appear.
I think SSL is useful against passive attacks on wireless networks. It’s not as useful as it should be against active attacks, such as DNS spoofing or router spoofing, because clients are crap at certificate verification and users ignore certificate verification warnings. But I care about defending my users against the easy attacks, so I make them use SSL because it’s easy to deploy and it’s better than nothing.
I tell anyone who will listen (I may someday find such) that encryption is all about moving your problems around rather than eliminating them.
Encryption moves the confidentiality problem from protecting your data to protecting your key(s). If that’s an easier problem, then you win. If you act like you’ve made the problem go away, you lose.
PCI still requires encryption in several places.
Requirement 2.1.1 requires encryption on wireless networks, 2.3 requires encryption of administrative traffic (in other words, no telnet), 3.4 says to “render [data] unreadable” and lists hashing or crypto as ways to do so, and the preamble to requirement 3 says “Encryption is a critical component of cardholder data protection. If an intruder circumvents other network
security controls and gains access to encrypted data, without the proper cryptographic keys, the data is
unreadable and unusable to that person. Other effective methods of protecting stored data should be
considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not
storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails”.
Requirement 4 says to encrypt cardholder data during transmission, so PCI is requiring crypto on the wire (“Never send unencrypted PANs by e-mail”) and merely pushing for it at rest.
Interestingly, PCI DSS explicitly forbids the kind of product whose limits you noted, the kind that decrypts data with your normal login credentials. That’s in 3.4.1.
They dropped an actual requirement to encrypt data at rest only, near as I can tell, because of pushback from merchants with legacy systems that couldn’t be retrofitted to encrypt stored data. They don’t make it easy to wriggle out of encryption: Appendix B says “For companies unable to render cardholder data unreadable (for example, by encryption) due to technical
constraints or business limitations, compensating controls may be considered. Only companies that have
undertaken a risk analysis and have legitimate technological othe use of compensating controls to achieve compliance.
“.
Well for starters, why bother sniffing when you can just hack the server directly and gather the data that way, it’s far easier regardless of SSL or not.
I assume you’ve never been on a public LAN, then — like an open wireless access point or a college campus network. Sniffing data on these networks is far more trivial than hacking a server.
Of course, encryption-in-place doesn’t really help you that much if someone hacks the server, either. If the server is going to make use of the data, it has to have the means to decrypt it. That means a hacker has access to the encrypted data and the key. Not very secure.
@Legally Confused
“Are CA1386 and SB1386 synonyms? Or related in what way, if any?”
They are the same: California State Bill 1386. Note that other states have started enacting similar bills addressing disclosure of breaches of unencrypted non-public personal information. WA SSB 6043 (Washington Substitute Senate Bill 6043) is one I can think of off the top of my head, and I know there are others. I bet Chris Walsh would know.
I found a list, and there are a lot more than I thought:
http://www.enpointe.com/security/regulations.htm
Iang says to Mr. X … “Nobody expects the Spanish Inquisition!”
🙂
Seriously though, SSL did not remove mass MITM sniffing as an attack against Internet web-transactions. That attack did not exist in the first place, it was created out of the over-active imaginations of the crypto-$$$$-eyed people of the time.
It’s extremely easy to argue against your position: check the analogues. How much evidence is there of mass (MITM or otherwise) sniffing of open Internet traffic at coffee shops? … precious little hard evidence and lots and lots of hype.
What did exist in 1990-1994 was passive sniffing of passwords. SSL v1 killed that dead, from what I recall, as did SSH. SSL v2 “solved MITMs” but was itself knocked out by phishing, and MITM. Go figure!
I agree it is totally unfair to dump all this angst on SSL. It’s good crypto work. It’s just bad business, and bad for crypto community to keep selling the meat of a dead horse.
For those who think the argument is about SSL and whether to use it or not: It isn’t.
It is more like this: if you do SSL and don’t do the rest, you are wasting your time. Even if you do SSL and only some of the rest, you may still be out of balance. Unless you have an opinion on the rest, your opinion on SSL is therefore worthless.
All security is a balance — there is only any point in doing SSL if it actually decreases your risks overall, for low costs. For that to happen, you have to show that the benefit of sniffing is better than the benefit of attacking elsewhere. That’s actually harder than it sounds, because e.g., hacking benefit acquires pre-qualified data whereas sniffing means you have to process the data yourself.
The debate intends to examine this question: security people insist that we must use SSL … because? This is like telling people that they must wear body armour when commuting … because? This makes good sense in some times and places — Iraq today, Washington DC around 2002 — but not as a general rule. Not Washington today, and not Iraq 10 years ago.