diff --git a/Security/authentication_guidance.md b/Security/authentication_guidance.md new file mode 100644 index 0000000..f42ecae --- /dev/null +++ b/Security/authentication_guidance.md @@ -0,0 +1,173 @@ +# Authentication Guidance & Hardening (Comprehensive, EU‑Aligned) + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +This document provides practical guidance and examples for implementing the Authentication Policy across [Organization] systems. +It includes detailed examples for assurance levels, distinction of methods (passwords vs PINs vs biometrics), special cases (BitLocker, local admin accounts), out‑of‑band methods, central vs. local authentication, and reauthentication. + +--- + +## 2. Method Identification Guide (What is it? Where does the secret live?) +Use this section to classify any method you encounter. + +### 2.1 Memorized Secrets (Passwords) +- **What it is:** A human‑chosen **password** sent to a **verifier** (server) that stores only a **hash**. +- **Where the secret lives:** In the **user’s memory**; verifier stores a **hashed verifier**. +- **Factor category:** **Something you know**. +- **Typical AAL:** **AAL1** alone; **AAL2** when combined with another factor. +- **Examples:** Account password for SSO, VPN, app logins. +- **Notes:** Allow paste/managers; use passphrases; blocklist screening; no composition rules; no periodic expiry. + +### 2.2 Activation Secrets (PINs that unlock local authenticators) +- **What it is:** A **PIN** used to unlock a **local cryptographic key** (TPM, smart card, FIDO2). The PIN itself is **never transmitted** to a server. +- **Where the secret lives:** **On the device/token** only (e.g., TPM/smart‑card); verifier never sees it. +- **Factor category:** **Something you know** (used locally), combined with **something you have** (device/token). +- **Typical AAL:** Contributes to **AAL2** or **AAL3** depending on hardware and protocol. +- **Examples and distinctions:** + - **Windows Hello PIN** → unlocks TPM‑bound private key on **that device only**; **not** the same as the account password. + - **Smart‑card PIN** → unlocks card’s private key; used with certificate‑based login. + - **FIDO2 PIN** → unlocks the authenticator to perform WebAuthn challenges. + - **Mobile device screen PIN** → unlocks the phone; when used with a bound authenticator app, it protects the **OOB** channel. + - **BitLocker pre‑boot PIN** → unlocks the disk key (see BitLocker section). +- **Minimums:** PIN **≥4**, **should be ≥6**; local throttling/lockout required. + +### 2.3 Biometrics (Local unlock only) +- **What it is:** **Fingerprint/face/iris** used to unlock a **local key** (e.g., Windows Hello, phone biometric). +- **Where the secret lives:** Biometric template stays on the device/TPM/secure enclave. +- **Factor category:** **Something you are** (local unlock). +- **Typical AAL:** Part of **AAL2/AAL3** when combined with hardware key; **never** as sole factor. + +### 2.4 Out‑of‑Band (OOB) Methods +- **What it is:** A second, **separate channel** (e.g., mobile app) to approve login. +- **Where the secret lives:** Bound to the **mobile device/app**; approvals sent over encrypted channel. +- **Factor category:** Typically **something you have** (the device), sometimes plus its **PIN/biometric** (something you know/are). +- **Typical AAL:** **AAL2** when **device‑bound and encrypted**. +- **Examples:** Push approvals; **QR‑code sign‑in** with Microsoft Authenticator. +- **Not permitted as primary:** SMS/voice/email (recovery only). + +--- + +## 3. Assurance Levels – Examples & Guidance + +### 🔹 AAL1 (Single Factor) +- **Examples:** + - Password‑only login to low‑risk intranet site + - Local Linux/Windows account with password + - BitLocker with **PIN only** (no TPM) + - Local admin password **without LAPS** +- **Risks:** Phishable/replayable; brute‑forceable. +- **Guidance:** Use only for low‑sensitivity or offline recovery; **not** for remote/external access; plan deprecation. + +### 🔹 AAL2 (Standard MFA) +- **Examples:** + - Password + **TOTP** authenticator app + - Password + **push** approval on a bound device + - Password + **QR‑code** sign‑in with Microsoft Authenticator + - **Smart‑card + PIN** + - **Windows Hello** (TPM‑backed key) + PIN/biometric + - **BitLocker: TPM + PIN** + - Local admin password **with LAPS** (unique per device, rotated) for offline recovery scenarios +- **Risks:** Still phishable (push/QR can be proxied). +- **Guidance:** Default for SaaS, VPN, employee desktops; allow push/QR only when **device‑bound** and **rate‑limited**; enroll **≥2 MFA methods** per user. + +### 🔹 AAL3 (High Assurance) +- **Examples:** + - **FIDO2/WebAuthn hardware** security key + - **PIV/smart‑card** login with crypto challenge + PIN + - **Windows Hello** with biometric unlocking a **TPM‑bound** key used for hardware‑backed auth + - **BitLocker: TPM + PIN + post‑boot FIDO2** login +- **Risks:** Strong phishing and verifier‑impersonation resistance. +- **Guidance:** Required for admins, production, regulated systems; **no OOB**; keys must be **non‑exportable** and hardware‑protected; biometrics only unlock keys. + +--- + +## 4. Central vs. Local Authentication +- **Central (preferred):** IdP/SSO (SAML/OIDC/RADIUS) with consistent policy, logging, and conditional access. +- **Local (supporting/offline):** BitLocker pre‑boot PIN, Windows Hello PIN, Linux root password. +- **Guidance:** Local methods **must** follow length/blocklist rules for memorized secrets and enforce local throttling; prefer TPM/smart‑card integration for higher assurance. + +--- + +## 5. BitLocker Pre‑Boot Authentication (Deep‑dive) +- **TPM only:** Disk key released automatically → **AAL1**. Not acceptable for sensitive data. +- **PIN only (no TPM):** PIN protects disk key → **AAL1**. Use only with compensating **post‑boot MFA** and limited roles. +- **TPM + PIN:** PIN unlocks TPM which releases disk key → **AAL2**. Enterprise baseline for laptops. +- **TPM + PIN + post‑boot FIDO2/smart‑card:** Meets **AAL3** for privileged/regulated systems. +- **Operational requirements:** PIN length **≥6** recommended; enforce lockout/anti‑hammering; maintain recovery key hygiene; test pre‑boot accessibility for users with assistive tech. + +--- + +## 6. Local Administrator Accounts +- **Without LAPS:** Shared/static password → **AAL1 (high risk)**; prohibited except as break‑glass in a vault with approvals and audit. +- **With LAPS:** Unique random password per device, rotated automatically → **AAL1 (mitigated)**; acceptable for offline recovery; retrieval must be logged. +- **Preferred daily admin:** Central privileged accounts with **MFA** (**AAL2/AAL3**). + +--- + +## 7. Reauthentication & Session Management +- **AAL1:** Reauth **≤ 30 days**. +- **AAL2:** Reauth **≤ 24 hours**, inactivity **≤ 1 hour**. +- **AAL3:** Reauth **≤ 12 hours**, inactivity **≤ 15 minutes**. +- **Tips:** Warn prior to expiry; support seamless reauth with device‑bound authenticators. + +--- + +## 8. Password Creation & User Education (Quick Guide) +- Prefer **passphrases** (multiple unrelated words with spaces). +- Avoid personal info, service names, or keyboard patterns. +- Use a **password manager**; unique secret per site/system. +- Expect **blocklist rejection** for weak/compromised choices. +- Do **not** write down passwords in plain sight; if written, store securely. + +--- + +## 9. Quick Comparison Tables + +### 9.1 Method Classification +| Method | What it is | Secret location | Factor(s) | Typical AAL | Notes | +|---|---|---|---|---|---| +| Account **password** | Memorized secret sent to verifier | User memory / verifier stores hash | Know | AAL1 (alone) | Needs blocklist; no composition; no expiry | +| **Windows Hello PIN** | Local PIN to unlock TPM key | Device TPM | Know + Have (device) | AAL2–AAL3* | Device‑specific; not account password | +| **Smart‑card PIN** | Local PIN to unlock card key | Smart‑card | Know + Have | AAL2–AAL3 | Cert‑based login | +| **FIDO2 PIN** | Local PIN to unlock FIDO key | Hardware key | Know + Have | AAL3 | Phishing‑resistant | +| **Biometric** | Local unlock (face/fingerprint) | Device enclave | Are (+ Have) | AAL2–AAL3 | Unlock only; not sole factor | +| **TOTP app** | One‑time code generator | Mobile device | Have (+ Know if app PIN) | AAL2 | Bind device; protect seed | +| **Push/QR OOB** | Encrypted approval channel | Mobile device | Have (+ Know/Are) | AAL2 | Device‑bound & rate‑limited | +| **SMS/voice/email OTP** | Code over PSTN/email | Network/mail | Have? (weak) | Recovery only | Not primary MFA | + +\*Depends on deployment: with hardware‑bound non‑exportable keys and phishing‑resistant protocol usage, Windows Hello deployments can reach AAL3. + +### 9.2 BitLocker Summary +| Mode | AAL | Use Case | Notes | +|---|---|---|---| +| TPM only | AAL1 | Low‑risk fleets | Not for sensitive data | +| PIN only (no TPM) | AAL1 | Legacy/no‑TPM | Must pair with post‑boot MFA | +| TPM + PIN | AAL2 | Enterprise baseline | Enforce ≥6 PIN, anti‑hammering | +| TPM + PIN + post‑boot FIDO2 | AAL3 | Admin/regulated | Strongest posture | + +--- + +## 10. Hardening Checklist +✅ Map systems to **AAL1–AAL3** +✅ Enforce **password** rules (length, 64‑char support, Unicode, blocklist, no composition) +✅ Enroll **≥2 MFA methods** per user (primary + backup) +✅ Prefer **FIDO2/smart‑card** for AAL3; ban **OOB** at AAL3 +✅ Permit only **device‑bound encrypted** push/QR; **ban SMS/email/voice** as primary +✅ Enforce **LAPS** on all Windows endpoints; ban shared local admin passwords +✅ Configure **rate‑limiting** for online guesses; local anti‑hammering for PINs +✅ Implement **session timeouts** per AAL; warn users pre‑expiry +✅ Audit **MFA resets**, **local admin retrievals**, and **failed logins** + +--- + +## 11. 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 diff --git a/Security/authentication_policy.md b/Security/authentication_policy.md new file mode 100644 index 0000000..da8993e --- /dev/null +++ b/Security/authentication_policy.md @@ -0,0 +1,93 @@ +# 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. + +### 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. + +### 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. + +### 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. + +--- + +## 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