We have HP notebooks here at work, and it is policy to have HP's hard drive encryption turned on to protect client databases and IP in the case of loss/theft.
I was wondering if there was any evidence of a performance hit in this situation? The machines are primarily used as development workstations. Anecdotal evidence here suggests that the machines are slower.
Should we be using another approach (i.e. only encrypting the sensitive data as opposed to the entire disk)?
The "HP Protect Tools" is a rebadged McAfee/Safeboot FDE product. The performance impact shouldn't be too bad -- I'm assuming that you're using AES.
We encrypted about 5,000 laptops three years ago, and our folks didn't report any significant performance issues. A few older boxes blue-screened, that's about it. You may be experiencing slowdowns immediately after enabling encryption... encrypting the disk can take 8-20 hours depending on the vintage of the equipment and size of the disk.
We've used Safeguard Easy for years and Truecrypt's whole disk encryption since it came out, and neither has caused a big performance hit; even the older notebooks run development and database software without a noticeable difference in speed. Some people will even tell you that whole disk encryption software makes some operations run considerably faster due to compression, improved drive read routines, pipelining and the like. I wouldn't go that far, but as with most things, the truth is probably somewhere in between.
The peace of mind from encrypting your disk, particularly if you have any kind of regulatory/compliance threshold in your industry (or are just paranoid) is worth the minimal hit of the encryption software we've used for this purpose.
To answer this question, we need to know: is your app disk bound, CPU bound, or something else? Traditionally disk encryption involves a minor hit to performance; disk is usually slow that the decryption overhead is miniscule. However, if CPU is a concern, this can get hairy.
Development workstations are usually CPU powerful, to improve productivity. Faster build times, autocompletion/intellisense, automated unit tests, etc. Normally a laptop's compromises in the name of portability hinder the idea; giving developers a laptop suggests you've already run out of ideas for spare CPU cycles and might be able to afford disk encryption.
What you need to do as an IT professional is build a model of what developers need computational power for, and benchmark how those tasks fare under proposed conditions: no encryption, full disk encryption, and partial encryption.
The only proof is to measure. Take timings on a laptop with no encryption and compare with one that does. Of course there will be overhead in the encryption, but don't rely on a subjective "feels slower". What encryption are you using? Bitlocker? 3rd party app?
As to the final question, it is too easy to accidentally miss (or even define) what is sensitive data. So I would keep the whole disk encryption if possible.
My own experience is that ca 30% of the CPU will be dedicated to crypto, and a 50% hit in disk performance. I've tried several encryption alternatives - SafeGuard, OSX FileVault, PGP WholeDisk.. the same rule of thumb seems to apply. The CPU-use is particularly annoying though, as it affects battery time too.
A quick google search revealed this test which seems to verify my gut-feeling: http://www.isyougeekedup.com/full-hard-disk-drive-encryption-benchmarks-and-performance/
Linked here are a blogger's measurements from 2012. On an SSD the impact is huge.
The CPU is the bottleneck but if you have plenty of physical threads or even Intel Hyperthreads this might not bother many users. The difference is less on an hard disk drive which is slower than an SSD to begin with. The results for both devices are shown at the link.
Link to measurements of read and write speeds before and after encryption
For the love of God and all that is pure and right, stay away from Credant!!
It is used in our (non-technology) company and virtually all the developers have a special security waiver to not have it installed on their PCs nor laptops. It suffers from horrible performance when accessing many files at once, like when compiling code. We also had an issue where we had a service that would read the registry and other configuration files, which started up before user login. Well, as the files were not unencrypted until after the user logged in, the service would die an early, horrible death.
Also, once this steaming pile of code is installed, it is supposedly as hard to uninstall as IE, but this has not been verified in a non-lab environment because it has usually resulted in hosing the system requiring a reimage. YMMV
Not sure if you can do this (maybe in a lab?) but can you try rerunning these tests with AV uninstalled (or at least disabled). The reason I suggest this is because we had a customer with a similar issue as yours (except they had more delay writing to the drive then deleting; they also had the write cache support issues that you have) and we reran our benchmark tests with AV removed from the system and found that Win2008 (before R2 was released) out preformed Win2003 by alot. Turned out that the AV was responsible and we had to find a different AV provider.) Not sure that it will help you or not but it's something to check if you have the option.
I would avoid and do not use the Drive Encryption for HP protecttools. I recently purchased an HP elitebook 8440w running windows 7 professional 64-bit. I thought I was doing the right thing by enabling drive encryption as this user would be traveling a bunch with sensitive documents. That was a great idea until the software would not let him login anymore. The drive encryption software uses a Mcafee Endpoint Encryption login prior to the hard drive being accessed to start booting the operating system.
I encountered several errors including Token file not found and token is not logged in. I attempted to login using the drive encryption backup file saved to USB to authenticate. After that, Windows 7 was stuck in the "Startup and Recovery" mode and would not boot normally no matter what option of safe mode, last known good configuration, boot logging or repair options were chosen.
In summary, this software is not ready for use in the business world. It is a great idea to use drive encryption, but if you encounter an issue or hard drive corruption, there is no method to decrypt the hard drive even with the appropriate authentication. Stay away, stay very far away from Drive encryption for HP ProtectTools!
(your mileage may vary but mine was abominable)