In our last post we covered the four enterprise key management strategies. Today we will finish off Pragmatic Key Management with recommendations on how to pick the right strategy for your project or organization.
To recap, there are four key management strategies:
- Local management
- Silo management
- Key management service
- Enterprise key management
As much as I would like to drag this out into a long and complex assessment process, it’s actually fairly simple:
- You should never use local key management for anything other than development, testing, and one-off applications. About the only thing I use it for is some personal encryption, and not even much of that.
- Stick with silo management if it meets your needs, but this generally only works for encryption-oriented silos such as full disk encryption, email, and a couple other cases. By ‘needs’ I mean everything from basic manageability and auditing/reporting all the way through administrator separation of duties, key rotation/backup/restore, multi-location key synchronization and replication, and all sorts of other requirements beyond the scope of this series.
- When local and silo won’t work, a key management service is the way to go.
- Full enterprise key management is nice to have, but not something to focus on at the start.
If you do stick with silo management but need a key manager for another project, it is often worthwhile to transition your siloed applications over to the key manager; once you have a key manager you might as well take advantage of it for backup, restore, redundancy, and other management features.
The key is to think strategically. Once you start managing multiple encryption applications, you will eventually move into some sort of dedicated key manager. To build a key management service, pick a platform that will grow as you increase usage – even if the first deployment is narrowly scoped. People often start with a single application, database, or storage encryption project – a silo where key management is poor or doesn’t exist. But don’t choose purely based on immediate requirements – pick something that meets your immediate needs and can expand into other areas, for example by providing a backup key manager for disk encryption.
We see two common problems when people build key management strategies. The first is that they don’t build strategically. Everyone buys or builds key management for each project, rather than offering and taking advantage of a central service whenever possible. On the other end of the spectrum, organizations obsess over implementing enterprise key management but forget to properly managing their silos and projects.
We see the best success when organizations plan strategically and then grow into broader key management. Practically speaking, this typically starts with a single project using a dedicated key manager, which is then expanded and leveraged for other complementary projects. It’s fine to keep some silos, and it’s okay to have key managers in their own silos when there is no need to plug them into something larger. For example, you don’t necessarily need to have both your database encryption and full disk encryption projects report up to a single enterprise key manager.
We have mentioned this before, but sweet spots which may justify moving up to a key manager include:
- Backup encryption
- Database encryption
- Application encryption
In all three areas we tend to see strong need for encryption but weak key management.
To recap: avoid local management; silos are fine when they meet your needs; step projects up to key managers when it makes sense for the project; expand coverage over time; and stick with one platform for cleaner management when feasible. Key management and how you structure your crypto system both matter more than the encryption engine itself. We haven’t discussed key manager selection criteria (fodder for a future report); but it should be obvious that deployment is easier when products support standards, include good APIs and plugins, and play well out of the box with common platforms and software.
You should now have a much better idea of how data encryption systems work, the different strategies for managing encryption keys, and how to pick the best one for your organization.
Reader interactions
2 Replies to “Choosing Your Key Management Strategy”
Richard- I think you’re right. Silo better describes scenario 3. What do you think of “Application” to describe the second? It’s really about managing keys within an application stack.
Key management means something different to almost everyone so it’s great that you’re trying to bring some standard language to the topic. I think you’ve got the 4 main scenarios spot on but I tend to think of the term ‘silo’ as applying to your third scenario rather than the second – i.e. aligning it with organizational silos within an enterprise (such as storage) rather than a single product or application. If I understand the blog correctly, the first two scenarios both refer to single apps – where the first refers to a single isolated instance and the second refers to a distributed multi-instance app – i.e. the difference between me managing my own laptop encryption rather than an enterprise managing a fleet of laptops all with the same encryption capabilities. Scenarios 3 and 4 instead cover key management as an abstracted service in the context of managing keys across a range of disparate apps or devices – the difference between the scenarios being one of scope. Scenario 3 is constrained to a related set of apps, often in a single organizational ‘silo’ – i.e. a variety of different storage encryption technologies but managed by a common IT/security team. Whereas Scenario 4 is when the problem is pushed out to the limit of the entire organization – not only spanning multiple products but also organizational domains – quite literally all the keys in the kingdom. At the risk of introducing new terminology, to me, calling Scenario 1’Local’ and Scenario 4 ‘Enterprise’ are spot on, but I can’t help thinking that Scenario 2 works better as ‘Distributed’ and scenario 3 as ‘Silo’ or ‘Domain’.