cqrenet/policies
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add AGENTS.md guidance and expand Security policy library

Browse Source
This commit is contained in:
Tomas Kracmar
2026-07-07 16:17:53 +02:00
parent 4ae6607c3d
commit 8d26180b8e
30 changed files with 1468 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Security/authentication_policy.md
+65 -5
View File
@@ -30,6 +30,7 @@ This policy supports GDPR principles of **data protection by design** and **acco
- **AAL1:** Single‑factor authentication. Permitted only for low‑sensitivity internal apps or offline scenarios.
- **AAL2:** Multi‑factor authentication combining two categories (e.g., password + OTP app, push, QR code OOB). Required for employee logins, SaaS, and external‑facing systems.
- **AAL3:** High‑assurance, hardware‑backed MFA (e.g., FIDO2, smartcards). Required for privileged/admin access, production, and regulated data systems.
- **Kill‑chain tier:** Systems whose compromise would be existential — the IdP itself, PKI/CA roots, backup and recovery infrastructure, the break‑glass vault — **must** be AAL3 with no exceptions. Protection is concentrated disproportionately here (barbell principle); do not spend equivalent effort hardening low‑value systems at the other end.
### 2.2 Memorized Secrets (Passwords)
- **Length:**
@@ -55,6 +56,7 @@ This policy supports GDPR principles of **data protection by design** and **acco
- **Allowed:** FIDO2/WebAuthn keys; smartcards with PIN; authenticator apps (TOTP, push, **QR‑code sign‑in**); device‑bound biometrics (unlock only).
- **Fallback only:** SMS/voice OTPs.
- **Prohibited:** Email OTP; KBA/security questions.
- **Vendor diversity:** Each user **must** enroll **≥2 MFA methods spanning at least two independent implementations** (e.g., a FIDO2 hardware key plus an authenticator app from a different vendor than the primary IdP's own). A single MFA vendor outage or compromise **must not** remove all of a user's factors.
### 2.5 Out‑of‑Band (OOB) Methods
- OOB authenticators **must** use **encrypted, device‑bound** channels (e.g., push or QR‑code flows) and **must** implement rate‑limiting.
@@ -63,6 +65,7 @@ This policy supports GDPR principles of **data protection by design** and **acco
### 2.6 Central vs. Local Authentication
- **Central IdP/SSO** **must** be the default for enterprise access.
- **Local authentication** (device‑only) may be used for **pre‑boot**, **offline**, or **recovery**, but **must** meet the applicable AAL and other requirements in this policy.
- **Graceful degradation:** The central IdP **must** have a documented, tested fallback authentication path for outage scenarios. An IdP with no fallback is a single point of failure for the entire organization; the fallback **must** be exercised at least annually.
### 2.7 BitLocker Pre‑Boot Authentication
- **TPM only:** AAL1; not acceptable for sensitive systems.
@@ -84,10 +87,67 @@ This policy supports GDPR principles of **data protection by design** and **acco
- Violations **may** result in disciplinary action or revocation of access.
- Non‑compliant systems **must** be remediated or formally excepted with CISO approval.
### 2.11 Vendor Exit Readiness
- [Organization] **must** maintain a documented, current migration path off its primary IdP/MFA vendor, executable within **90 days** without loss of authentication capability.
- This path **must** be reviewed **annually** and after any material change to the IdP/MFA vendor relationship.
### 2.12 Incident‑Driven Structural Learning
- Every MFA bypass, credential‑stuffing event exceeding threshold, break‑glass invocation, or IdP outage **must** trigger a **blameless post‑mortem** producing **at least one structural change** (policy, architecture, or control) within **30 days**.
- Structural findings **must** be tracked to closure; recurring root causes without a structural fix are a policy violation in themselves.
### 2.13 Break‑Glass Drills
- Break‑glass procedures **must** be exercised at least **quarterly**, in a non‑production or scoped environment first, with a **pre‑agreed abort condition** and **bounded blast radius**.
- Untested break‑glass access **is treated as broken access** — an unexercised emergency path is a liability, not a control.
### 2.14 Ownership & Documentation
- Authentication architecture — IdP configuration, Conditional Access/policy rules, break‑glass procedure, MFA vendor configuration — **must** be documented in **owned, version‑controlled form** with a **named accountable owner**.
- This knowledge **must not** exist solely as tribal knowledge held by one individual; loss of that individual **must not** mean loss of the organization's ability to operate or rebuild its authentication systems.
---
## 3. References
- NIST SP 800‑63B (Digital Identity Guidelines, 2023 update)
- CIS Controls v8.1 (Controls 5 & 6)
- ENISA Guidelines on Identity and Access Management
- OWASP Authentication Cheat Sheet
## 3. Account Type Requirements
[Organization] recognizes the account types below. Each carries a **minimum** AAL; where an account also accesses data at a given TLP sensitivity (§4), the **higher** of the two minimums applies.
| Account Type | Examples | Minimum AAL | MFA / Authenticator | Reauth / Inactivity | Special Controls |
|---|---|---|---|---|---|
| **Standard User** | Employee, contractor daily-use account | AAL2 | Password + TOTP/push/FIDO2 | ≤24h / ≤1h | Standard joiner/mover/leaver process |
| **Privileged / Admin** | Domain admin, cloud admin, DBA, security admin | AAL3 | FIDO2/WebAuthn or smart‑card; no OOB | ≤12h / ≤15min | Separate from daily-use account; JIT/PIM elevation; fully logged |
| **Service / Machine / API** | Automation, CI/CD, application-to-application | N/A (non-interactive) | Certificate, managed identity, or vaulted key | N/A | No interactive login; automated rotation; no shared use across services |
| **Break-glass / Emergency** | Emergency domain admin, DR access | AAL2 minimum, AAL3 preferred | Vaulted credential, MFA required at checkout | Time-bound, single-use | Sealed in PAM vault; real-time alert on checkout; mandatory post-use audit and credential rotation |
| **Third-party / Vendor** | MSP, external support, auditor with standing access | AAL2 (AAL3 if privileged or TLP:AMBER+STRICT/RED data) | Federated SSO preferred; MFA mandatory | Per role, per §2.9 | Time-bound access; contractually mandated MFA; offboarding SLA ≤ 24h from contract end |
| **Guest / External Collaborator** | Partner, contractor without standing access | AAL2 | Federated identity or authenticator app | Session-bound to engagement | Requires internal sponsor; no standing/persistent access |
| **Shared / Generic / System** | Legacy shared logins, kiosk accounts | **Prohibited** unless individually attributable | N/A | N/A | Requires documented exception, compensating controls, and CISO approval per §4 (Exceptions) |
---
## 4. Data Sensitivity Classification (TLP)
[Organization] classifies information using the [FIRST.org Traffic Light Protocol (TLP) 2.0](https://www.first.org/tlp/) — full scheme and handling requirements defined in the [Data Classification & Handling Policy](data_classification_policy.md), the canonical source. Systems and accounts **must** meet the minimum AAL for the most sensitive TLP-classified data they can access; where this exceeds the account type's minimum in §3, the **higher** value governs.
| TLP Level | Meaning | Minimum AAL | Additional Controls |
|---|---|---|---|
| **TLP:CLEAR** | Disclosure not limited (public) | AAL1 (org default AAL2 baseline per §2.1 still applies to logins) | None beyond baseline |
| **TLP:GREEN** | Limited disclosure, community-wide | AAL2 | Standard MFA |
| **TLP:AMBER** | Limited disclosure, organization + need-to-know | AAL2 (AAL3 for privileged/admin access) | Access logged; least privilege |
| **TLP:AMBER+STRICT** | Limited disclosure, organization only, no further sharing | AAL3 | Phishing-resistant MFA mandatory; no OOB; quarterly access review |
| **TLP:RED** | Named recipients only | AAL3 | Phishing-resistant MFA mandatory; no OOB; per-access approval; full audit trail; break-glass accounts excluded from standing access |
---
## 5. Antifragility Alignment
This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. Traceability from pillar to clause:
| Pillar | Applied In | How |
|---|---|---|
| **1. Structural Decoupling** | §2.6, §2.11 | Documented IdP fallback path; 90-day vendor exit readiness — no single IdP/MFA vendor can hold the org hostage |
| **2. Optionality Preservation** | §2.4, §2.9 | ≥2 MFA methods from independent implementations per user; ≥2 methods enrolled preserves the right to authenticate if one path fails |
| **3. Stress-to-Signal Conversion** | §2.12, §2.13 | Every MFA bypass/outage/break-glass event forces a structural fix within 30 days; break-glass drilled quarterly with bounded blast radius and abort condition |
| **4. Sovereign Intelligence** | §2.14 | IdP config, Conditional Access rules, break-glass procedure documented and owned — not tribal knowledge held by one admin |
| **5. Asymmetric Payoff Design (Barbell)** | §2.1 (kill-chain tier), §3 (Account Type table) | Paranoid AAL3 concentrated on kill-chain systems (IdP, PKI roots, backup infra, break-glass vault) and privileged accounts; standard AAL2 baseline elsewhere — nothing moderate in the middle |
---
## 6. References
- [NIST SP 800‑63B (Digital Identity Guidelines, 2023 update)](https://pages.nist.gov/800-63-3/sp800-63b.html)
- [CIS Controls v8.1 (Controls 5 & 6)](https://www.cisecurity.org/controls/v8-1)
- [ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)
- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)