vault

How to Standardize Cryptography in the Enterprise with HashiCorp Vault

Learn how centralizing encryption tools in a self-service platform for developers lowers the cost of ownership, centralizes best practices, and makes auditing easier.

Security organizations in modern enterprise IT are dedicating more budget, resources, and expertise toward implementing the patterns of zero trust. Zero trust is an approach to security built on authorization and encryption everywhere. In this post, I’ll focus on how to get better at the “encryption everywhere” component and demo an example using HashiCorp Vault to centralize the cryptographic tools offered to developers, expanding the security footprint and reducing the total cost of management.

»The Cryptography Challenge

Security organizations have to deal with numerous threat surfaces, including:

  • Network intrusion detection
  • Platform patch management
  • Identity and access management

But that’s only part of the problem. A less prominent but equally critical threat surface involves your developers and the tools they use daily.

For example, Ars Technica recently described a bug in the ECDSA algorithm deployed in Java versions 15 and higher. Because of this bug, a malformed signature could trick the Java runtime into verifying bogus cryptographic signatures. Neil Madden of ForgeRock is quoted in the article saying: “If you are running one of the vulnerable versions, then an attacker can easily forge some types of SSL certificates and handshakes (allowing interception and modification of communications), signed JWTs, SAML assertions or OIDC id tokens, and even WebAuthn authentication messages. All are using the digital equivalent of a blank piece of paper."

That sounds really bad! Luckily Oracle offers a patch to correct the vulnerability. A simple fix, right? But how simple is it? Let’s look at the process. The IT staff has to:

  1. Identify all of the platforms running the vulnerable runtime.
  2. Identify the development teams writing the affected code.
  3. Have the development teams test their code on the patched runtime.
  4. Update the runtime on affected platforms.
  5. Update affected software and infrastructure as code build pipelines.
  6. Schedule downtime to push the changes.

That doesn’t sound simple. And it has to be done across cloud and data center environments. And when a different runtime, maybe Ruby or .NET, has a similar vulnerability next month, you will have to do it all again.

»Cryptographic Sprawl

Developers have many reasons for choosing the languages and frameworks that they use:

  • Functionality: The project requires functionality that only one toolset provides.
  • Developer knowledge: Team members are familiar with a toolset, leading to increased productivity.
  • Legacy codebase requirements: The code needs to consume or be consumed by other platforms and code that limit choice.
  • Platform limitations: The code has to run in a specific environment with its own limitations.

In security operations, as in all operations, uniformity is key to effectively manage at scale. It is far easier to manage an environment if you know that every platform is identical; you don’t need to investigate each problem like a unique snowflake. Uniformity also lowers the total cost of ownership.

»Unachievable Mandates

But the reasons listed above for choosing languages and frameworks are legitimate. And each platform brings its own implementation of cryptographic algorithms. These crypto libraries mostly offer the same functionality but are implemented independently. So, while the Security team might be able to dictate standards, there will always be critical exceptions that cannot be changed. The result is cryptographic sprawl.

The Security team also mandates behaviors in the environment, such as:

  • Encryption is required on the wire
  • Sensitive data will be hashed
  • Digital signatures will be used to validate payloads

Some of those exceptions that developers require might use technology so old that they simply can’t perform the cryptographic functions that security mandates. Typically, it’s those mission-critical legacy projects that you just can’t get off the network and everyone is terrified to change.

Do you trust HMAC signature verification in PowerShell 1.0 on Windows 2008 or in Perl on Red Hat Enterprise Linux 5? Can the crypto library for Python 2.7 perform a SHA3 hash? When the chosen code library can’t meet encryption mandates, developers are sometimes tempted to build their own cryptographic solution. But developers rolling their own cryptography is as bad as none at all. This means that for some, the security mandates may be unachievable.

»The Solution - Centralizing Cryptography

So how can you tackle cryptographic sprawl and unachievable mandates? How can you lower the total cost of ownership for cryptography?

Specifically, how do you:

  • Reduce the time and effort required for the management of cryptography
  • Reduce the risk of exposure for cryptographic keys
  • Maintain cryptographic standards and governance
  • Offer modern cryptographic functionality to all workloads

The solution is to centralize and standardize cryptographic services on an accessible, language-agnostic platform. HashiCorp Vault is a popular option for doing this. For many organizations, it has become their platform for providing cryptographic services to their developers centrally, as an IT service.

What does it mean to deliver encryption as a service (EaaS)? Rather than have developers use the native cryptographic capabilities on their platform of choice, cryptographic functions are published in centralized Vault REST APIs managed by security architects. Vault serves a centralized collection of policy-driven cryptographic services that enforce corporate governance and security best practices and are accessible by all application platforms.

Developers can use these service APIs to:

  • Encrypt data and decrypt ciphertext
  • Generate certificates backed by an organizational certificate authority (CA)
  • Tokenize data
  • Create hashes
  • Generate digital signatures

The diagram below illustrates this workflow:

Multiple languages and frameworks can use encryption as a service.

»Let Developers Do What They Do Best

Application developers are not security experts. They should not have to make decisions about cryptography: Which hashing algorithm to use? What key length for a certificate or an encryption key? How do you build an HMAC signature? Developers will either spend development time researching solutions or they’ll take a guess; neither is a good choice.

When you centralize cryptographic functions with Vault, developers engage with cryptography at a higher level. Instead of “encrypt this text with x algorithm and y key and protect the key,” they just have to write simpler code to say “encrypt this text.” The developer doesn’t have to fill in any blanks. They just write the domain code that produces value for the business, reducing time to value. They leave security to the experts, reducing risk.

»Standards Are Set by Security

As hashing and encryption algorithms age, they are invariably broken. One day SHA-1 is the standard hashing algorithm, and the next day it should never be used. Standardization that keeps up with changes in the security landscape is needed to ensure secure operations.

The Security team needs to define those standards, both to stay up to date and to enforce compliance obligations. By centralizing cryptographic functionality using EaaS on Vault, standards are defined by Security personnel, developers are given self-service workflows to consume those best practices without having to know the details, and compliance auditing is made easier.

»Smaller Blast Radius

Key management is a problem in encryption: How do applications share symmetric keys? Where are those keys kept? Once in production, who has access to the platform where the keys reside? Are the keys getting caught in backups? And what is the lifecycle of the keys? Are they rotated? It is dangerous to leave the key lifecycle in the hands of application developers.

Too often, application developers are expected to reinvent the wheel regarding security. Rather than expect every application developer to know about and implement key security, key rotation, and rewrapping, it is easier to centralize cryptography with Vault. In Vault’s EaaS, cryptographic keys are maintained with Vault itself, never to be exposed to developers. There are no insecure keys on edge devices, reducing cryptographic sprawl.

»Reduced Cost of Maintenance

The cost of maintenance is greatly reduced by centralizing cryptographic functions on Vault. The work required to mitigate the deficient Java library discussed above is non-existent in an EaaS environment. HashiCorp is maintaining the Vault platform and security personnel are choosing which algorithms to expose to developers. When all developers use Vault’s centralized service for cryptography, the need to manage and maintain cryptographic libraries for different language runtimes across the enterprise is significantly reduced.

Routine maintenance is simplified as well. Tasks that should be done with regular frequency, like key rotation, can be difficult without centralization. By storing the keys in the platform, Vault also centralizes key maintenance allowing for a regular schedule of rotation and easy rewrapping. The total cost of ownership of cryptography is lowered.

»Modern Cryptography for Legacy Platforms

What good are standards if everyone in the organization can’t meet them, especially in security? Code running on legacy platforms with older crypto libraries won’t be able to meet newer cryptographic standards that the security team mandates.

While security and platform organizations work to replace these systems, Vault EaaS can help make cryptographic standards attainable for legacy code. Vault frees developers of their reliance on the native crypto libraries and provides a platform-agnostic REST API for cryptographic functions. This opens a path to modern cryptography for legacy platforms and runtimes in many use cases, meaning developers are then able to meet the organization’s cryptographic mandates.

»Cryptography for All

Security is not just about intrusion detection and patching. Cryptographic security standards are essential to maintaining a secure, compliant environment. Maintaining cryptographic standards in the enterprise traditionally is fraught with challenges: different runtimes and platforms, developer education, and a rapidly changing security landscape.

Centralizing cryptographic functions through Vault’s encryption as a service functionality lowers the cost of ownership, centralizes best practices, makes auditing easier, and makes modern cryptography available to all developers.

Sign up for the latest HashiCorp news