2.9 KiB
Title: Secrets Management Standard Document ID: [STD-SECRETS-001] Version: 0.1 Draft Status: Draft Owner: CISO (Paul Jenkins) Approver: CISO (Paul Jenkins) Classification: Internal Effective date: [DD Month YYYY] Review date: [DD Month YYYY]
Secrets Management Standard
Purpose
This standard defines the minimum requirements for creating, storing, using, rotating, and retiring secrets and related sensitive authentication material.
Scope
This standard applies to passwords, API keys, tokens, certificates, private keys, connection strings, and other sensitive credentials used within the ISMS scope.
Mandatory Requirements
Secrets must be stored only in approved controlled locations or mechanisms appropriate to their sensitivity and usage pattern.
Secrets must not be hard-coded into source code, infrastructure definitions, build scripts, container images, documentation, or collaboration tools unless explicitly justified and approved.
Access to secrets must be limited to authorised users, services, and processes based on least privilege.
Secrets must be rotated, revoked, or replaced when compromise is suspected, when personnel with access depart, when system design changes require it, or at defined intervals where appropriate.
Shared secrets should be avoided where more traceable identity-based mechanisms are available.
Secrets used by automation, cloud services, Kubernetes workloads, and CI/CD pipelines must be managed in a way that reduces exposure through logs, configuration files, and debugging output.
Test or non-production secrets must not be reused for production purposes.
Implementation Guidance
BlackDice should favour centrally governed and auditable secret storage and retrieval mechanisms over manual distribution or local storage.
Secret lifecycle management should cover generation, approval, distribution, rotation, revocation, replacement, and disposal.
For containerised and cloud-native workloads, secret injection methods should minimise persistence in images, repositories, and long-lived static files.
Monitoring should detect potentially exposed secrets in repositories, build artefacts, or operational records where feasible.
Roles and Responsibilities
- [Role] must define the approved secrets management approach.
- System owners must ensure secrets used by their services are controlled appropriately.
- Engineering and operational teams must handle secrets according to this standard and report exposure promptly.
Exceptions
Exceptions must be documented, risk-assessed, approved, and reviewed through the exception process.
Related Documents
- Cryptography and Key Management Policy
- Secure Development Policy
- CI/CD Security Standard
- Kubernetes Security Standard
Version Control
| Version | Date | Description of Change | Author |
|---|---|---|---|
| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |