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
parent 7bab42398a
commit 64f73371c9
24 changed files with 3325 additions and 66 deletions
@@ -0,0 +1,372 @@
+# Consultant Field Guide
+
+> *"The philosophy tells you what to value. This document tells you how to make the call when two things you value are in conflict."*
+
+This document is the internal complement to the [Engagement Model](engagement-model.md). The engagement model covers the mechanics of delivery: how engagements are structured, scoped, priced, and handed over. This document covers the thinking behind the work — the mental models, the qualification filters, the prioritisation logic, the failure patterns, and the technical onboarding path.
+
+Read the [Engagement Model](engagement-model.md) first. Then read this.
+
+---
+
+## Part 1: How We Make Decisions
+
+Five types of decisions arise in every engagement. The philosophy documents describe what to value. This section describes how to make the call in practice.
+
+---
+
+### Decision Type 1: Prioritisation
+
+**The question**: Which of the client's ten problems do we fix first?
+
+**The mental model**: The kill chain test.
+
+Ask: *"If this is not fixed and an adversary exploits it, does the organisation fail to operate?"*
+
+- **Yes** → P0. Fix before anything else. Do not leave until it is closed or mitigated.
+- **No, but material damage results** → P1. Close within the engagement.
+- **No** → P2. Document it, put it in the risk register, schedule it for a later module.
+
+P0 examples: Domain admins logging in from email/browsing workstations. Backups that have never been restored. Internet-facing systems with unpatched critical CVEs. MFA not enforced on any account.
+
+The most common prioritisation failure: treating forty findings as equally important because they all appeared in the same scan output. A client who fixes a P2 before their P0 has been made less safe, not more. Rank everything. Communicate the ranking loudly.
+
+---
+
+### Decision Type 2: Tool Selection
+
+**The question**: Do we use what the client owns, an open-source tool, or a commercial product?
+
+**The mental model**: The sovereign test — applied in order.
+
+1. Can we close this gap with what the client already owns or has already paid for? If yes, configure and operationalise it. Do not recommend anything else.
+2. If not, can we close it with an open-source tool in the sovereign tool stack? If yes, deploy it.
+3. If not — because the gap requires 24/7 managed response we cannot staff, compliance genuinely requires a vendor attestation, or the scale exceeds what open-source handles efficiently — then recommend the appropriate commercial partner.
+
+The test for step 3: *"Would I make this recommendation if I earned no more from it than from deploying the open-source alternative?"* If the answer is no, the recommendation is compromised.
+
+When you do recommend a commercial tool, disclose the partnership relationship at the moment of recommendation. Not in the footnotes.
+
+---
+
+### Decision Type 3: Scope
+
+**The question**: Is this request within scope? If the scope needs to change, how?
+
+**The mental model**: The completion-criteria test.
+
+A scope is defined only when you can write a sentence of the form: *"The work is complete when [verifiable condition]."* If you cannot write that sentence, the scope is not defined. Undefined scope is undeliverable.
+
+For scope changes during delivery:
+- Is the request something the agreed completion criteria would reasonably require? → Absorb it.
+- Is it genuinely new work? → Change order, written, before execution.
+- Is it something you should have scoped initially but missed? → Absorb it and note it as a scoping lesson.
+
+Never retroactively charge for out-of-scope work you did without a change order. Never silently absorb work that should be a change order. Both erode trust, in different directions.
+
+---
+
+### Decision Type 4: Communication
+
+**The question**: How do I communicate a difficult finding, a risk, a scope problem, or a project delay?
+
+**The mental model**: The "would I want to know?" test — applied to timing and framing.
+
+- Say it early. The client's distress from a critical finding is proportional to how long they were not told about it.
+- Say it plainly. No hedging, no softening, no burying in a paragraph of context.
+- Say what it means in business terms, not technical ones. "Your KRBTGT password is 847 days old" is a technical finding. "An attacker who compromises any domain account can forge authentication tokens valid for up to 847 days, which means we cannot trust any AD authentication even after we reset passwords" is a business finding.
+- Then say what we do about it.
+
+The sequence: *finding → business impact → recommended action → timeline*. Always in that order.
+
+---
+
+### Decision Type 5: Recommendation
+
+**The question**: What should the client do next?
+
+**The mental model**: The independence test.
+
+Before making any recommendation, ask: *"If I had no commercial relationship with any vendor and no financial stake in the client's decision, would I still make this recommendation?"* If yes, make it. If no, find the recommendation you would make under those conditions, and make that one instead.
+
+A recommendation that enriches you at the client's expense is not a recommendation. It is a conflict of interest wearing a consultant's jacket. The long-term value of independence — referrals, retained relationships, reputation — always exceeds the short-term value of a compromised recommendation.
+
+---
+
+## Part 2: The Discovery Call
+
+The discovery call happens before the Brownhat Diagnostic. Its purpose is not to sell anything. It is to determine whether this client is a fit for our work and whether we are a fit for their situation.
+
+### What to ask
+
+**The trigger question**: *"What happened recently that made you call us?"*
+
+Listen for: a specific incident, an audit finding, a regulatory deadline, a new hire who saw problems, a breach at a peer organisation. The trigger shapes everything — it tells you which domain is most sensitive, who the executive sponsor is, and how much urgency is real versus performed.
+
+**The accountability question**: *"Who in your organisation is ultimately accountable for security outcomes?"*
+
+Listen for: a specific person with budget authority. "Everyone is responsible" means no one is. Without a named executive sponsor who can make decisions and approve changes, the engagement will die in committee.
+
+**The tools question**: *"What tools do you have? M365 licensing level? Any existing EDR, SIEM, or PAM?"*
+
+This tells you how much existing tooling can be leveraged before any purchase is needed. An E5 client with underused Defender has a different engagement structure than an E3 client with no EDR at all.
+
+**The history question**: *"Have you had any incidents or near-misses in the past two years?"*
+
+Incidents reveal the actual threat landscape, the real response capability, and what the organisation already knows about its weaknesses. Post-incident clients have more internal urgency — and often more political complexity.
+
+**The success question**: *"What does success look like at the end of this engagement?"*
+
+Listen for specificity. "We want to be more secure" is not a success definition. "We want to pass our NIS2 audit in Q2 without findings" is. Clients who cannot articulate success criteria cannot be satisfied — they will always want more, differently, and retroactively.
+
+---
+
+### What disqualifies a client
+
+Some client situations are not a fit. Recognising them before starting an engagement is a service to the client and to yourself.
+
+| Signal | What it means | Response |
+|--------|--------------|---------|
+| No executive sponsor with decision authority | The engagement will require every decision to go through a committee that never meets | Ask who can approve changes in 24 hours. If the answer is unclear, do not start. |
+| "We just need a compliance certificate" | They want a stamp, not resilience | Redirect to a compliance auditor who will produce the stamp. We produce evidence; the stamp is a side effect. If they only want the side effect, we are the wrong provider. |
+| "We already know what we need, skip the diagnostic" — and no documentation to support this | High risk of undiscovered scope and mid-engagement surprises | See the [Engagement Model](engagement-model.md), Section 7. Never skip without equivalent documentation. |
+| The named project contact has no visibility into IT operations | You will spend half your time waiting for access and information | Escalate to the executive sponsor; require a named IT lead with operational access as a kickoff prerequisite. |
+| Budget so constrained that the Brownhat Diagnostic consumes most of it | There is no room to act on the findings; the diagnostic becomes a dead-end exercise | Have an honest conversation: the diagnostic is valuable standalone, but acting on it requires further investment. Confirm the client understands and accepts that constraint. |
+
+---
+
+### When to say no
+
+Decline engagements where:
+
+- The client wants findings presented to a regulator as "third-party validation" of work the client designed themselves, without independent assessment
+- The client has been vague or inconsistent about material facts during discovery — this will worsen during delivery
+- The scope involves active offensive operations against third parties without written authorisation from the targets
+- The client's goal is to reduce a finding's severity in an existing audit rather than to close the actual gap
+
+Saying no is not a failure. It is judgment. A reputation for honesty about fit is worth more than any single engagement.
+
+---
+
+## Part 3: Module Selection — When the Client Can Only Afford One
+
+The Brownhat Diagnostic produces a prioritised module roadmap. When the client has budget for one module and multiple problems, the selection logic is:
+
+**Step 1: What is the kill chain?**
+
+From the diagnostic findings, identify the shortest path from "nothing bad has happened yet" to "the organisation fails." The module that closes the highest-priority node on that path is the right recommendation.
+
+**Step 2: If two modules address the same node, choose the faster time-to-value.**
+
+Module 6 (AD Hardening) closes more attack paths faster than Module 12 (Blue/Purple Team) for a client with a degraded AD. But Module 12 produces detection capability that persists. If both are equal by kill-chain analysis, choose the module that produces durable, operational output over the module that produces a point-in-time fix.
+
+**Step 3: Never recommend a later-stage module when an earlier-stage gap is unaddressed.**
+
+Detection engineering (Module 12) is waste if identity is uncontrolled (Module 2). A red team engagement (Module 10) will find what the kill chain already shows if the basic hygiene isn't done. The right answer is almost always the module that fixes the foundation — not the module that tests it.
+
+---
+
+### Common single-module scenarios
+
+| Client situation | First module | Rationale |
+|-----------------|-------------|-----------|
+| "Our AD is a mess — stale accounts, no tiering, legacy configs" | **Module 6** | Closes the most attack paths fastest; produces durable structural improvement |
+| "We had a phishing incident; accounts were compromised" | **Module 2** | The exploit path was identity; fix the foundation before adding detection on top of it |
+| "We have no visibility — we would not know if we were breached" | **Module 1** then **Module 12** | Endpoint management establishes the asset baseline; blue/purple team builds detection on top |
+| "DORA audit in 5 months" | **Brownhat Diagnostic** first | The diagnostic maps the gaps to specific controls; module selection follows from the audit findings |
+| "Our MSSP generates 300 alerts a day and nothing gets fixed" | **Module 12** | The MSSP problem is a detection engineering problem; retained capability closes it |
+| "We are moving to M365 and want to do it right" | **Module 1** → **Module 2** → **Module 3** | In sequence: endpoint baseline, identity security, then hardening |
+| "We have OT and IT on the same flat network" | **Module 8** | The segmentation gap is existential; close it before any other work |
+
+---
+
+## Part 4: The Ten Most Common Mistakes
+
+These are the failure patterns that appear most often in first engagements. They are not failures of competence. They are failures of discipline — usually under client pressure, time pressure, or social discomfort.
+
+---
+
+**1. Starting with recommendations before understanding**
+
+Recommending modules, tools, or configurations before the Brownhat Diagnostic is complete. The savings in week 1 cost three times as much in week 5 when the undiscovered scope surfaces.
+
+---
+
+**2. Scope without completion criteria**
+
+Agreeing to "improve AD security" or "harden the M365 tenant" without writing down what "improved" and "hardened" mean in verifiable terms. The work never ends; the client never feels satisfied; the invoice is always a surprise.
+
+---
+
+**3. Absorbing scope creep silently**
+
+Doing out-of-scope work to avoid the discomfort of raising a change order. This trains the client that scope is negotiable and invoices are estimates. It feels worse at billing time than the conversation would have felt mid-engagement.
+
+---
+
+**4. Leaving without runbooks**
+
+Completing technically excellent work without documenting how to operate it. Three months later, something changes or breaks, and nobody on the client side knows how the system works. The client calls back — but not with gratitude.
+
+---
+
+**5. Recommending a purchase before demonstrating existing-tools value**
+
+Proposing a new commercial tool in week 2 before showing the client what their existing investments can do. This looks like reselling, not consulting. It destroys the credibility of the "existing tools first" principle in the same engagement where you invoked it.
+
+---
+
+**6. Hiding bad news**
+
+Discovering a critical finding and softening it to manage the client's reaction. The client's distress from a critical finding is proportional to how long they were not told about it. Say it plainly, frame the remediation, and let the client's reaction be what it is.
+
+---
+
+**7. Over-promising timelines**
+
+Committing to module durations based on the nominal calendar, knowing that the client's access provisioning, decision-making cadence, and existing workload will add weeks. Scope to the realistic case; under-promise and over-deliver.
+
+---
+
+**8. Treating all findings as equally urgent**
+
+Producing a finding list with thirty items where a P0 and a P2 look identical. The client picks items by recognition or by urgency they invent, and the kill chain remains open. Make the priority structure impossible to miss — it should be the first thing a client sees, not something they have to infer.
+
+---
+
+**9. Making changes without explicit client approval**
+
+Even obviously correct changes. The technical work is not the only product of the engagement — trust is also a product. Trust is built on consent, not just competence. Every production change has explicit written approval before execution.
+
+---
+
+**10. Confusing baseline for delivery**
+
+Week 1 produces the baseline. It does not produce improvements. Clients sometimes interpret a week of scanning and documentation as slow progress and apply pressure to start making changes. The week 1 discipline is non-negotiable. Explain why: *"Everything we change in week 2 will be benchmarked against what we documented in week 1. Without the baseline, we cannot measure the improvement. And we cannot improve safely what we do not yet understand."*
+
+---
+
+## Part 5: Technical Onboarding
+
+### CQRE tool repositories
+
+Before leading a module, you need to be able to deploy and use the tools that module depends on. All CQRE tools are hosted at git.cqre.net:
+
+| Tool | Repository | Used in |
+|------|-----------|---------|
+| **ASTRAL** | `cqrenet/astral` (public) · `cqrenet/Intune` (internal, full version) | Modules 1, 2, 3 |
+| **AOC** | `cqrenet/aoc` | Modules 2, 3, 12; retained capability |
+| **macOS_IntuneManagement** | `cqrenet/macOS_IntuneManagement` | Module 1; tenant migrations |
+| **Elysium** | `cqrenet/elysium` | Module 6, 10 |
+| **CAExporter** | `vibecoding/CAExporter` | Modules 2, 3 |
+| **E8-CAT** | `vibecoding/E8-CAT` | Modules 1, 3 |
+| **IntunePolicyParser** | `vibecoding/IntunePolicyParser` | Module 1; alongside ASTRAL |
+| **M365-Scripts** | `cqrenet/M365-Scripts` | Module 1 (MDE device lifecycle) |
+
+Each repository contains its own README with deployment instructions. Read the README and deploy the tool in a lab environment before using it with a client. Do not learn a tool at a client's expense.
+
+### Required competencies before leading each module
+
+This is the minimum bar for leading (not shadowing) a module. If you are not there yet, shadow the module first.
+
+| Module | Minimum competency |
+|--------|-------------------|
+| **Module 1** (Endpoint) | PowerShell 7+; Intune policy structure; ASTRAL deployment and configuration; E8-CAT scoring |
+| **Module 2** (Identity) | Entra ID architecture; Conditional Access design; PIM/PAM concepts; AOC deployment; CAExporter export and analysis |
+| **Module 3** (M365 Hardening) | Modules 1 and 2 competency; Prowler Azure audit; ASTRAL drift detection; ASR rules |
+| **Module 6** (AD Hardening) | Active Directory architecture; BloodHound collection and analysis; DSInternals and Elysium operation; LAPS deployment; GPO design; Sysmon configuration |
+| **Module 8** (OT Security) | OT/IT network segmentation concepts; NIS2 Article 21 and 23 requirements; SCADA/ICS risk framing; Zeek or Suricata basics |
+| **Module 12** (Blue/Purple Team) | MITRE ATT&CK framework; KQL or Sigma rule authoring; Wazuh deployment; TheHive and Shuffle basics; detection engineering fundamentals |
+| **Module 13** (Privileged Access) | WireGuard protocol; Tailscale and Headscale deployment; Teleport architecture and session recording; SSH certificate authority concepts |
+| **Module 14** (Sovereign Communications) | Delta Chat and chatmail relay deployment; Matrix/Synapse basics (for enterprise deployments); out-of-band communication design |
+
+### Building your lab environment
+
+Before your first client engagement, build a personal lab that lets you safely test deployments:
+
+- **M365 developer tenant** — Microsoft's free developer programme provides an E5 tenant. Use it for ASTRAL, AOC, CAExporter, and M365 module testing. Register via the Microsoft 365 Developer Programme.
+- **A small Linux VM (any cloud)** — For chatmail relay, Wazuh, TheHive, and Shuffle deployments. A €5–10/month VPS is sufficient for personal lab use.
+- **A Windows Server VM** — For AD module testing: BloodHound, Elysium, LAPS, Sysmon. Can be local (Hyper-V, VMware) or cloud.
+- **A CQRE internal environment** — Ask for access to the shared lab environment used for tool testing and client demos.
+
+The rule: you must have deployed and operated every tool you plan to use with a client, in a controlled environment, before the client engagement begins.
+
+---
+
+## Part 6: Writing a Proposal
+
+A Brownhat engagement proposal has four parts, in this order:
+
+---
+
+### Part 1: What we found
+
+Two to five specific findings from the Brownhat Diagnostic or discovery call. Not generic risk language. Specific observations:
+
+> *"Your Active Directory contains 847 user accounts, of which 312 have not been accessed in over 12 months. Eleven domain administrator accounts exist; six are used for daily workstation tasks including email and web browsing. The KRBTGT password has not been rotated in 1,247 days."*
+
+The client should recognise their environment in this section. If they do not, the discovery was not thorough enough.
+
+---
+
+### Part 2: What we recommend
+
+One specific module — the one that closes the highest-priority gap from the diagnostic. With an explicit scope: the deliverables, the completion criteria, and what is out of scope.
+
+> *"We recommend Module 6: On-Premise AD Hardening. Scope: BloodHound attack path analysis and remediation report; Elysium password audit with prioritised remediation list; LAPS deployment to all domain-joined workstations (confirmed 100% coverage); KRBTGT rotation; reduction of Global Administrator accounts to a documented minimum; operating runbook for ongoing AD hygiene.*
+> *Out of scope: Azure AD Connect hardening (Module 2), endpoint EDR deployment (Module 1), and any changes to OT network infrastructure.*
+> *Complete when: LAPS coverage is verified at 100%, KRBTGT rotation is confirmed, and the privileged account count and BloodHound attack path count are documented against the post-engagement baseline."*
+
+---
+
+### Part 3: What you will receive
+
+The Module Completion Package for this specific module. Restate the standard package (from the [Engagement Model](engagement-model.md)) with module-specific additions:
+
+> *"At completion of this engagement, you will receive: a configuration baseline document; the BloodHound and Elysium output files delivered to your own repository; operating runbooks for LAPS management, KRBTGT rotation cadence, and privileged account review; an updated risk register entry for each finding; a before-and-after AD security score (PingCastle); and a recommended next module with rationale."*
+
+---
+
+### Part 4: Investment
+
+| Item | Detail |
+|------|--------|
+| **Consultant effort** | [N] days |
+| **Calendar timeline** | [Start date] → [Completion date] |
+| **Infrastructure** | [Any costs, e.g., chatmail relay €5–10/month] |
+| **External licensing** | [None / or specify] |
+| **Total** | [Fixed fee in €] |
+
+Include a note on payment terms (e.g., 50% at kickoff, 50% at completion).
+
+---
+
+### What never goes in a proposal
+
+| Never include | Why |
+|---------------|-----|
+| Vague risk language ("your organisation faces significant cybersecurity risks") | Every client already believes this. It adds no information and signals you do not know their specific situation. |
+| Tool shopping lists before the diagnostic | Recommending specific products before understanding the environment is reselling, not consulting. |
+| Pricing ranges | A range signals that you do not know the scope. Scope it properly and give a fixed price. |
+| Multi-year commitments in a first proposal | The client has not yet seen you work. Earn the next engagement. |
+| Best-case timelines presented as the estimate | The client will hold you to them. Scope to the realistic case. |
+| A list of everything you found rather than a prioritised narrative | Volume is not insight. A proposal is not a scan report. |
+
+---
+
+## Integration With Existing Frameworks
+
+| Document | Relationship |
+|----------|-------------|
+| [Engagement Model](engagement-model.md) | The operational complement: delivery mechanics, client requirements, pricing structure, communication cadence. Read first. |
+| [Move Fast and Fix Things](move-fast-and-fix-things.md) | The source of the "existing tools first" and "fix the kill chain first" principles operationalised in Part 1 |
+| [NIST CSF 2.0 Baseline Assessment](../assessment-templates/nist-csf-baseline.md) | The Brownhat Diagnostic: the entry point for every new client, referenced throughout Parts 2 and 3 |
+| [Modular Engagements](modular-engagements.md) | The full module menu: descriptions, durations, investment levels, and per-module deliverables referenced in Parts 3 and 6 |
+| [Sovereign Tool Stack](../playbooks/sovereign-tool-stack.md) | The tool selection doctrine (sovereign test), the per-module tool pairings, and the commercial partnership framework |
+| [C-Suite Conversation Guide](c-suite-conversation-guide.md) | The client-facing persuasion scripts and objection handling that complement the internal decision models in this document |
+| [Antifragile Risk Register](../assessment-templates/antifragile-risk-register.md) | The risk register format used in the module completion package and referenced in prioritisation |
+
+---
+
+*For delivery mechanics and pricing, see [Engagement Model](engagement-model.md).*
+*For module descriptions and selection, see [Modular Engagements](modular-engagements.md).*
+*For client-facing scripts, see [C-Suite Conversation Guide](c-suite-conversation-guide.md).*