Self-Encrypting Drives Aren't Magic Security Dust

Suddenly, everyone’s talking about at-rest, on-disk encryption again. No surprise why: Recent news about NSA surveillance programs and Bradley Manning's conviction for leaking U.S. classified files have reawakened interest in data protection. But I worry that people will once again fall into the trap of thinking that a single technology automatically means security.

The other day I received a press release from desk encryption vendor WinMagic proudly announcing that Hewlett-Packard had chosen WinMagic's SecureDoc tech for HP’s Client Security product. SecureDoc is a pretty venerable product, with broad deployment, a lot of industry accolades, and -- most importantly -- native support for Opal-compliant self-encrypting drives, or SEDs. (Opal is a standard for storage device policy management.)

Now, SEDs are appealing for a lot of reasons: They require no specific software to work; they do their encryption and decryption in dedicated hardware for speed; and they’re apparently tougher to hack. But they’re not magic dust that automatically blesses an organization with bulletproof data security. What’s more, I’m not convinced they’re an automatic upgrade path from software-only on-disk encryption, for a variety of reasons.

• Minimal amount of stress encryption puts on the average CPU. Even on notebook computers, software encryption doesn’t generate the kind of CPU usage that would hobble today’s systems or lower battery life. Having encryption in hardware is a nice bonus, but hardly a quantum leap.

• Not every SED is alike. First off, not all such drives are Opal-compliant, which means while they may use a strong encryption algorithm, their implementation of it is another story. SandForce’s implementation of AES encryption on its SSDs, for instance, turned out to have some problems. Buying any old drive won’t cut it; you have to do research.

• Upgrading software-based encryption is less disruptive. If the implementation of the encryption algorithm used by the drive turns out to be vulnerable to some kind of attack, the entire drive may need to be replaced. A software-based system can be upgraded a little less painfully; it still requires the drive be re-encrypted, but such things can be done passively in the background and even across multiple user sessions. The above-mentioned SandForce drives, for instance, couldn’t be fixed with a firmware patch; they had to be completely ditched.

[Email encryption is a tough balancing act for organizations. Read how in, "Email Encryption And The Goldilocks Principle."]

• Management on a large scale. Software-based encryption, whether by third-party endpoint protection suites or an OS-native technology like Microsoft BitLocker makes management part of the deployment process. SEDs need to be treated like an explicitly managed asset in order to be useful, not something that’s just deployed once and forgotten about.

• Software-based encryption doesn’t require new hardware. Existing assets can be protected with it, although the degree of protection will vary. For instance, cold-boot attacks might be easier to stage on such hardware, although some of this can be mitigated with a PIN or other two-factor authentication scheme.

• Audit incentive. Unless the next wave of SEDs are open hardware along the lines of the Open Compute Project’s work, it’s hard to audit a SED's design for flaws in its encryption. Software is a little easier to do this with, especially if it’s an open source product.

Why organizations encrypt is also an important consideration. A 2011 Ponemon Institute study surveyed some 500 IT professionals and found that the single biggest reason for using SEDs was compliance with regulations -- rather than protecting customers or minimizing the cost of a data breach. “These choices may be less important to IT practitioners,” said the report, “because they do not deal directly with consumers or financial issues.” Consequently, an organization may just default to using the endpoint encryption systems it already has in hand --i.e., software-based products, rather than purchase all-new hardware.

Okay, I need to be honest. I don't mean to sound like I believe SEDs have no place in an organization. With the right deployment strategy and the right attention to the specific security problems they mitigate, they can be useful. But they’re not by themselves a defense against data theft or loss, nor are they by themselves a compliance procedure.

Security is a process, not a product, and while you can buy products that make the process easier, the majority of the heavy lifting is still yours to do.