86 lines
6.0 KiB
Markdown
86 lines
6.0 KiB
Markdown
# Secrets & Key Management Policy
|
|
|
|
**Document owner:** [Owner/Role]
|
|
**Approved by:** [Steering Committee / CISO]
|
|
**Effective date:** [YYYY-MM-DD]
|
|
**Review cadence:** [Annually]
|
|
|
|
---
|
|
|
|
## 1. Purpose & Scope
|
|
This policy establishes mandatory requirements for the generation, storage, access, rotation, and retirement of secrets and cryptographic keys — API keys, service credentials, TLS certificates, encryption keys, and signing keys — across [Organization] systems. It applies to all employees, contractors, and systems that create or consume secrets.
|
|
|
|
This policy is the **canonical source** for cryptographic algorithm/parameter standards and kill-chain secret handling referenced elsewhere in this repository (e.g., [Password Policy §2.13](password_policy_generic.md), [Password Policy (M365/AD) §2.13](password_policy_m365_ad.md)).
|
|
|
|
---
|
|
|
|
## 2. Policy Statements
|
|
|
|
### 2.1 Secret Inventory & Ownership
|
|
- Every secret **must** have a named owner and a documented purpose.
|
|
- An inventory of active secrets **must** be maintained in the approved secret manager; secrets with no identifiable owner **must** be rotated and reassigned or retired within 30 days of discovery.
|
|
|
|
### 2.2 Storage
|
|
- Secrets **must** be stored only in an approved secret manager, key vault, or HSM.
|
|
- Secrets **must not** be stored in source code, config files committed to version control, tickets, chat messages, or shared documents.
|
|
- Any secret found outside an approved store **must** be treated as compromised: rotated immediately, not just relocated.
|
|
|
|
### 2.3 Cryptographic Standards
|
|
| Purpose | Approved | Minimum Parameters |
|
|
|---|---|---|
|
|
| Password hashing | Argon2id (preferred), bcrypt, PBKDF2 | Argon2id: memory ≥19 MiB, iterations ≥2; per-credential unique salt ≥128 bits |
|
|
| Symmetric encryption at rest | AES-256-GCM | Unique IV/nonce per operation |
|
|
| Transport encryption | TLS 1.2 minimum, TLS 1.3 preferred | Modern cipher suites only; disable TLS 1.0/1.1 |
|
|
| Asymmetric keys | RSA ≥3072-bit, ECDSA P-256 or higher | — |
|
|
| Signing | Ed25519 or ECDSA P-256+ | — |
|
|
| Legacy/weak algorithms (MD5, SHA-1 for integrity, DES/3DES, RC4, NTLMv1) | **Prohibited** for new use; existing use tracked as a remediation item | — |
|
|
|
|
### 2.4 Access Control
|
|
- Access to secrets **must** follow least privilege and, where supported, just-in-time elevation.
|
|
- All secret retrieval **must** be logged (who, what, when).
|
|
- Human access to production secrets **should** be exceptional and time-bound; services **must** authenticate via managed identity/certificate rather than a retrieved static secret where the platform supports it.
|
|
- **AI Agent (Autonomous) accounts** (per [Authentication Policy §3.1](authentication_policy.md)) **must not** hold a static long-lived credential equivalent to a service account password. Agent credentials **must** be short-lived and scoped to the task/session, expiring automatically at task completion — a compromised agent session should not yield a standing key an attacker can reuse after the session ends.
|
|
|
|
### 2.5 Kill-Chain Secrets (Barbell Principle)
|
|
Secrets gating existential systems — PKI/CA root passphrases, backup/DR encryption master keys, break-glass vault master credentials, HSM activation secrets — **must** receive protection disproportionate to ordinary secrets:
|
|
- **Split-knowledge / dual control**: no single person holds the complete secret.
|
|
- Physical or HSM-backed storage, not a general-purpose secret manager.
|
|
- Real-time alerting on access; access requires a second approver.
|
|
- Do **not** spread equivalent extra effort across low-value secrets — concentrate paranoia here; keep §2.2–§2.4 lean everywhere else.
|
|
|
|
### 2.6 Rotation & Expiry
|
|
| Secret Type | Rotation Cadence |
|
|
|---|---|
|
|
| Human-facing passwords | Incident-driven only (no scheduled expiry, per [Password Policy §2.3](password_policy_generic.md)) |
|
|
| Service account secrets / API keys | Automated, ≤90 days |
|
|
| TLS certificates | Before expiry, automated renewal preferred |
|
|
| Kill-chain secrets (§2.5) | Annually, or immediately after any custodian change |
|
|
| Any secret suspected compromised | Immediately |
|
|
|
|
### 2.7 Secret Compromise Response
|
|
- A suspected or confirmed secret compromise **must** trigger immediate rotation, revocation of derived sessions/tokens, and a structural post-mortem per [Authentication Policy §2.12](authentication_policy.md).
|
|
|
|
### 2.8 Enforcement
|
|
- Violations **may** result in disciplinary action or revocation of access.
|
|
- Secrets discovered in version control history **must** be rotated even after removal from the current commit — history does not un-leak a secret.
|
|
|
|
---
|
|
|
|
## 3. Antifragility Alignment
|
|
This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**.
|
|
|
|
| Pillar | Applied In | How |
|
|
|---|---|---|
|
|
| **1. Structural Decoupling** | §2.4 | Services authenticate via managed identity/certificate rather than a portable static secret where possible — removes a class of dependency entirely |
|
|
| **2. Optionality Preservation** | §2.3 | Standardized, non-proprietary algorithms (AES, Argon2id, ECDSA) avoid lock-in to a single vendor's crypto scheme |
|
|
| **3. Stress-to-Signal Conversion** | §2.7 | Every compromised secret forces a structural post-mortem, not just a quiet rotation |
|
|
| **4. Sovereign Intelligence** | §2.1 | Named owner per secret; inventory is owned and current, not tribal knowledge of "whoever set it up" |
|
|
| **5. Asymmetric Payoff Design (Barbell)** | §2.5 | Split-knowledge/HSM concentrated on kill-chain secrets; ordinary secrets get the lean baseline — nothing moderate spread everywhere |
|
|
|
|
---
|
|
|
|
## 4. References
|
|
- **[NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)**
|
|
- **[OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)**
|
|
- **[OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)**
|