«Version 1.0 Released: September 13, 2012 Securosis, L.L.C. Securosis, L.L.C. Author’s Note The content in this report was ...»
• 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 application stack management if it meets your needs, but this generally only works for encryption-oriented products 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 application stack won’t work, building a silo with 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 application stack management but need a key manager for another project, it is often worthwhile to transition your applications over to the silo key manager; once you have a key manager you might as well take advantage of it for backup, restore, redundancy, and other management features.
Here are some of the reasons to move up the stack, especially from application stack management to an external key
• If you require more robust reporting (especially for compliance) than is included in your application stack’s key management. For example, some compliance initiatives require secure (segregated) logging and reporting not only of all key operations (like key rotations), but also any administrator access to keys or key management functions.
Pragmatic Key Management for Encryption 12 Securosis, L.L.C.
• If you’re concerned about key backup and restore processes, especially access to older archived data. For example, if you encrypt a backup you might need to access it up to seven years later, even if you’ve upgraded or changed which backup software you use.
• If you need greater granularity in administrative control, such as split keys or m-of-n administrator keys for high-level access (where you need something like 3 of 4 potential administrators to all provide their key before allowing an action).
• Not all application stack key management can handle re-keying of older data during a key rotation, which may be a requirement.
• When you need to manage keys across different applications that aren’t fully integrated into the application stack (this is also often the ﬁrst step towards enterprise key management).
• When you need to synchronize or replicate keys across locations and this isn’t supported by the application.
This isn’t an exclusive list, but some of the more common reasons we see for moving to external key management in data encryption implementations.
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 in a silo, pick a platform that will grow as you increase usage – even if the ﬁrst 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 ﬁrst 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 manage 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 ﬁne to keep some application stack managers, 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, due to a mix of longevity needs and very limited key management implementations in the backup products themselves.
• Database encryption, since most database management systems only include the most rudimentary key management, and rarely the ability to centrally manage keys across different database instances or segregate keys from the database administrators.
• Application encryption, which nearly always relies on a custom encryption implementation and, for security reasons, should separate key management from the application itself.
• Cloud encryption, due to the high volume of keys and variety of deployment scenarios faced.
In all four areas we tend to see strong need for encryption but weak key management.
To recap: avoid local management; application stack managers are ﬁne when they meet your needs; step projects up to external 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.
Who We Are About the Author Rich Mogull, Analyst and CEO Rich has twenty years of experience in information security, physical security, and risk management. He specializes in data security, application security, emerging security technologies, and security management. Prior to founding Securosis, Rich was a Research Vice President at Gartner on the security team where he also served as research cochair for the Gartner Security Summit. Prior to his seven years at Gartner, Rich worked as an independent consultant, web application developer, software development manager at the University of Colorado, and systems and network administrator. Rich is the Security Editor of TidBITS, a monthly columnist for Dark Reading, and a frequent contributor to publications ranging from Information Security Magazine to Macworld. He is a frequent industry speaker at events including the RSA Security Conference and DefCon, and has spoken on every continent except Antarctica (where he’s happy to speak for free — assuming travel is covered).
About Securosis Securosis, L.L.C. is an independent research and analysis ﬁrm dedicated to thought leadership, objectivity, and transparency. Our analysts have all held executive level positions and are dedicated to providing high-value, pragmatic advisory services.
We provide services in four main areas:
• Publishing and speaking: Including independent objective white papers, webcasts, and in-person presentations.
• Strategic consulting for end users: Including product selection assistance, technology and architecture strategy, education, security management evaluations, and risk assessments.
• Strategic consulting for vendors: Including market and product analysis and strategy, technology guidance, product evaluations, and merger and acquisition assessments.
• Investor consulting: Technical due diligence including product and market evaluations, available in conjunction with deep product assessments with our research partners.
Our clients range from stealth startups to some of the best known technology vendors and end users. Clients include large ﬁnancial institutions, institutional investors, mid-sized enterprises, and major security vendors.
Securosis has partnered with security testing labs to provide unique product evaluations that combine in-depth technical analysis with high-level product, architecture, and market analysis.