This article can also be found in the Premium Editorial Download "Information Security magazine: How to tell if you need the help of security integrators and consultants."
Download it now to read this article plus other related content.
|5 Keys to Picking a Vendor|
Develop a checklist of important questions you should ask before choosing an encryption vendor. Here's a good place to start:
We all know the problem with passwords: If they're too simple, they are easily guessed or cracked; if they're too hard, users either forget them or put them up on a note stuck up on their monitor. One approach is to require users to create a long (say 30 characters) but easy-to-remember pass phrase.
This password needs to be different than their account password and not stored anywhere on the system. All too often, organizations tie private key access to the user log-in password, making it all to easy for an attacker to gain access to it and negate the encryption.
Many organizations make the mistake of archiving private keys so they can decrypt information later. If more than one person knows a private key, its value is decreased, and user accountability is problematic. The proper way to handle this is with a master key that is embedded into all of the encryption. This will prevent a user from holding the company hostage, while allowing you to recover data if a key is lost or corrupted.
Protection. Once the key is unlocked with a password, it should be stored in a protected RAM drive so it is not accessible to any program. The drive should exist only as long as the key is needed to decrypt--no more than a few minutes. The RAM drive should be a function of the encryption software.
Retirement. This is actually one of the biggest key management security problems. When a key is no longer needed or the risk of compromise is too high, it must be retired in a way that assures no one can use it. This sounds self-evident, but it's not always the case. Keys that are no longer valid are put on a certificate revocation list (CRL) by the CA. The problem is that it is the responsibility of a site to pull down the latest CRL and make sure is the key is still valid before trusting it.
Since many sites skip this step, it is possible to have an expired key that sites still trust. This may be a problem with the encryption software, but is much more likely to be the result of poor implementation. Most organizations try to implement encryption by themselves, but don't understand the concept and don't configure it correctly.
This was first published in June 2007