Roger's Information Security Blog

As part of my Symantec Endpoint Encryption (SEE) upgrade, I verified that the new version worked with our main computer models.   During that testing, I looked at how boot/shutdown times changed, and verified that the system could still reboot and enter/exist sleep and hibernate correctly.  The only problem that came out of that testing was when standby was used, the user no longer had to do a preboot authentication before logging into Windows.  Previously GuardianEdge Hard Disk  (GEHD) Encryption provided full disk encryption on a cold boot and on returning from standby or hibernate.    Further testing found GEHD 9.5.3 also had this problem, I just didn’t know it.  

Since the cold boot was announced, it has been best practice to not allow computers using Full Disk Encryption (FDE) to enter sleep.  The encryption key typically remains in memory while the computer is in sleep mode and is thus susceptible to the attack.  

As a side note, hibernate is also dangerous if your FDE product doesn’t encrypt the hibernate file.   SEE should not have this issue.

Personally I refrain from using hibernate or sleep.   In my experience, it is unreliable.  So I’m not the most sympathetic person here.    There is always a tradeoff between security and usability.   If sleep is insecure and you fail to disable sleep then you only have the appearance of security.   You’ve checked the encryption box without actually protecting the data.

Management’s first response to this documented need to disable sleep is to ask for a report comparing sleep versus quarantine shutdown times.    In my experience, getting off XP is the first step toward having decent shutdown times.   The second step is reloading the system once it has the crud.    The effect of creeping crud will be more noticeable now that we are on three-year leases. 

For more information on protection against cold boot attacks with Symantec Endpoint Protection see their knowledgebase.

Symantec Endpoint Encryption (SEE) 8.0.1 is my first upgrade since Symantec purchased GuardianEdge.  It is a newer version inspite of being a lower number than GuardianEdge 9.5.x.    I guess it is really too soon to expect big changes.   I was hoping they would address some of the installer annoyances.

With SEE, you install a management server, then create the client install packages.   These are MSI packages.

Separate 32 bit and 64 bit Installer Files
I don’t do MSI package generation myself, but the software I’ve seen allows you to put both 32 bit and 64 into one installation file.   I would think this would make things a lot easier.   The main drawback would be the size of the install file.    I end up putting both 32 and 64 bit files into one installation package and call the appropriate one based on the CPU architecture.   So it doesn’t save me space and instead requires extra scripting work.   Is there some technical limitation I’m not aware of?

Upgrades
Upgrading versions of Symantec Endpoint Encryption (or GuardianEdge Hard Disk Encryption) requires using special switches.   When performing an upgrade, I need to use the command line MSIEXEC /i “\.msi REINSTALL=”ALL” REINSTALLMODE=”vomus”.   This upgrades the client by reinstalling all features of the product.

On the other hand, a regular install of Symantec Endpoint Encrytption, where it was not installed previously, uses more familiar switches (/qb).   In previous upgrades I’ve found that if I try to use the reinstall/reinstallmode switches on a fresh install it will not work.   I then have to script the install to use different command line options based on installation status in addition to 32 bit versions 64 bit.

To make matters worse,  some computers in my environment have Removable Storage Encryption and others don’t.   My install script is getting too complicated.

Full Control
When creating the installation package, you must save the client installation package to a local or network volume with Full control permissions set.  The SEE instructions say “This ensures the success of the upgrade package, as it will retain the Windows permissions of the location to which it is saved.”    Again, I don’t create MSI packages often.   Adobe Reader and Symantec Endpoint Encryption both create packages where a setup.exe calls the MSI.   However in neither case am I advised to change permissions on a folder.

I think I actually have seen issues that support has blamed on not creating the package in a directory with Full Control.    But I’m not sure what the actual problem is.

The old Files
In the past, when I’ve upgraded using the switches provided, I found I needed to have all the old install file available.   While people are generally on one version, I found it better to leave every version I’ve ever used in the install directory.   That can take up a lot of room.

I’m really lost as to the cause of this issue.   Shouldn’t MSI files be cached locally so even if it did need the original installation files it should have them, not require me to have them.   I am going to try one more time and removing the old install files from my SEE8.0.1 package and see if I still have issues.   Perhaps that was a problem only with older versions of the product.

Doesn’t Symantec own a MSI packaging company?   Hopefully some in-house expertise can cross divisions of the company to create a better product.

I was asked recently via email how to pragmatically uninstall GuardianEdge.   I’d been thinking about something similar, that is how do you migrate endpoint security vendors including Full Disk Encryption.

To a certain extent this problem doesn’t affect very many people.   Is Full Disk Encryption installed at many companies outside the Federal Government and Government Contractors?  I imagine its starting to make more inroads via the encryption safe harbor and regulatory requirements.  

I’ve had Full Disk Encryption deployed for over 3 years.   With many security products that is an eternity.   Features change.  Companies get bought and sold.   What if I decide to switch from yellow (Symantec) to red (McAfee).   Does Sophos have a color?  

As far as uninstalling GuardianEdge specifically, I’m pretty sure the manual says you need to decrypt before you uninstall.   Therefore, I would need to deploy a decrypt policy via Group Policy, then after sufficient time has occurred for decryption, uninstall GuardianEdge and replace it with my new favorite Full Disk Encryption.   The problem with this scenario is 1) The computer is left unencrypted for a period of time 2) this period of time is unspecified 3) The end-user will experience the joyful performance hit of decrypting and encrypting the hard drive.    Not Good!

Another possibility is to introduce the new encryption products as computers are replaced.   This has the benefit of not interrupting the user.   The downside is the helpdesk would have to keep track of two different one-time password programs to allow users to access computers with a forgotten password.   Management is twice as hard.   I’d have to maintain two different systems.   With a three-year lease cycle on computers it would be quite a while before all computers are on the new system.

We’re about to do a rip and replace migration to Windows 7.   This would be an ideal time when you’re already doing a system refresh.   You don’t have to worry about the decrypt/uninstall.   You just back up data, drop the Win7 Ghost load, restore data, encrypt.   It is a rare opportunity.

I don’t like these options.   Readers, have any of you migrated Full Disk Encryption products?   Do you see any alternatives I”m missing?   Comments welcomed below.   First time commenters will be held in the moderation queue.   All comments must clear the spam filter.