Business Rules for Key and Secrets Management
KSM Business Rules
BR-KSM-1: KSM Auditing Must Be Enabled and Connected to CMS Logging Infrastructure
KSM systems must be configured with full auditing enabled, ensuring that all access to secrets and keys is recorded in tamper-proof logs.
Related CMS ARS Security Controls include: AU-2 - Event Logging.
Rationale:
One of the key advantages of using a KSM is to obtain a clear history of who accessed what secrets and when. A KSM audit log gives this history. The KSM audit log should be connected via CMS enterprise logging tools to the CMS log management infrastructure.
BR-KSM-2: KSM Must Use RBAC with Separate Roles by CMS Application Environment
KSM must be configured with separate credentials for each CMS application environment (Development, Test, Implementation, and Production).
Related CMS ARS Security Controls include:
Rationale:
By segmenting secrets and credentials across environment boundaries, CMS reduces the likelihood that credentials may leak and be used out of context. This reduces the risk of accidental or malicious use.
BR-KSM-3: Ensure the KSM Has Sufficient Availability for Your Applications
KSM should provide sufficiently robust availability to avoid any constraints on applications from accessing key resources like databases and API-based services.
Related CMS ARS Security Controls include: CP-2 - Contingency Plan, CP-7(3) - Priority of Service, and PL-8 - Security and Privacy Architectures.
Rationale:
Given the critical role that the KSM plays in an application, a KSM can be a single point of failure for an application. Inability to obtain credentials reliably can lead to service disruption. If necessary, it may be necessary to operate multiple KSM instances to offer sufficient availability for all applications.
BR-KSM-4: Audit Logs for Credential Leaks
It is possible to leave debugging statements in place in software that cause a leak of credentials into logs. Automated scans can also be performed to search for logging statements that reference known fields containing secrets.
Related CMS ARS Security Controls include: AU-2 - Event Logging, and AU-3 - Content of Audit Records.
Rationale:
It is a common mistake to log credentials to audit logs. Even with a KSM, it is possible to log credentials that could be used to compromise systems, including the KSM. To mitigate this risk, perform code reviews on logging statements to prevent such occurrences.
KSM Recommended Practices
RP-KSM-1: Applications Should Use a KSM to Manage Keys and Secrets
Configure CMS applications to use KSM whenever possible as opposed to custom solutions.
Related CMS ARS Security Controls include:
Rationale:
Persistent data files that contain secrets create both ongoing maintenance overhead and security vulnerabilities. File encryption alone does not constitute a secrets management solution. Alternative approaches using files, environment variables, UNIX pipes, and others are not as comprehensive, secure, or scalable as a KSM. Using alternatives often leads to one-off solutions that might be appropriate for one application but will not scale across the organization, leading to training and data management problems.
RP-KSM-2: Configure Applications to Use Dynamic Credentials
Instead of static credentials, use dynamic credentials managed by the KSM to provide access.
Related CMS ARS Security Controls include:
Rationale:
Dynamic credentials are automatically rotated and managed by the KSM. This renders them only valid for short periods and sometimes only once (depending on the configuration), This makes a credential less likely to be used maliciously.
RP-KSM-3: Consider Credential Injection into VM Images during Startup
Some VM managers and clouds allow for credential injection to occur during VM startup. This has the advantage of not requiring VMs to request credentials. Instead, this guarantees that a VM receives only those secrets.
Related CMS ARS Security Controls include:
Rationale:
This recommended practice guarantees that a VM receive only the credentials injected during startup.