13 KiB
13 KiB
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) |
4. Data Sensitivity Classification (TLP)
[Organization] classifies information using the FIRST.org Traffic Light Protocol (TLP) 2.0 — full scheme and handling requirements defined in the Data Classification & Handling Policy, 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 |