cqrenet/policies
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
policies/Security/authentication_policy.md

5.8 KiB
Raw Permalink Blame History

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