diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..c897261 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,87 @@ +# Agent Guidance: Organizational Policies Repository + +## Project Overview + +This repository is **not a software project**. It is a documentation repository that serves as the single source of truth for official organizational policies. All content is written in Markdown and version-controlled with Git. + +- **Repository root:** `/Users/avedelphina/Local/policies` +- **Primary language:** English (all documents and metadata are in English) +- **Content format:** Markdown (`.md`) +- **Version control:** Git +- **License / confidentiality:** All content is confidential and for internal organizational use only. All rights reserved. + +The repository currently contains one policy category: + +- **`Security/`** — Information security, authentication, password, and identity-management policies and implementation guidance. + +No application code, build artifacts, package managers, or runtime environments are present. + +## Repository Structure + +``` +. +├── README.md # Human-facing project description and contribution guidelines +├── .gitignore # Ignores .DS_Store only +└── Security/ + ├── authentication_guidance.md # Practical hardening guidance for authentication + ├── authentication_policy.md # Normative authentication policy (AALs, MFA, session management) + ├── password_guidance_generic.md # System-agnostic password implementation guidance + ├── password_guidance_m365_ad.md # Microsoft 365 / AD password guidance (marked as Draft) + ├── password_policy_generic.md # System-agnostic password and authenticator policy + └── password_policy_m365_ad.md # Microsoft 365 / AD password and authenticator policy +``` + +## Technology Stack + +- **Markup:** GitHub-flavored Markdown +- **Tooling:** Plain text editors and Git; no compilers, interpreters, linters, or package managers are configured +- **No build system:** There is no `pyproject.toml`, `package.json`, `Cargo.toml`, `Makefile`, `setup.py`, CI/CD configuration, or equivalent +- **No runtime architecture:** This repository produces human-readable policy documents, not an executable application or service + +## Document Conventions + +When editing or adding policy documents, follow the conventions already established in the existing files: + +1. **Header metadata block** — Begin each policy or guidance document with: + ```markdown + **Document owner:** [Owner/Role] + **Approved by:** [Steering Committee / CISO] + **Effective date:** [YYYY-MM-DD] + **Review cadence:** [Annually] + ``` +2. **Section numbering** — Use decimal heading numbers (`## 1. …`, `### 2.1 …`) for policy documents; guidance documents may use either decimal or bracketed numbers (`## 1) …`). +3. **Organization placeholder** — Use `[Organization]` where the company name should appear. +4. **Normative language** — Policy documents use RFC-style keywords such as **must**, **shall**, **should**, **may**, and **prohibited**. Guidance documents use **should**, **recommend**, and **consider**. +5. **References** — Cite authoritative sources in a final `## References` section. Commonly referenced standards include: + - NIST SP 800-63B (Digital Identity Guidelines) + - CIS Controls v8.1 + - ENISA Digital Identity and Data Protection guidance + - OWASP Authentication Cheat Sheet + - Microsoft Security Baselines for Windows / M365 / AD +6. **Tables and checklists** — Use Markdown tables for matrix requirements (e.g., account type × AAL, TLP sensitivity × AAL) and emoji checkboxes (`✅`) for hardening checklists. +7. **Draft status** — If a document is not yet approved, append `(Draft)` to its title. + +## Build and Test Commands + +There are no build, test, or deploy commands for this repository. Changes are validated through: + +- Markdown rendering preview +- Manual editorial and legal/policy review +- Pull-request review by the policy management team + +## Contribution and Review Workflow + +1. Create a feature branch for any change. +2. Edit or add Markdown policy documents using the conventions above. +3. Open a pull request describing the proposed updates. +4. The policy management team reviews and merges approved changes. + +All contributions must align with organizational goals and legal requirements. Do not commit generated build artifacts, temporary files, or `.DS_Store` files. + +## Security Considerations + +- The repository content itself defines security requirements; treat the files as sensitive organizational records. +- Do not embed secrets, credentials, or private individual data in any Markdown file. +- Keep placeholder fields (`[Owner/Role]`, `[YYYY-MM-DD]`, `[Organization]`) until they are formally populated by the policy owner. +- Maintain consistency across related policies. For example, password length requirements (15 characters single-factor, 8 characters with MFA, 64-character maximum) and MFA baselines should remain aligned between the Authentication Policy, Password Policy (generic), and Password Policy (M365 + AD). +- Any exception to policy requirements must be documented with compensating controls, CISO approval, and a review date not exceeding 12 months. diff --git a/README.md b/README.md index 13326b2..f710b57 100644 --- a/README.md +++ b/README.md @@ -30,4 +30,4 @@ Please ensure that all contributions align with organizational goals and legal r ## Licensing -All content in this repository is licensed under the MIT license. \ No newline at end of file +All content in this repository is confidential and for internal organizational use only. All rights reserved. \ No newline at end of file diff --git a/Security/acceptable_use_guidance.md b/Security/acceptable_use_guidance.md new file mode 100644 index 0000000..79db7d6 --- /dev/null +++ b/Security/acceptable_use_guidance.md @@ -0,0 +1,33 @@ +# Acceptable Use Guidance + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +Implementation guidance for the [Acceptable Use Policy](acceptable_use_policy.md). Applies to all staff and to managers handling exceptions. + +--- + +## 2. Shadow IT / Shadow AI — Practical Detection +- Monitor SaaS discovery via CASB/SSO login patterns (unsanctioned app sign-ins via "Login with Google/Microsoft" are the easiest signal). +- Common shadow-AI entry point: pasting internal docs/code into a public chatbot for "just a quick summary" — treat this as the default failure mode to educate against, not an edge case. +- Provide an approved, low-friction AI tool option so staff aren't forced into shadow use to get work done — a policy with no sanctioned alternative just pushes usage underground. + +## 3. Approval Fast-Path +- Low-risk tools (no data beyond TLP:CLEAR/GREEN touches the tool): lightweight self-service approval with automatic logging. +- Any tool touching TLP:AMBER+: security review required before use, checking for a no-train/no-retain data processing clause. + +## 4. Onboarding Checklist +✅ New hires acknowledge this policy before systems access is granted. +✅ Approved SaaS/AI tool list published and easy to find (not buried in a wiki no one reads). +✅ Reporting channel for suspected phishing/shadow IT is one click away, not a multi-step process. + +--- + +## 5. References +- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)** +- **[CIS Controls v8.1](https://www.cisecurity.org/controls/v8-1)** diff --git a/Security/acceptable_use_policy.md b/Security/acceptable_use_policy.md new file mode 100644 index 0000000..25b7a65 --- /dev/null +++ b/Security/acceptable_use_policy.md @@ -0,0 +1,61 @@ +# Acceptable Use Policy + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +This policy defines acceptable use of [Organization] systems, accounts, and data by all employees, contractors, and vendors with access to those systems. + +--- + +## 2. Policy Statements + +### 2.1 General Use +- Systems and accounts **must** be used primarily for authorized business purposes. +- Incidental personal use is permitted where it does not interfere with duties, consume disproportionate resources, or violate this policy. + +### 2.2 Prohibited Activities +- Unauthorized access to systems or data outside one's role (see [Access Control Policy §3.1](access_control_policy.md)). +- Disabling, bypassing, or circumventing security controls (MFA, endpoint protection, logging) without a documented exception. +- Sharing credentials or allowing account use by another person, including "temporary" sharing for convenience. +- Illegal activity, harassment, or use that damages [Organization]'s reputation. + +### 2.3 Email & Communication +- Business email **must not** be used for unrelated personal accounts of consequence (banking, unrelated business ventures). +- Suspected phishing **must** be reported, not just deleted. + +### 2.4 Cloud Services & Shadow IT +- New SaaS tools, including AI/LLM tools, **must** be approved before use with company data — unsanctioned tools create the "knowledge/AI leak" risk described in the organization's Antifragile Enterprise Manifest (Pillar 4: Sovereign Intelligence): data and reasoning sent to an unapproved third party is cognition the organization no longer controls. +- Approved AI tools **must** be used per any organization-specific data handling addendum; TLP:AMBER+STRICT/RED data (per [Data Classification Policy](data_classification_policy.md)) **must not** be submitted to a cloud AI service without verified contractual no-train/no-retain terms. + +### 2.5 Personal & BYOD Devices +- Personal devices accessing company data **must** meet minimum security baseline (screen lock, encryption, current OS) — full BYOD/MDM requirements are covered in a dedicated device management policy where one exists. + +### 2.6 Monitoring Notice +- [Organization] **may** monitor system and account usage as permitted by applicable law, for security and operational purposes. Users **should** have no expectation of privacy in company systems beyond what law requires. + +### 2.7 Enforcement +- Violations **may** result in disciplinary action, up to and including termination of access or employment. + +--- + +## 3. Antifragility Alignment +This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. + +| Pillar | Applied In | How | +|---|---|---| +| **1. Structural Decoupling** | §2.4 | Approval gate on new SaaS/AI tools prevents unmapped, unmanaged dependencies from silently accumulating | +| **2. Optionality Preservation** | §2.4 | Requiring no-train/no-retain terms before sending sensitive data to a vendor preserves control over that data later | +| **3. Stress-to-Signal Conversion** | §2.3 | Reported phishing (not just deleted) becomes signal that feeds security awareness and control updates | +| **4. Sovereign Intelligence** | §2.4 | This is the pillar's most direct policy expression: shadow AI/cloud use is exactly the "AI leak" the manifest warns about | +| **5. Asymmetric Payoff Design (Barbell)** | §2.4 | Extra scrutiny concentrated on AMBER+STRICT/RED data reaching AI tools; low-sensitivity personal use stays lightly governed | + +--- + +## 4. References +- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)** +- **[CIS Controls v8.1](https://www.cisecurity.org/controls/v8-1)** diff --git a/Security/access_control_guidance.md b/Security/access_control_guidance.md new file mode 100644 index 0000000..bca6dd8 --- /dev/null +++ b/Security/access_control_guidance.md @@ -0,0 +1,43 @@ +# Access Control & Least Privilege Guidance + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +Implementation guidance for the [Access Control & Least Privilege Policy](access_control_policy.md). Applies to IT/IAM, managers, and system/data owners. + +--- + +## 2. Role Design — How To +- Start from job function, not from current access ("what does a Support Engineer need" not "what does Alice currently have" — the latter just codifies drift). +- Use Entra ID/Azure AD groups or equivalent RBAC roles; avoid direct resource ACLs for anything beyond a one-off, time-bound exception. +- Keep the number of distinct roles small — role sprawl is as bad as ad hoc grants; if two roles differ by one permission, question whether they should be one role with a scoped exception. + +## 3. Joiner-Mover-Leaver — Practical Flow +1. **Joiner:** HR system triggers IAM provisioning workflow on start date; access live day 1, not requested ad hoc by the new hire's manager over chat. +2. **Mover:** Role change in HR system triggers automatic review — old role's access **removed**, not left "just in case." +3. **Leaver:** Termination in HR system triggers same-day deprovisioning; involuntary terminations trigger immediate (not end-of-day) revocation, coordinated with the immediate manager. + +## 4. Access Review — Worked Example +| Account Type | Reviewer | What to Check | +|---|---|---| +| Privileged/Admin | Access Owner + manager | Still needed? Still least-privilege scoped? Any dormant admin sessions? | +| Standard User | Manager | Role still matches job function? Any accumulated ad hoc grants to fold into role or revoke? | +| Service Account | System owner | Still in use? Rotation current per [Secrets & Key Management Policy](secrets_management_policy.md)? | + +## 5. Checklist +✅ Joiner-mover-leaver automated from HR system, not manual ticket-only. +✅ Privileged access reviewed quarterly, standard semi-annually. +✅ Separation-of-duties matrix documented for finance/production-deploy roles. +✅ Dormant accounts flagged per [Password Policy §2.11](password_policy_generic.md) (45-day inactivity). +✅ Ad hoc/direct grants logged and swept into the next access review. + +--- + +## 6. References +- **[NIST SP 800-53 Rev. 5 (AC family)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)** +- **[CIS Controls v8.1](https://www.cisecurity.org/controls/v8-1)** diff --git a/Security/access_control_policy.md b/Security/access_control_policy.md new file mode 100644 index 0000000..035bb0b --- /dev/null +++ b/Security/access_control_policy.md @@ -0,0 +1,78 @@ +# Access Control & Least Privilege Policy + +**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 granting, reviewing, and revoking access to [Organization] systems and data, based on least privilege and need-to-know. It applies to all employees, contractors, vendors, and service accounts, and complements the account types defined in [Authentication Policy §3](authentication_policy.md). + +--- + +## 2. Roles & Responsibilities +- **Access Owner (system/data owner):** Approves access requests and grants for their system. +- **Manager:** Approves role-appropriate access for direct reports; initiates leaver/mover requests. +- **IT/IAM:** Provisions, reviews, and revokes access per this policy. + +--- + +## 3. Policy Statements + +### 3.1 Least Privilege & Need-to-Know +- Access **must** be granted at the minimum level required for a person's role. +- Standing access to TLP:AMBER+STRICT/RED data (per [Data Classification Policy](data_classification_policy.md)) **must** be justified and time-bound where feasible; prefer just-in-time elevation. + +### 3.2 Role-Based Access Control +- Access **must** be granted through defined roles mapped to job function, not ad hoc individual grants. +- Direct/ad hoc grants outside a defined role **must** be logged, time-bound, and reviewed at next access review. +- Role definitions **must** be documented and owned (see [Authentication Policy §2.14](authentication_policy.md)). + +### 3.3 Joiner-Mover-Leaver Lifecycle +- **Joiner:** Access provisioned per role on or after start date; no standing access before identity verification completes. +- **Mover:** Access **must** be updated within **5 business days** of a role change; prior role's access **must** be removed, not just supplemented. +- **Leaver:** Access **must** be revoked within **24 hours** of termination (immediately for involuntary termination), consistent with [Vendor Risk Management Policy §3.6](vendor_risk_management_policy.md) for third parties. + +### 3.4 Separation of Duties +- Conflicting duties (e.g., payment initiation and approval, code deployment and production access approval) **must not** be held by the same individual without a documented compensating control. +- A separation-of-duties conflict matrix **must** be maintained for financial and production-critical systems. + +### 3.5 Periodic Access Reviews +| Account Type (per Authentication Policy §3) | Review Cadence | +|---|---| +| Privileged/Admin | Quarterly | +| Standard User | Semi-annually | +| Third-party/Vendor | Per contract term, minimum annually | +| Service/Machine | Annually, plus on owner change | + +- Reviews **must** be performed by the Access Owner, not solely by IT. +- Unreviewed access past the cadence **must** be treated as a finding and escalated. + +### 3.6 Emergency / Break-Glass Access +- Governed by [Authentication Policy §3](authentication_policy.md) (Break-glass account type) and [§2.13](authentication_policy.md) (drills). + +### 3.7 Enforcement +- Violations **may** result in disciplinary action or revocation of access. +- Systems unable to support role-based provisioning or timely revocation **must** be remediated or formally excepted with CISO approval. + +--- + +## 4. Antifragility Alignment +This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. + +| Pillar | Applied In | How | +|---|---|---| +| **1. Structural Decoupling** | §3.2 | Role definitions are documented independent of any single IAM vendor's proprietary grouping model | +| **2. Optionality Preservation** | §3.1 | Just-in-time elevation preferred over standing access — preserves the option to say no without an offboarding project | +| **3. Stress-to-Signal Conversion** | §3.5 | Unreviewed access past cadence is a tracked finding, not silence | +| **4. Sovereign Intelligence** | §3.2 | Roles and SoD matrix documented and owned, not held as tribal "ask Dave" knowledge | +| **5. Asymmetric Payoff Design (Barbell)** | §3.5 | Quarterly review concentrated on privileged accounts; standard users get a lighter semi-annual cadence | + +--- + +## 5. References +- **[NIST SP 800-53 Rev. 5, Security and Privacy Controls (AC family)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)** +- **[CIS Controls v8.1 (Controls 5 & 6)](https://www.cisecurity.org/controls/v8-1)** +- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)** diff --git a/Security/authentication_guidance.md b/Security/authentication_guidance.md index f42ecae..49f1ec7 100644 --- a/Security/authentication_guidance.md +++ b/Security/authentication_guidance.md @@ -166,8 +166,37 @@ Use this section to classify any method you encounter. --- -## 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 +## 11. Account Type × TLP Sensitivity — Worked Examples +Normative minimums are in Policy §§3–4. Governing AAL = **max(account-type minimum, data-sensitivity minimum)**. + +| Scenario | Account Type Min | TLP of Data Touched | Data Min | Governing AAL | +|---|---|---|---|---| +| Helpdesk agent reading public knowledge base | Standard User → AAL2 | TLP:CLEAR → AAL1 | — | **AAL2** (account floor wins) | +| Finance analyst opening internal budget doc | Standard User → AAL2 | TLP:GREEN → AAL2 | — | **AAL2** | +| HR admin accessing employee PII export | Privileged/Admin → AAL3 | TLP:AMBER → AAL2 (AAL3 for admin) | — | **AAL3** | +| Domain admin managing DCs | Privileged/Admin → AAL3 | TLP:AMBER+STRICT → AAL3 | — | **AAL3**, no OOB | +| SOC analyst pulling active incident IOCs shared by a partner | Standard User → AAL2 | TLP:RED → AAL3 | — | **AAL3** (data floor wins over account floor) | +| CI/CD pipeline pulling build artifacts | Service/Machine → N/A | TLP:GREEN → AAL2 | — | Not applicable — no interactive auth; use managed identity/certificate per §3 | +| Vendor support engineer troubleshooting a ticket | Third-party → AAL2 | TLP:AMBER → AAL2 | — | **AAL2**, time-bound | +| On-call engineer invoking break-glass domain admin during MFA outage | Break-glass → AAL2 min | TLP:AMBER+STRICT → AAL3 | — | **AAL3 preferred**, but checkout proceeds at AAL2 minimum with mandatory post-incident review — see §3 | + +**Rule of thumb:** never let a low-sensitivity account type "borrow down" the AAL required by high-sensitivity data, and never let low-sensitivity data waive the AAL an account type otherwise requires (e.g., admin accounts stay AAL3 even reading TLP:CLEAR content). + +--- + +## 12. Antifragility — Practical Playbook +Concrete moves per pillar (policy clauses in parens): + +- **Structural Decoupling (§2.6, §2.11):** Keep a written runbook for authenticating users if the IdP is down — e.g., break-glass local admin + offline MFA seed backup. Test it, don't just write it. Maintain a live doc: "if we had to leave [IdP vendor] in 90 days, here's the plan" — even if you never execute it. +- **Optionality Preservation (§2.4):** Don't let "MFA" mean "one app from one vendor." A FIDO2 key **and** a TOTP app satisfies §2.4 even if the authenticator app vendor has an outage. Enrollment flow should force both before granting access. +- **Stress-to-Signal Conversion (§2.12, §2.13):** Log every MFA fatigue/push-bombing attempt as an incident, not noise — recurring pattern with no policy change is a finding. Break-glass drill format: non-prod first, read-only check before destructive, one account before many, written abort trigger ("if X happens, stop and roll back") agreed before starting. +- **Sovereign Intelligence (§2.14):** One-page "if the IdP admin got hit by a bus" doc: where Conditional Access rules live, who has break-glass credentials, how MFA vendor is configured. Named owner, reviewed at least yearly. +- **Asymmetric Payoff / Barbell (§2.1, §3):** Resist the urge to apply AAL2.5-ish "extra effort" everywhere. Kill-chain systems (IdP, PKI root, backup infra, break-glass vault) get AAL3 + extra scrutiny, full stop. Everything else gets the AAL2 baseline and no more — spending moderate effort broadly instead of concentrating it on kill-chain nodes is the failure mode this pillar exists to prevent. + +--- + +## 13. 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) diff --git a/Security/authentication_policy.md b/Security/authentication_policy.md index da8993e..689aeeb 100644 --- a/Security/authentication_policy.md +++ b/Security/authentication_policy.md @@ -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) diff --git a/Security/business_continuity_dr_guidance.md b/Security/business_continuity_dr_guidance.md new file mode 100644 index 0000000..ac660b0 --- /dev/null +++ b/Security/business_continuity_dr_guidance.md @@ -0,0 +1,37 @@ +# Business Continuity & Disaster Recovery Guidance + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +Implementation guidance for the [Business Continuity & Disaster Recovery Policy](business_continuity_dr_policy.md). Applies to IT, system owners, and business continuity coordinators. + +--- + +## 2. BIA — Practical Approach +- Interview each business unit: "if this system is down for 4 hours / 24 hours / a week, what breaks?" +- Convert answers into RTO/RPO, then map to the tier table in policy §2.2 — don't let every system owner claim "critical," that defeats the tiering. + +## 3. Backup — 3-2-1-1 Pattern +- **3** copies of data, **2** different media/storage types, **1** offsite, **1** offline/immutable — the extra "1" beyond the classic 3-2-1 is specifically to survive ransomware that targets connected backup systems. + +## 4. Greenfield Rebuild — What "Tested" Means +- Not: "we have Terraform files somewhere." +- Yes: a scheduled exercise (can be non-production) that actually runs the documented rebuild process end-to-end and records how long it took and what broke in the documentation. +- Treat gaps found during the exercise as findings, feeding [Authentication Policy §2.12](authentication_policy.md) structural learning. + +## 5. DR Test Checklist +✅ Full failover test run annually for kill-chain/critical systems, with results documented. +✅ Backup restoration spot-tested quarterly for kill-chain systems. +✅ Break-glass access confirmed to work if the primary IdP is the thing that's down (test this specifically — it's the scenario people forget). +✅ Greenfield rebuild capability exercised at least once every 5 years, findings tracked. + +--- + +## 6. References +- **[NIST SP 800-34 Rev. 1](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)** +- **[ISO 22301:2019](https://www.iso.org/standard/75106.html)** diff --git a/Security/business_continuity_dr_policy.md b/Security/business_continuity_dr_policy.md new file mode 100644 index 0000000..7bb25c1 --- /dev/null +++ b/Security/business_continuity_dr_policy.md @@ -0,0 +1,63 @@ +# Business Continuity & Disaster Recovery Policy + +**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 [Organization]'s ability to recover from disruption — outages, ransomware, natural disaster, or vendor failure. It applies to all systems, with the tightest requirements applied to kill-chain systems defined in [Authentication Policy §2.1](authentication_policy.md). + +--- + +## 2. Policy Statements + +### 2.1 Business Impact Analysis (BIA) +- A BIA **must** be conducted at least annually, identifying critical processes, dependencies, and acceptable downtime. + +### 2.2 Recovery Objectives by Tier +| Tier | RTO (Recovery Time) | RPO (Recovery Point / max data loss) | +|---|---|---| +| Kill-chain (IdP, PKI, backup infra, break-glass vault) | ≤ 4 hours | ≤ 15 minutes | +| Critical business systems | ≤ 24 hours | ≤ 4 hours | +| Standard systems | ≤ 72 hours | ≤ 24 hours | +| Low-priority systems | Best effort | Best effort | + +### 2.3 Backup Requirements +- Backups **must** be encrypted (per [Secrets & Key Management Policy §2.3](secrets_management_policy.md)) and include at least one copy that is offline or immutable (air-gapped or WORM), unreachable by a compromised production credential. +- Backup restoration **must** be tested at least quarterly for kill-chain systems, annually for others. + +### 2.4 DR Testing +- A full failover test **must** be conducted at least **annually** for kill-chain and critical systems. +- Tests **must** follow the calibrated-dose principle: bounded blast radius, non-production first where feasible, pre-agreed abort condition — consistent with [Authentication Policy §2.13](authentication_policy.md) and [Incident Response Policy §3.6](incident_response_policy.md). + +### 2.5 Break-Glass & Emergency Access During DR +- DR procedures **must** account for break-glass account availability when the primary IdP is part of the outage — see [Authentication Policy §3](authentication_policy.md) and [§2.6](authentication_policy.md) (graceful degradation). + +### 2.6 Greenfield Rebuild Capability +- [Organization] **must** maintain the documented, version-controlled capability to rebuild its environment from scratch — not merely restore from backup — at least once every **five years**, or on demand after a compromise where restoring from backup risks reintroducing the compromised state. +- This capability **must** be exercised, not just claimed on paper; an untested greenfield rebuild plan is treated the same as untested break-glass access. + +### 2.7 Enforcement +- Systems without a current BIA, tested backup, or documented RTO/RPO **must** be remediated or formally excepted with CISO approval. + +--- + +## 3. Antifragility Alignment +This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. + +| Pillar | Applied In | How | +|---|---|---| +| **1. Structural Decoupling** | §2.6 | Greenfield rebuild capability is the ultimate expression of decoupling — the org can leave its own compromised/legacy state behind entirely | +| **2. Optionality Preservation** | §2.3 | Offline/immutable backup copy preserves the option to recover even if the primary environment (and its credentials) is fully compromised | +| **3. Stress-to-Signal Conversion** | §2.4 | DR tests are dosed exercises, not annual theater — findings feed structural fixes per [Authentication Policy §2.12](authentication_policy.md) | +| **4. Sovereign Intelligence** | §2.6 | Rebuild capability requires documented, owned architecture knowledge — the antidote to "only Dave knows how this works" | +| **5. Asymmetric Payoff Design (Barbell)** | §2.2 | 4-hour RTO concentrated on kill-chain systems; low-priority systems get best-effort — no moderate RTO spread evenly across everything | + +--- + +## 4. References +- **[NIST SP 800-34 Rev. 1, Contingency Planning Guide](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)** +- **[ISO 22301:2019, Business Continuity Management Systems](https://www.iso.org/standard/75106.html)** diff --git a/Security/data_classification_guidance.md b/Security/data_classification_guidance.md new file mode 100644 index 0000000..ad8f907 --- /dev/null +++ b/Security/data_classification_guidance.md @@ -0,0 +1,46 @@ +# Data Classification & Handling Guidance + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +Implementation guidance for the [Data Classification & Handling Policy](data_classification_policy.md). Applies to IT, data owners, and system owners implementing labeling and handling controls. + +--- + +## 2. Labeling — How To + +- **M365/Entra:** Use Microsoft Purview sensitivity labels mapped 1:1 to TLP levels (CLEAR/GREEN/AMBER/AMBER+STRICT/RED). Auto-apply default label per site/library; require justification to downgrade. +- **Cloud storage (S3/Blob/GCS):** Use bucket/object tags (`classification=TLP-AMBER`) enforced by policy-as-code (bucket policy or Conditional Access) rather than convention alone. +- **Code repositories:** Classification lives in the repo's README/CODEOWNERS metadata, not per-file — a repo touching RED material (e.g., PKI root config) is RED end-to-end. +- **Physical documents:** Header/footer stamp with TLP marking; RED documents numbered and logged at checkout. + +## 3. Worked Examples + +| Data | Classification | Why | +|---|---|---| +| Published blog post | TLP:CLEAR | Meant for public consumption | +| Internal engineering wiki | TLP:GREEN | All staff, not for external release | +| Customer contract | TLP:AMBER | Need-to-know within org | +| Pending acquisition terms | TLP:AMBER+STRICT | Named individuals, market-moving if leaked | +| Break-glass credentials, PKI root passphrase | TLP:RED | Compromise is existential — see [Authentication Policy §2.1 kill-chain tier](authentication_policy.md) | +| Active incident forensics (mid-investigation) | TLP:RED → reclassify to TLP:AMBER once resolved | Protects investigation in progress; declassify per §3.4 once closed | + +## 4. DLP & Technical Enforcement Checklist +✅ Sensitivity labels configured and auto-applied by default location. +✅ DLP policy blocks external email/share for AMBER+STRICT and RED labels. +✅ Encryption at rest enabled for all AMBER and above (see [Password Policy §2.7](password_policy_generic.md) for algorithm standards). +✅ Access logging enabled for AMBER+STRICT/RED storage locations. +✅ Quarterly review of unlabeled/default-classified content for drift. +✅ Printing/physical controls documented for RED material, if applicable. + +--- + +## 5. References +- **[FIRST.org Traffic Light Protocol (TLP) 2.0](https://www.first.org/tlp/)** +- **[NIST SP 800-60 Vol. 1 Rev. 1](https://csrc.nist.gov/pubs/sp/800/60/v1/r1/final)** +- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)** diff --git a/Security/data_classification_policy.md b/Security/data_classification_policy.md new file mode 100644 index 0000000..a757c87 --- /dev/null +++ b/Security/data_classification_policy.md @@ -0,0 +1,86 @@ +# Data Classification & Handling Policy + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +This policy defines how [Organization] classifies information and the handling requirements — storage, transmission, sharing, and destruction — attached to each classification level. It applies to all information created, received, or processed by employees, contractors, vendors, and systems, in any format (digital, physical, verbal). + +This policy is the **canonical source** for the classification scheme referenced elsewhere in this repository (e.g., [Authentication Policy §4](authentication_policy.md)). + +--- + +## 2. Roles & Responsibilities +- **Data Owner:** Business role accountable for a given data set; assigns initial classification and approves declassification. +- **Data Custodian:** IT/system owner responsible for implementing technical handling controls (encryption, access control, DLP) for data at rest under their care. +- **All Users:** Must label data they create per §3.2 and handle data per its assigned level. + +--- + +## 3. Policy Statements + +### 3.1 Classification Scheme +[Organization] classifies information using the [FIRST.org Traffic Light Protocol (TLP) 2.0](https://www.first.org/tlp/): + +| Level | Meaning | Default Applies To | +|---|---|---| +| **TLP:CLEAR** | Disclosure not limited (public) | Marketing materials, published docs | +| **TLP:GREEN** | Limited disclosure, community-wide (all staff) | Internal wikis, general process docs | +| **TLP:AMBER** | Limited disclosure, organization + need-to-know | Financials, HR records, customer data | +| **TLP:AMBER+STRICT** | Limited disclosure, named individuals/org only, no further sharing | M&A material, active investigations, source code for kill-chain systems | +| **TLP:RED** | Named recipients only | Credentials, incident forensics, active exploit details, PKI root material | + +Default level when unlabeled: **TLP:AMBER**. Silence is not TLP:CLEAR — undated/unlabeled data **must not** be treated as public. + +### 3.2 Labeling Requirements +- Documents and datasets **must** carry a visible or metadata label at creation (e.g., document header, sensitivity label in M365, object tag in cloud storage). +- Systems **must** default new content to the classification of the workspace/repository it lives in unless overridden. +- Labels **must** be reviewed at any material change to content sensitivity. + +### 3.3 Handling Requirements by Level + +| Control | CLEAR | GREEN | AMBER | AMBER+STRICT | RED | +|---|---|---|---|---|---| +| Encryption at rest | Optional | Recommended | **Required** | **Required** | **Required** + key access logged | +| Encryption in transit | Optional | **Required** (TLS 1.2+) | **Required** | **Required** | **Required**, no email | +| Internal sharing | Unrestricted | All staff | Need-to-know | Named individuals only | Named individuals only, approval logged | +| External sharing | Unrestricted | With NDA | Contractual DLP clause required | Prohibited without CISO approval | Prohibited | +| Storage location | Any approved system | Any approved system | Approved systems with access logging | Restricted storage, MFA-gated (see [Authentication Policy §4](authentication_policy.md)) | Vaulted / HSM-backed where applicable | +| Printing | Unrestricted | Unrestricted | Discouraged, must not leave premises unattended | Prohibited unless logged and approved | Prohibited | +| Destruction | Standard deletion | Standard deletion | Secure delete/wipe | Secure delete/wipe + logged | Cryptographic erasure or physical destruction, logged | + +### 3.4 Reclassification & Declassification +- Only the **Data Owner** may lower a classification level. +- Declassification **must** be documented with rationale and date. +- Data **must** be reviewed for reclassification when it becomes stale (e.g., an incident report moves from RED to AMBER once resolved and disclosed internally). + +### 3.5 Mishandling & Incident Reporting +- Any suspected mishandling (e.g., AMBER+STRICT data emailed externally) **must** be reported to Security immediately and treated as a security incident. + +### 3.6 Enforcement +- Violations **may** result in disciplinary action or revocation of access. +- System owners **must** remediate non-compliant storage/sharing configurations or document a CISO-approved exception. + +--- + +## 4. Antifragility Alignment +This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. + +| Pillar | Applied In | How | +|---|---|---| +| **1. Structural Decoupling** | §3.3 | Classification is stored as portable metadata/labels, not locked into one vendor's proprietary DLP format | +| **2. Optionality Preservation** | §3.3 | External sharing requires contractual DLP/export clauses — data can move without losing its protection | +| **3. Stress-to-Signal Conversion** | §3.5 | Every mishandling incident is treated as a security incident, feeding structural fixes (see [Authentication Policy §2.12](authentication_policy.md)) | +| **4. Sovereign Intelligence** | §2 | Named Data Owner and Custodian per data set — classification accountability isn't tribal knowledge | +| **5. Asymmetric Payoff Design (Barbell)** | §3.3 | Paranoid controls (HSM, cryptographic erasure, logged approval) concentrated at RED/AMBER+STRICT; CLEAR/GREEN stay lightweight — nothing moderate in the middle | + +--- + +## 5. References +- **[FIRST.org Traffic Light Protocol (TLP) 2.0](https://www.first.org/tlp/)** +- **[NIST SP 800-60 Vol. 1 Rev. 1, Guide for Mapping Types of Information to Security Categories](https://csrc.nist.gov/pubs/sp/800/60/v1/r1/final)** +- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)** diff --git a/Security/data_retention_disposal_guidance.md b/Security/data_retention_disposal_guidance.md new file mode 100644 index 0000000..94e92a0 --- /dev/null +++ b/Security/data_retention_disposal_guidance.md @@ -0,0 +1,43 @@ +# Data Retention & Disposal Guidance + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +Implementation guidance for the [Data Retention & Disposal Policy](data_retention_disposal_policy.md). Applies to IT, data owners, and Legal. + +--- + +## 2. Automating Retention +- Use lifecycle policies native to the storage platform (M365 retention labels, S3 lifecycle rules, database TTL/partition-drop jobs) rather than relying on manual deletion — manual processes are the reason retention schedules drift into indefinite retention. +- Tag data at creation with its retention class so lifecycle rules can act on it automatically. + +## 3. Sanitization Method by Media +| Media | Method | +|---|---| +| Cloud storage object | Cryptographic erasure (delete the key) or platform secure-delete API | +| Local SSD/HDD (AMBER+ data) | Cryptographic erasure preferred; full-disk overwrite if unencrypted | +| Physical media (RED data) | Physical destruction (shred/degauss), logged | +| Backup tapes/snapshots | Expire per retention schedule; confirm deletion propagates, don't assume | + +## 4. Right-to-Erasure Workflow +1. Verify requester identity. +2. Check for legal hold — if present, inform requester of the exception per §2.5 of the policy. +3. Delete from primary systems, then trigger backup propagation (or document why not, e.g., immutable backup within its retention window). +4. Confirm and log completion within the statutory window. + +## 5. Checklist +✅ Retention schedule (policy §2.1) mapped to actual system lifecycle rules, not just written down. +✅ Legal hold process tested at least once with a mock hold. +✅ Backup deletion propagation verified, not assumed. +✅ Disposal of AMBER+STRICT/RED data logged with method and authorizer. + +--- + +## 6. References +- **[NIST SP 800-88 Rev. 2](https://csrc.nist.gov/pubs/sp/800/88/r2/final)** +- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)** diff --git a/Security/data_retention_disposal_policy.md b/Security/data_retention_disposal_policy.md new file mode 100644 index 0000000..fd3bc2c --- /dev/null +++ b/Security/data_retention_disposal_policy.md @@ -0,0 +1,66 @@ +# Data Retention & Disposal Policy + +**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 how long [Organization] retains data and how it is disposed of at end of life. It applies to all data classified under the [Data Classification & Handling Policy](data_classification_policy.md), and supports GDPR principles of storage limitation and the right to erasure (Art. 17). + +--- + +## 2. Policy Statements + +### 2.1 Retention Schedule +| Data Category | Classification | Retention Period | +|---|---|---| +| Financial records | TLP:AMBER | 7 years (statutory) | +| Employee HR records | TLP:AMBER | Duration of employment + 6 years | +| Customer personal data | TLP:AMBER | Duration of relationship + 2 years, or per contract | +| Security/audit logs | TLP:AMBER | Per [Logging, Monitoring & Retention Policy §2.3](logging_monitoring_policy.md) | +| Incident forensics | TLP:RED → AMBER on closure | 3 years from closure | +| Marketing/public content | TLP:CLEAR | Business need, no mandated minimum | + +Retention periods **must not** exceed what is necessary for the stated business or legal purpose — indefinite retention is a violation of this policy, not a safe default. + +### 2.2 Legal Hold +- Data subject to litigation, investigation, or regulatory hold **must** be preserved regardless of the schedule in §2.1 until the hold is lifted by Legal. + +### 2.3 Disposal & Destruction +- Disposal method **must** match the classification level per [Data Classification Policy §3.3](data_classification_policy.md): + - TLP:CLEAR/GREEN: standard deletion. + - TLP:AMBER and above: secure delete/wipe or cryptographic erasure. + - Physical media holding TLP:AMBER+STRICT/RED data: sanitized per [NIST SP 800-88](https://csrc.nist.gov/pubs/sp/800/88/r2/final) or physically destroyed. +- Disposal of AMBER+STRICT/RED data **must** be logged (what, when, method, who authorized). + +### 2.4 Backup Alignment +- Backup retention **must not** silently extend the retention of data otherwise scheduled for deletion; deletion requests (including right-to-erasure) **must** propagate to backups within a defined window (**≤90 days**) or be documented as a technical exception. + +### 2.5 Right to Erasure +- Verified erasure requests **must** be fulfilled within the statutory window (GDPR: without undue delay, within 1 month, extendable to 3). +- Exceptions (legal hold, legitimate business need) **must** be documented and communicated to the requester where required by law. + +### 2.6 Enforcement +- Data retained past its scheduled disposal date without a documented legal hold or exception **must** be treated as a policy violation and remediated. + +--- + +## 3. Antifragility Alignment +This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. + +| Pillar | Applied In | How | +|---|---|---| +| **1. Structural Decoupling** | §2.4 | Deletion propagating to backups prevents "the vendor's backup system" from becoming a hidden place data outlives its intended lifecycle | +| **2. Optionality Preservation** | §2.1 | Disciplined retention avoids the illusion of value in hoarded data that later becomes a liability with no offsetting benefit | +| **3. Stress-to-Signal Conversion** | §2.6 | Data found past its disposal date is a tracked finding, not a shrug | +| **4. Sovereign Intelligence** | §2.3 | Disposal of sensitive data is logged and owned — auditable proof, not an assumption | +| **5. Asymmetric Payoff Design (Barbell)** | §2.3 | Cryptographic erasure/physical destruction concentrated on AMBER+STRICT/RED; CLEAR/GREEN gets standard deletion — no moderate process applied to everything | + +--- + +## 4. References +- **[NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization](https://csrc.nist.gov/pubs/sp/800/88/r2/final)** +- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)** diff --git a/Security/incident_response_guidance.md b/Security/incident_response_guidance.md new file mode 100644 index 0000000..c8ebea6 --- /dev/null +++ b/Security/incident_response_guidance.md @@ -0,0 +1,45 @@ +# Incident Response Guidance + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +Implementation guidance for the [Incident Response Policy](incident_response_policy.md). Applies to the IR team and all staff as first reporters. + +--- + +## 2. Severity Triage — Quick Reference +| Question | If Yes | +|---|---| +| Kill-chain system involved (IdP, PKI, backup, break-glass)? | SEV1 | +| TLP:AMBER+STRICT/RED data confirmed exposed? | SEV1/SEV2 | +| Contained to one endpoint, no lateral movement seen? | SEV3 | +| Just an anomaly, nothing confirmed yet? | SEV4, investigate before downgrading further | + +## 3. Post-Mortem Template (Blameless) +1. Timeline — what happened, when, who/what detected it. +2. Root cause — technical, not "human error" as a final answer; ask what let the human error matter. +3. What worked — don't only harvest failures. +4. Structural change — the mandatory output per policy §3.5. Must be a policy, architecture, or control change, not just "we'll be more careful." +5. Owner and due date for the structural change. + +## 4. Tabletop Exercise — Calibrated Dose Checklist +✅ Scope defined and bounded before starting (which systems, which team). +✅ Abort condition agreed in advance ("if X happens, we stop and debrief"). +✅ Non-production/simulated scenario before ever touching production for the first run of a new scenario type. +✅ Findings captured and fed into the post-mortem template above, even for a successful exercise. + +## 5. Notification Timeline Cheat Sheet +- T+1h: internal report and triage. +- T+72h: GDPR breach notification assessment complete (notify if required). +- Ongoing: customer/partner notification per contract, coordinated through Legal — don't let engineering notify unilaterally. + +--- + +## 6. References +- **[NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)** +- **[ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)** diff --git a/Security/incident_response_policy.md b/Security/incident_response_policy.md new file mode 100644 index 0000000..d56fcf3 --- /dev/null +++ b/Security/incident_response_policy.md @@ -0,0 +1,75 @@ +# Incident Response Policy + +**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 detecting, responding to, and learning from security incidents at [Organization]. It applies to all employees, contractors, vendors, and systems. + +--- + +## 2. Roles & Responsibilities +- **Incident Response Lead:** Owns the response, coordinates the IR team, declares severity. +- **IR Team:** Technical responders (security, IT, relevant system owners). +- **Communications/Legal:** Owns external notification and regulatory reporting. +- **All Users:** Must report suspected incidents immediately via the designated channel. + +--- + +## 3. Policy Statements + +### 3.1 Incident Classification +| Severity | Criteria | Example | +|---|---|---| +| **SEV1 (Critical)** | Kill-chain system compromise, confirmed breach of TLP:RED data, ransomware | Domain admin credential compromise | +| **SEV2 (High)** | Confirmed unauthorized access to TLP:AMBER+STRICT data, significant service outage | Break-glass account misuse | +| **SEV3 (Medium)** | Contained incident, limited scope, no confirmed data loss | Isolated phishing click, malware on one endpoint | +| **SEV4 (Low)** | Suspicious activity requiring investigation, no confirmed impact | Failed login anomaly | + +Incident details **must** be handled at the TLP level of the data involved (per [Data Classification Policy](data_classification_policy.md)) — most active investigations default to **TLP:RED**. + +### 3.2 Detection & Reporting +- Suspected incidents **must** be reported within **1 hour** of discovery via the designated channel. +- Automated alerts from [Logging, Monitoring & Retention Policy §2.4](logging_monitoring_policy.md) feed directly into triage. + +### 3.3 Response Lifecycle +[Organization] follows the NIST incident response lifecycle: **Preparation → Detection & Analysis → Containment, Eradication & Recovery → Post-Incident Activity.** +- Containment decisions **must** balance evidence preservation against stopping active damage; kill-chain systems favor immediate isolation. + +### 3.4 Notification Requirements +- Regulatory breach notification (e.g., GDPR Art. 33) **must** be assessed within **72 hours** of becoming aware of a personal data breach. +- Affected customers/partners **must** be notified per contractual and legal obligations, coordinated through Legal/Communications. + +### 3.5 Structural Post-Mortem Mandate +- Every SEV1/SEV2 incident **must** produce a blameless post-mortem with **at least one structural change** (policy, architecture, or control) within **30 days**, per [Authentication Policy §2.12](authentication_policy.md). +- Findings **must** be tracked to closure; a recurring root cause without a structural fix is itself a policy violation. + +### 3.6 Exercises +- Tabletop exercises **must** be run at least **semi-annually**. +- Exercises **must** follow the calibrated-dose principle: non-production before production scope, a bounded blast radius, and a pre-agreed abort condition — see [Authentication Policy §2.13](authentication_policy.md) for the same principle applied to break-glass drills. + +### 3.7 Enforcement +- Failure to report a known incident **may** result in disciplinary action. + +--- + +## 4. Antifragility Alignment +This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. + +| Pillar | Applied In | How | +|---|---|---| +| **1. Structural Decoupling** | §3.3 | Containment favors isolating the affected system over hoping the blast radius stays small on its own | +| **2. Optionality Preservation** | §3.3 | Evidence preservation vs. containment is a deliberate trade-off, not a forced default that removes options later | +| **3. Stress-to-Signal Conversion** | §3.5, §3.6 | This is the pillar's home policy: every SEV1/2 forces a structural fix; drills are dosed, bounded, and abortable | +| **4. Sovereign Intelligence** | §2 | Named IR Lead and team; incident knowledge captured in post-mortems, not lost when responders move on | +| **5. Asymmetric Payoff Design (Barbell)** | §3.1 | Severity tiers concentrate response urgency and TLP:RED confidentiality on kill-chain/critical incidents | + +--- + +## 5. References +- **[NIST SP 800-61 Rev. 3, Incident Response Recommendations (CSF 2.0 Profile)](https://csrc.nist.gov/pubs/sp/800/61/r3/final)** +- **[ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)** diff --git a/Security/logging_monitoring_guidance.md b/Security/logging_monitoring_guidance.md new file mode 100644 index 0000000..fe9eb9a --- /dev/null +++ b/Security/logging_monitoring_guidance.md @@ -0,0 +1,42 @@ +# Logging, Monitoring & Retention Guidance + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +Implementation guidance for the [Logging, Monitoring & Retention Policy](logging_monitoring_policy.md). Applies to IT, security operations, and system owners. + +--- + +## 2. Log Source Priority Checklist +Wire these up first — they're the ones an attacker needs to touch: +1. IdP/authentication logs (sign-in, MFA, admin role changes). +2. PKI/CA and backup infrastructure access logs. +3. Secret manager retrieval logs. +4. Privileged/admin action logs (EDR, cloud audit logs, AD/Entra audit logs). +5. Everything else, as capacity allows. + +## 3. Retention Tiering — Practical Setup +- Hot/searchable tier: 90 days, fast query for active investigation. +- Warm/archived tier: remainder of retention period (per policy §2.3 table), cheaper storage, slower retrieval, still admissible for audits. +- Kill-chain system logs: consider a separate, stricter-access archive so a compromised SIEM admin account can't touch the evidence of its own misuse. + +## 4. Alert Tuning +- Start narrow (break-glass checkout, kill-chain admin actions) and expand — broad noisy alerting trains responders to ignore alerts, which defeats the point. +- Review false-positive rate monthly for the first quarter after any new alert rule; quarterly thereafter. + +## 5. Checklist +✅ Centralized log shipping configured for all kill-chain and privileged systems. +✅ Logs are append-only/WORM where the platform supports it. +✅ Real-time alert on break-glass checkout, verified with a test invocation. +✅ Retention schedule matches the table in policy §2.3, reviewed against [Data Retention & Disposal Policy](data_retention_disposal_policy.md) for personal-data-bearing logs. + +--- + +## 6. References +- **[NIST SP 800-92, Guide to Computer Security Log Management](https://csrc.nist.gov/pubs/sp/800/92/final)** +- **[CIS Controls v8.1 (Control 8)](https://www.cisecurity.org/controls/v8-1)** diff --git a/Security/logging_monitoring_policy.md b/Security/logging_monitoring_policy.md new file mode 100644 index 0000000..d250536 --- /dev/null +++ b/Security/logging_monitoring_policy.md @@ -0,0 +1,68 @@ +# Logging, Monitoring & Retention Policy + +**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 security-relevant logging, centralized monitoring, and log retention across [Organization] systems. It applies to all systems that authenticate users, process TLP:AMBER or above data, or sit in the kill-chain tier defined in [Authentication Policy §2.1](authentication_policy.md). + +--- + +## 2. Policy Statements + +### 2.1 What Must Be Logged +- Authentication events (success, failure, MFA resets, break-glass invocation). +- Administrative/privileged actions (permission changes, configuration changes to IdP/PKI/backup systems). +- Access to TLP:AMBER+STRICT/RED data (per [Data Classification Policy §3.3](data_classification_policy.md)). +- Secret retrieval events (per [Secrets & Key Management Policy §2.4](secrets_management_policy.md)). +- System/network security events (firewall denies, IDS/IPS alerts, endpoint detections). + +### 2.2 Log Protection +- Logs **must** be shipped to a centralized, access-restricted store (SIEM or equivalent) separate from the systems that generate them. +- Logs **must** be tamper-evident (append-only/WORM where the platform supports it); local-only logs are not sufficient for kill-chain systems. +- Access to raw logs **must** follow least privilege (per [Access Control Policy §3.1](access_control_policy.md)). + +### 2.3 Retention Periods +| Log Type | Minimum Retention | +|---|---| +| Authentication & MFA events | 1 year | +| Privileged/admin action logs | 2 years | +| Kill-chain system logs (IdP, PKI, backup, break-glass) | 3 years | +| Standard application/security logs | 1 year | +| Network/firewall logs | 90 days online, 1 year archived | + +Retention **must not** exceed the schedule defined in the (forthcoming) Data Retention & Disposal Policy for logs containing personal data. + +### 2.4 Monitoring & Alerting +- Real-time alerting **must** be configured for: break-glass checkout, kill-chain system access, MFA resets, and privileged role changes. +- Alert thresholds **must** be reviewed at least annually to reduce false-positive fatigue without silencing genuine signal. + +### 2.5 Log Review Cadence +- Automated alerting is primary; manual review of aggregate trends **must** occur at least monthly for kill-chain systems. + +### 2.6 Enforcement +- Systems that cannot ship logs to the central store **must** be remediated or formally excepted with CISO approval and a compensating control. + +--- + +## 3. Antifragility Alignment +This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. + +| Pillar | Applied In | How | +|---|---|---| +| **1. Structural Decoupling** | §2.2 | Logs shipped off-system to a store independent of the generating platform — a compromised host can't erase its own evidence | +| **2. Optionality Preservation** | §2.2 | Centralized store in standard formats avoids lock-in to one SIEM vendor's proprietary log format | +| **3. Stress-to-Signal Conversion** | §2.1, §2.4 | Instrumenting kill-chain and privileged events is the raw material for the structural post-mortems required in [Authentication Policy §2.12](authentication_policy.md) | +| **4. Sovereign Intelligence** | §2.5 | Log review findings are tracked and owned, not left as raw data no one reads | +| **5. Asymmetric Payoff Design (Barbell)** | §2.3 | 3-year retention and real-time alerting concentrated on kill-chain systems; standard logs get the lean 1-year baseline | + +--- + +## 4. References +- **[NIST SP 800-92, Guide to Computer Security Log Management](https://csrc.nist.gov/pubs/sp/800/92/final)** +- **[CIS Controls v8.1 (Control 8)](https://www.cisecurity.org/controls/v8-1)** +- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)** diff --git a/Security/password_guidance_generic.md b/Security/password_guidance_generic.md index e75e565..6123f19 100644 --- a/Security/password_guidance_generic.md +++ b/Security/password_guidance_generic.md @@ -41,7 +41,7 @@ It applies to IT, IAM administrators, and system owners. ### 2.5 Multi-Factor Authentication (MFA) - Require MFA for: - - All external-facing logins. + - All employee logins, SaaS, and external-facing systems (AAL2 baseline). - Administrative access. - Remote access (VPN, SSH, RDP, portals). - Systems handling **sensitive or regulated data**. @@ -58,7 +58,7 @@ It applies to IT, IAM administrators, and system owners. - Store passwords using: - **Argon2id (preferred)**, or - **bcrypt** / **PBKDF2** with high work factor. -- Use **unique salts** (≥32 bits) per credential. +- Use **unique salts** (≥128 bits) per credential. - Consider adding a server-side **“pepper”** stored securely (HSM/TEE). ### 2.8 Resets & Recovery @@ -103,10 +103,11 @@ Applications authenticating users **must**: ✅ Require password manager compatibility (paste/show-password). ✅ Review and disable legacy authentication protocols (e.g., plain text FTP/POP/IMAP, NTLMv1). ✅ Audit password changes, resets, and lockout events. +✅ Split-knowledge/dual-control on kill-chain secrets (PKI root, backup keys, break-glass vault) per §2.13 — nothing moderate applied broadly instead. --- ## 4) References -- **NIST SP 800-63B, Digital Identity Guidelines (2023 update)** -- **CIS Controls v8.1 (Controls 5 & 6)** -- **OWASP Authentication Cheat Sheet** +- **[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)** +- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)** diff --git a/Security/password_guidance_m365_ad.md b/Security/password_guidance_m365_ad.md index afcaa24..f7674b3 100644 --- a/Security/password_guidance_m365_ad.md +++ b/Security/password_guidance_m365_ad.md @@ -64,7 +64,7 @@ This policy defines requirements for passwords and related authenticator handlin ## 6) Storage & transmission - All AD/M365 authentication happens over **TLS**. -- Passwords stored as **salted, hashed verifiers** (NTLMv2/Kerberos with AES). +- Prefer **Kerberos (AES)** over NTLM: the NTLM/NT hash is **unsalted**, a known pass-the-hash weakness — disabling NTLMv1/LM does not fix this, it only removes the weakest variants. - Domain controllers must disable **NTLMv1** and LM hashes. - Use **Argon2id/bcrypt** if custom apps store passwords. @@ -119,7 +119,8 @@ Apps authenticating against AD or Entra ID must: - ✅ Disable **legacy auth protocols** (POP, IMAP, SMTP Basic, NTLMv1). - ✅ Review dormant accounts quarterly (disable after 45 days). - ✅ Require TLS 1.2+ for all endpoints. -- ✅ Audit password changes and lockout events. +- ✅ Audit password changes and lockout events. +- ✅ Split-knowledge/dual-control on Enterprise Admin break-glass, AD FS/Entra Connect secrets, PKI root per §2.13 — concentrate protection there, not spread thin everywhere. --- @@ -129,8 +130,8 @@ Apps authenticating against AD or Entra ID must: --- ## 14) References -- **NIST SP 800-63B, Digital Identity Guidelines (2023 update)** -- **CIS Controls v8.1** (Controls 5 & 6) -- **Microsoft Security Baselines (Windows, AD, M365)** -- **OWASP Authentication Cheat Sheet** +- **[NIST SP 800-63B, Digital Identity Guidelines (2023 update)](https://pages.nist.gov/800-63-3/sp800-63b.html)** +- **[CIS Controls v8.1](https://www.cisecurity.org/controls/v8-1)** (Controls 5 & 6) +- **[Microsoft Security Baselines (Windows, AD, M365)](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines)** +- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)** diff --git a/Security/password_policy_generic.md b/Security/password_policy_generic.md index fccd22e..d03a809 100644 --- a/Security/password_policy_generic.md +++ b/Security/password_policy_generic.md @@ -22,6 +22,7 @@ This policy establishes mandatory requirements for password creation, management ### 2.2 Complexity - Passwords **must not** be subject to composition rules requiring upper/lowercase, numbers, or symbols. - Passwords **must** be screened against a blocklist of weak, common, or compromised passwords. +- Passwords **must not** match the user's current password or any of the last **5** passwords (where technically supported). ### 2.3 Expiration - Passwords **shall not** expire on a scheduled basis. @@ -34,6 +35,7 @@ This policy establishes mandatory requirements for password creation, management ### 2.5 Multi-Factor Authentication (MFA) - MFA **must** be enforced for: + - All employee, SaaS, and external-facing logins (per Authentication Policy AAL2 baseline) - Remote access - Administrative access - Access to sensitive data or critical systems @@ -76,6 +78,11 @@ Applications authenticating users: - **Must** allow paste/autofill and must not truncate passwords. - **Must** store verifiers using modern password hashing methods. +### 2.13 Kill-Chain Credential Protection (Barbell Principle) +- Credentials that gate existential systems — PKI/CA root passphrases, backup encryption keys, break-glass vault master credentials, HSM activation secrets — **must** receive protection disproportionate to ordinary accounts: **split-knowledge / dual control** (no single person holds the complete secret), physical or HSM-backed storage, and access logged with real-time alerting. +- Do **not** spread equivalent extra effort across low-value accounts — moderate protection applied broadly buys neither real security for what matters nor economy for what doesn't. Concentrate paranoia on the kill-chain few; keep the baseline (§2.1–§2.12) lean everywhere else. +- Full requirements and rotation cadence: see [Secrets & Key Management Policy §2.5](secrets_management_policy.md) — canonical source for this control. + --- ## 3) Enforcement @@ -91,6 +98,6 @@ Applications authenticating users: --- ## 5) References -- **NIST SP 800-63B, Digital Identity Guidelines (2023 update)** -- **CIS Controls v8.1, Controls 5 & 6** -- **OWASP Authentication Cheat Sheet** +- **[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)** +- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)** diff --git a/Security/password_policy_m365_ad.md b/Security/password_policy_m365_ad.md index 60414ee..2cf30d5 100644 --- a/Security/password_policy_m365_ad.md +++ b/Security/password_policy_m365_ad.md @@ -22,6 +22,7 @@ This policy establishes mandatory requirements for password creation, management ### 2.2 Complexity - Passwords **must not** be subject to complexity rules requiring upper/lowercase, numbers, or symbols. - Passwords **shall** be screened against a blocklist of weak, common, and compromised passwords using **Azure AD Password Protection**. +- Passwords **must not** match the user's current password or any of the last **5** passwords (where technically supported). ### 2.3 Expiration - Passwords **shall not** expire on a scheduled basis. @@ -47,7 +48,7 @@ This policy establishes mandatory requirements for password creation, management ### 2.7 Storage & Transmission - Passwords **must** only be transmitted over encrypted channels (TLS 1.2+). -- AD and M365 **must** store passwords as salted and hashed verifiers. +- AD and M365 authentication **must** rely on Kerberos (AES) rather than NTLM where possible; the legacy NT hash used by NTLM is **unsalted** and vulnerable to pass-the-hash attacks, so NTLM use **should** be minimized even with NTLMv1/LM disabled. - NTLMv1 and LAN Manager (LM) hashes **must** be disabled. - Custom applications **must** use Argon2id, bcrypt, or PBKDF2 for password storage. @@ -78,6 +79,11 @@ Applications authenticating against AD or Entra ID: - **Must** allow paste/autofill and must not truncate passwords. - **Must** store verifiers using modern password hashing methods if not federated. +### 2.13 Kill-Chain Credential Protection (Barbell Principle) +- Credentials gating existential systems — Enterprise Admin/Domain Admin break-glass credentials, AD FS/Entra Connect service account secrets, PKI/CA root passphrases (if operating internal PKI), Bitlocker/backup recovery key escrow master access — **must** receive protection disproportionate to ordinary accounts: **split-knowledge / dual control**, HSM or sealed-vault storage, and real-time alerting on access. +- Do **not** spread equivalent extra effort across low-value accounts — concentrate paranoia on this small kill-chain set; keep the AAL2 baseline (§2.1–§2.12) lean everywhere else. +- Full requirements and rotation cadence: see [Secrets & Key Management Policy §2.5](secrets_management_policy.md) — canonical source for this control. + --- ## 3) Enforcement @@ -93,7 +99,7 @@ Applications authenticating against AD or Entra ID: --- ## 5) References -- **NIST SP 800-63B, Digital Identity Guidelines (2023 update)** -- **CIS Controls v8.1, Controls 5 & 6** -- **Microsoft Security Baselines (M365 & Windows/AD)** -- **OWASP Authentication Cheat Sheet** +- **[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)** +- **[Microsoft Security Baselines (M365 & Windows/AD)](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines)** +- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)** diff --git a/Security/secrets_management_guidance.md b/Security/secrets_management_guidance.md new file mode 100644 index 0000000..b7ddb4a --- /dev/null +++ b/Security/secrets_management_guidance.md @@ -0,0 +1,40 @@ +# Secrets & Key Management Guidance + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +Implementation guidance for the [Secrets & Key Management Policy](secrets_management_policy.md). Applies to engineering, IT/IAM, and system owners. + +--- + +## 2. Approved Tooling Patterns +- **Cloud-native:** Azure Key Vault, AWS Secrets Manager/KMS, GCP Secret Manager — prefer platform-native over a bolted-on third party where the platform is already the trust boundary. +- **Self-hosted/hybrid:** HashiCorp Vault with auto-unseal via cloud KMS. +- **CI/CD:** Secrets injected at runtime via OIDC federation (no long-lived cloud credentials stored in the CI system) — see [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html). + +## 3. Split-Knowledge — How To (Kill-Chain Secrets) +Practical patterns for §2.5: +- **Shamir's Secret Sharing** (e.g., via HSM or `ssss`) to split a root key across ≥3 custodians with a quorum (e.g., 2-of-3) to reconstruct. +- Two named custodians each hold half a passphrase; both required to unseal. +- HSM-native M-of-N key ceremony (common for PKI root CA generation) — documented, witnessed, and recorded. + +## 4. Secret Scanning +- Enable pre-commit and CI-time secret scanning (e.g., gitleaks, trufflehog, or platform-native scanning) on every repository. +- A detected secret **must** be rotated immediately, even if the commit is reverted — git history retains it. + +## 5. Rotation Automation Checklist +✅ Service account secrets rotate automatically every ≤90 days, no manual step. +✅ TLS certificates auto-renew (ACME/cert-manager or equivalent) with alerting on renewal failure. +✅ Kill-chain secrets have a calendar-enforced annual rotation with two-person sign-off. +✅ Secret manager audit log retained and reviewed — see also [Password Guidance §2.2](password_guidance_generic.md) for blocklist/rotation cadence context. + +--- + +## 6. References +- **[NIST SP 800-57 Part 1 Rev. 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)** +- **[OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)** diff --git a/Security/secrets_management_policy.md b/Security/secrets_management_policy.md new file mode 100644 index 0000000..b220aa4 --- /dev/null +++ b/Security/secrets_management_policy.md @@ -0,0 +1,84 @@ +# Secrets & Key Management Policy + +**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 the generation, storage, access, rotation, and retirement of secrets and cryptographic keys — API keys, service credentials, TLS certificates, encryption keys, and signing keys — across [Organization] systems. It applies to all employees, contractors, and systems that create or consume secrets. + +This policy is the **canonical source** for cryptographic algorithm/parameter standards and kill-chain secret handling referenced elsewhere in this repository (e.g., [Password Policy §2.13](password_policy_generic.md), [Password Policy (M365/AD) §2.13](password_policy_m365_ad.md)). + +--- + +## 2. Policy Statements + +### 2.1 Secret Inventory & Ownership +- Every secret **must** have a named owner and a documented purpose. +- An inventory of active secrets **must** be maintained in the approved secret manager; secrets with no identifiable owner **must** be rotated and reassigned or retired within 30 days of discovery. + +### 2.2 Storage +- Secrets **must** be stored only in an approved secret manager, key vault, or HSM. +- Secrets **must not** be stored in source code, config files committed to version control, tickets, chat messages, or shared documents. +- Any secret found outside an approved store **must** be treated as compromised: rotated immediately, not just relocated. + +### 2.3 Cryptographic Standards +| Purpose | Approved | Minimum Parameters | +|---|---|---| +| Password hashing | Argon2id (preferred), bcrypt, PBKDF2 | Argon2id: memory ≥19 MiB, iterations ≥2; per-credential unique salt ≥128 bits | +| Symmetric encryption at rest | AES-256-GCM | Unique IV/nonce per operation | +| Transport encryption | TLS 1.2 minimum, TLS 1.3 preferred | Modern cipher suites only; disable TLS 1.0/1.1 | +| Asymmetric keys | RSA ≥3072-bit, ECDSA P-256 or higher | — | +| Signing | Ed25519 or ECDSA P-256+ | — | +| Legacy/weak algorithms (MD5, SHA-1 for integrity, DES/3DES, RC4, NTLMv1) | **Prohibited** for new use; existing use tracked as a remediation item | — | + +### 2.4 Access Control +- Access to secrets **must** follow least privilege and, where supported, just-in-time elevation. +- All secret retrieval **must** be logged (who, what, when). +- Human access to production secrets **should** be exceptional and time-bound; services **must** authenticate via managed identity/certificate rather than a retrieved static secret where the platform supports it. + +### 2.5 Kill-Chain Secrets (Barbell Principle) +Secrets gating existential systems — PKI/CA root passphrases, backup/DR encryption master keys, break-glass vault master credentials, HSM activation secrets — **must** receive protection disproportionate to ordinary secrets: +- **Split-knowledge / dual control**: no single person holds the complete secret. +- Physical or HSM-backed storage, not a general-purpose secret manager. +- Real-time alerting on access; access requires a second approver. +- Do **not** spread equivalent extra effort across low-value secrets — concentrate paranoia here; keep §2.2–§2.4 lean everywhere else. + +### 2.6 Rotation & Expiry +| Secret Type | Rotation Cadence | +|---|---| +| Human-facing passwords | Incident-driven only (no scheduled expiry, per [Password Policy §2.3](password_policy_generic.md)) | +| Service account secrets / API keys | Automated, ≤90 days | +| TLS certificates | Before expiry, automated renewal preferred | +| Kill-chain secrets (§2.5) | Annually, or immediately after any custodian change | +| Any secret suspected compromised | Immediately | + +### 2.7 Secret Compromise Response +- A suspected or confirmed secret compromise **must** trigger immediate rotation, revocation of derived sessions/tokens, and a structural post-mortem per [Authentication Policy §2.12](authentication_policy.md). + +### 2.8 Enforcement +- Violations **may** result in disciplinary action or revocation of access. +- Secrets discovered in version control history **must** be rotated even after removal from the current commit — history does not un-leak a secret. + +--- + +## 3. Antifragility Alignment +This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. + +| Pillar | Applied In | How | +|---|---|---| +| **1. Structural Decoupling** | §2.4 | Services authenticate via managed identity/certificate rather than a portable static secret where possible — removes a class of dependency entirely | +| **2. Optionality Preservation** | §2.3 | Standardized, non-proprietary algorithms (AES, Argon2id, ECDSA) avoid lock-in to a single vendor's crypto scheme | +| **3. Stress-to-Signal Conversion** | §2.7 | Every compromised secret forces a structural post-mortem, not just a quiet rotation | +| **4. Sovereign Intelligence** | §2.1 | Named owner per secret; inventory is owned and current, not tribal knowledge of "whoever set it up" | +| **5. Asymmetric Payoff Design (Barbell)** | §2.5 | Split-knowledge/HSM concentrated on kill-chain secrets; ordinary secrets get the lean baseline — nothing moderate spread everywhere | + +--- + +## 4. References +- **[NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final)** +- **[OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)** +- **[OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)** diff --git a/Security/secure_sdlc_guidance.md b/Security/secure_sdlc_guidance.md new file mode 100644 index 0000000..8f635a7 --- /dev/null +++ b/Security/secure_sdlc_guidance.md @@ -0,0 +1,41 @@ +# Secure SDLC Guidance + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +Implementation guidance for the [Secure Software Development Lifecycle Policy](secure_sdlc_policy.md). Applies to engineering teams. + +--- + +## 2. Tooling Patterns +- **SAST:** run in CI on every PR, not just nightly — catch it before merge, not after. +- **Dependency scanning:** Dependabot/Renovate + a vulnerability scanner (e.g., Snyk, Trivy, `npm audit`/`pip-audit`) gated in CI. +- **SBOM:** generate via CycloneDX or SPDX tooling as a build artifact, not a one-off manual exercise. +- **Secret scanning:** pre-commit hook + CI-time scan — see [Secrets & Key Management Guidance §4](secrets_management_guidance.md). + +## 3. ASVS Level — How to Decide +- Level 1: internal tools, low sensitivity, no kill-chain adjacency. +- Level 2: anything externally exposed, anything touching TLP:AMBER+ data, anything adjacent to a kill-chain system per [Authentication Policy §2.1](authentication_policy.md). +- Level 3: reserve for the kill-chain systems themselves (IdP, PKI, payment processing) — not the default; apply deliberately. + +## 4. Threat Modeling — Lightweight Version +- STRIDE walkthrough in a design doc before build starts for anything hitting ASVS Level 2+. +- Doesn't need a dedicated meeting for every feature — fold it into design review for qualifying systems only. + +## 5. Checklist +✅ SAST + dependency scan gates block merge on new critical/high findings. +✅ SBOM generated per production build. +✅ Threat model documented for kill-chain-adjacent systems before build. +✅ Pen test scheduled annually for externally exposed production apps. +✅ No hardcoded secrets — verified by scanner, not just code review. + +--- + +## 6. References +- **[NIST SP 800-218 (SSDF)](https://csrc.nist.gov/pubs/sp/800/218/final)** +- **[OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/)** diff --git a/Security/secure_sdlc_policy.md b/Security/secure_sdlc_policy.md new file mode 100644 index 0000000..e96bd22 --- /dev/null +++ b/Security/secure_sdlc_policy.md @@ -0,0 +1,60 @@ +# Secure Software Development Lifecycle (SDLC) Policy + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +This policy establishes mandatory secure development requirements for software built or materially customized by [Organization]. It applies to all engineering teams and to third-party developers per the [Vendor & Third-Party Risk Management Policy](vendor_risk_management_policy.md). + +--- + +## 2. Policy Statements + +### 2.1 Secure Design & Threat Modeling +- New systems handling TLP:AMBER+STRICT/RED data or touching kill-chain infrastructure (per [Authentication Policy §2.1](authentication_policy.md)) **must** undergo threat modeling before implementation begins. + +### 2.2 Secure Coding Standards +- Applications **must** meet [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) Level 1 minimum; kill-chain-adjacent and externally exposed applications **must** meet Level 2. +- Authentication implementations **must** conform to [Authentication Policy](authentication_policy.md) and [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html). + +### 2.3 Dependency & Supply Chain Security +- A Software Bill of Materials (SBOM) **must** be generated for production applications. +- Dependencies **must** be scanned for known vulnerabilities on every build; findings follow the SLA in [Vulnerability & Patch Management Policy §2.2](vulnerability_patch_management_policy.md). +- Dependency pinning **must** be used; automatic unpinned upgrades to production are prohibited. + +### 2.4 Code Review & Analysis +- All production code changes **must** be peer reviewed before merge. +- Static analysis (SAST) **must** run on every build; dynamic analysis (DAST) **must** run at least before each production release for externally exposed applications. + +### 2.5 Secrets in Code +- Secrets **must not** be committed to source control — see [Secrets & Key Management Policy §2.2](secrets_management_policy.md) and its secret-scanning guidance. + +### 2.6 Penetration Testing +- Kill-chain-adjacent and externally exposed production applications **must** undergo penetration testing at least annually and after material architecture change. + +### 2.7 Enforcement +- Production deployment **must not** proceed without passing SAST and dependency scanning gates, absent a documented, time-bound CISO exception. + +--- + +## 3. Antifragility Alignment +This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. + +| Pillar | Applied In | How | +|---|---|---| +| **1. Structural Decoupling** | §2.3 | SBOM and pinned dependencies make the hidden coupling graph of third-party code visible and controllable | +| **2. Optionality Preservation** | §2.2 | Following an open standard (ASVS) rather than a single vendor's proprietary security checklist keeps the standard portable | +| **3. Stress-to-Signal Conversion** | §2.4 | SAST/DAST findings and pen test results feed the same structural-fix process as any other incident | +| **4. Sovereign Intelligence** | §2.1 | Threat models are documented artifacts, not a conversation that evaporates after the design meeting | +| **5. Asymmetric Payoff Design (Barbell)** | §2.2, §2.6 | ASVS Level 2 and mandatory pen testing concentrated on kill-chain-adjacent/external apps; internal low-risk tools stay at Level 1 | + +--- + +## 4. References +- **[NIST SP 800-218, Secure Software Development Framework (SSDF)](https://csrc.nist.gov/pubs/sp/800/218/final)** +- **[OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/)** +- **[OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)** diff --git a/Security/vendor_risk_management_guidance.md b/Security/vendor_risk_management_guidance.md new file mode 100644 index 0000000..e43dae5 --- /dev/null +++ b/Security/vendor_risk_management_guidance.md @@ -0,0 +1,44 @@ +# Vendor & Third-Party Risk Management Guidance + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +Implementation guidance for the [Vendor & Third-Party Risk Management Policy](vendor_risk_management_policy.md). Applies to Procurement, Vendor Owners, and Security reviewing onboarding requests. + +--- + +## 2. Tiering — Quick Decision Tree +1. Does the vendor touch TLP:RED or TLP:AMBER+STRICT data, or sit on the kill-chain (per Authentication Policy §2.1)? → **Critical**. +2. Does it touch TLP:AMBER data or run a significant business function? → **High**. +3. Does it touch only TLP:GREEN data or have limited, non-privileged system access? → **Medium**. +4. No system access, TLP:CLEAR only? → **Low**. + +## 3. Due Diligence — Practical Checklist +- Request SOC 2 Type II (or ISO 27001 cert) — check the **report period**, not just that one exists; a report older than 12 months is effectively expired. +- For Critical vendors without a SOC 2 (common with smaller/newer vendors): require a completed security questionnaire (CAIQ or equivalent) plus a call with their security lead. +- Cyber insurance: confirm coverage amount is proportionate to potential exposure, not just that a certificate exists. + +## 4. Concentration Risk — Worked Example +| Vendor | Function | Alternative Exists? | Exit Plan Status | +|---|---|---|---| +| Cloud IdP | Authentication for all staff | No (single IdP by design) | **Required**: documented break-glass + 90-day migration runbook — see [Authentication Policy §2.11](authentication_policy.md) | +| Payroll processor | Payroll | Yes (2 alternatives evaluated) | Lower priority — market has substitutes | +| Single MSP running all endpoint management | Device security | No | **Required**: document in-house fallback capability or dual-MSP readiness | + +## 5. Offboarding Checklist +✅ Access revoked within 24h of termination. +✅ API keys/service accounts rotated or deleted. +✅ Data return or destruction certificate received and filed. +✅ Federated trust (SSO app registration, SAML/OIDC config) removed from IdP. +✅ Vendor Owner confirms no shared inbox/shared credential remains active. + +--- + +## 6. References +- **[NIST SP 800-161 Rev. 1](https://csrc.nist.gov/pubs/sp/800/161/r1/final)** +- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)** diff --git a/Security/vendor_risk_management_policy.md b/Security/vendor_risk_management_policy.md new file mode 100644 index 0000000..4cd1728 --- /dev/null +++ b/Security/vendor_risk_management_policy.md @@ -0,0 +1,91 @@ +# Vendor & Third-Party Risk Management Policy + +**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 assessing, onboarding, monitoring, and offboarding third parties (vendors, suppliers, MSPs, SaaS providers) that access [Organization] systems or data. It applies to all business units engaging third parties, and to Third-party/Vendor accounts defined in [Authentication Policy §3](authentication_policy.md). + +--- + +## 2. Roles & Responsibilities +- **Vendor Owner (business sponsor):** Accountable for the relationship, ensures due diligence is completed before onboarding, tracks reassessment dates. +- **Security/CISO:** Defines tiering criteria, reviews due diligence evidence, approves exceptions. +- **Procurement/Legal:** Ensures contractual requirements (§3.3) are included before signature. + +--- + +## 3. Policy Statements + +### 3.1 Vendor Tiering +Every vendor **must** be tiered at onboarding, based on the highest TLP level of data accessed (per [Data Classification Policy](data_classification_policy.md)) and business criticality: + +| Tier | Criteria | Example | +|---|---|---| +| **Critical** | Accesses TLP:AMBER+STRICT/RED data, or is a single point of failure for a revenue-critical or kill-chain function (per [Authentication Policy §2.1](authentication_policy.md)) | Cloud IdP, payroll processor, core SaaS platform | +| **High** | Accesses TLP:AMBER data, or supports a significant business function | CRM vendor, MSP with standing admin access | +| **Medium** | Accesses TLP:GREEN data or limited system access | Marketing tools, non-privileged SaaS | +| **Low** | Accesses only TLP:CLEAR data, no system access | Public-facing content vendors | + +### 3.2 Due Diligence Requirements + +| Tier | Required Before Onboarding | +|---|---| +| Critical | Security questionnaire; current SOC 2 Type II or ISO 27001 certificate; penetration test summary (last 12 months); cyber insurance evidence; documented exit/migration plan | +| High | Security questionnaire; SOC 2/ISO 27001 or equivalent attestation | +| Medium | Security questionnaire (lightweight) | +| Low | None required beyond standard procurement terms | + +### 3.3 Contractual Requirements +For **Critical** and **High** tier vendors, contracts **must** include: +- Data protection / processing terms (GDPR Art. 28 or equivalent where applicable). +- Breach notification **within 72 hours** of vendor becoming aware. +- Right-to-audit or right to receive independent audit reports. +- **Data export and exit clauses** as primary terms — format, timeline (≤30 days from request), and any de-provisioning assistance. Absence of an exit clause is a contract blocker for Critical tier. +- No unilateral change to data residency or subprocessors without notice. + +### 3.4 Ongoing Monitoring & Reassessment +- **Critical:** Reassessed annually; SOC 2/ISO certificate currency checked continuously (expiry alert). +- **High:** Reassessed every 18 months. +- **Medium/Low:** Reassessed at renewal or every 3 years, whichever is sooner. +- Any material vendor incident (breach, outage >4h, ownership change) triggers an out-of-cycle reassessment. + +### 3.5 Concentration Risk / Single-Vendor Dependency +- Vendor Owners **must** flag any Critical-tier vendor for which no viable alternative or fallback exists. +- For each flagged dependency, a documented exit/migration path **must** exist and be executable within **90 days** (aligned with [Authentication Policy §2.11](authentication_policy.md)). +- Concentration risk **must** be reviewed at least annually as part of the kill-chain mapping exercise. + +### 3.6 Offboarding +- On contract termination, vendor access **must** be revoked within **24 hours**. +- Data return or certified destruction **must** be confirmed in writing within the contractual exit window. +- Any shared credentials, API keys, or federated trust relationships **must** be rotated or removed. + +### 3.7 Vendor-Involved Incidents +- Vendor-caused or vendor-affecting incidents **must** be handled per the incident-driven structural learning process in [Authentication Policy §2.12](authentication_policy.md) — a structural change (contract amendment, control, or vendor replacement) is required within 30 days of root cause confirmation. + +### 3.8 Enforcement +- Onboarding without completed due diligence **must not** proceed. Exceptions require documented CISO approval with compensating controls and a review date ≤ 6 months out. + +--- + +## 4. Antifragility Alignment +This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. + +| Pillar | Applied In | How | +|---|---|---| +| **1. Structural Decoupling** | §3.5 | Concentration-risk flagging forces mapping of hidden single points of failure; 90-day exit path required for each | +| **2. Optionality Preservation** | §3.3 | Data export/exit clauses are primary contract terms, not afterthoughts — preserves the right to leave | +| **3. Stress-to-Signal Conversion** | §3.7 | Vendor incidents force a structural change within 30 days, not just a post-mortem doc nobody reads | +| **4. Sovereign Intelligence** | §2 | Named Vendor Owner per relationship; due diligence evidence retained and owned, not scattered across inboxes | +| **5. Asymmetric Payoff Design (Barbell)** | §3.1–§3.2 | Heavy diligence and contractual rigor concentrated on Critical tier; Low tier gets minimal friction — no moderate process applied uniformly | + +--- + +## 5. References +- **[NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management](https://csrc.nist.gov/pubs/sp/800/161/r1/final)** +- **[ISO/IEC 27001:2022](https://www.iso.org/standard/27001)** +- **[ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)** diff --git a/Security/vulnerability_patch_management_guidance.md b/Security/vulnerability_patch_management_guidance.md new file mode 100644 index 0000000..e964177 --- /dev/null +++ b/Security/vulnerability_patch_management_guidance.md @@ -0,0 +1,39 @@ +# Vulnerability & Patch Management Guidance + +**Document owner:** [Owner/Role] +**Approved by:** [Steering Committee / CISO] +**Effective date:** [YYYY-MM-DD] +**Review cadence:** [Annually] + +--- + +## 1. Purpose & Scope +Implementation guidance for the [Vulnerability & Patch Management Policy](vulnerability_patch_management_policy.md). Applies to IT, security operations, and system owners. + +--- + +## 2. Prioritization — Practical Order +1. Check the finding against the [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) first — actively exploited beats a higher CVSS score that's theoretical. +2. Cross-reference against kill-chain asset inventory (per [Authentication Policy §2.1](authentication_policy.md)) — same CVE on a kill-chain system jumps the queue. +3. Then fall back to CVSS-based SLA table in policy §2.2. + +## 3. Patch Testing Before Rollout +- Kill-chain and production-critical systems: patch in a staging/canary group first, even under an accelerated SLA — an emergency patch that breaks production is not a win. +- Low-priority systems: standard maintenance window testing is sufficient. + +## 4. Exception Tracking +- Every SLA exception needs: system, CVE, compensating control (e.g., network isolation, WAF rule), owner, and review date ≤90 days out. +- Review the exception list monthly — an exception with no progress after two review cycles escalates to CISO. + +## 5. Checklist +✅ Weekly external / monthly internal scanning running and reviewed. +✅ KEV catalog checked against current open findings weekly. +✅ Kill-chain systems on continuous scanning where tooling allows. +✅ Exception list reviewed monthly, none open past 90 days without CISO sign-off. +✅ Emergency patch process tested at least once — don't discover the process during a real zero-day. + +--- + +## 6. References +- **[NIST SP 800-40 Rev. 4](https://csrc.nist.gov/pubs/sp/800/40/r4/final)** +- **[CISA KEV Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)** diff --git a/Security/vulnerability_patch_management_policy.md b/Security/vulnerability_patch_management_policy.md new file mode 100644 index 0000000..1926c2e --- /dev/null +++ b/Security/vulnerability_patch_management_policy.md @@ -0,0 +1,62 @@ +# Vulnerability & Patch Management Policy + +**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 identifying, prioritizing, and remediating vulnerabilities across [Organization]'s IT, cloud, and OT/IoT assets. It applies to all systems, including those managed by third parties per the [Vendor & Third-Party Risk Management Policy](vendor_risk_management_policy.md). + +--- + +## 2. Policy Statements + +### 2.1 Vulnerability Scanning +- Internet-facing assets **must** be scanned at least **weekly**; internal assets **must** be scanned at least **monthly**. +- Authenticated scanning **should** be used where supported for accuracy. +- Kill-chain systems (per [Authentication Policy §2.1](authentication_policy.md)) **must** be scanned continuously where tooling supports it. + +### 2.2 Patch SLA by Severity +| Severity | SLA | +|---|---| +| **CISA KEV-listed** (actively exploited) | ≤ 15 days, kill-chain systems ≤ 72 hours | +| **Critical (CVSS ≥9.0)** | ≤ 15 days | +| **High (CVSS 7.0–8.9)** | ≤ 30 days | +| **Medium (CVSS 4.0–6.9)** | ≤ 90 days | +| **Low (CVSS <4.0)** | Next scheduled maintenance window | + +### 2.3 Emergency Patching +- A confirmed zero-day or actively exploited vulnerability affecting a kill-chain system **must** trigger emergency change process — patch or compensating control (e.g., network isolation) within the SLA above regardless of standard change windows. + +### 2.4 Exceptions +- Missed SLAs **must** be documented with compensating controls and CISO approval, with a review date not exceeding 90 days. +- Unpatchable legacy systems **must** be isolated (network segmentation) as a compensating control, not left exposed by default. + +### 2.5 Kill-Chain Priority (Barbell Principle) +- Vulnerability remediation effort **must** be concentrated disproportionately on kill-chain systems and internet-facing assets; low-criticality internal systems on the standard SLA table do not warrant equivalent urgency. + +### 2.6 Enforcement +- Repeated SLA misses without an approved exception **must** be escalated to the CISO and tracked as a recurring finding per [Authentication Policy §2.12](authentication_policy.md) structural learning process. + +--- + +## 3. Antifragility Alignment +This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. + +| Pillar | Applied In | How | +|---|---|---| +| **1. Structural Decoupling** | §2.4 | Network isolation as a compensating control means one unpatchable legacy system doesn't become a standing risk to everything else | +| **2. Optionality Preservation** | §2.4 | Isolation preserves the option to keep a legacy system running without accepting its full risk | +| **3. Stress-to-Signal Conversion** | §2.6 | Repeated SLA misses feed the structural post-mortem process rather than becoming permanent exceptions | +| **4. Sovereign Intelligence** | §2.4 | Exceptions and compensating controls documented and owned, with a forced review date | +| **5. Asymmetric Payoff Design (Barbell)** | §2.2, §2.5 | Tight SLA (≤72h) concentrated on kill-chain + KEV-listed vulnerabilities; low severity gets the lean next-cycle treatment | + +--- + +## 4. References +- **[NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning](https://csrc.nist.gov/pubs/sp/800/40/r4/final)** +- **[CISA Known Exploited Vulnerabilities (KEV) Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)** +- **[CIS Controls v8.1 (Control 7)](https://www.cisecurity.org/controls/v8-1)**