Common Challenges with Key Management: Security (Part 3 of 6)

Image credit: Photo by Chunlea Ju on Unsplash

The Importance of Security in Key Management Solutions

The primary purpose of encryption is to protect the confidentiality and integrity of encrypted data. However, this protection relies upon the security of the keys used by the encryption workflow. Anyone with access to the encryption keys can decrypt the data (eliminating the protections that encryption offers) and generate valid signatures for fake or modified data.

As a result, key management systems must strike a careful balance between usability and security. On the one hand, certain applications and users have legitimate reasons to access the encrypted data, which means that they must have access to the encryption keys. On the other hand, if these legitimate accounts are compromised by an attacker, they can place the security of the data at risk.

Common Key Management Mistakes

The security of encrypted data depends on the protection of the encryption keys. Two of the most common mistakes that jeopardize key and data security are assigning excessive permissions to accounts and insecurely storing authentication information.

Excessive Permissions

The principle of least privilege states that an account’s permissions should be limited to the bare minimum required for it to perform its duties. This makes sense because, if an account is compromised (which is increasingly common due to the use of weak or reused passwords), then the damage that can be caused by the compromised account is minimized.

Since some users and applications have a legitimate need to access certain data, it is logical that they have access to the corresponding keys. However, many organizations provision accounts with excessive privileges, providing them with access to data that they don’t require or assigning them unnecessary permissions for certain resources (like write access when only read access is required). This places the organization’s data at risk because any compromised accounts can have a much greater impact on data security.

Insecure Storage

Applications commonly require access to a number of different resources. This could include databases, other applications, cloud-based infrastructure, and more.

One of the most common methods of managing access tokens, passwords, and other authentication information for these applications is to embed them in the code or in a configuration file deployed alongside the code. This makes it easy for the application to import the necessary information and use it in its requests.

The issue with this approach is that these keys can be revealed in a number of different ways. An attacker with access to the application or its source code could read authentication information from it. Alternatively, if the application or configuration is uploaded to GitHub or another public version control system, the authentication data could be publicly exposed, and scanners exist for identifying and collecting this information from these public repositories.

When possible, authentication information should be stored in a Hardware Security Module (HSM). An HSM has integrated protections that help to prevent disclosure or leakage of confidential information, especially cryptographic keys.

In the event that this is not possible, keys should be designed using the principles of least privilege and separation of duties. Each application with access to data should have a unique key with certain permissions assigned to it that is stored in a configuration file (which should not be included in GitHub repositories). This helps to ensure that, in the event of a breach, the impact of the breach is minimized and that the leaked key can be replaced rapidly with minimal impact on operations.

Case Study: Capital One

In August 2019, Capital One was the victim of a highly-publicized data breach. The attack leaked the sensitive information of about 100 million Americans.

The data breach was made possible by a misconfiguration in the web application firewall (WAF) protecting the organization’s Amazon Web Services (AWS)-based cloud infrastructure. The WAF was vulnerable to a server-side request forgery attack that enabled an attacker to force it to send requests to the organization’s cloud-based applications on the attacker’s behalf.

This was problematic because the WAF was accidentally granted an excessive level of permissions on the financial institution’s AWS deployment. Since the WAF had full read access to all data stored in the AWS cloud, the attacker was able to access and exfiltrate a great deal of sensitive information.

Improving Key Management Security with Ubiq

Ubiq offers a simple process for developers to assign and manage credentials for their applications. Using the Ubiq Software as a Service (SaaS) web interface, a developer can create a new application and generate unique read-only encryption keys for all other applications that require access to its data.

This ensures that least privilege and separation of duties are enforced and enables the developer to easily track and manage the use of each of the created keys. To see the Ubiq Platform in action, check out this demo.

Read next: Common Challenges with Key Management: Availability (Part 4 of 6)