Files
antifragile/antifragile-consulting/assessment-templates/nist-csf-baseline.md
T
tomas.kracmar 64f73371c9 feat: Add engagement model, consultant field guide, deliverable templates, CQRE tools integration, and Czech localization
New documents:
- core/engagement-model.md: Full client-facing engagement lifecycle (Sections 1-6) plus consultant delivery discipline (Section 7)
- core/consultant-field-guide.md: Decision models, client qualification, module selection, 10 common mistakes, technical onboarding, proposal writing
- core/about-cqre.md: Company overview template with [PLACEHOLDER] markers for client-facing use
- core/about-cqre-cs.md: Czech version of company overview (O společnosti CQRE)
- core/executive-summary-cs.md: Czech translation of the board executive summary
- assessment-templates/nist-csf-baseline.md: Full Brownhat Diagnostic workshop methodology (NIST CSF 2.0)
- assessment-templates/nist-csf-baseline-cs.md: Czech version of Brownhat Diagnostic (for Czech-language workshops)
- assessment-templates/module-completion-report.md: Module completion package template
- assessment-templates/risk-register-example.md: 8 fully populated risk entries (Meridian Logistics GmbH fictional engagement)
- playbooks/privileged-access-architecture.md: Module 13 - Teleport, Tailscale/Headscale, JIT access, vendor governance
- playbooks/sovereign-communications.md: Module 14 - Delta Chat chatmail relay, Matrix/Element, crisis channels

Updated documents:
- playbooks/sovereign-tool-stack.md: Added Elysium, CAExporter, E8-CAT, macOS_IntuneManagement, IntunePolicyParser, M365-Scripts; updated capability matrix and module pairings
- core/modular-engagements.md: Module 2 now includes CAExporter as first step; Module 6 includes Elysium password audit
- reference/nist-csf-mapping.md: Added back-reference to nist-csf-baseline.md
- assessment-templates/README.md: Changed Q1/Q2/Q3/Q4 to Phase 1/2/3/4, added Status column
- index.md: Registered all new documents; restructured consultant navigation into three labeled groups (1-25)
- README.md: Updated directory tree; updated Quick Start for Consultants

Czech localization pointers:
- executive-summary.md: Added Česká verze pointer
- nist-csf-baseline.md: Added Česká verze pointer
- engagement-model.md: Added note that client-facing Czech translation is planned

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-27 21:33:52 +02:00

263 lines
16 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# NIST CSF 2.0 Baseline Assessment
> *"Most organisations do not know what they do not know. This workshop makes the unknown visible — in two half-days, without a single technical tool."*
## Purpose
This assessment is the **entry point before any module selection**. It answers the question every client needs answered before committing to a programme: *"Where are we actually, and what matters most to fix?"*
It is a structured workshop, not a technical audit. No tools are installed. No data is collected from systems. The output is a clear picture of the organisation's security posture across the six NIST CSF 2.0 functions, a strengths/gaps report, and a prioritised remediation roadmap that maps directly to the antifragile module menu.
**Duration**: Two half-days (4 hours each). In-person strongly preferred; remote with camera-on acceptable.
**Who attends**:
- CIO/CISO or equivalent (mandatory)
- IT manager / infrastructure lead (mandatory)
- One business process owner (finance, operations, or HR — whoever owns the most critical data)
- Optional: Legal/compliance, operations manager for OT environments
**Prerequisites**: None. This is the starting point.
---
## How to Run the Workshop
### Before the Workshop
Send the client a one-page prep note:
> *"We will spend two half-days together answering honest questions about how your organisation manages security today. There are no wrong answers. Our goal is to understand the reality of your current state — not what the policies say, not what you would like to be doing, but what actually happens. Please bring the people who know how things actually work."*
No homework, no questionnaire to fill in advance. Pre-filled questionnaires produce aspirational answers. The workshop produces honest ones.
### Session Structure
**Session 1 (Half-Day 1): Context and Foundation**
- 30 min — Introduction, ground rules, methodology overview
- 90 min — GOVERN domain (organisational context and risk management)
- 60 min — IDENTIFY domain (asset management and risk assessment)
- 20 min — Wrap, parking lot, preview of Session 2
**Session 2 (Half-Day 2): Controls, Detection, and Recovery**
- 30 min — Recap and open threads from Session 1
- 45 min — PROTECT domain (controls and safeguards)
- 45 min — DETECT domain (monitoring and anomaly detection)
- 30 min — RESPOND domain (incident management)
- 30 min — RECOVER domain (recovery and improvement)
- 20 min — Preliminary findings, next steps
---
## Domain Questionnaires
For each question, record:
- **Current state** (what actually happens)
- **Evidence** (what documentation or artefacts exist)
- **Score**: 🔴 Not present / 🟡 Partial or inconsistent / 🟢 Operational and effective
The score is a discussion tool, not an audit finding. Its purpose is to surface gaps, not to pass or fail the client.
---
### GV — GOVERN
*Identifies the processes, roles, and oversight structures that make security decisions and set direction.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| GV-1 | Who in the organisation is ultimately accountable for cybersecurity? Do they have budget authority? | "If there were a breach tonight, who would make decisions about disclosure and remediation?" |
| GV-2 | Does the organisation have a documented cybersecurity policy? When was it last reviewed? | "Has anyone read it in the past 12 months? Does it reflect what you actually do?" |
| GV-3 | Is cybersecurity risk formally reported to the board or executive committee? How often? | "What does the board actually see? Risk ratings? Incident summaries? Nothing?" |
| GV-4 | Are security roles and responsibilities clearly assigned and understood by the people who hold them? | "If I asked your IT manager what their security responsibilities are, would their answer match your expectation?" |
| GV-5 | Does the organisation have a process for reviewing and approving new technology before deployment? | "How was your last major SaaS tool evaluated before procurement?" |
| GV-6 | Are third-party suppliers and vendors assessed for security risk? | "Do you know whether your critical suppliers have had breaches in the past year?" |
**Key insight to surface**: Most SMBs have "security responsibility" informally assigned to whoever manages IT. This is not the same as having an accountable executive. The gap is usually not technical — it is governance.
---
### ID — IDENTIFY
*Develops organisational understanding of assets, business context, resources, and capabilities to manage cybersecurity risk.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| ID-1 | Does the organisation maintain an inventory of its hardware assets? Is it current? | "If I asked you right now how many laptops your company owns, could you tell me?" |
| ID-2 | Does the organisation maintain an inventory of software and SaaS services in use? | "Do you know which SaaS tools your employees are using with company data? Including the unofficial ones?" |
| ID-3 | Are the organisation's most critical business processes and the data they depend on documented? | "Which three systems, if unavailable for a week, would most threaten the business?" |
| ID-4 | Has a risk assessment been conducted in the past 12 months? | "Who conducted it? Was it technical-only, or did it include business process risk?" |
| ID-5 | Are data classification levels defined and applied to sensitive data? | "Do employees know which documents are confidential and what that means in practice?" |
| ID-6 | Does the organisation understand its external attack surface (public-facing services, domains, IP ranges)? | "Have you ever scanned your own organisation from the outside?" |
**Key insight to surface**: The gap between "we have an asset register" and "we have a current, accurate asset register that security decisions are based on" is almost always larger than the client expects.
---
### PR — PROTECT
*Develops and implements appropriate safeguards to ensure delivery of critical services.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| PR-1 | Is multi-factor authentication enforced for all user accounts, including administrative accounts? | "Are there any exceptions? VPN access? Legacy applications? Shared accounts?" |
| PR-2 | How are privileged (administrative) accounts managed? Are they separate from daily-use accounts? | "Does your IT admin check email from the same account they use to manage servers?" |
| PR-3 | Are software updates and patches applied systematically across all devices? What is the typical lag? | "How long after Microsoft releases a critical patch do your endpoints typically receive it?" |
| PR-4 | Is sensitive data encrypted at rest and in transit? | "If a laptop were stolen tonight, could an attacker access the data on it?" |
| PR-5 | Is access to systems based on least privilege (minimum necessary access)? | "When a new employee joins, what do they get access to by default?" |
| PR-6 | Is there a security awareness training programme for all employees? When did the last session occur? | "If I phished your employees today, roughly what percentage would click the link?" |
| PR-7 | Are endpoint devices protected with up-to-date anti-malware/EDR? What is the coverage percentage? | "Are there devices — personal laptops, BYOD — that access company data without endpoint protection?" |
**Key insight to surface**: Most organisations have MFA deployed but not enforced. The distinction matters enormously — "deployed" means it exists; "enforced" means no one can bypass it.
---
### DE — DETECT
*Develops and implements appropriate activities to identify the occurrence of a cybersecurity event.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| DE-1 | Is there centralised logging for critical systems? Who reviews the logs? | "Where do your server logs go? When was the last time someone looked at them for a non-incident reason?" |
| DE-2 | Are there automated alerts for security-relevant events? | "What would trigger an alert tonight if someone was trying to brute-force your admin account from a foreign country?" |
| DE-3 | Is there monitoring for unusual user behaviour (logins outside business hours, large data exports)? | "Would you know if an employee downloaded every document from your SharePoint tonight?" |
| DE-4 | How are security alerts triaged and escalated? Who receives them? | "If your SIEM generated 100 alerts tonight, who would see them? Tomorrow morning? Or immediately?" |
| DE-5 | Has the effectiveness of detection controls been tested? | "When did you last verify that your monitoring would actually catch something?" |
**Key insight to surface**: Most clients have logs. Almost none have someone reading them. "We log everything" and "we detect threats" are different capabilities.
---
### RS — RESPOND
*Develops and implements appropriate activities to take action regarding a detected cybersecurity incident.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| RS-1 | Does the organisation have a documented incident response plan? | "Has it been tested? Does it include contact lists, decision trees, and communication templates?" |
| RS-2 | Who is responsible for declaring an incident and coordinating the response? | "At 2 AM on a Saturday, if ransomware is spreading through the network, who makes the call to isolate systems?" |
| RS-3 | Does the organisation have an out-of-band communication channel for incident response? | "If your email and Teams are down during an incident, how do you communicate?" |
| RS-4 | Are external parties (legal counsel, IR firm, insurer, regulator) pre-identified and contracted? | "Do you have a relationship with a cyber insurer? An incident response retainer? Legal counsel familiar with data breach notification?" |
| RS-5 | How are lessons from incidents or near-misses captured and acted on? | "Can you give an example of a process that changed because of a security incident in the last two years?" |
**Key insight to surface**: Most organisations have an incident response plan that has never been tested. An untested plan is not a plan. It is a document. The question to ask is: "When did you last pretend to have a ransomware incident?"
---
### RC — RECOVER
*Develops and implements appropriate activities to maintain plans for resilience and to restore any capabilities impaired by a cybersecurity incident.*
| # | Question | Probe If Unclear |
|---|----------|-----------------|
| RC-1 | Does the organisation back up its critical systems? How often? Are backups tested? | "When was the last time you restored from backup? Not copied — actually restored and verified it worked?" |
| RC-2 | Are backups stored separately from the primary systems (offline or immutable)? | "If ransomware encrypted your servers tonight, could it also reach your backups?" |
| RC-3 | Are recovery time objectives (RTOs) and recovery point objectives (RPOs) defined for critical systems? | "If your core system went down, how long could the business operate without it? An hour? A day? A week?" |
| RC-4 | Are recovery procedures documented and known to the people who would execute them? | "If your primary IT person were unavailable during an incident, could someone else execute the recovery?" |
| RC-5 | Has a full recovery drill been conducted for at least one critical system? | "Have you ever actually rebuilt a server from backup in a test environment to verify the process works?" |
**Key insight to surface**: Backups that have not been restored are not backups. They are hopes. The most common discovery in this domain is that backups exist, but no one has verified they are consistent, complete, or restorable in the required timeframe.
---
## Scoring and Gap Analysis
After completing all domains, compile the scores into a summary matrix:
| Domain | Score | Critical Gaps (🔴) | Notable Strengths (🟢) |
|--------|-------|-------------------|----------------------|
| GOVERN | | | |
| IDENTIFY | | | |
| PROTECT | | | |
| DETECT | | | |
| RESPOND | | | |
| RECOVER | | | |
**Domain score**: Count of 🟢 items ÷ total items. Not a precise metric — a discussion tool for prioritisation.
**The kill chain overlay**: After scoring, ask one more question:
> *"Based on what we have discussed, what is the shortest path from 'nothing bad has happened yet' to 'the organisation cannot operate'? Walk me through it."*
This produces the kill chain. The modules that close the kill chain are the priority recommendation.
---
## Report Structure
The assessment produces a two-part deliverable:
### Part 1: Current State Report (delivered 5 business days post-workshop)
1. **Executive Summary** — one page; overall posture, three critical gaps, three key strengths
2. **Domain Findings** — per domain: current state, evidence gaps, key risks
3. **Kill Chain Analysis** — the shortest path to organisational failure based on workshop findings
4. **Quick Wins** — up to 5 items that can be improved in < 30 days with existing tools and no budget
### Part 2: Remediation Roadmap (included with Part 1)
Maps findings directly to antifragile modules:
| Priority | Gap | Module | Estimated Effort |
|----------|-----|--------|-----------------|
| P0 (kill chain) | [Finding] | [Module #] | [Duration] |
| P1 (critical) | [Finding] | [Module #] | [Duration] |
| P2 (important) | [Finding] | [Module #] | [Duration] |
---
## Mapping to Module Selection
| Common Assessment Finding | Recommended Entry Module |
|--------------------------|-------------------------|
| No asset inventory; unknown attack surface | Module 1 (Endpoint) + Module 3 (M365 Hardening) |
| MFA deployed but not enforced; weak identity hygiene | Module 2 (Identity Security) |
| No logging or alerting; "blind" to attacks | Module 3 (M365 Hardening) + Module 12 (Blue/Purple Team) |
| Backups exist but untested; no recovery drill | Module 7 (Recovery & Resilience) |
| OT/IT network not segmented; no vendor access control | Module 8 (OT Security) + Module 13 (Privileged Access) |
| AD in poor health; stale accounts; no PAW | Module 6 (On-Premise AD Hardening) |
| No incident response plan or crisis comms | Module 14 (Sovereign Communications) + Module 7 |
| Tools owned but not used; teams feel out of control | Module 11 (Embedded Quality) |
| Dev and security siloed; slow release cycles | Module 9 (Organisational Resilience) |
| MSSP underperforms; no custom detection | Module 12 (Blue/Purple Team) |
---
## Pricing and Engagement Model
This assessment is a **standalone paid engagement**, not a free scoping call.
**Typical scope**:
- Pre-engagement preparation: 2 hours
- Two half-day workshop sessions: 8 hours total
- Report preparation: 48 hours
- Report presentation and Q&A: 2 hours
- **Total consultant time**: 1620 hours
**What it produces**:
- A clear, honest picture of where the organisation stands
- An evidence-based module recommendation (not a generic "you need more security" pitch)
- A prioritised roadmap the client can act on immediately, with or without engaging further
**The pitch**:
> *"Before we recommend anything, we want to understand exactly where you are. This assessment takes two half-days and produces an honest report: your strengths, your gaps, and the three things that matter most to fix. If we recommend modules after this, you will understand exactly why. If you decide not to proceed, you still have a roadmap you can execute independently. Either outcome is a good outcome."*
---
## Integration With Existing Frameworks
| Document | Integration |
|----------|-------------|
| [NIST CSF 2.0 Mapping](../reference/nist-csf-mapping.md) | This assessment operationalises the framework mapping — the questionnaire domains map directly to the reference |
| [Modular Engagements](../core/modular-engagements.md) | Assessment findings drive the Diagnostic Path and module selection |
| [Antifragile Risk Register](antifragile-risk-register.md) | Assessment findings populate the initial risk register |
| [Rapid Modernisation Plan](../playbooks/rapid-modernisation-plan.md) | Phase 1 (Hygiene) exit criteria mirror the Identify and Protect domain findings |
| [Business Case Template](../playbooks/business-case-template.md) | Assessment findings provide the risk quantification input for the business case |
---
*For the standards reference, see [NIST CSF 2.0 Mapping](../reference/nist-csf-mapping.md).*
*For the module selection process, see [Modular Engagements](../core/modular-engagements.md).*
*For the risk register template, see [Antifragile Risk Register](antifragile-risk-register.md).*
*Česká verze (pro workshopy vedené v češtině): [Základní hodnocení NIST CSF 2.0](nist-csf-baseline-cs.md)*