“Ability” – Best Practices For Encryption Key Management

Data encryption is a significant component of an organization’s response to emerging security threats and regulatory compliance mandates. Most of the organizations have already implemented controls by encrypting data, but find that managing the associated encryption keys throughout their lifecycle quickly becomes a problem.

Improper key management practices also create a new set of security vulnerabilities and risks making important data inaccessible to authorized users who need it. In a nutshell, encryption is easy but key management is challenging.  If you lose an encryption key, you effectively lose access to your data.  If you fail to control and audit access to the keys, you will fail your next audit. If you store the keys with data, encryption is useless and extremely vulnerable.

A unified data protection strategy to protect sensitive data wherever it lives along with a centralized key management solution that can create and manage keys securely provides peace of mind by meeting stringent standards and audit/compliances, is the way out to survive with constantly increasing requirements to encrypt nearly everything.

We’ve seen recent corporate and government attempts to circumvent encryption. But imagine a similar situation within your organization where the keys to important data are being managed by an individual who is out sick or was injured in a car accident on the way home – even worse. The problem of managing keys in silos is not only with unauthorized distribution, but also with getting a key to an authorized user, especially in cases where the key owner is not available for some reason.

The solution is to use centralized key management techniques and never leave keys to the discretion of one individual.  It will never lock you out of your own data again.

Centralized key management looks like a hub-and-spoke architecture for distributed key management. A clustered centralized key manager storing millions of key objects securely exposing various standard protocols that allows encryption and decryption clients to exist throughout the enterprise network.  Key management components and protocols are easily deployed to these clients and integrated with the local encryption applications. Once integrated, encryption and decryption of the data is performed locally, minimizing the risk of a network or single point of failure avoiding a large impact on the overall data security posture. The key manager must manage the generation, secure storage, rotation, export, and retirement of the keys used for encryption at the spokes, providing interoperability and scalability.

Here are six best practices we’ve labelled “ability factors” to consider for an encryption solution and its centralized key manager:

  1. “Compliantability”

The standards that define the security requirements around hardware and software encryption systems is Federal Information Processing Standard (FIPS) 140-2, the most widely used. It has different profiles for different types of systems (hardware vs. software) and four different security levels. Also, FIPS certification may only apply to a component of a system, not the entire cryptographic boundary. Although a fully vetted and certified system is always desired. Additionally, consider if you also need to meet Common Criteria (ISO/IEC 15408) standards. Common Criteria isn’t encryption specific, but a general standard for validating the functional and assurance security requirements and may be required for certain regulations or contracts with partners or customers.

The National Institute of Standards and Technology (NIST) recommends AES as the highest standard for encryption since 2001. AES supports multiple modes of encryption, and three key sizes for encryption: 128-bit, 192-bit, and 256-bit keys (recommended). Any encryption used to protect data-at-rest should use AES standard encryption.

Payment Card Industry Data Security Standard (PCI DSS) also mandates that the keys must be conveyed or transmitted in a secure manner. The best approach to meet the mandate is to involve Public/Private keys to protect the tunnel in-between key manager and its clients.  A key manager that supports enhanced Public Key Cryptography along with an internal Certificate Authority (CA) to avoid any external dependencies is preferred.

  1. “Availability”

Security and compliance requirements define data centers that are more compartmentalized. Organizations are more distributed, with multiple data centers and even more applications and services that span them. There are two models that can be defined.

  1. Centralized Cluster: In this model, the key manager is positioned in a central location accessible from wherever it might be needed. Typically, organizations select this option when they want to maintain a single key manager.  It was a common practice in traditional data centers, but isn’t well-suited for the compartmentalized ones we see today.
  2. Distributed Clusters:  In this model, key managers are distributed in different physical locations syncing data across them. This is the best model for supporting multiple data centers across multiple physical locations and geographies, if needed. This can also be used within a single segregated data center for redundancy.  You may be able to use a mix of physical and virtual key managers, although I don’t recommend this due to the potential for memory compromises exposing your crown jewels.
  1. “Scalability”

Custom application of key managers are becoming more compartmentalized and distributed as we move away from monolithic designs into increasingly distributed, and sometimes short-lived, services. This increases demand to issue and manage keys at wider scale without compromising security, for example distributing data encryption keys to temporary data containers. A centralized key management solution is supposed to scale to support the ever-growing needs of the enterprise.  It is desirable to sustain thousands of clients and millions of keys for a truly enterprise scale solution.

  1. “Interoperability”

A well-designed central key management service is relatively futile if it can’t manage all your encryption keys. The key managers are known to enforce vendor specific protocols for key exchange which could be a good idea if the vendor have end-to-end ecosystem of storage solutions, but to avoid vendor lock-in, an industry standard support is vital.

Well known vendor neutral key management/exchange standards that define how systems exchange and communicate keys are

  • OASIS KMIP (Key Management Interoperability Protocol)
  • PKCS #11 (Public Key Cryptography Standard)

KMIP is extensively used in key managers for data-at-rest encryption solutions, whereas PKCS #11 for HSMs (Hardware Security Modules), but there is a lot of overlap.

Other standards, like Microsoft’s CAPI and Java Cryptography Extension (JCE) apply to encryption and key management for very particular programming languages and applications.

  1. “Manageability”

We have focused on requirements to meet evolving data center architectures, different deployment scenarios and interoperability; but traditional user/system management practices still apply:

  1. Role Based Access Control: Implementing multiple levels of administrators and their roles ideally require defined duties such as a backup administrator who should be restricted to his role only.
  2. Multiple Credentials: With stringent environments, the key management solutions live on dual access control authorities for operations directly impacting key security and other major administrative functions.
  3. InfoSec, Data Owners or Infrastructure: Another question generally raised by the senior management is – Who should be managing these boxes? The InfoSec team who know nothing about the data/process being encrypted or the Data Owners or the Infrastructure team? Unfortunately, there is no one-size-fits-all answer to that question.
    1. It is a good idea to separate the keys from data and distribute the responsibilities. If the Data Owners are also key admins, then who is watching the watchman?
    2. With segregated duties, do we have enough admins ready to take part into the process and take the ownership?
    3. Infrastructure team who can better manage the platform like any other servers?
    4. Dual access control is a good idea, but the solution and key manager supports it?
    5. How about Dev, Prod and QA systems?

    Many users and senior managers have struggled with those questions. Here are a few guidelines:

    1. The Infrastructure team cannot be a good candidate to owe key management process due to physical access to the data.
    2. The Data Owner sounds like a bad candidate again as they can access the data and convert to plain-text without any additional permissions.
    3. Information Security is the best team to own the key managers and the keys. This way, we will be able to enforce separation of duties and avoid collusion.
    4. Enable audit logs, including purpose: Logs will be mandatory for compliance, but are vital to maintain security of the keys. Purpose codes (or equivalent metadata if supported) confirms why a key accessed, instead of just by who and when.
    5. If dual control is enabled, then InfoSec and Data Owners is a good idea
  1. “Performanceability”

Another aspect of managing the encryption ecosystem is to understand the impact on performance with added complexity and platform dependence. Newer technologies (for example, HPE Secure Encryption) are available in the market that implements encryption at hardware layer being transparent to the applications and even to the underlying operating system making it platform agnostic. Technologies also support in-place encryption of data instead of migrating it around.

Key rotation is another important aspect of key management. The encryption solution must support rekey activities to be compliant with regulatory bodies and to overcome any catastrophic situation. Rekey should not require decrypting a set of encrypted data and then re-encrypting it when the keys expire or are changed. A solution that supports key hierarchy is desired so that the higher-level keys can be changed keeping the data intact.

Conclusion

Data managed by organizations is growing by a tremendous rate and so are the complexities around managing it and keeping it secure with distributed environments. Application demands for performance and security while compliance requirements are adopting new patterns such as letting business units manage their own assets, to meet increasing agility pressure and be competitive in the market.  Encryption is the most effective way out to keep our data secure while maintaining separation of duties, enforcing compliance, and auditing access to keep auditors happy.

Encryption requires key management and centralized is the best approach among the ones available. It is impossible to manage individual keys at the enterprise scale, especially for regulated environments. It used to be an option when interoperability was still a dream, but industry standards like KMIP and others are driving us to reduce the friction and provide a single pane of glass towards centralized key management.

Learn more about HPE Enterprise Secure Key Management (ESKM).

Author:
Manish Upasani
Data Security Solution Architect

Leave a Reply

Your email address will not be published. Required fields are marked *