Related Resources

FISMA further emphasizes the importance of continuously monitoring information system security by requiring agencies to conduct assessments of security controls at a risk-defined frequency. The CMS ARS states that CMS information systems must define, develop, disseminate, review, and update its Risk Assessment documentation at least once every three years or whenever a significant change has occurred. This includes a formal, documented system security/privacy package that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and formal, documented processes and procedures to facilitate the implementation of the policy and associated controls.

Policy

Policy delineates the security management structure, clearly assigns security responsibilities, and lays the foundation necessary to reliably measure progress, compliance, and direction to all CMS employees, contractors, and any individual who receives authorization to access CMS information technology (IT) systems or systems maintained on behalf of CMS to assure the confidentiality, integrity, and availability of CMS information and information systems.

Information Systems Security and Privacy Policy (IS2P2)

The CMS IS2P2 defines the framework and policy under which CMS protects and controls access to CMS information and information systems in compliance with the Department of Human and Health Services (HHS) policy, federal law, and regulations. This policy requires all CMS stakeholders to implement adequate information security and privacy safeguards to protect all CMS's sensitive information.

The policies contained within the CMS IS2P2 assist in satisfying the requirements for controls that require CMS to create a policy and associated procedures related to information systems.

The dynamic nature of information security and privacy disciplines and the constant need for assessing risk across the CMS environment can result in gaps in policy, outside of the routine policy review cycle. The CMS Policy Framework includes the option to issue a CIO Directive to address these types of gaps in CMS policy by providing guidance to CMS stakeholders while a policy is being developed, updated, cleared, and approved.

Chief Information Officer (CIO) Directives

The CMS Chief Information Officer (CIO), the CMS Chief Information Security Officer (CISO), and the CMS Senior Official for Privacy (SOP) jointly develop and maintain the CMS IS2P2. The CIO delegates authority and responsibility to specific organizations and officials within CMS to develop and administer defined aspects of the CMS Information Security and Privacy Program as appropriate.

Standards

Standards define both functional and assurance requirements within the CMS security and privacy environment. CMS policy is executed with the requirements prescribed in standards with the objective of enabling consistency across the CMS environment. The CMS environment includes users, networks, devices, all software, processes, information in storage or transit, applications, services, and systems that can be connected directly or indirectly to networks. These components are responsible for meeting and complying with the security and privacy baseline defined in policy and further prescribed in standards. The parameters and thresholds for policy implementation are built into the CMS standards, and provide a foundation for the procedural guidance provided by the Program Guide series.

Secrets Management

A secret is a digital authentication credential. Secrets are individually named sets of sensitive information, and address a broad spectrum of secure data. Secrets need to be protected against unauthorized disclosure, and all keys need to be protected against modification, tempering, deletion and disclosure. There are different types of secrets, including:

Secrets management refers to the tools and methods for managing digital authentication credentials (secrets), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.

Passwords and keys are some of the most broadly used and important tools your organization has for authenticating applications and users and providing them with access to sensitive systems, services, and information. Because secrets have to be transmitted securely, secrets management must account for and mitigate the risks to these secrets, both in transit and at rest.

Note – Root access keys should be protected at all costs and deleted if possible. A bad actor may shut down servers, delete data, create and destroy users, or any other API capability with the root user’s key. For this reason, CMS highly recommends that root access key should not be in use or should be disabled if already in use. CMS also recommends keeping the root user’s credentials safe and private. Do not share them with other employees or contractors. It is also advisable to activate Multi Factor Authentication (MFA) for the root account to protect it even if the password leaks. Also, access and secret access keys should only be developed at a user level, and never at a root level.

The security objectives (Confidentiality, Integrity and Availability) should always be protected in regards to secrets management. The Federal Information Processing Standards (FIPS) Publication 199 defines three levels of potential impact on organizations or individuals (low, moderate, high) should there be a breach of security (i.e., a loss of confidentiality, integrity, or availability) and has additional examples on the impact of loss of one or more of the security objectives.

Key Management

Key management refers to managing cryptographic keys within a cryptosystem. The term “cryptosystem” is shorthand for “cryptographic system” and refers to a computer system that employs cryptography, a method of protecting information and communications through the use of codes so that only those for whom the information is intended can read and process it.

Cryptosystems deal with generating, exchanging, storing, using and replacing keys as needed at the user level.

The security of the cryptosystem is dependent upon successful key management. Proper management ensures a key stays safe throughout its lifecycle, from generation and use to storing and deletion.

Cryptographic Keys

Cryptography is used to secure communications over networks, to protect information stored in databases, and for many other critical applications. Cryptographic keys play an important part in the operation of cryptography.

With effective cryptographic key management, data that is encrypted can still be protected even in the event of a breach, since encrypted data cannot be decrypted without the right keys. Proper usage of encryption and key management will assist an organization’s efforts to protect their data. NIST SP 800-57 Recommendations for Key Management (Part 1, Revision 5) provides an updated guideline for general cryptographic key management.

At CMS, mechanisms are employed to:

At CMS, cryptographic protection applies to both portable storage devices (e.g., USB memory sticks, CDs, digital video disks, external/removable hard disk drives) and mobile devices with storage capability (e.g., smart phones, tablets, E-readers). This applies to all digital assets like application software, Data Stores (Such as databases and file systems), Cloud Service, and Software As a Service.

When cryptographic mechanisms are needed, CMS information systems use encryption products that have been validated under the Cryptographic Module Validation Program to confirm compliance with Federal Information Processing Standards (FIPS) 140-2 in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

Key Management Concepts

Key Management Phases

Pre-Operational PhaseOperational PhasePost-Operational PhaseDestroyed Phase

According to NIST SP 800-57 Recommendation for Key Management: Part 1 - General in Section 8, there are four phases of key management:

  1. Pre-operational phase: The keying material is not yet available for normal cryptographic operations. Keys may not yet be generated or are in the pre-activation state. System or enterprise attributes are established during this phase as well.
  2. Operational phase: The keying material is available and in normal use. Keys are in the active or suspended state. Keys in the active state may be designated as protect only, process only, or both protect and process; keys in the suspended state can be used for processing only.
  3. Post-operational phase: The keying material is no longer in normal use, but access to the keying material is possible, and the keying material may be used for processing protected information. Keys are in the deactivated or compromised states. Keys in the post-operational phase may be in an archive.
  4. Destroyed phase: Keys are no longer available. Records of their existence may or may not have been deleted. Keys are in the destroyed state. Although the keys themselves may have been destroyed, the key’s metadata (e.g., key name, type, cryptoperiod, and usage period) may be retained. A cryptoperiod is the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect.

Key Establishment

Key establishment is the process that results in the sharing of a key between two or more entities. This process could be by a manual distribution, by using automated key-transport or key agreement mechanisms, or by key derivation using an already-shared key between or among those entities. Key establishment processes include the creation of a key. Key establishment techniques and issues are discussed in Section 5.3 of NIST SP 800-175B Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms.

Key Management Functions

Roles and responsibilities need to be defined for the CMS management of at least the following functions:

Cryptographic Key Management Systems (CKMS)

The term cryptographic key management system (CKMS) refers to the framework and services that provide for the generation, establishment, control, accounting, and destruction of cryptographic keys and associated management information.

It includes all elements (hardware, software, other equipment, and documentation); facilities; personnel; procedures; standards; and information products that form the system that establishes, manages, and supports cryptographic products and services for end entities.

A CKMS may handle symmetric keys, asymmetric keys or both. Key management policies, practice statements, and specifications should identify common CKMS elements and suggest functions of and relationships among the organizational elements responsible for the management and use of cryptographic keys.

NIST SP 800-152 contains requirements for the design, implementation, and procurement of a CKMS for the CMS organization. A key management system can be designed to provide services for a single individual (e.g., in a personal data-storage system), an organization (e.g., in a secure Virtual Private Network (VPN) for intraoffice communications), or a large complex of organizations (e.g., in secure communications for the U.S. Government).

Key Management Planning

According to NIST SP.800-57 Part 2 Revision 1, CMS organizations are required by statutory and administrative rules and guidelines to protect the confidentiality and integrity of their sensitive information and processes. Federal agencies are required to determine a FIPS 200 impact level (i.e., Low, Moderate or High) based on the security categories defined in FIPS 199. The security categories are based on the potential impact on an organization if certain events occur that jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals.

CMS encourages Application Development Organizations (ADOs) to utilize software solutions (both on premises and in the Cloud) that help with the creation, identification, management, retrieval, rotation, and removal of keys - especially when these products help ADOs to better comply with CMS key management policy and its requirements.

CMS organizations also need to define their security objectives for storing and/or communicating their sensitive information. These objectives may include the following:

The development of new cryptographic systems, including CKMS, should ideally be conducted following the processes described in NIST SP 800-160 Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. However, in many cases, systems that rely on cryptographic protection are already being used. Where such systems are being augmented or otherwise modified, security/privacy planning is still required, but the NIST SP 800-160 processes will need to be abridged or otherwise adapted because of legacy constraints. CMS organizations must still select NIST SP 800-53, based on ARS 5.0 Control Catalog, security/privacy controls based on system design, operational characteristics, and FIPS 199 impact levels.

Key management planning should involve the following steps:

  1. An appropriate key management architecture is selected based on the available cryptographic mechanisms and objectives. Section 2.3 of NIST SP 800-57 Part. 2 Revision 1 provides examples of architectures to be considered.
  2. A Key Management Specification is developed for each cryptographic product to be used in the system. When developing a Key Management Specification for a cryptographic product, the unique key management products and services needed from the CKMS to support the operation of the cryptographic product must be defined. The specification of cryptographic mechanisms, including key management functions, should consider the CMS organization’s resource limitations and procedural environment. If a Key Management Plan already exists for a CMS organization, the Key Management Specification needs to be in conformance with the CKMS Security Policy. The CKMS Practice Statement should support both the CKMS Security Policy and the Key Management Specification.
  3. Based on the Key Management Plan, a CKMS Security Policy (CKMS SP) is developed that documents the decisions made in developing the Key Management Plan. A CKMS SP is a set of rules that are established to describe the goals, responsibilities, and overall requirements for the management of cryptographic keying material throughout the entire key lifecycle.
  4. A CKMS may be operated by the organization owning the information to be protected, or may be operated by another organization (e.g., under contract). The organization operating the CKMS develops a CKMS Practice Statement (CKMS PS). A CKMS PS specifies how key management procedures and techniques are used to enforce the CKMS SP.

Key Strength

CMS organizations should consider the following best practices:

Public Key Infrastructure

Public key infrastructure (PKI), as stated in NIST Special Publication 800-32: Introduction to Public Key Technology and the Federal PKI Infrastructure, is the combination of software, encryption technologies, and services that enables enterprises to protect the security of their communications and business transactions on networks. PKI integrates digital certificates, public key cryptography, and certification authorities (CA) into a complete enterprise-wide network security architecture.

All public key certificates used at CMS are issued in accordance with Federal PKI policy and validated to the Federal PKI trust anchor when being used for user signing, encrypting purposes, authentication, and authorization.

The CA is responsible for issuing a public key certificate for each identity, confirming that the identity has the appropriate credentials. Note - certification authority (CA) is similar to a notary. The CA confirms the identities of parties sending and receiving electronic payments or other communications.

At CMS, various Certificate Authority requests are available and processed through the Infrastructure and User Services Group - Division of Operations Management (IUSG-DOM).

There are two ways to submit a CA request for a certificate:

Note: Only users with a CMS USER ID who have access to or VPN to the CMS Network will be able to login to the Agency Solution for Customer Support (ASCS). If you do not have a CMS USER ID, see option #2 below to submit an email request.

For inquiries on the type of certificate to request, contact the CMS - DOMSSLCert mailbox at DOMSSLCert@cms.hhs.gov for assistance.

Key Usage

Per NIST SP 800-57 Part 1 Revision 5: Recommendation for Key Management, a single key should be used for only one purpose (e.g., encryption, integrity authentication, key wrapping, random bit generation, or digital signatures).

There are several reasons for this:

This recommendation permits the use of a private key-transport or key-agreement key to generate a digital signature for the following special case: When requesting the (initial) certificate for a static key-establishment key that was generated as specified in FIPS 186-5, the corresponding private key may be used to sign the certificate request.

Key Management Lifecycle Best Practices

Generation

Cryptographic keys should be generated within cryptographic modules with at least a FIPS 140-2 compliance. For explanatory purposes, consider the cryptographic module in which a key is generated to be the key-generating module.

Any random value required by the key-generating module should be generated within that module; that is, the Random Bit Generator that generates the random value should be implemented within cryptographic modules with at least a FIPS 140-2 compliance that generates the key.

Hardware cryptographic modules are preferred over software cryptographic modules for protection.

Use/Distribution

The generated keys should be transported (when necessary) using secure channels and should be used by their associated cryptographic algorithm within at least a FIPS 140-2 compliant cryptographic module. For additional detail for the recommendations in this section refer to NIST Special Publication 800-133.

Keys or secrets should be shared out of band and should never be sent with or alongside the data the secrets or keys they are protecting. Also, secrets shared out-of-band should be protected and not stored somewhere that can be easily compromised (like on a piece of paper on a user’s desk). Out of band sharing of keys should be deleted or destroyed immediately after use.

ADOs should also consider using a Diffie-Hellman algorithm like Secure-Remote Procedure Call (S-RPC) for the sharing of keys when out of band sharing is not a viable option. Note - The Diffie–Hellman (DH) Algorithm is a key-exchange protocol that enables two parties communicating over public channel to establish a mutual secret without it being transmitted over the Internet. DH enables the two to use a public key to encrypt and decrypt their conversation or data using symmetric cryptography.

Examples of how keys can be shared included:

ADOs should document the method being used for the business or system owner. ADOs are also encouraged to use TLS Version 1.2 or 1.3 encryption standards for Data-in-transit.

Storage

Escrow and Backup

Data that has been encrypted with lost cryptographic keys will never be recovered. Therefore, it is essential that the application incorporate a secure key backup capability, especially for applications that support data-at-rest encryption for long-term data stores.

When backing up keys, ensure that the database that is used to store the keys is encrypted using at least a FIPS 140-2 validated module. It is sometimes useful to escrow key material for use in investigations and for re-provisioning of key material to users in the event that the key is lost or corrupted.

Never escrow keys used for performing digital signatures, but consider the need to escrow keys that support encryption. Oftentimes, escrow can be performed by the Certificate Authority (CA) or key management system that provisions certificates and keys, however in some instances separate APIs must be implemented to allow the system to perform the escrow for the application.

Accountability and Audit

Accountability involves the identification of those that have access to, or control of, cryptographic keys throughout their lifecycles. Accountability can be an effective tool to help prevent key compromises and to reduce the impact of compromises once they are detected.

At a minimum, the key management system should account for all individuals who are able to view plaintext cryptographic keys.

In addition, more sophisticated key-management systems may account for all individuals authorized to access or control any cryptographic keys, whether in plaintext or ciphertext form.

Accountability provides three significant advantages:

Certain principles have been found to be useful in enforcing the accountability of cryptographic keys. These principles might not apply to all systems or all types of keys.

Some of the principles that apply to long-term keys controlled by humans include:

New technology developments and attacks should be taken into consideration. On a more frequent basis, the actions of the humans that use, operate, and maintain the system should be reviewed to verify that the humans continue to follow established security/privacy procedures.

Strong cryptographic systems can be compromised by lax and inappropriate human actions. Highly unusual events should be noted and reviewed as possible indicators of attempted attacks on the system.

Accountability and Audit ensures the security objectives (Confidentiality, Integrity and Availability) are maintained. Effective integrity can be maintained if ADOs incorporate logging and provide for audit trails so we can track who used keys or secrets, for what purpose, etc.

Integrity of the keys supports non-repudiation.

Key Rotation

Key rotation provides several benefits, which are not limited to:

For symmetric encryption, CMS organizations should configure automation key rotation by setting a key rotation period and starting time when key is created.

For asymmetric encryption, CMS organizations should always manually rotate keys, because the new public key must be distributed before the key pair can be used.

Recommended minimum frequency of key rotation – Annually.

Note - The rotation schedule can be based on either the key's age or the number or volume of messages encrypted with a key version. NIST SP 800-57 Recommendation for Key Management describes cryptoperiods as a factor in determining an appropriate period for rotation.

If responsible personnel have indications that keys have been compromised, they should manually rotate the keys and re-encrypt data that was encrypted by the compromised keys as soon as possible. To re-encrypt data, download the old data, decrypt it with the old key, encrypt the old data using the new key, and then re-upload the re-encrypted data.

CMS recommends Online Certificate Status Protocol (OCSP) over Certificate Lifecycle Management (CLM) because there can be latencies in the system where CLM may not have the most up to date revocations.

Key Revocation

According to NIST SP 800-57 Part 2 Recommendation for Key Management: Part 2 – Best Practices for Key Management Organizations, symmetric keys are often revoked by the use of Compromised Key Lists (CKLs). Certificate Revocation Lists (CRLs) are commonly used to revoke public key certificates, thus revoking the private key corresponding to the public key in the certificate. Regardless of whether symmetric or asymmetric keys are used, a means of revoking keys is recommended.

This CMS guide will use the term revoked key notification (RKN) to refer to a mechanism to revoke keys. An RKN may include the revocation reason and an indication of when the revocation was requested. The inclusion of the revocation reason can be useful in risk decisions regarding the information that was received or stored using those keys.

A key may also be suspended from use for a variety of reasons, such as an unknown status of the key or due to the key owner being temporarily unavailable (e.g., the key owner is on extended leave). In the case of a certificate suspension, the intent is to suspend the use of the public key included in the certificate (e.g., to not verify digital signatures or establish keys while the use of the certificate is suspended). This may be communicated to relying parties as an “on hold” revocation reason code in a CRL and in an OCSP response. The certificate may later be revoked (e.g., a compromise of the private key corresponding to the public key in the certificate was confirmed) or the certificate may be reactivated (e.g., the key has not been compromised or the owner returned to work).

Compromise of Keys

Key compromise occurs when the protective mechanisms for the key fail (e.g., the confidentiality, integrity, or association of the key to its owner fail;) and the key can no longer be trusted to provide the required security. It is the responsibility of an owner of a private or secret key to protect the confidentiality of that key. Reporting a possible key compromise is the responsibility of anyone suspecting that a key has been compromised (e.g., the key’s owner or an entity that observes that the data protected by that key has been compromised).

When a key is compromised, all use of the key to apply cryptographic protection to information (e.g., compute a digital signature or encrypt information) should cease, and the compromised key should be revoked.

Guidelines to Minimize the Likelihood of a Key Compromise