A few weeks ago, we were on a conference call with one of the premier analysts in this industry when the subject of private keys came up. We’ve always taken for granted that everyone in the industry understood that as part of certificate management we also manage the private keys associated with those certificates. This analyst made it clear to us that we couldn’t make this assumption. Two reasons: 1) very few realize that managing certificates also requires the management of private keys, and 2) not many understand how critical the security of private keys is in protecting sensitive data.
If you’ve ever heard me present, you’ve heard me use this phrase, “the key is the data”--which is a phrase and concept directly from my friend, Marc Massar, who knows more than a little bit about encryption. The point is that if you protect data by encrypting it with a certificate, the private key becomes the data you have to protect (i.e. that encrypted data is effectively useless without the key but if the wrong person gets that key, your data is at risk).
At this point, you may be asking yourself, “Thanks for sharing, Paul, but why should I care?”
Let’s see if we can relate this to a topic you may have already spent some time thinking about: symmetric keys. Here’s an example. Based on PCI or some other regulation, you decide to encrypt the columns that contain personally identifiable information (PII) in your database using symmetric keys. That’s great. But what about when you retrieve that data from the database? The database is going to decrypt the data using the symmetric key(s) and pass it across the network. So, assuming you’re still worried about the security of that data, how do you ensure the data is secured as it travels across the network? You encrypt it using a certificate and private key. So it stands to reason that you want to implement the same security procedures for your private keys as you do for your symmetric keys.
Then you might say, we’re not subject to PCI because we don’t process credit cards. Well, let’s see what other types of data you’re passing across your network and the Internet that you might want to assure are properly protected based on the industry you’re in:
- Bank account information
- Insurance information
- Patient healthcare records
- Employee salary and benefits information
- Corporate financial information
- Stock account information
- Corporate trade secrets
- Etc.
So how are you managing your private keys today? If you’re like most organizations, you’re doing it manually with no dual control. Here are the typical steps an administrator goes through to generate a key pair (which includes a private and public key) and get a certificate
- Create a keystore, if one doesn’t already exist
- Assign that keystore a password to protect its contents, including the private key(s)
- Generate a key pair (public and private key)
- Generate a certificate signing request (CSR)
- Submit the CSR to the CA
- Retrieve the certificate from the CA
- Install needed CA certificate(s) in the keystore
- Install the certificate in the keystore
- Backup the private key (if deemed necessary)
- Extract the private key and certificate so they can be placed on other systems (e.g. for load balanced configurations)
The problem with administrators performing these steps manually is that it opens you up to a bunch of potential security problems, either because they’re not following best practices or because they’re malicious. Here are some security challenges that present themselves:
- Administrators normally use the same keystore password on multiple systems (sometimes hundreds) so it is easy to remember them.
- Administrators usually have to share keystore passwords with other administrators because they’re all sharing in the work managing a group of systems.
- Administrators rarely comply with corporate password rotation policies (e.g. change every 90 days) for keystore passwords and will often use the same password for years. (One administrator at a very large bank told us they call keystore passwords “passphrases” so that they don’t have to comply with the corporate “password” rotation policy. If you can believe it, this practice actually got them in compliance with their auditors.)
- Administrators who have direct access to keystores and the passwords that protect them can make copies of private keys which can be used to decrypt the data you’re trying to protect. This is a big problem if those administrators leave the organization.
- Most organizations don’t make it a practice of replacing private keys when the administrators who have had access to them are reassigned to a different department or leave the organization.
Given the typical re-use of the same password across multiple systems, the fact that passwords aren’t changed for years, and the sharing of passwords amongst multiple administrators, you can imagine the risks organizations are exposing themselves to
If you have these challenges within your organization or department, here are some best practices I recommend implementing to better protect the private keys that safeguard your most critical data:
- Automate: Use an automated key and certificate management system that removes the need for administrators to access keystores directly and the passwords that protect them
- Rotate Passwords: Change keystore passwords regularly
- Separate Duties and Roles: Have a different set of administrators manage keystore passwords than the administrators who manage the systems where the keystores reside
- Proactively Change Keys: Change private keys (and the corresponding certificates) each time an administrator who has had access is reassigned or leaves the organization
If at this point you’re wondering how on earth you might feasibility accomplish this, you may want to give Venafi a call. We’ve been helping large organizations in financial services, telecommunications, healthcare, and other industries manage their private keys and certificates for a long time. With them, we’ve developed a slew of best practices to make sure encryption is an asset, not a liability.