Last week I said that I would go deeper into the forms of encryption that can be used to protect your information and I stated that, “the most common encryption method in use today for data at rest won’t do anything to protect your company from a system hack.” But let me back up for a moment.
Just like matter can exist in the 4 states of solid, liquid, gas, or plasma, information or data can exist in 3 states; in rest, in motion, and in use. In the December 2009 issue of HP Connect Magazine, I published an article that asked the question, “Will Volume Level Encryption Keep My Data Safe?” Even though computing has seen radical shift in the last half a decade, the information presented in that article is just as accurate and valuable today as it was 4 years ago. (With the exception that IBM received a patent for their data in use protection method and are now promoting it as a solution to cloud security.)
The Cliffs Notes version of that article is that data can be encrypted at the container level (disk, communications link), hardware block level, file level, record level, or field level using the same or different keys and the encryption can be performed in hardware or software. If done in software, the encryption engine can be built into the disk driver, operating system, database, application, or an encryption library.
The most common type of encryption is at the volume level and can be done in software (Microsoft Bitlocker, Symantec Drive Encryption, etc.) or hardware (self-encrypting disk drives). The answer to the question asked in the title of my HP Connect Magazine article is no – volume level encryption won’t keep your information safe unless the system or disks are powered off. So even if Target encrypted their data, it wouldn’t have done anything to stop the theft of 40 million customer credit and debit card accounts from their systems if they used full disk encryption.
While I said that the amount of protection afforded an object should be proportional to its value, I glossed over the fact that you also need to determine the lifetime of your information. That is, when does it stop being valuable? Are you protecting product launch dates or battle plans (a few months), credit card numbers and PINs (3 years), product design documents (from months to years), or government and trade secrets (generations to forever)? You need to encrypt for the life of your data. That means choosing an encryption algorithm and key length that can stand up for the lifetime of the data.
Credit cards and PINs have a lifetime of about 3 years. Target says hackers took encrypted PIN data but can’t crack it because it’s secured with Triple DES. But Target is not saying how many keys or what key length was used, and that is important according to NIST. Two-key Triple DES encryption was only acceptable through 2010, it is in restricted use from 2011 through 2015, and it is disallowed after 2015. So the PINs may be at risk depending on the keys and the computing resources of the hackers.
In my Fall World DRJ session on the intersection of cyber security and business continuity, I said that All of your information should be laid out on a grid, with its value to the company on one axis and its lifetime on the other. Information that is low in value with a short lifetime falls at the left bottom, while information that is key to your organization’s existence with a very long lifetime appears in the upper right and corner. The Coca Cola formula probably would go there.
I dumped a lot of information on top of you in this entry and pointed you to even more, but all of it is actionable. If you are concerned about the security of your information, you need to identify:
- Your most important information
- Its lifetime
- What needs to be done to protect it from cyber threats
And if your IT staff tells you that your information is encrypted, ask about:
- Full disk encryption versus more granular encryption
- If hardware or software encryption is in use
- The encryption algorithm and key length
- How the encryption key is protected
- The certification of the encryption implementation