69 lines
2.9 KiB
Markdown
69 lines
2.9 KiB
Markdown
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] |
|