A Key Management System (KMS) must be designed in a manner that supports the goals of each organization using the KMS. The aim of a security policy is to provide a secure working environment for the organization by establishing required security measures, protocols and controls.
It consists of the rules and requirements by an organization that governs the use of its information and services, and the security level and strategies for protecting the Confidentiality, Integrity, and Availability (CIA) of its information.
In complex systems policies may be broken down into sub-polices or may have different policies covering different applications or categories of information.
Information Security Policy
An organization’s Information Security Policy is created to support and enforce parts of the organization’s Information Management Policy. It specifies rules for collecting, protecting, and distributing valuable and sensitive information in both paper and electronic form.
The inputs to the Information Security Policy include, the Information Management Policy specifications, the potential threats to the security of the organization’s information, and the risks involved with the unauthorized disclosure, modification, and destruction of the information.
The outputs of the Information Security Policy layer include information sensitivity
levels (low, medium, and high) assigned to various categories of information and high-level rules for protecting the information.
KMS Security Policy
The Information Security Policy may also be used to create a KMS Security Policy that specifies the use and protection of cryptographic keys, algorithms, and mechanisms that provide confidentiality and integrity protection of the keys and their metadata for the organization.
A KMS Security Policy needs to establish and specify rules for protecting the confidentiality, integrity, availability, and source authentication of all cryptographic keys and metadata used by the System. These rules cover the entire key lifecycle, including when they are operational, stored, and transported.
It may include the selection of all cryptographic mechanisms and cryptographic protocols that can be used by the KMS. It needs to be consistent with the higher-level policies of the organization. The KMS designer should create security features in the design of the system and these should be well documented. This can be considered to form the designer’s initial KMS Security Policy.
1. State how and when the features are used to support the KMS Security Policy.
2. Include Key Security Policy, specifying the protections applied to each key type and its metadata
3. Include Key and Metadata Retention Policy, specifying the length of time that keys and metadata are to be retained. The Key and Metadata Retention Policy should be based on the sensitivity of the information that the keys and metadata protect.
4. Specify how any automated portions of the KMS Security Policy are expressed in an unambiguous tabular form or a formal language (such as, XML or ASN.1), such that an automated security system in the KMS can enforce them
The organization may work with the KMS designer or the KMS service provider to develop a modified KMS Security Policy, based on the initial KMS Security Policy developed by the designer. The KMS Security policy should be documented, so that the persons responsible for maintaining the policy can easily understand the policy and correctly perform their roles and responsibilities. Ultimately, it is the responsibility of the organizations that use the KMS to assure that the KMS design adequately supports, or can be configured to support, the KMS Security Policy.
References and Further Reading
- NIST Special Publication 800-130: A Framework for Designing Cryptograhic Key Management Systems (2013), by E.Barker, M.Smid, D.Branstad and S.Chokhani
- 10 Tips for a Cryptographic Key Management System in the Banking Industry (2015) by Ashiq J.A.
- Cryptographic Key Management Policy: A Layered Approach (2015) by James H. Reinholm
- Image: "security", courtesy of DaveBleasdale, Flickr (CC BY 2.0)