In the past I have tried to make the case for encrypting physical servers on premise. The argument for not needing to encrypt them is usually that these servers run for weeks, months or even years without being brought down, and that they are physically protected within a well-fortified data center. The protection that FDE (Full Drive Encryption) brings only really applies to data at rest and it seldom is at rest on these servers. I would counter that all drives eventually leave the data center for repair or disposal and having them encrypted protects you from having your old drives with your customer data on them show up on eBay. An encrypted drive can be quickly and easily crypto-erased if it is still operational, and if not, the data is still not accessible without the encryption key.
From May 17th to 19th, I had the pleasure of attending the Fifth International Cryptographic Module Conference (ICMC 2017) with my colleague, Alexander Mazuruc. Alex usually attends this conference which focuses on cryptographic modules and FIPS 140 type issues, but this year there were 8 tracks on related subjects such as Quantum-safe crypto (yes, that is a thing), and Common Criteria. The conference had about 35 different sponsors including the Trusted Commuting Group. Overall I found the conference very informative and a good place to network in the community.
I have written about the security implications of using sleep with encrypted drives in the past and have offered both short term and longer term solutions that would allow users to use sleep under some conditions and not risk (too much) a data breach. Today I am writing to offer another, common sense, alternative: Just don’t use sleep because you don’t really need it.
It has been a while since I have written about UEFI, Secure Boot and their impact on Full Disk Encryption (FDE) pre-boot authentication (PBA) so it’s time for an update on what is new in this area, but first here is a recap because this is a bit of an arcane technical subject. UEFI stands for “Unified Extensible Firmware Interface”. The UEFI specification defines a standard model for the interface between personal-computer operating systems and platform firmware. It provides a standard environment for booting an operating system and running pre-boot applications such as the PBA for FDE. It replaces the traditional legacy BIOS interface that was used with Windows 7 and older systems. Now that Windows 10 is being widely adopted I expect to see UEFI used on almost all new machines.
Last week, I once again had the pleasure and privilege of attending the RSA Conference in San Francisco. I heard estimates of a record breaking 40,000 attendees. It didn’t seem much busier than previous years but as another participant pointed out to me, that might be because it was better organized, with pre-registration for the sessions, this year. This year I focused my sessions on the Cloud.
If you have been following our blogs you know that the ideal FDE architecture has two main components. The actual encryption component is a separate layer from the key management. The encryption can be done by the OS (e.g. BitLocker for Windows or FileVault2 for Mac), by Self-Encrypting Drives (SEDs) or by ISVs such as WinMagic’s FIPS140-2 validated software cryptographic engine.
In a previous blog I wrote that at Black Hat Europe 2015, two forensics experts from KPMG Canada presented their findings in a presentation titled “Bypassing Self-Encrypting Drives (SED) in Enterprise Environments”.
I once again had the pleasure and privilege of attending the largest security conference in the world; the 2016 RSA Security Conference in San Francisco. This year’s conference was well attended with a reported 40,000 attendees. This is up from fewer than 20,000 just a few years ago.