165 lines
16 KiB
Markdown
165 lines
16 KiB
Markdown
# Authentication Policy (Comprehensive, EU‑Aligned)
|
||
|
||
**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 authentication across [Organization] systems, including:
|
||
- Passwords and memorized secrets
|
||
- Multi‑factor authentication (MFA)
|
||
- Authenticator Assurance Levels (AALs)
|
||
- Out‑of‑band (OOB) authentication
|
||
- Central vs. local authentication
|
||
- Special cases (BitLocker, local admin accounts, device/smart‑card/mobile PINs)
|
||
- Session management and reauthentication
|
||
|
||
It is aligned with **NIST SP 800‑63B** (as best practice), **CIS Controls v8.1**, and **ENISA guidance**.
|
||
It applies to all employees, contractors, vendors, and service accounts.
|
||
This policy supports GDPR principles of **data protection by design** and **accountability**.
|
||
|
||
---
|
||
|
||
## 2. Policy Statements
|
||
|
||
### 2.1 Assurance Levels
|
||
- [Organization] **shall** align with Authenticator Assurance Levels (AALs):
|
||
- **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:**
|
||
- **15+ characters** when used as a single factor.
|
||
- **8+ characters** when used only in combination with MFA.
|
||
- Systems **must** allow at least **64 characters**, accept **spaces/Unicode**, and **must not truncate** entered secrets.
|
||
- **Composition:** No mandatory composition rules (no required mixes of upper/lower/digit/symbol).
|
||
- **Screening:** New/changed passwords **must** be screened against **blocklists** of commonly used, expected, or **compromised** passwords (including organization‑specific terms).
|
||
- **Expiration:** **No periodic expiration**. Change **only** upon suspected compromise or policy breach.
|
||
- **Usability:** **Allow paste/autofill** and provide a **“show password”** option. **No password hints** and **no knowledge‑based questions (KBA)**.
|
||
- **Reuse:** Password **must not** match the user’s current or any **of the last 5** passwords (where technically supported).
|
||
- **Rate limiting:** Verifiers **must** throttle online guessing (progressive delays; avoid permanent lockout DoS).
|
||
- **Storage:** Store only **salted, hashed** verifiers using **Argon2id (preferred)**, **bcrypt**, or **PBKDF2** with strong parameters; per‑credential unique salt; optional server‑side **pepper** protected separately.
|
||
- **Transport:** Collect and transmit passwords only over **authenticated, encrypted channels** (TLS 1.2+).
|
||
- **Managers:** Users **should** use an approved **password manager** to generate/store unique passwords.
|
||
|
||
### 2.3 Activation Secrets (Local Unlock PINs/Biometrics)
|
||
- **Definition:** An **activation secret** (e.g., device PIN, Windows Hello PIN, smart‑card PIN, FIDO2 PIN) is used **only to unlock a local authenticator/TPM/smart‑card**. It is **not transmitted** to a server and is **not** a password.
|
||
- **Requirements:** Activation secrets **shall** remain on the device/token; **shall be ≥4 characters** and **should be ≥6**; online guesses **shall** be throttled/limited locally.
|
||
- **Biometrics:** May be used **only** to unlock a device‑bound key and **must not** be the sole authenticator.
|
||
|
||
### 2.4 Acceptable Authenticators
|
||
- **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.
|
||
- **SMS/voice/email** **must not** be used as **primary** MFA. SMS/voice may be used **only** as recovery with risk acceptance.
|
||
|
||
### 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.
|
||
- **PIN only (no TPM):** AAL1; acceptable only with compensating controls.
|
||
- **TPM + PIN:** AAL2; recommended baseline for enterprise laptops.
|
||
- **TPM + PIN + post‑boot FIDO2/smart‑card MFA:** Meets AAL3 for administrative systems.
|
||
|
||
### 2.8 Local Administrator Accounts
|
||
- Local admin accounts **must not** share passwords across devices.
|
||
- **LAPS or equivalent** **must** randomize and rotate local admin passwords.
|
||
- Local admin accounts **must not** be used for daily administration; use **central privileged accounts with MFA** (AAL2/AAL3).
|
||
|
||
### 2.9 Reauthentication & Session Management
|
||
- **AAL1:** Reauthentication **≤ 30 days**.
|
||
- **AAL2:** Reauthentication **≤ 24 hours**, inactivity timeout **≤ 1 hour**.
|
||
- **AAL3:** Reauthentication **≤ 12 hours**, inactivity timeout **≤ 15 minutes**.
|
||
|
||
### 2.10 Enforcement
|
||
- 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. 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) |
|
||
| **AI Agent (Autonomous)** | LLM-based agent, orchestrator, sub-agent, autonomous automation with tool/action access | N/A (credential-based) — governed by §3.1 capability scoping, not AAL alone | Short-lived/session-scoped credential; no static long-lived key | Task-scoped, expires at task completion | See §3.1 — this is not a Service Account with extra steps |
|
||
|
||
### 3.1 AI Agent Identity — Why It's Not a Service Account
|
||
A **Service/Machine account** runs fixed code with an enumerable, static scope: you can audit exactly what it does before granting access. An **AI Agent** decides its action sequence at runtime from a prompt plus whatever tools/data it can reach — the scope is only enumerable as "the union of everything its tools allow," not as a fixed set of API calls. It also typically acts **on behalf of** a human or another agent, and can **spawn sub-agents**, neither of which a service account does. Treat it as a distinct account type with its own control model:
|
||
|
||
- **Capability/tool-scoping is the privilege boundary, not role membership.** Least privilege for an agent means least *tools* and least *data reachable through those tools* — the tool/plugin/MCP-server allow-list **must** be reviewed and approved like any other permission grant (see [Access Control Policy §3.7](access_control_policy.md)).
|
||
- **Delegation chain must be logged end-to-end.** Every agent action **must** log the full chain — invoking human/system → orchestrating agent → sub-agent → tool call → target system — not just "agent X did Y." See [Logging, Monitoring & Retention Policy §2.1](logging_monitoring_policy.md).
|
||
- **No standing autonomous access to the kill-chain tier (§2.1).** Actions touching kill-chain systems **must** require human-in-the-loop approval per action; autonomy is permitted everywhere else within the agent's scoped capabilities. This is the barbell applied to agents.
|
||
- **Sub-agents must not escalate privilege.** A spawned sub-agent's tool/data access **must** be a subset of its parent's — delegation narrows, never widens.
|
||
- **Credentials must be short-lived and session/task-scoped**, per [Secrets & Key Management Policy §2.4](secrets_management_policy.md) — no static long-lived API key standing in for the agent indefinitely, the way a service account password might.
|
||
- **Prompt injection is a modeled threat, not an edge case.** Untrusted content the agent consumes (web pages, documents, tool output, another agent's output) **must** be treated as a potential attacker-controlled input capable of hijacking the agent's actions *within its own legitimate permissions* — a confused-deputy attack, not a credential theft. Mitigations: tool allow-listing, human confirmation gates on high-risk actions, and treating "agent + untrusted content" as a trust-boundary crossing in threat models (see [Secure SDLC Policy §2.1](secure_sdlc_policy.md)).
|
||
|
||
---
|
||
|
||
## 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, §3.1 | IdP config, Conditional Access rules, break-glass procedure documented and owned — not tribal knowledge held by one admin. An autonomous cloud-hosted agent with broad tool access is the sharpest form of the manifest's "AI leak" risk: it doesn't just process your data on infrastructure you don't control, it can **act** on it |
|
||
| **5. Asymmetric Payoff Design (Barbell)** | §2.1 (kill-chain tier), §3 (Account Type table), §3.1 (agent kill-chain gate) | Paranoid AAL3 concentrated on kill-chain systems (IdP, PKI roots, backup infra, break-glass vault) and privileged accounts; standard AAL2 baseline elsewhere. Same logic applied to agents: human-in-the-loop mandatory at the kill-chain boundary, bounded autonomy everywhere else — 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)
|