Now that you have a better understanding of major key manager features and options we can spend some time outlining the selection process. This largely comes down to understanding your current technical and business requirements (including any pesky compliance requirements), and trying to plan ahead for future needs.

Yes, this is all incredibly obvious, but with so many different options out there – from HSMs with key management to cloud key management services – it’s too easy to get distracted by the bells and whistles and miss some core requirements.

Determine current project requirements

Nobody buys a key manager for fun. It isn’t like you find yourself with some spare budget and go, “Hey, I think I want a key manager”. There is always a current project driving requirements, so that’s the best place to start.

We will talk about potential future requirements, but never let them interfere with your immediate needs. We have seen projects get diverted or derailed as the selection team tries to plan for every contingency, then buys a product that barely meets current needs, which quickly causes more major technical frustration.

1. List existing systems, applications, and services involved: The best place to start is to pull together a list of the different systems, application stacks, and services that need key management. This could be as simple as “Oracle databases” or as complex as a list of different databases, programming languages used in applications, directory servers, backup systems, and other off-the-shelf application stacks.
2. Determine required platform support: With your list of systems, applications, and services in hand; determine exactly what platform support you need. This includes which programming languages need API support, any packaged applications needing support (including versions), and even potentially the operating systems and hardware involved. This should also include encryption algorithms to support. Be as specific as possible because you will send this list to prospective vendors to ensure their product can support your platforms.
3. Map out draft architectures: Not only is it important to know which technical platforms need support, you also need an idea of how you plan on connecting them to the key manager. For example there is a big difference between connecting a single database to a key manager in the same data center, and supporting a few hundred cloud instances connected back to a key manager in a hybrid cloud scenario. If you plan to one or more key managers in an enterprise deployment, with multiple different platforms, in different locations within your environment, you will want to bee sure you can get all the appropriate bits connected – and you might need features such as multiple network interfaces.
4. Calculate performance requirements: It can be difficult to accurately calculate performance needs before you start testing, but do your best. The two key pieces to estimate are the number of key operations per second and your network requirements (both speed and number of concurrent network connections/sockets). If you plan to use a key manager that also performs cryptographic operations include those performance requirements.
5. List any additional encryption support required: We have focused almost exclusively on key management, but as we mentioned some key managers also support a variety of other crypto operations. If you plan to use the tool for encryption, decryption, signing, certificate management, or other functions; make a list and include any detailed requirements like the ones above (platform support, performance, etc.).
6. Determine compliance, administration, reporting, and certification requirements: This is the laundry list of any compliance requirements (such as which operations require auditing), administrative and systems management features (backup, administrator separation of duties, etc.), reporting needs (such as pre-built PCI reports), and certifications (nearly always FIPS 140). We have detailed these throughout this series, and you can use it as a guide when you build your checklist.
7. List additional technical requirements: By now you will have a list of your core requirements but there are likely additional technical features on your required or optional list.

And last but not least spend some time planning for the future. Check with other business units to see if they have key management needs or are already using a key manager. Talk to your developers to see if they might need encryption and key management for an upcoming project. Review any existing key management, especially in application stacks, that might benefit from a more robust solution.

You don’t want to list out every potential scenario to the point where no product can possibly meet all your needs, but it is useful to take a step back before you put together an RFP, to see if you can take a more strategic approach.

Write your draft RFP

Try to align your RFP to the requirements collected above. There is often a tendency to ask for every feature you have ever seen in product demos, but this frequently results in bad RFP responses that make it even harder to match vendor responses against your priorities. (That’s a polite way of saying that an expansive cookie-cutter RFP request is likely to result in a cookie-cutter response rather than one tailored to your needs).

Enough of the soapbox – let’s get into testing.

Testing

Integrating a key manager into your operations will either be incredibly easy or incredibly tricky, depending on everything from network topography to applications involved to overall architecture. For any project of serious scale it is absolutely essential to test compatibility and performance before you buy.

Integration Testing

The single most crucial piece to test is whether the key manager will actually work with whatever application or systems you need to connect it with.

Ideally you will test this in your own environment before you buy, but this isn’t always possible. Not all vendors can provide test systems or licenses to all potential customers, and in many situations you will need services support or even custom programming to integrate the key manager. Here are some suggestions and expectations for how to test and minimize your risk:

• If you are deploying the tool to manage the keys of a common application or platform that the vendor commonly supports, such as a major backup system, odds are it will work in your environment. Ask the vendor how many production deployments they know of with your version, and for a reference, and you may not need to test yourself.
• References are also your friends for less-direct use cases. Ideally reach out to your personal network for someone doing something similar instead of relying on vendor references, but those will also do in a pinch. Focus your questions on the complexity of integration, hidden obstacles, and amount of effort involved in the project. Ideally talk to someone at the engineering level, not the CISO who approved the budget and didn’t actually manage the implementation.
• Be wary of selecting a product when you can’t test it if you cannot find more than a couple references from people using it in similar circumstances.
• The vendor may be able to provide a virtual machine or software for testing, even if you plan on using hardware. This is generally fine for integration testing.
• To test, perform a basic integration on a non-production system and practice the workflow. Depending on the nature of the project you should test some or all of key management, exchange, generation, rotation, and any other features you expect to use.
• For larger and more complex projects, it may make sense to buy a single license for more rigorous testing and a full proof of concept. You may even want to purchase low-end licenses for multiple products to compare them. Clearly this is only an option for larger organizations and larger projects.

For basic projects integration testing doesn’t need to be overly complex. You simply want to make sure the tool will handle keys, for the operations you need, on the applications and systems within your project scope. Larger and more complex projects obviously need much more in-depth testing.

Stress/Performance Testing

Don’t ever trust a spec sheet. Key manager performance varies based on the kinds of operations you perform, any cryptographic operations (encryption, key generation, etc.), and network load. As before, direct testing isn’t always possible or even needed, but any testing is best focused on the following areas:

• The number of key exchanges, of the type you require, per second. This isn’t necessary for deployments where you aren’t performing that many operations (including some backup scenarios).
• The number of key generation operations per second.
• The number of any other required crypto operations (beyond key management) per second, if those are within scope for your project (e.g., encryption).
• Network bandwidth.
• Number of concurrent network sockets supported (this may be the limiting factor rather than bandwidth).

Make sure you perform this testing on the same platform you plan to use for deployment, as operations may not scale linearly. For example, if you are deploying software or a virtual appliance, put it on the same hardware you expect to use later. If you are deploying in the cloud, make sure you know what physical server you are on (in private clouds – this doesn’t apply to public), and what instance flavor (size) you are using.

Backup, Recovery, and Management Testing

Perform a key backup and restore, making sure you understand the workflow. If, for example, you plan to require m of n administrative keys for a recovery, test that. Also walk through the management interface, including audit and reporting, to make sure it fits your needs and expected workflow.

Conclusion

Hopefully this has helped you gain a better understanding of the role of enterprise key managers, the major features to look for, and how to evaluate and select one (or more).

Increasing privacy concerns, regulations, use of distributed and cloud computing, and even BYOD are driving more use of encryption in more diverse organizations than we have ever seen before. Sometimes the encryption implementations do a fine job of handling encryption keys themselves, but we see plenty of use cases and specific implementations where it makes far more sense to shift to an external key manager.

Don’t forget to read our Pragmatic Key Management for Data Encryption paper for an overview of key management strategies and more use cases, then use this series (and the eventual paper) for guidance if you decide to use an external key manager.