Initial commit

02-standards/secrets-management-standard.md

@@ -0,0 +1,68 @@
+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] |