The Importance of Availability in Key Management Solutions
An organization’s sensitive data is often vital to its ability to operate and compete in the marketplace. Whether its customer PII or proprietary research and development (R&D) data, exposure of this information could destroy an organization’s reputation and competitive advantage.
As a result, many organizations attempt to protect this information using a variety of different safeguards. Common protections include the use of encryption and access controls to deny unauthorized users the ability to access (and potentially modify) this data. The stronger these protections, the lower the organization’s risk of a data breach. Not all organizations have a tailored and efficient key management system.
However, the organization also needs to be able to access this data to pursue its daily operations. If legitimate users and applications cannot rapidly access the data that they require, then the business’s productivity and profitability will suffer. The availability of this sensitive data - to legitimate users - is essential to the health of the business.
Common Key Management Mistakes
If poorly designed and implemented, a key management system may sacrifice availability for security or vice versa. As a result, many organizations opt to maximize availability at the expense of security. Some common examples of mistakes that organizations make that sacrifice security for availability include the use of embedded and hardcoded keys, weak key usage, and the failure to implement proper redundancy for HSMs.
One of the simplest methods for ensuring that an application has access to encryption keys or authentication information is embedding the keys in the application itself. Storing them within variables enables them to be easily accessed wherever needed within the application.
This approach creates a couple of different issues. The first is that it makes the sensitive data more vulnerable to exposure. Access to the application’s source code (via a source code repository like GitHub) or using reverse engineering tools like IDA Pro (which automatically extracts strings and locates their usage within a compiled binary) allows an attacker to easily find these keys.
After the keys have been exposed, the use of embedded or hardcoded keys makes incident response more difficult. If keys are built into the application itself, replacing them with a new version requires deploying an updated version of the application to all users. In general, most organizations are slow to apply patches, meaning that the developer needs to choose between breaking functionality for users of an outdated version or leaving the data exposed until all users update.
Most organizations have a number of different systems, and some employees and administrators may require access to many of them. The complexity of keeping track of all of this encryption and authentication data can lead employees to adopt insecure key management practices.
One common way to increase availability is to use weak passwords which are used to gain access systems or are used to derive a cryptographic key from, or reuse keys across multiple systems. Basing a password off of the system it is used for (like MySQL123! or P0stgr3) or using the same password for multiple systems (without a secure solution like Single Sign On) makes it easier for employees to access these systems.
However, this increased access comes at the cost of security. Password crackers commonly include dictionaries of commonly used passwords, which dramatically decreases the time it requires to crack them. Once the password is cracked, an attacker can use it to gain access to the target systems to steal data or pursue other goals (such as data encryption with ransomware).
Lack of Redundancy for HSMs
For sensitive information, best practices mandate that all encryption and authentication information be stored within a Hardware Security Module (HSM). HSMs are designed to incorporate built-in protections and processing power so that all cryptographic operations are performed on the HSM. This helps to protect any sensitive information stored on the HSM because it never leaves the secure enclave.
Using a single HSM creates a single point of failure within an organization’s environment because any applications relying on the HSM are unusable if the HSM is offline. As a result, industry standards and best practices recommend deploying three HSMs (see diagram below) in a configuration that offers high-availability to minimize the probability of an outage or reduced performance.
Due to the expense and knowledge required to implement this design, many organizations take an alternative approach. Whether using a single HSM or insecurely storing keys, this puts at risk the availability and security of the service.
Case Study: Starbucks
In late 2019, Starbucks accidentally exposed one of their API keys. This key was discovered in a public GitHub repository created by Starbucks developers.
The potential impact of this API key exposure was significant because the key was tied to Starbucks’s JumpCloud account on AWS. This is AWS’s version of Active Directory, and an attacker with access to this key could have taken over Starbucks’s AWS account, run commands on its AWS servers, and add or remove users on its AWS account.
The leaked key was discovered and ethically reported to Starbucks by an independent security researcher. In response, Starbucks awarded this researcher a bug bounty of $4,000, the maximum bounty possible on its bug bounty program during that year.
Improving Key Availability with Ubiq
A key management system needs to be able to ensure that encryption keys and authentication data are continuously available to its applications and users. This includes redundancy to ensure that outages of a single key management system do not bring down an entire network.
Ubiq’s API-based developer platform offers a user-friendly encryption and key management solution with built-in redundancy and high availability. To learn more about the Ubiq Platform, check out this demo.