# 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.

### 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)**