Slashdot Mirror
How To, When You Have To Encrypt Absolutely Everything?
Dark Neuron writes "My institution has thousands of computers, and is looking at starting an IT policy to encrypt everything, all hard drives, including desktops, laptops, external hard drives, USB flash drives, etc. I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives, but I am concerned about overhead and speed penalties. Does anyone have experience and/or advice with encrypting every single device in a similar situation?"
I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives ...
I think you're going to find most people advising you to choose TrueCrypt which boasts:
I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking the various encryption algorithms it offers.
... but i am concerned about overhead and speed penalties.
Aren't we all. I mean, no one wants an Office Space like scenario where every day before you leave you have to wait for the damn little bar to cross the screen to save your progress for the day. You have another option which is to wait until the drive manufacturers build all that into the hardware's firmware so that it is as fast as they can make it.
... I also would feel very uneasy if someone assured me they had a method to do that. Drive encryption is one of those seemingly trivial but necessary reasons why companies have many system administrators and not some automagical solution.
I wouldn't recommend waiting that long, however.
Here's my formal suggestion: do a small test on a few users or even a few devices no one depends on, some USB drives, etc. Use them yourself and see what kind of overhead (for both user and device) we're talking about here. Then weigh that with how much comfort you get with universally encrypting everything. If A is greater than B (with a sinister sounding name like 'Dark Neuron' who knows?), draft up a plan. Otherwise, just wait until you have the funds to upgrade the hard drives to those with the built in encryption.
I do not know for certain but I do not believe there is a painless push-across-the-network way to do this
My work here is dung.
Let me explain to you how this works. In pictures:
http://xkcd.com/538/
Tired of Political Trolls? Opt Out!
Don't do it.
A subtle balance between encrypting most essentials and leaving non-essentials unencrypted. For example, you may want to only encrypt parts of your hard disk as encrypting the whole disk will impact performance.
Also, watch how external USB keys are encrypted. if you deal with clients and offer loaner machines, their USB drives could become encrypted and useless when they return to their own office.
I'm all for encrypting, however hopefully the higher ups also consider the potential performance hits and liability issues.
"Security" that gets in people's way is a security threat, because people will find a way to work around it, and be worse off because of it. Never try to lock down everything, or you'll have no control over what is compromised. Figure out what you really need to secure, and lock that down. Really. Trying to secure everything is a sure sign that someone lacks the knowledge to make security decisions.
What's your key management strategy?
You want TrueCrypt.
It's probably better than a hardware solution. They keep screwing up and snake-oiling the hardware ones, but you can audit TrueCrypt (and people have), and pre-boot authenticated system drive encryption is pretty much what you want.
As for speed... I don't know what you're worried about. AES-256-XTS (best-in-breed, the new standard, which TrueCrypt pioneered and uses) runs at over 150MB/sec in benchmark, and that's on one core. Your hard disk very probably doesn't run that fast.
All our machines are encrypted using similar means, and we've never experienced any problems with performance.
PGP's Whole Disk Encryption isn't as good - that kept stalling in kernel mode under XP, causing hiccups on lots of disk accesses; and eventually the driver bluescreened on every boot and there was absolutely no way we could get it back, which lost us terabytes of data... but TrueCrypt has caused us no such problems, and costs nothing. (If it worked with the leftover eTokens from our earlier PGP deployment, it'd be perfect.)
TrueCrypt does not support Pre-boot full disk encryption on the Mac. Only product I know of that does that right now is PGP Whole disk (latest version).
I see this all the time and it always makes me cringe.
If you treat all data the same, it is impossible to convince users to treat any data differently from any other, and they will all default to "Sloppy", and you won't care because you'll be certain that the encryption is going to save your ass.
It is a much much better idea to have a very distinct line between secure and insecure, so that people have that distinction hammered into their heads every time they touch secure data. Otherwise, someone is going to get sloppy with their private key, and you're going to get exploited and never see it coming.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
That comic has been making the rounds. It's cute, but not applicable.
If the submitter is in an organization with thousands of machines, the notion that any user will be required to keep their password confidential in the face of torture is laughable. That's for specially trained operatives, soldiers, and other assorted heroes. Those of us in the normal world will probably adopt a more rationale perspective. If someone were crazy enough to steal one of our laptops, simultaneously snatch the user, and threaten them with torture, our folks know to give up all passwords, immediately. We're only required to keep data confidential where it is reasonable to do so. When floods sweep away your car, wave goodbye to your laptop in the trunk. When someone threatens you physically, tell 'em what they want to hear.
Our people are more important than our data. Our people are more important than the publics data. If we lose a chunk of data, we have ways to reconstruct what was lost and mitigate damage. If we lose an employee, there is no way to achieve a good outcome.
Reasonable?
Tell the suits you are implementing state-of-the art ROT-26 encryption on everything. Take a month off. Come back, pronounce it complete, and ask for a raise.
SpyDock: Scientific Python in a Docker container
An elaborate system of Post It Notes (All ROT13'd)
Maybe its just the corporate environment that I'm in and please I would love to be wrong. But from what I can tell a good number of open sourced products just don't scale up to the enterprise level.
There aren't any tools that manage them centrally and allow for compliance and auditing.
Crap. Has anyone told Google yet? Best get them to switch to Windows quickly!
Plase back everything up frist! Send it to us at editor@wikileaks.org and we'll store that data for you for free. We have mirror sites to protect the data; just send it before encrypting it.
I see this directive a lot. It boils down to "We don't know where our sensitive data is, or don't trust our employees to keep it where it should be, so we're encrypting everything!".
Most of the time when I see this, it's because the person making the directive is responsible for security in some manner but has no experience with risk management and mitigation, so they go for the "all out, definitely safe!" shotgun solution. The problem is there's no such thing!
What risks are you actually attempting to mitigate through encrypting everything, and are you aware of the risks you are creating? These are questions the person who made the directive should be able to answer! For instance, if you are trying to mitigate the "PII/Lost Laptop" risk, why not implement drive encryption on laptops only, and buy USB sticks (such as Ironkey) which guarantee the encryption? If you're trying to stop a malicious insider, no amount of encryption will save you if they've been given the key.
Finally as others suggested, what's your key management and password management strategy? I -love- truecrypt but I wouldn't suggest it for a whole enterprise without being able to answer the question "How do I recover the key to this workstation when the employee dies unexpectedly of a heart attack?".
Best of luck in your endeavor but remember this rule: When it comes to implementing security, NEVER BE AFRAID TO ASK MORE QUESTIONS - especially about requirements.
Truecrypt is fast. I have it on all my computers and backup devices that handle sensitive information, and there is zero slowdown visible to the user, even for IO-intensive operations. Steve Gibson from the "security now" podcast did his own benchmark where he created a drive image and timed how long it took to defrag the drive, then restored the bits from the image, encrypted with TC, then timed the defrag again. He then repeated the process three times because he didnt believe the results -- the encrypted filesystem ran FASTER. Take the anecdote for what it is, but the principle seems to hold true in my experience too. TrueCrypt is damn fast. It chews a few % of your CPU time when in use, but it doesnt slow things down.
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea...."
RFC 1925
Hard drive encryption isn't meant to protect against social engineering attacks. It's meant to protect against attacks that don't require social engineering, like stealing or cloning a database server's drives for the information. More than anything, it's meant to provide reasonable assurance that if one of your employees' computers gets stolen by a common thief who just wants to sell it for the cash value, somebody else down the line won't be able to read the data in the drive and take advantage of it.
Are you adequate?
Given how glacially slow IT moves in a university -- and how much buy-in the prima donnas demand for even the slightest decisions -- I'm sure the password topic is still brought up at the weekly meeting.
Security only works if the convenience/security ratio is balanced properly for the environment at hand. At a public university which is used to openness, the "encrypt everything" just wouldn't fly (because that one tenured prof who likes to share and then remote mount his entire C: drive between his office and home over an unencrypted network connection would pitch a fit and kill that plan by fiat). If you work at a security company or bank or the NSA, then I'd suspect you'd have an easier time of it.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
My company has been running all the machines that aren't at our data center encrypted, starting around August of 2007. On my laptop I honestly just have not noticed the overhead of encryption more than once or twice in that time. When I started it was on a 1.8GHz Pentium M box, so it's even less of a concern with my 2.5GHz Core 2 Duo.
As I said, it's worked out so well that it's now the standard setup on our laptops. The Eee's my wife and I got last week are running encrypted partitions as well.
Before I started, I was worried about the overhead of the encryption, but I was really worried for no reason. I've almost never noticed it, and none of the other folks in my organization complain about it either.
We are using the Linux encryption stuff running under LVM, so our swap is encrypted as well. Everything but /boot is encrypted. We are using "cryptsetup" (dm_crypt) (built into the Ubuntu Hardy and up "alt" installer and Fedora 10 and up). I'd recommend that for the Linux side.
I've heard good things about TruCrypt, but haven't used it. We don't use Windows or Mac, so the stuff that's built into Linux is our preference.
The dm_crypt stuff includes "LUKS", which allows you to have multiple keys for accessing the data. So you'd probably want to set up a "user key" and "company key" for each system, and if the user forgets their key someone can check out the company key and set a new user key.
So, in that way you don't need to worry about the user forgetting their password.
Also, you still need to have good backups of the file-systems, so if someone does forget their data you can at worst case recover from the most recent backup.
So the worry of losing keys is a no-op. If you don't have good backups, check out backuppc. I've been very impressed with it.
Finally, as far as the other poster saying that it's a "shotgun" approach for people who are too lazy to identify their important data... Do you also try to back up only your most important data? What if someone adds a new important data?
I started with only encrypting a part of the system (because full system encryption was difficult to achieve in older Linux releases). The problem is with leakage. As with backups, it's more provably correct to cover more data rather than less.
This is why for backups I only do exclusions instead of listing the data I want to back up. That way if more data gets added, I have to explicitly exclude it for it not to be backed up.
The same thing applies to crypto. Ok, so you encrypt your sensitive data. Do you have updatedb running? Or beagle? If someone looks at the "locate" database of all the files on your system, will that expose something you didn't want exposed? Like the list of your clients? It would for ours, because our document repository has useful file-names. Similar for the beagle database.
What are you leaking that you didn't intend to be?
Just encrypt the whole damn thing.
Sean
What are you trying to protect?
From what? What attacks? What value does it have to the attacker? What value does the secret hold to you? Who are the attackers?
For example if the value of the secret is low to you, then spending money on protecting it is a waste. Encryption costs to buy, costs to run, costs to manage keys, costs in convenience. eg. (Most secrets aren't worth a trip across town because you forgot your keys once)
If the attackers are internal, (they usually are), then encryption buys you nothing.
If the value of the secret is large and the attackers have physical access, then encryption is the strongest link in a very weak chain.
If many people have access to the secret, then social engineering will weasel it out no matter what your encryption.
If the attackers are evil and powerful, then encryption is a red flag to very Bad Bulls. You better off with more primitive methods that require real humans to eye ball it.
Get these questions lined up and answered before you start.
My company has been encrypting everything for some time. We have used Truecrypt with no issues for around 1.5 years I believe. Our linux machines are all encrypted. It's easy to implement with Fedora 9+ and Ubuntu 8.10 alternate installer as Anaconda handles it for you. I also have several encrypted RAID arrays. If you want pm me for a write up on it. I don't want my site getting slashdotted ;) . I'll be happy to give you my how-tos'
Just remember, nothing is 100% secure. Document everything.
As far as performance is concerned. We have noticed no significant impact from disk encryption. Let all the naysayers whine and say I'm full of it. TOP reports that our encryption from cryptsetup consumes about 5% of our procs on our older IBM celerons 2ghz, that's while writing to an array. The array (mdadm) consumes about another 5 %. It consumes around the same on a single core of our new machines. Our new machines, i.e. Core2Duo 2.2's, Xeon Quads 2.13's and an AMD dual core 2.2 you don't even notice it.
Frankly it's so easy to encrypt a system drive these days I am of the mind you are foolish not to do so.
The only downside I have come across with system encryption is that I can't do remote reboots. There is a way around it I've read but it's not really an issue for us. Message me if you want, or can. I never have pm'd anyone here before.