Resisting the PGP Whole Disk Encryption Craze 480
alaederach writes "I run a lab in a non-profit academic life sciences research institute. Our IT recently decided it would be a good idea to use PGP whole disk encryption on all of our computers, laptops and servers and picked PGP's suite of software. The main reason is that a small subset of our researchers work with patient information which we obviously are mandated to keep confidential. My lab does a lot of high-performance computational work (on genes from Tetrahymena, no humans here) and I am concerned that the overhead of complying with our ITs new security policy will be quite detrimental to my research program. For example, dynamically reallocating a partition on a PGP encrypted disk is apparently not possible. Furthermore, there is some evidence that certain forms of compression are also incompatible with PGP whole disk encryption. Interestingly, it is hard to find any negative articles on PGP, probably because most of them are written by IT pros who are only focused on the security, and not usability. I therefore ask the Slashdot community, what are the disadvantages of PGP in terms of performance, Linux, and high-performance computational research?"
Here's a quick experiment (Score:5, Informative)
what are the disadvantages of PGP in terms of high-performance computational research?
O(1) ;)
Here's a brief experiment I ran: dd if=/dev/zero of=/home/jonas/zeroes bs=1048576 count=1024; that is, writing one gig of zeroes to a disk encrypted with ubuntu's disk encryption from the 8.04 alternative installer.
I saw a roughly constant ~30% CPU usage from kcryptd, going from 25% to 35%, on a 2.13GHz Pentium M (in a thinkpad t43p). So I have 1.5 GHz worth of cycles left.
Hard disk write speed was about 30 megs per second, but oscillating in big leaps. I did my observations with conky, sampling in one-second intervals, but conky is known to sometimes merge two samples. That's probably not the only factor, disk writes are most efficient when clumped together into one big (much preferably sequential) write, so I'd assume the kernel does this.
You haven't told us what your disk usage patterns are. But if you're doing one big read, one big computation, and then one big write, there's going to be zero impact (almost): there was lots of CPU capacity left.
Another low impact scenario is that you have a server that reads work units from disk, hand them to clients, gets results and writes the results back [I assume clients don't need any disk activity]. There you can read a bunch of work units in advance while the server is idle, then hand them out instantaneously when needed.
Aside: bugger, fault in my experiment: I didn't look at the CPU usage of kernel code that's not in the process table. Take what I say with a grain of salt.
But: do the measurement in your own world. My software, hardware and artificial measured usage pattern may differ from yours, subtly but enough that my conclusion doesn't transfer. Be scientific about it :)
Re:Isolate sensitive data (Score:5, Informative)
You really want blanket encryption because you to worry about such things as swap space, scratch copies made and then deleted and people forgetting to encrypt files. /boot encrypted during install.
If the encryption is done at the block device level (such as dmcrypt on linux) the impact is minimal on how things work and overhead and you are fairly well protected (unless the machine is accessed while powered up by someone wants the data as opposed to just the machine).
Fedora can make all partitions except
Re:Encryption is good for security, bad for perfor (Score:5, Informative)
Sorry, they "claim" that.
But on my core 2 2.4 Ghz machine, windows boottime more than doubled after encoding the system partition.
Yeah, i can get 100Mbyte/s linear reads and writes.
But for some reason, random or semi random access get hosed quite a bit.
Maybe it messes with the comand queueing, or the internal prefetch alorithmns, i dont know. Never had a problem on data partitions, but the performance impact on the system drive was enourmous (up to the point that even with 6Gbyte RAM, it wasnt fun anymore)
Ah, and i forgot one thing: the 100Mbyte/s is nearly 100% cpu load on both cores. I dont know where you get 1% overhead from... Even the in-memory benchmark only gets about 150Mbyte under full load on two cores.
S
apply security if you really need it! (Score:5, Informative)
Positive:
- added security
Negative:
- worse performance
- you may forget the password (it has happened before.)
- has to be mounted manually (or at least type in password each time you need access to the data.)
- it's painful to backup
- it's painful to do a proper file systems check
- if the discs are somehow taken by the authorities you might have to give up your password (or be sentenced for whatever they think you have on the discs.)
- discs are only secure if they are not mounted.
There are a few negative sides, but usually they make up for the positive, i.e. if you really need the security then of course this is the way to go. Also remember to secure the other aspects of the machine, like physical access (including fire/theft), software protection (anti malware and virus) and network protection (firewalls, etc.)
Bothered about Windows 95 compatability? (Score:2, Informative)
You cited an extremely brief review about a 1.0 product on Windows 95 as evidence that 'there might be problems resizing a partition'?
Whole disk encryption or an encrypted volume should be mandatory for your confidential data on a laptop. For windows, use PGP, it's fine, or use truecrypt, which is fine also.
For linux, use a dm-crypt volume or (again) truecrypt if you care about moving your data to windows - you'll be within the spirit of the security policy and won't notice the difference.
You're wasting your time, however, putting disk encryption on a server thats in a locked computer room or data centre - no one will be around to decrypt the volume after a reboot or crash, or you'll sticky tape the passphrase to the machine, so if it's stolen you are still hosed.
Don't leave servers in public areas though!
Truecrypt does that and is better (Score:5, Informative)
Re:Encryption is good for security, bad for perfor (Score:5, Informative)
The numbers on my machine are about 20% slower read and 30% slower write. I'm using 256 bit LUKS with serpent-xts-essiv:sha256.
Might I also suggest hardware encryption? Seagate (and others I believe) make drives that do AES128 (good enouhg for this sort of thing I believe) in hardware. Zero performance hit. No software required. Set a drive password and go.
Re:Isolate sensitive data (Score:5, Informative)
I second that.
If you're looking for an excuse not to protect the data, that's one thing. But TrueCrypt has lots of support and does a good job. PGP in general is well-known and has been refined frequently. That's the reason you don't find a lot of negative criticism-- there isn't any because it works fairly seemlessly. You'll find hard disk controllers don't help the process much, but if the machine does work in batches, and you backup frequently (presuming you're backing up an encrypted partition) and you use a UPS (or your controller supports battery-backed write cache), you can use various write cacheing driver options and techniques to boost performance dramatically. What write cacheing *can* do is to also cause transactional integrity problems if there's a machine hickup. Otherwise, writes are queued up and get batched onto disk. Performance can be 10x, so long as you understand the potential evils involved. It takes the sting out of the disk I/O degradation, but how much will vary with the duty cycles of your application's I/O profile.
Put things into perspective (Score:2, Informative)
Current optimized kernel versions of AES manage about 50mb to 60 mb/s on a 3ghz cpu. This _maxes out_ the core on which the IO thread is running on. This is not a linux-specific quirk, but just plain mathematics. AES is fairly expensive, and neither blowfish nor twofish are faster by any meaningul value. If you're not blessed with a multicore CPU, full disk encryption will most certainly crawl your whole system down when you do anything disk-serious; and even with multicores, your system will be sluggish in the worst of times when you do heavy IO (think: the keyboard irq handler not caaaaaaaaattccchhhhing up.)
You can have yourselves one of those PCI encryption addon cards (Soekris sells some), but their bandwidth is very limited as well (155mbps, last time I checked).
Consider carefully if you want privacy, or easy throughput. You can't have both right now.
Re:Encryption is good for security, bad for perfor (Score:5, Informative)
That is interesting - if the overhead was really 1%, then why even bother with optimizations for multi cores?
The other thing I cannot understand is why anyone would want to run whole-disk encryption on a compute server. Even the US DoD machines that are used for classified research do not do this!
Re:Encryption is good for security, bad for perfor (Score:4, Informative)
Presumably, he meant that encryption done on the disk itself is transparent to the rest of the computer. What you see is a comparatively slow hard drive, not the existing resources (ie, CPU) being eaten up by the encryption job and low disk throughput. Same all other dedicated controllers: you're offloading processing to a dedicated chip, so, for the purpose of generic programs on the CPU, you can assume there's no performance hit.
Re:Encryption is good for security, bad for perfor (Score:4, Informative)
It may incur overhead but it need not. Consider that you don't need "instant" encryption, you simply need a device inside the hard drive between the computer interface and the actual storage medium that is capable of encrypting and decrypting at or above the drive's maximum throughput speed. This need not be "instant", it merely need be fast enough block-by-block to pass the data along. Consider that hard disks store data in blocks, not streams.
Random Experiences with disk encryption (Score:5, Informative)
My workplace recently mandated that all laptops/portable media be encrypted. The impact to the system cpu usage isn't that significant to be honest, except when attempting to access, say, USB drives.
What's more important is the reliability of the disk itself.
As everyone knows, drivers shipped with laptops tend to be the first casualties of boot-sector-loading programs, like disk encryption and certain virus scanners.
Guess what happens when your encrypted disk can't be booted? You can't boot under a windows/emergency restore disk, because your partition is not readable. You can't boot off anything other than the hard drive. Guess what happens if the corruption doesn't allow you to run the encryption app's boot loader? Only solution is to format the disk.
Some of us who have been hit by this already have gone through the trouble of ensuring that any data we want to keep is stored on a shared drive, and that all work is done in a VM, which is occasionally uploaded to the shared drive as well. Since any given windows or driver-affecting update could kill our machine at any minute and make it entirely unrestorable, that's what's required.
So in essence, we're switching back to storing the media on a non-encrypted device because the loss of the data is more important than the security of the data.
This reminds me of the policies surrounding passwords I've seen at many companies; limiting the set of choices by making password creation requirements, and forcing them to change so often that people end up writing them down and leaving them on their desk. Defeats much of the purpose of having them in the first place.
Re:Isolate sensitive data (Score:2, Informative)
Surely what is required is to isolate the sensitive information, so that it can be protected.
Blanket encryption may impress some people, but it hardly solves the problem.
From what I've heard on slashdot, whole disk encryption solves the following problems:
1. No risk of protected data being stored unprotected in, for example, page files or temp files.
2. No risk of users unknowingly saving data outside of protected areas.
3. No risk of applications storing data outside of protected areas by default (e.g. saved login credentials, data to 'work offline' from network servers).
Of course, this sort of protection is more common for laptops than for workstations, and in the specific case being discussed it would only be sensible for the local IT people to set up the high performance computing researchers with an unencrypted disk or partition to store their data on.
Re:Truecrypt does that and is better (Score:2, Informative)
Re:Incompatible? (Score:3, Informative)
Well it's true that encrypted data can't be compressed. That's why you encrypt the compressed data.
Re:From experience (Score:1, Informative)
How could it possibly be in Microsoft's interest to allow or facilitate the resizing of partitions?
Err... I guess you're not aware that Vista has a built-in partition resizing tool. I used recently it on a new Dell 530 to shrink the Vista partition from 500Gb to 50Gb before installing Ubuntu** and it worked just fine.
** Yes, I'm aware that I could have bought a 530n with Ubuntu pre-installed, but at that time the particular discounts available meant that I got a better spec machine with Vista than I would have for the same price with Ubuntu.
Re:Policy fundamentalism (Score:4, Informative)
Re:Overhead (Score:3, Informative)
Truecrypt Whole Disk Encryption has less than 1% over head. I can't see the problem. Surely the patent and IP information security outweighs this minimal overhead.
That's what we got told when our laptops were "whole disk encrypted" with a competing product.... but it now means that a windows hibernate and restore take of the order of several minutes(!) rather than 10s of seconds.**
I have not experienced PGP so maybe it has a much more efficient system, but I have my doubts.
**Yes I know that MS make it impossible for these systems (apart from their own 8-|) to guarantee security of the hibernate file but I can't see how that would affect the performance.
Re:Policy fundamentalism (Score:5, Informative)
I'm with Smertrios on this one.. IT policy is just that.. a corporate policy. It's not subject to end-user interpretation, it's a definition of how IT resources are to be deployed and utilized. The written policy itself is what gives the company the "teeth" to discipline employees who choose to make their own interpretations and NOT comply.
Now back on topic: Whole disk encryption? For removable / transportable media, ABSOLUTELY! For enterprise data backups, ABSOLUTLEY! For live data on active servers, meh.. not as critical. If your data center employs appropriate physical, network and host security, your data is reasonably safe. If someone compromises your network -> system security, they've got your data.. encrypted or not. It's wonderful that your IT department has the desire to achieve the highest level of security possible, but there is always a balance that needs to be struck between the holy grail of ultimate security and the ability to do business. The OP needs to help everyone find that balance. A good place to start would be his local neighborhood HIPAA expert to make sure that no "business needs" prevent the company from maintaining regulatory compliance. Once the specific requirements for his continues compliance have been identified, then anything beyond that becomes somewhat negotiable.
No that's not a problem (Score:5, Informative)
Read the FAQ [truecrypt.org]; drives usually have larger block sizes than the block size used for encryption, so there is not much difference.
Re:feel-good actions (Score:3, Informative)
I suspect that what he's talking about is the "Cold-Boot" attack, where a running computer is switched off (or maybe using the HW-reset switch) a very short time and then rebooted from a USB stick which dumps all memory to disk where you can still read everything. The memory dump is then analyzed to find encryption keys.
The only disk encryption software I have experience of (Check Point Full Disk Encryption (previously Pointsec for PC)) includes protection against that attack. I expect truecrypt and PGP does too though.
No difference between encrypted and unencrypted (Score:2, Informative)
The drive is encrypted by a symmetric block cipher, which means you have blocks of data (typically 128 bits). So, unless you can recover to that resolution, losing the data within that cipher block means you lose that size of chunk of data. Depending on the type of file, you may lose important header information and end up losing that file, but that's no different than in an unencrypted file system.
The only thing you need to be careful of is backup of the volume header. If that isn't backed up and somehow gets corrupted, or it can't be restored, then you'll lose your information. From a pure probability perspective, this is pretty remote.
Re:People misunderstanding the question... (Score:5, Informative)
I can tell you that when we ran a PGP encrypted disk partition on a 12 disk raid 50 I had MAJOR performance losses compared to a standard raid 50. This was on older hardware, I had tested it on a 8 processor Xeon PIII 800 system with only 4 gig of ram installed, but it had a significant impact on data transfer rate.
and yes I like re-purposing the Killer SQL servers of yester-year into a "Holy CRAP THAT's YOUR NAS??!??!"
The hit was NOT on the drives, it was on the processors. It was enough of a hit to slow down data transfer rate out the GB connection to be as slow as a consumer single disk NAS.
Re:Overhead (Score:5, Informative)
The patient information is a pretty serious concern. Any breach or loss of data covered under HIPAA, SOX, FERPA, or Privacy Act can result in some pretty severe expenses. The cost of notification to the individuals whose data was lost or exposed can run to more than $1,500 per individual, depending on the size of the breach. Base expenses start at $1-2M and go up fast. Litigation and fines can cost millions more. Anything that gets hacked or breached, that has information that should be protected, could put a company these days on the wrong side of the balance sheet.
HPC and encryption (Score:2, Informative)
I've never heard of any HPC computer using disk encryption. Though compute intensive work need not be I/O intensive, it might very well be. If there is a real need to keep your data secure in your HPC environment, other measures that encryption are just as effective.
Frankly, encrypting everything is just not the best solution. Especially since encryption doesn't prevent legitimate users of making copies on non-encrypted media and loosing those. I guess your IT staff just found a cool new toy, but well, I don't see any traces of procedures to help safeguard the data.
My word of advice: get a security-officer to define proper procedures for data classification and data handling, really, all you need is procedure and well then maybe, pgp whole disk will play part in implementing a proper data handling procedure for data classified as C=extremely high.
Re:5 reasons (Score:2, Informative)
I agree - it seems to me like:
1. data in the data centre should not be encrypted (assuming your data centres are physically secure)
2. everything outside the data centre should be encrypted
An exception to this might be where a 3rd party is managing your data centre (e.g. traditional outsouring or the cloud)
As you say, products like VMware ACE and Sun Ray help to keep sensitive business data unencrypted in the data centre where it is physically secure, or encrypted when it is 'out and about'.
Here's a disadvantage: recovery (Score:3, Informative)
If there is one HUGE problem with whole disk encryption it is recovery from disk failure. I'm not talking about your average Windows crash, PGP whole disk crypto is OK with that. I'm talking about a more massive failure which makes a mess of the NTFS indexing (Windows can do that too).
Normally, you have three options:
- restart and pretend you don't have a problem. Rather hard if you're missing a lot of files :-).
- permit CHKDSK to clean up the disk. In my experience that is a sure way to guarantee you will never be able to access your files in a sensible state ever again. No idea why, but Microsoft doesn't appear to have focused on file recovery with CHKDSK, more on returning the disk to a consistent state. Or maybe I need to do some RTFM :-)
- use another tool to access the disk which doesn't need a 100% clean NTFS layout to still scrape the files off. This can be typically done with a Linux live CD as the read-only NTFS mount of Linux is substantially less picky about how consistent the file system is. I introduced this idea to a large consultancy when I worked there and they have saved a good amount of data this way over the years.
When you use full disk crypto, forget about booting up another OS to recover data. Installing full disk crypto without adding a good backup solution (encrypted, of course) is asking for trouble.
What I like about PGP is the ability to use additional keys which are split, so you need to involve multiple people before you can backdoor it. However, it always makes me wonder if there isn't an additional key of which we don't know anything..
overhead for patient research? (Score:2, Informative)
The overhead for this technology is during retrieving and storing data to the hard disk.
Unless you're running a database server on your personal machine the overhead is negligible.
Unfortunately it's not the security panacea they might think it is. The only thing it protects
you from is public disclosure of data from lost or stolen machines. If the machines are in
a protected access environment and aren't removed is probably a waste of time. It might
make good "security theatre" though. (it will make some people feel better even if it's worthless)
Re:Disk Encryption (Score:4, Informative)
Performance is not the problem. Compared to other problems, this one is insignificant. It gets even more insignificant with multi core CPUs.
I'm sorry, but this is just wrong. Encryption, with a sufficiently fast CPU, will not affect your throughput. It will, however, affect your latency. I know, from the results of part of my PhD, that in an I/O bound scientific computation process, a 0.5% decrease in average latency can give around a 20% better running time. If decrypting a block takes 1ms, added to the 9ms for seeking, then you can easily be slowing down the kind of task that the original poster is talking about by 50% or more.
Most users won't notice encryption because most users don't do much that's I/O limited, and when they do it's often limited by throughput, not latency. Try running full-disk encryption on your database server, or on a scientific computing machine, and you will see serious performance problems.
Here's the results of a test on Truecrypt overhead (Score:2, Informative)
Transcript:
http://www.grc.com/sn/sn-133.htm [grc.com]
Re:People misunderstanding the question... (Score:5, Informative)
I think the strategy should be to perform some speed comparison tests, to see if your research can be done with full disk crypto. Setup some vmware or other virtual machines.. and your test physical server.. Plug in a spare Hard drive, install a fresh OS, do testing of some virtual machines _with_ and without full disk encryption (on both host and on the VM), and tell them that the full disk encryption is slow if it is: reduces the effectiveness of disk cache, wastes memory, bogs down the CPU of machines that are needing to be used 100%, and better hardware is needed to run full disk encryption.
You're in research, and such a major change to your environment deserves to be looked at a little before you implement it...
I suspect with full disk crypto on your hardware backing the virtual disk, VM I/O performance will tank.
Show them nice graphs of research computing productivity on the same equipment WITHOUT full disk decryption, and WITH it.
Use "full disk encryption" policy as immediate justification for additional better hardware to compensate for the fact that the encryption is parasitic.
And note the migration costs and loss of research time that results in having to make such drastic changes.
Once you show the extra cost involved, they perhaps rethink the full-disk encryption blanket policy.
Just make sure the cost you show is high... (much higher than any imagined savings through simplified policy and assured security)
If you can't so much as justify a position against it, then why is PGP such a problem? If it doesn't hurt you... it certainly makes your research more secure from being stolen.
1% overhead is still a hit if you are using your equipment 100%.
But actually, I don't believe for a second that TrueCrypt or PGP is limited merely 1% overhead, the figure is deceptive in that running disk encryption has effects other than measurable disk I/O slowdown.
There is also CPU usage of the encryption, and memory and reduces page cache effectiveness.
i.e. The heavy cost of encryption must now in all likelihood be performed before data can be written to the page cache. This reduces system throughput.
You may measure simple operations as only impacted by 1%, but in reality, there are certain write patterns that this will hurt severely.
Just plain SELinux has overhead in excess of 10%.
I would expect full-disk encryption of 30% or higher.
It may be difficult to measure its true overhead if you don't fully use your hardware.
Some disadvantages? (Score:2, Informative)
Re:Repeat after me (Score:5, Informative)
Parent is on the right track, imo. Submitter should work with the IT dept to assess the impact of this.
Setup two machines running the same processing task that is actual work that he does, one with encryption and one without. Compare the difference in processing. If the performance loss is acceptable, all done. If it's not acceptable, submitter needs to start agitating now that this will seriously hamper his/her ability to do the job, and push IT to come up with a different solution.
A previous employer rolled this out, and after my work productivity got killed, i found their assessment consisted of two guys opening MS Word, making some edits, saving, and exiting word.
Re:Truecrypt does that and is better (Score:2, Informative)
Requirements can specify the means - FIPS 140-2 (Score:3, Informative)
Especially when we're talking about security.
If your requirement is "I need my disks to be encrypted", for example, and your requirements go no further than that, then you may find your vendor of choice decides to encrypt your disk by XORing it with "TheSuperSecretPasskey". Technically encrypted, but not very useful.
Think that's unlikely? That's how some eBook DRM schemes work.
In the US and Canada, there's something called FIPS 140-2 [wikipedia.org] which describes in painful detail exactly what constitutes a "secure system", including what crypto algorithms may be used (right down to the RNGs). The idea is to make it so your typical government employee can distinguish between something that is actually secure, and something which is snake-oil secure, without a doctorate in math.
Likely the requirements in this case are coming from something like HIPAA [wikipedia.org], which I'm less familiar with, but specifies exactly how patient information should be treated.
Just a thought... (Score:2, Informative)
Risk vs Reward (Score:3, Informative)
alaederach wasn't looking for a sales pitch on Truecrypt. The decision has been made. He is looking to the slashdot community to empower him with a good argument to resist encryption. I hope that he chooses to embrace encryption, while recognizing that it is not applicable to every environment or computer. He can still make an informed argument against it in his case, provided he is correct in his assessment.
POLICY
alaederach, I believe the folks that posted advice about resolving this through the proper channels to get an exception to the policy is your best route. Dont start argumentatively. Explain your concerns and keep an open mind about them. Start with a member of the team that is deploying PGP and ask what the proper procedure is to get an exception to the policy. If there is a project manager assigned, that would be the person to start with. Project managers are usually more open to the needs of your area, and have the power to address issues that are raised during the implementation process. Kindly explain your concern, and ask if a high performance system can be benchmarked and tested prior to the roll out of PGP.
PERFORMANCE
As a proud tin foil hat wearing network administrator whom has rolled out PGP, I did not find a performance hit that was enough justification to make an exception in our environment. However, the identified risk of data loss and theft was a concern for the traveling laptops. The servers were less of a risk due to the physical security controls that were in place. PGP was only rolled out to laptops in my environment. I would recommend extensive testing prior to the roll out for high performance machines. Boot times were slower, but were measured in seconds vs minutes. In every case where performance was an issue, it was typical problems that one might find on a windows machine, and was unrelated to the encryption.
SECURITY
Every time I have worked as a member of a team deploying a security measure, the same argument is claimed by someone. "There is no reason to do X as it can be subverted." That goes for policy, physical access controls, software, and hardware. Encryption is no exception to this. Yes, warm and cold boot attacks are possible. Yes, highly motivated individuals, groups, and governments may have the ability to access your data. Security is best used with many layers. It can be highly effective at reducing risk, and keep higher percentages of the population from accessing or corrupting your data. alaederach, your best argument here is risk vs reward. This is where you kindly make your claim that risk is low due to the low impact of data loss in your environment. At the same time, if you have good physical security controls, you might want to include that in your argument. If the data that your work produces is valued higher by the decision makers than what you are sharing with us, then you may want request the performance testing and explain the risk of lower production due to performance. Geeks love performance testing, and if the highest risk is determined to be your computing performance, you just might find an exception to the policy.
MYTHS
A network adminstrator that gets hit by a bus, will cause your data to be lost. FALSE. The majority of organizations that have the funds to implement a project such as this, will also have determined off site storage of encryption keys as well as any othe data that would be backed up. Usually it is a different geographical location that utilizes high physical security controls. Yes there will be members of the staff that will have access. That is why there are Human Resource controls in place to vet the administrators. I.E. background checks.
An encrypted drive can not be accessed to retrieve data. FALSE. encrypted or unencrypted, proper data backup methods should be in place. With PGP specifically, I created a bartPE cd that allowed retrieval of data on a hard
Re:People misunderstanding the question... (Score:5, Informative)
Fine, as long as you work my hours. I work in a job where I may be setting up at 0500 for a multi-person network-heavy presentation scheduled to go at 0630, and I have zero time for argument.
Sounds like you may very well be the kind of user that makes IT staff bitter and hostile. If you didn't make arrangements with the IT staff for your presentation before your presentation is scheduled to start, how is that my problem? One thing that never fails to draw the ire of IT staff is a user who consistently doesn't tell anyone what they need until it's time to go live, then expects said IT staff to drop everything to accommodate their needs at the last minute.
I've had great support and lousy support, and yes, I bring my own network hardware in case the local admin doesn't have what I need.
That's reasonable. However, depending upon what you bring, the local admin may or may not be willing to plug your gear into his network. As the local admin, I am the guy that gets called on the carpet when rogue equipment takes down the network. If I don't know what the gear is or what it will do on my network, it doesn't get installed until it's been tested in a sandbox first. In the past, I've had rogue equipment cause routing loops which in turn caused spanning tree on my switch to turn off the port to the offending network drop, taking out most of a department (they had installed a SOHO switch because they needed more ports, but never told us). I've seen rogue equipment replying to DHCP requests causing conflicting IP addresses or IP addresses that were in an entirely different subnet than the main network. I could go on, but you get the picture. So please excuse me if I don't just take your word for it that your equipment won't break things, unless I know you and know that you really do know what you are talking about.
That said, I almost never have a problem, because good network admins do indeed work with me, and lousy ones either (a) aren't there to complain, or (b) trust me far more than they should.
As long as you are reasonable in your requests and are willing to compromise with the admins on your network, most admins, IMHO, will do their best to find a solution that both they and you can live with. From what I've seen, while the BOFH does indeed exist, he is more of an exception than the rule.
Oh, and I ask (and explain and discuss and compromise) long before any equipment sees power. It's only polite.
That goes a very long ways towards earning the trust of the local admin. I withdraw my first comment about how you sound like the type of user who causes IT staff to become bitter and hostile. I'll bend over backwards -- even at the last minute -- for someone who tries to work with me and/or has shown me that I can trust them.
I've never (ten years or so) had a local hardware issue extend into the host network. It seems to be fairly hard to do that if you're not an idiot (and if your own equipment is truly solid, which mine is).
There's the catch. While most people are reasonably intelligent, there are enough people who aren't to make network admins suspicious of others, if we don't know their technical competency. There are many users who think they know more about networking than the admins who built the network. Sometimes this is true, and sometimes it isn't. At my current job, there is a user that I trust very, very much. He held my job before I did, and still probably knows more about the network than I do (he left for a different department because he got fed up with the guy who used to manage the department). OTOH, there is another user who thinks he is God's gift to networking. While he does have a little knowledge...well, a little knowledge is a dangerous thing.
WDE only protects against a few things (Score:4, Informative)
Your IT people need to remember that whole-disk encryption only protects against some threats, not all. It's mainly going to protect against physical theft of the drives themselves, or the computer they're in. That means it's going to mainly benefit laptops that're out in the world where they can be easily stolen. Office desktops, if they're stolen that means someone had physical access to the building to take them. If the IT department can't name the last time a desktop was stolen from the building, theft is probably not an issue. Servers aren't likely to be stolen at all, they're locked up in a presumably secured data center and I just don't see an outsider being able to get in there let alone unrack a server and walk out with it under their arm. Again, if IT can't name the last time a server was stolen it's probably a non-issue.
And even in the case of a laptop, the encryption only protects the disk while the computer's powered off or in a state where the encryption software's discarded the key and won't decrypt the disk again without you re-entering the password. We found where I work that the standard suspend mode of the laptops does not trigger PGP to prompt for the password on resume, for instance. Since most of our people leave their laptop suspended while carrying it around rather than turning it completely off (to speed up start-up), the PGP encryption essentially isn't protecting the disk at all since the thief won't need the password to get the data decrypted. I don't count the normal screen lock, since if that were sufficient you'd just force password lock on the screen saver and not need encryption at all.
And of course whole-disk encryption won't protect you at all from viruses, trojans and other malware that gets onto the system and starts sending data back home. That stuff's running after you've helpfully given PGP the password and it's cheerfully decrypting data for you, and it's running as you so PGP thinks it's you accessing the data. Again, for office desktops and servers remote access by malware's probably a bigger concern than physical access to the machines and you need something other than whole-disk encryption to protect against those threats.
To be honest, I'm much more of a fan of removeable media. Put the patient data on a USB stick, then plug the stick in to access the data and remove it when you're done. If the sensitive data isn't on the computer then nobody can get it by stealing the computer. Just don't fall victim to those "encrypted" USB sticks, many of them either use algorithms that're trivial to break or they fail miserably at some point (eg. leaving the encryption key in unencrypted unprotected space where it can be extracted and used by a thief). It's much easier to lock some USB sticks or CD/DVDs up in a secure drawer than it is to protect a computer.
Maybe a little late here, but... (Score:3, Informative)
We have about 80 laptops in the field, and about 2x that in desktops.
Since we deal with a lot of sensitive data (read: personally identifiable) I have been deploying PGP WDE for the past few months to all laptops (no desktops).
Speed:
Our users primarily use a web browser and Outlook. No one has complained about speed yet. Caveat: While it's encrypting, the laptops will slow to a crawl until it's done. We've had a lot of complaints, even after my helpdesk guys advise them.
Administration:
Couldn't be easier. Someone mentioned that you could essentially "lose the key." Not possible, and I've tested it. WDE creates a backup 1 time use token so that if someone forgets their password you're not up a creek. Also, the server side software allows for backups, so you're covered on that end.
Cost/etc:
Expensive as hell, in my opinion, but a hell of a lot cheaper than having to pay our lawyers. My impression is a very positive one. The only thing that leaves much to be desired is support. You have to submit a ticket online, and if you're lucky, you'll get a call back within the day.
Answering a few of the questions (Score:2, Informative)
First, the article that you link to is not about the current products.
The article is about "PGP Disk" which is now what we call "PGP Virtual Disk." That is a container-disk encryption system. It is still offered along with PGP WDE, as it's nice to have both. There have been many improvements to it since that article was written.
My guess is that article is over ten years old. There's no date on it, but based upon what he says -- he installed it on Windows 95 running an AMD K6 200-MHz computer with 9 GB of Ultra DMA EIDE drives and 64 MB of SDRAM memory -- my guess is that it dates from late 1997.
If you want to do a fair comparison, let's also test against the experimental Linux 1.2 kernel, too, which also dates from about that time. That article also talks about CAST (which is still an option in Virtual Disk, but WDE uses AES). I can go on, but you're not asking about that, you're asking about WDE. My point is that if you research our present products and reference an article about a different product from last century, it's not going to tell you what you want.
I want to talk about the three main issues I see here: partitioning, compression, and performance.
When it comes to partitioning, PGP WDE operates below the partitions. We think that this is a huge benefit. We do not presently support dynamic repartitioning. It's a goal, as our long-term plan is to support Windows, Mac OS X, and Linux on the same disk with multiple partitions. We're not there yet. My personal opinion is that partitioning made sense when disks had megabytes. It doesn't make sense when they have terabytes, except for some obvious exceptions, like that you want to have a triple-boot disk. Your situation seems to be different, and I'd love to hear your views and needs for dynamic partitioning.
There are no issues with compression with WDE or Virtual Disk. I don't even understand what the issue could be. An encrypting driver writes blocks of ones and zeros. It's below the file system as well as below the partitioning system. It all just works. I'm using WDE on all my computers, and it just works.
The last issue, which you didn't bring up, but is important, is performance. When you measure *any* WDE system, not just ours, there is obviously a performance loss -- because you're adding the encryption. This is even true with hardware encryption.
Nearly any number between "essentially zero" and 100% are true, given what you measure. On a steady-state running system doing normal tasks, the WDE overhead is essentially zero. Users won't notice it at all.
At the other end of the scale, we've done some performance measurement, and compared the real WDE driver against one that no-oped the encryption. The result is that the encryption takes about 1/2 the time of the total driver throughput. You can call this 50% or 100% depending on how you like to count.
In a real-world situation, the real factor is how much time you are spending in the disk driver. If you have a heavily IO-bound system that's spending 30% of its time in the driver, then WDE is costing you 15% of your CPU. But if you're compute-bound, then WDE is costing you literally nothing.
However, if you get a hardware encrypting disk, you don't improve the situation. We've benchmarked some of the new encrypting spindles against their non-encrypting versions. The performance overhead is much worse for those than for our WDE. It adds zero to your CPU, but it's a huge latency issue, up to nearly a one-quarter drop. This shouldn't be a surprise -- we're doing the encryption on a 64-bit Intel or AMD processor, and they're doing it on an embedded CPU on the controller. Which one do you think is going to be faster?
There are a set of advantages and disadvantages to doing encryption on the CPU or on the disk, but speed goes to doing it in software. The speed advantage of software is only to shift even more to t
Re:Repeat after me (Score:3, Informative)
Actually, it's very difficult to make that determination. The IT people aren't pushing PGP for their health -- the cost of these applications is outrageous.
I've been through this - we approached a group of people who insisted that full disk encryption would cause all sorts of issues. They weren't able to document these issues, of course. We also got the "why does this matter to us anyway... we don't have any PPSI".
Then we go down with the security folks and audit the desktops. What did we find? All sorts of sensitive information that they didn't even know that they had. (It didn't show up in their reports, but was buried within the source datasets).
This scenario is more common than you thing and encrypting everything is the best defense. In our environment, which has nearly 60,000 users, unless you are using a thin client, you get full disk encryption.