> 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
