Dear Patrick, This is really a beautiful rant. You should publish it somewhere.
On Apr 23, 2009, at 10:00 AM, Patrick Cahalan wrote: >> But your proposed 95% solution of "not storing sensitive data in >> the first place" isn't a workable one for most organizations. Yes, >> they >> shouldn't store the whole CCN and CCV2. But how about customer >> names? Or >> email messages? Or Microsoft SQL Server databases of customers? > > There's sensitive data, and there's sensitive data. Still, I'll take > being called out for "exaggerating for effect" in good grace. > > It's probably more like 65%. Of the remaining 35%, when it comes to > protecting it, you're doing it wrong. > >> Also, in many organizations, it is simply not possible to keep >> track of >> which hard drives have been exposed to confidential information and >> which have not. > > This I'll disagree with; or more to the point, I agree this is true, > but this is not a problem that FDE can "solve", and it *is* a critical > problem that needs to be tackled in most organizations, right now. In > fact, from an organizational security standpoint, introducing FDE can > make this problem worse: "Oh, I can carry the customer database home > on my laptop because it's encrypted." > > No, you can't take the customer database home because you don't > actually need it. You find it convenient. You don't like the VPN > setup. You don't like to have to plan ahead. You're on a deadline. > Whatever the reason is (and many of them have legitimate > organizational value), the right answer is, "If you need access to > this information that badly, stay late. If you don't like to stay > late, fix your project management so that you can meet your deadlines. > If the SEC audits us and finds out that I let you take that home, > I'll get fired." Enabling this sort of thing should be the very rare > exception, not the rule. Make any executive who wants to do this > justify it by making a business case for it, and make them sign a > policy on the dotted line. If they lose the data, there needs to be > consequences. If you can't enforce this, you've got problems. > > While it's certainly true that people in an organization will email > sensitive documents around (leaving them all over a bunch of different > desktops) and it's also true you can mitigate this by encrypting the > drives... encrypting the desktop drives introduces a bunch of other > issues. Who has the boot password? The employee, or the helpdesk? > Do you reset them when a helpdesk person leaves? The employee? Do > you really reset them? No, really? If you go to that trouble, why > can't you just blast the drive, or yank the drive and shred it, which > (from an organizational standpoint) is probably at least as easy if > not easier? If a box crashes due to hardware failure on the > motherboard at EOL, am I *really* going to replace the motherboard > just so I can boot the box and zero the drive? Or am I just going to > chuck the thing in the trash? Wouldn't it make much more sense to > have a trash can sitting in your hardware closet just for hard drives, > and when it's half-full take it down to the e-disposer and shred it? > > If you're worried about your email store, forget about encrypting your > desktops (or your exchange server or IMAP server, for that matter)... > are you doing any sort of auditing on your outgoing mail? If I allow > people to email "sensitive data".doc files, what's to stop them from > emailing those docs to your competitor's gmail account? Can you even > catch that? > > Your employees surf the web, their machines get hacked, and all the > juicy data on those machines gets delightedly nabbed by actual > criminals, while the box is running and the disk is unencrypted. > Maybe preventing employees from having access to that data in the > first place is where you should be starting your attack on this > problem. > > What if you have high turnover? In the helpdesk? If the employee has > the password, how does the helpdesk fix the box if the employee isn't > around? Do they *both* have a password? What's your password policy? > How do you enforce it? You can no longer boot desktops remotely, > unless you have KVM over IP, or serial console, or some other method > which enables you to enter the password without sitting at the desk. > How do you enable that? What effect does it have on your network > security policy? What if you have 9 different locations with three > employees each... and one guy in a truck who is your entire helpdesk > staff, and the remote boot capability is broken in two places at once? > When a critical update needs to be applied because a worm is in the > wild? If someone loses or forgets their boot password and they're in > China, how do you get it to them? Do you just let them call to get > it? That means the helpdesk has a list of cleartext passwords for > every bootable device (oy). How do you protect that list? How do you > prevent social engineering in a large organization? If I can call a > phone number and get a password over the phone without any sort of > real authentication, you've got a truck sized hole in your security > policy. You can't revoke an FDE password remotely, what if an > employee walks off with a bunch of your encrypted drives? > >> But in every case that I've bought a server, the hard drive wasn't >> wiped, and the data wasn't encrypted, and I was able to recover >> stuff. FDE would make it much easier to do an instant wipe in >> those cases. > > I'll bet you dollars to donuts that *if* encrypted drives were the > norm (as opposed to the exception), *and* every organization in the > world used them, you would *still* be able to get piles and piles and > piles of used drives that you could crack open in relatively short > order since the passwords would be trivial. People wouldn't bother to > do the instant wipe, for the same reasons that they don't bother to do > wipes on drives now... because they're lazy and their security policy > is garbage. > > Look, I'm not trying to badmouth full disk encryption. It has a > valuable place in any organization's overall security policy. But far > too often FDE is regarded as a patch to cover up some other problem, > and introducing it organization-wide will just open up so many other > issues that it will wind up being worked around almost immediately. > You've just spent a ton of money on hard drives and motherboards to > mask a bunch of symptoms when your real problem is that you've > marginalized your IT security folks to the point where everybody in > the org just ignores them entirely and doesn't give too cents about > security. > > You can't do that anymore, or more to the point you can still get away > with it today, but the situation isn't getting any better, and sooner > or later (10 years, tops) you're going to see real civil and criminal > penalties for letting this data get loose. SB 1386 and SOX aren't the > end of this sort of regulation, they're the beginning. > _______________________________________________ > FDE mailing list > FDE@www.xml-dev.com > http://www.xml-dev.com/mailman/listinfo/fde > _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde
