cqrenet/antifragile
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Add engagement model, consultant field guide, deliverable templates, CQRE tools integration, and Czech localization

Browse Source 
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>
This commit is contained in:
Tomas Kracmar
2026-05-27 21:33:52 +02:00
parent 7bab42398a
commit 64f73371c9
24 changed files with 3325 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files
antifragile-consulting/playbooks/privileged-access-architecture.md
+223
View File
@@ -0,0 +1,223 @@
# Privileged Access Architecture
> *"Your VPN authenticates people to your network. Your PAM authenticates people to specific resources inside it. Most organisations deploy neither correctly. The result is a flat network where a compromised laptop reaches every server, and a stolen VPN credential reaches everything else."*
## For the Executive Reader
Every organisation has two access control problems hiding behind the label "VPN":
1. **Who can reach the network?** The VPN problem — getting authorised people onto the network at all.
2. **Who can touch which specific systems?** The PAM problem — ensuring that once inside the network, users can only reach what they need, nothing more, and every action is recorded.
Most organisations solve the first problem badly (legacy VPN, IP whitelisting, overlapping access methods nobody remembers creating) and ignore the second entirely. An attacker who compromises a VPN credential in this configuration has access to everything.
The antifragile answer is a two-layer architecture: **network access** (Tailscale or Headscale) sitting in front of **protocol-aware privileged access** (Teleport). Each layer can be deployed independently. Together they close the most common kill chain in the playbook.
*For module selection, see [Modular Engagements](../core/modular-engagements.md). For the asset classification that determines which systems require PAM, see [T0 Asset Framework](../core/t0-asset-framework.md).*
---
## The Two Layers
### Layer 1: Network Access — Tailscale / Headscale + WireGuard
**What it solves**: Replace the legacy VPN sprawl. Admins and remote workers get secure, identity-aware access to internal networks without exposing services to the internet.
**How it works**: WireGuard mesh VPN managed by a control plane (Tailscale as a service, or Headscale self-hosted). Every device gets a node identity. Access is controlled by ACL policies, not IP rules. No open firewall ports required on servers.
**Why it matters for security**:
- Eliminates the "VPN = everything" flat-network problem via ACL policies
- Every connection is mutually authenticated (device certificate + identity)
- Audit log of who connected to what, when
- Access can be revoked instantly by removing a node from the control plane
### Layer 2: Protocol-Aware PAM — Teleport
**What it solves**: Once someone is on the network, enforce *which specific servers, databases, and Kubernetes clusters* they can access — and record every session in a tamper-evident audit trail.
**How it works**: Teleport proxies connections to SSH servers, Windows hosts (RDP), Kubernetes clusters, and databases. Users authenticate once (SSO/MFA); Teleport issues short-lived certificates. Sessions are recorded and searchable. No static credentials stored on servers.
**Why it matters for security**:
- Eliminates shared/static credentials on servers (`root`, `administrator`)
- Just-in-time access: permissions expire, removing standing access
- Session recording: every `sudo`, every SQL query, every RDP session
- Auditor-ready evidence: access logs that regulators actually accept
---
## Tool Details
### Teleport
| Attribute | Detail |
|-----------|--------|
| **What it does** | Protocol-aware privileged access proxy for SSH, RDP, Kubernetes, databases, and internal web applications. Short-lived certificates. Full session recording. |
| **Antifragile pillar** | Sovereign Intelligence, Structural Decoupling |
| **Open-source status** | Community Edition (CE) is open-source and self-hosted |
#### CE Eligibility — Be Honest With Clients
Teleport CE is an excellent, capable product. The licensing constraint is important to communicate clearly:
> **Teleport CE is free for organisations with fewer than 100 employees AND less than $10M annual revenue.** Both conditions must be met.
This catches more clients than it appears. A manufacturing company with 800 employees and 6 administrators who would touch Teleport **cannot** legally deploy CE, even though it would work perfectly for their use case. When in doubt, check with the client's legal team before deploying CE at scale.
| Scenario | Recommendation |
|----------|---------------|
| < 100 employees, < $10M revenue | **Teleport CE** — free, self-hosted, full feature set for this scale |
| > 100 employees OR > $10M revenue | **Teleport Enterprise** (commercial) or see Alternatives below |
| Client needs vendor support | **Teleport Enterprise** regardless of size |
| Client has sovereign data mandate | **Teleport CE or Enterprise self-hosted** (both are self-hosted) |
| OT/SCADA vendor remote access at scale | **Teleport Enterprise** — session recording and just-in-time access are critical |
#### Teleport CE vs Enterprise Feature Comparison
| Feature | CE | Enterprise |
|---------|-----|-----------|
| SSH, RDP, K8s, DB access proxying | ✅ | ✅ |
| Session recording | ✅ | ✅ |
| Short-lived certificates | ✅ | ✅ |
| SSO integration | ✅ | ✅ |
| Just-in-time (JIT) access | ✅ | ✅ |
| Access request workflows | ✅ | ✅ |
| Device trust (trusted devices only) | Limited | ✅ |
| Access monitoring & alerts | Limited | ✅ |
| FedRAMP / compliance reports | ❌ | ✅ |
| Commercial support SLA | ❌ | ✅ |
| High availability clustering | Limited | ✅ |
| **License restriction** | **< 100 employees AND < $10M revenue** | None |
**The conversation for non-qualifying clients**:
> *"Teleport CE would work technically — your admins would love it. The license terms prohibit it for organisations your size. We can deploy Teleport Enterprise (priced per protected resource, not per user), or we can architect the network access layer with Tailscale and use certificate-based SSH access for the protocol layer. Both are valid paths. The right choice depends on whether session recording and JIT workflows are on your auditor's checklist."*
---
### Tailscale — Commercial Partnership
| Attribute | Detail |
|-----------|--------|
| **What it does** | Managed WireGuard mesh VPN. Every device gets a node identity. Access controlled by ACL policies. Works on any device, any OS, any cloud. |
| **Why we partner** | Tailscale provides the managed control plane, commercial support, and SSO integrations that make enterprise deployment painless. Per-user pricing is predictable. |
| **Sovereign alternative** | Headscale (open-source self-hosted control plane for WireGuard) — see below |
| **Antifragile pillar** | Structural Decoupling, Optionality Preservation |
| **Engagement modules** | Module 2 (Identity Security), Module 6 (AD Hardening), Module 8 (OT Security), Module 13 (this module) |
**When to recommend Tailscale (commercial)**:
- Client wants commercial support and SLA
- Client needs Tailscale's SSO integrations (Okta, Azure AD, Google)
- Client has a mixed-device estate that benefits from Tailscale's client apps
- Client's procurement requires a vendor contract
**The conversation**:
> *"You currently have a legacy VPN that requires a specific client, routes all traffic through your data centre, and gives everyone access to the same network. Tailscale replaces it with a mesh that puts every authorised device directly in contact with every authorised resource — no central bottleneck, no broad network exposure. An admin in Prague connects to the server in Vienna as if they are on the same LAN. A supplier accesses only the one application they need, nothing else. When you revoke access, it is immediate and complete."*
---
### Headscale + WireGuard — Sovereign Alternative
| Attribute | Detail |
|-----------|--------|
| **What it does** | Self-hosted control plane (Headscale) for WireGuard mesh networks. Functionally equivalent to Tailscale without the external control plane. Data never leaves client infrastructure. |
| **Why we use it** | For clients with sovereign-data mandates, air-gapped environments, or regulated industries where data about network topology and device identities cannot reside with a third party. |
| **Trade-off vs Tailscale** | More engineering overhead; no managed apps; SSO integration requires custom OIDC configuration; no commercial support |
| **Antifragile pillar** | Sovereign Intelligence, Structural Decoupling |
| **When to deploy** | Clients with NIS2/DORA requirements on data residency; utilities/OT environments; clients who have explicitly declined SaaS control planes |
**Deployment model**: Headscale server on client infrastructure or CQRE-managed VM; WireGuard clients on all devices. Managed by us as a retained service or handed over to the client's infrastructure team.
---
### Smallstep — Certificate-Based SSH Access
| Attribute | Detail |
|-----------|--------|
| **What it does** | SSH certificate authority. Issues short-lived SSH certificates tied to identity (SSO/OIDC). Eliminates static SSH keys. No agent required on target servers. |
| **Why we use it** | For clients who need certificate-based SSH access control but cannot justify Teleport. Covers the most common privileged access vector (SSH) at low cost and complexity. |
| **Limitation vs Teleport** | No session recording; no RDP/Kubernetes/DB proxying; no GUI |
| **Antifragile pillar** | Sovereign Intelligence, Structural Decoupling |
| **When to deploy** | Linux-heavy clients; DevOps teams; as a stepping stone before Teleport |
---
## The Decision Framework
```
Does the client have legacy VPN sprawl or flat-network vendor access?
├── YES → Deploy Layer 1 (network access) first
│ ├── Wants managed service + commercial support → Tailscale (partnership)
│ └── Wants full sovereignty / data residency → Headscale + WireGuard
│
Does the client need protocol-aware session recording / JIT / DB access?
├── YES → Add Layer 2 (PAM)
│ ├── < 100 employees AND < $10M revenue → Teleport CE (free, self-hosted)
│ ├── Larger org / needs support → Teleport Enterprise (commercial)
│ └── SSH-only, budget-constrained → Smallstep (certificates only)
│
Does the client need both layers?
├── MOST CLIENTS → Tailscale (network) + Teleport CE/Enterprise (PAM)
└── OT/CRITICAL INFRA → Headscale (sovereign network) + Teleport (recorded vendor access)
```
---
## OT and Critical Infrastructure Considerations
This module is especially valuable for Module 8 (OT Security Assessment) clients. The most common and dangerous finding in OT environments is **uncontrolled vendor remote access**: SCADA vendors, maintenance contractors, and automation engineers with persistent VPN credentials and no session recording.
**The OT-specific requirements**:
| Requirement | Solution |
|-------------|---------|
| Vendor access without standing credentials | Teleport JIT access: vendor requests access, engineer approves, session recorded, credential expires |
| No persistent VPN for OT networks | Tailscale/Headscale ACL policy: vendor node can reach only the specific OT asset, nothing else |
| Auditability for regulators (NIS2, CER) | Teleport session recordings: complete record of every vendor action on every OT system |
| Air-gapped or restricted networks | Headscale on-premise: no outbound control plane dependency |
| Separation of IT and OT access | Separate Tailscale/Headscale networks with explicit, audited bridge points |
**The executive pitch for utilities and telco**:
> *"Your SCADA vendor has a VPN credential that gives them access to your control network. It has not been rotated in three years. You do not know when they last used it or what they did. If that credential is compromised, an attacker has access to your control systems without ever touching your IT network. We replace that with a session that the vendor requests on the day they need it, that an engineer approves, that is recorded start to finish, and that expires the moment the maintenance window closes. This is not extra bureaucracy. This is the audit evidence your regulator will ask for under NIS2."*
---
## CQRE Deployment Tiers
| Tier | Description | Best for |
|------|-------------|---------|
| **Assessment & Design** | Architecture review, tool selection, design document, implementation roadmap | Clients with existing VPN/PAM debt; pre-deployment planning |
| **Managed Deployment** | CQRE installs and configures the chosen stack; hands over to client team | Clients without internal infrastructure expertise |
| **Fully Managed Service** | CQRE operates the network access and PAM layer as a managed service | Clients who want the capability without the operational burden |
| **Retained Advisory** | Quarterly reviews, policy updates, incident support | Clients who have deployed and want ongoing assurance |
---
## Per-Module Tool Pairing
| Module | Access Architecture Role |
|--------|------------------------|
| **Module 2: M365 Identity Security** | Tailscale/Headscale for admin access to cloud management plane; Teleport for server access |
| **Module 6: On-Premise AD Hardening** | Teleport CE as PAW replacement for domain controller access; recorded sessions for all Tier 0 admin activity |
| **Module 8: OT Security Assessment** | Headscale for sovereign OT network access; Teleport for vendor access with full session recording |
| **Module 10: Red Team & Validation** | Verify that Tailscale ACLs actually enforce segmentation; test Teleport JIT bypass scenarios |
| **Module 13: This module** | Full deployment of chosen network + PAM stack |
---
## Integration With Existing Frameworks
| Document | Integration |
|----------|-------------|
| [T0 Asset Framework](../core/t0-asset-framework.md) | T0 assets (domain controllers, key servers, OT controllers) require Teleport session recording; Tailscale ACLs isolate T0 network segments |
| [AD and Endpoint Hardening](ad-endpoint-hardening.md) | PAW architecture is enhanced by Teleport; privileged accounts should authenticate through PAM, not direct RDP |
| [Sovereign Tool Stack](sovereign-tool-stack.md) | Tailscale/Headscale extends the network access layer; Teleport extends the identity and session intelligence layer |
| [Vertical: Power and Utilities](../reference/vertical-power-utilities.md) | Vendor remote access to OT is addressed directly by this module |
| [Vertical: Telco](../reference/vertical-telco.md) | Network operations centre access, vendor access to network elements |
---
*For the OT security context, see [Vertical: Power and Utilities](../reference/vertical-power-utilities.md).*
*For identity and T0 asset protection, see [T0 Asset Framework](../core/t0-asset-framework.md).*
*For the full module menu, see [Modular Engagements](../core/modular-engagements.md).*
antifragile-consulting/playbooks/sovereign-communications.md
+206
View File
@@ -0,0 +1,206 @@
# Sovereign Communications
> *"Your incident response plan assumes your communication platform is available. Your incident response plan is wrong."*
## For the Executive Reader
Every organisation has a single communication platform — Teams, Slack, or similar — that depends on the same corporate identity, the same internet connection, and often the same Microsoft or Google account as everything else. When an incident takes down corporate IT, the communication platform goes down too. When Active Directory is compromised, the attacker can monitor your incident response in real time.
Sovereign communications solves this with a two-tier architecture:
- **Tier 1 — Delta Chat**: A 10-minute deployment on independent infrastructure. Encrypted, works on mobile, requires no corporate account to log in. Used as an out-of-band channel and crisis fallback.
- **Tier 2 — Matrix/Element**: A full sovereign messaging platform for organisations that want to own their primary communications entirely — no vendor dependency, federated, self-hosted.
These are not competing products. They serve different needs and often both are deployed.
*For the module overview, see [Modular Engagements](../core/modular-engagements.md#module-14-sovereign-communications).*
---
## Why Communications Infrastructure Is a Security Control
Most organisations treat their communication platform as a productivity tool and their security tools as a separate category. This is the mistake. Communication infrastructure is:
| Risk Category | Exposure |
|--------------|---------|
| **Incident response dependency** | If Teams is down during a ransomware attack, how do you coordinate response? |
| **Identity dependency** | M365 Teams requires Entra ID. If identity is compromised, the communication platform is too. |
| **Insider threat surface** | A compromised admin account can read every Teams channel in your tenant silently. |
| **Vendor continuity** | A Teams or Slack outage is outside your control. Your response capability should not be. |
| **OT/Crisis operations** | Control room operators cannot rely on a communication tool that depends on corporate IT — especially when the incident is in the corporate IT. |
**The antifragile principle**: Your crisis communication channel must be independent from the infrastructure that might fail during the crisis.
---
## Tier 1: Delta Chat
### What It Is
Delta Chat is an open-source messaging application that uses **email as its transport layer** — specifically IMAP/SMTP with Autocrypt end-to-end encryption (OpenPGP). It looks and works like a modern instant messenger. It is, technically, encrypted email.
### Why This Is Antifragile
| Property | Why It Matters |
|----------|---------------|
| **Runs on email infrastructure** | SMTP/IMAP is the most resilient, federated, widely deployed protocol in existence |
| **Works with any email account** | No new accounts, no new server required if existing email is used |
| **E2E encrypted by default** | Messages are encrypted before leaving the device; the server never sees plaintext |
| **No accounts to compromise** | Delta Chat uses email addresses — there is no separate "Delta Chat account" to take over |
| **Federated** | Anyone with an email address can participate; no walled garden |
| **Works on mobile without corporate MDM** | Personal devices can be enrolled in crisis channels without corporate management |
| **Open-source and auditable** | No opaque server-side processing; the encryption implementation is public |
### The Two Deployment Options
#### Option A: Use Existing Email Infrastructure
Delta Chat can be pointed at any existing IMAP/SMTP server. If the client already has a stable email platform, Delta Chat adds encrypted messaging on top of it with no new infrastructure.
**Best for**: Adding encryption and a better UX to existing internal communication; M365/Exchange clients who want an encrypted channel without new servers.
**Limitation**: If the email server goes down, Delta Chat goes down. The communication channel and the email infrastructure are the same.
#### Option B: Deploy a Chatmail Relay (Recommended for Crisis/OT)
**Chatmail** is a purpose-built, minimal email relay optimised for Delta Chat. It is not a full mail server — it is designed specifically to be fast, lightweight, and easy to deploy as a Delta Chat backend.
| Chatmail Property | Detail |
|------------------|--------|
| **Deployment time** | ~10 minutes on any small VPS |
| **Infrastructure cost** | €5–10/month on a small cloud instance |
| **Independence** | Completely separate from the client's corporate email/IT infrastructure |
| **No domain dependency** | Does not require integration with the client's existing email domain |
| **Optimised for push** | Purpose-built for Delta Chat's push notification model — messages arrive instantly on mobile |
| **Minimal attack surface** | Not a full mail server; purpose-built, smaller footprint than Postfix + Dovecot |
**Deployment**: One VPS, one domain (e.g., `chat.clientname.cqre.net`), 10 minutes. Users create accounts by scanning a QR code in Delta Chat. No IT involvement required on the user side.
**This is the recommended approach for OT/critical infrastructure clients** and any client where the crisis channel must be independent from corporate infrastructure.
**The conversation**:
> *"We are going to spin up a €7/month server that runs a dedicated chat relay. It has nothing to do with your Active Directory, your Exchange, your Azure, or your corporate network. When your primary infrastructure has a bad day, this server does not care. Your operations team scans a QR code and they are on a channel that is encrypted end-to-end, works on personal phones, and requires no corporate account. We do this today, in this meeting. It takes 10 minutes."*
### Typical Deployment Scope
| Use Case | Delta Chat Configuration |
|----------|------------------------|
| **Crisis/incident response** | Chatmail relay on independent cloud; separate from corporate infra; key responders enrolled |
| **OT operations channel** | Chatmail relay; separate from IT network; control room operators + management enrolled |
| **Board/executive channel** | Chatmail relay; executives enrolled on personal devices; no corporate MDM dependency |
| **Supplier/vendor coordination** | Existing email (Option A); suppliers use their own email addresses; no account setup required |
| **Primary encrypted comms for small teams** | Existing email (Option A); team uses Delta Chat daily for all sensitive communication |
---
## Tier 2: Matrix / Element
### What It Is
Matrix is an open standard for decentralised, federated real-time communication. Element is the primary client application. Synapse and Dendrite are the main server implementations. The combination provides a full-featured, sovereign alternative to Teams or Slack: text, voice, video, file sharing, bridges to other platforms, and automation.
### When Tier 2 Is Warranted
| Client Situation | Matrix/Element Appropriate? |
|-----------------|---------------------------|
| Needs a full Teams/Slack replacement with sovereignty | ✅ Yes |
| Regulated industry requiring data residency for all communications | ✅ Yes |
| OT operator who wants persistent rooms for shift handovers + crisis channel | ✅ Yes |
| Needs bridges to existing platforms (Slack, Teams, Signal, WhatsApp) | ✅ Yes |
| Just needs a crisis fallback channel | ❌ Delta Chat is simpler and faster |
| Just needs encrypted messaging on existing email | ❌ Delta Chat is simpler and faster |
### Matrix/Element Feature Comparison vs Teams/Slack
| Feature | Matrix/Element | Teams / Slack |
|---------|---------------|---------------|
| Persistent rooms | ✅ | ✅ |
| Voice/video calls | ✅ | ✅ |
| File sharing | ✅ | ✅ |
| E2E encryption | ✅ (per room) | Limited/none |
| Self-hosted | ✅ (required for sovereignty) | ❌ |
| Federation with other instances | ✅ | ❌ |
| Bridges (Slack, Teams, Signal) | ✅ (via bridges) | Limited |
| Bot/automation support | ✅ | ✅ |
| Third-party data exposure | None (self-hosted) | Vendor has access |
| Per-user licensing cost | None (self-hosted) | €5–30/user/month |
| Data residency guarantee | Full control | Vendor-dependent |
### CQRE Implementation Options
| Option | Description | Best For |
|--------|-------------|---------|
| **Fully Managed** | CQRE hosts and operates Synapse in our infrastructure; client datacenter region selectable | Clients who want the capability without operating it |
| **On-Premises** | CQRE installs and configures Synapse on client infrastructure; client operates it | Clients with strict data residency requirements |
| **Managed On-Premises** | CQRE installs and manages Synapse on client infrastructure on a support contract | Best of both: sovereign data, no operational burden on client |
**The conversation**:
> *"You are paying €20 per user per month for Slack. That is €240K per year for 1,000 users. Every message your executives send about acquisition targets, regulatory responses, and incident response sits on Slack's infrastructure. We replace that with a self-hosted Matrix instance. Same features. Better encryption. Zero per-user cost after infrastructure. Your messages never leave your building."*
---
## The Dual-Stack Architecture
For most clients, the recommended posture is:
```
PRIMARY CHANNEL: Teams / Slack / email (existing corporate platform)
↓ Fails during incident
OUT-OF-BAND CHANNEL: Delta Chat on chatmail relay
(independent infrastructure, works on personal devices)
For organisations wanting full sovereignty:
PRIMARY CHANNEL: Matrix/Element (self-hosted)
↓ Fails during infrastructure incident
OUT-OF-BAND CHANNEL: Delta Chat on chatmail relay
(different infrastructure, different failure mode)
```
**The key insight**: The out-of-band channel must have a **different failure mode** from the primary channel. If both run on the same VPS or depend on the same corporate identity, they will fail together.
---
## OT and Critical Infrastructure
For utilities, telco, and manufacturing clients, sovereign communications is not a convenience — it is an operational requirement.
| Scenario | Recommendation |
|----------|---------------|
| **Ransomware hits corporate IT** | Delta Chat on chatmail relay — independent from corporate domain; operations can continue coordinating |
| **Power outage affects datacenter** | Delta Chat on cloud-hosted chatmail relay — works on mobile over 4G/5G while datacenter is dark |
| **OT incident requires IT/OT team coordination** | Delta Chat channel pre-enrolled with OT engineers, IT responders, management, and external incident response team |
| **Regulator requires documented crisis comms capability** | Matrix/Element with full audit log + Delta Chat as the fallback — both documented in IR runbooks |
| **Vendor coordination during OT maintenance** | Delta Chat on chatmail relay — vendor uses their own email address; no corporate account provisioning required |
**NIS2 relevance**: NIS2 Article 21 requires operators of essential services to have documented crisis communication procedures. A deployed, tested out-of-band channel is evidence; a policy that says "we will use Teams" is not.
---
## Deployment Complexity
| Tool | Time to First Value | Infrastructure | Expertise Required |
|------|--------------------|-----------|--------------------|
| Delta Chat (existing email) | 5 minutes (per user) | None | Very low |
| Delta Chat + chatmail relay | 10–30 minutes total | One small VPS | Low |
| Matrix/Element (managed by CQRE) | 1–2 days | CQRE infrastructure | Low (client side) |
| Matrix/Element (on-premises) | 2–5 days | Client VPS or VM | Medium |
---
## Integration With Existing Frameworks
| Document | Integration |
|----------|-------------|
| [Modular Engagements](../core/modular-engagements.md) | Module 14; natural follow-on to Module 7 (Recovery & Resilience) and Module 8 (OT Security) |
| [Vertical: Power and Utilities](../reference/vertical-power-utilities.md) | OT crisis communications; NIS2 Article 21 crisis procedure evidence |
| [Vertical: Telco](../reference/vertical-telco.md) | Network operations out-of-band channel; incident bridge coordination |
| [Rapid Modernisation Plan](rapid-modernisation-plan.md) | Delta Chat chatmail relay is a Phase 3 (Sovereignty) quick win — 10 minutes of deployment, immediately demonstrable |
| [T0 Asset Framework](../core/t0-asset-framework.md) | Crisis communication channel is a T1 operational asset; Delta Chat relay should have the same protection as other critical services |
---
*For the OT security context, see [Vertical: Power and Utilities](../reference/vertical-power-utilities.md).*
*For recovery and resilience planning, see [Implementation Playbook](implementation-playbook.md).*
*For the full module menu, see [Modular Engagements](../core/modular-engagements.md).*
antifragile-consulting/playbooks/sovereign-tool-stack.md
+79 -1
View File
@@ -85,6 +85,25 @@ This document provides the complete capability map for our consulting practice:
---
### Active Directory Password Audit
#### Elysium (Our Platform)
| Attribute | Detail |
|-----------|--------|
| **What it does** | Automated detection of weak and compromised passwords in Active Directory. Downloads a known-hash database (KHDB) of breached credentials, compares it against domain password hashes using the DSInternals suite, and identifies accounts with dictionary passwords, known-breached credentials, default passwords, or missing encryption keys — all without transmitting usernames or plaintext passwords outside the secure host. |
| **Why we built it** | Password spray attacks succeed because users choose weak passwords regardless of policy. No open-source tool audits AD passwords in a privacy-preserving way without expensive PAM integrations. Elysium finds the accounts an attacker would crack first — before they do — while keeping individual identity data confined to a dedicated secure host. Only compressed, encrypted hash data moves between systems; usernames are never part of the transfer. |
| **Antifragile pillar** | Stress-to-Signal Conversion, Sovereign Intelligence |
| **Engagement modules** | Module 6 (On-Premise AD Hardening); Module 10 (Red Team & Validation); any environment where credential-based attacks (password spray, stuffing) are in the threat model |
| **Typical output** | "47 domain accounts match known-compromised hashes. 12 match common dictionary patterns. 3 are privileged accounts. Here is the remediation priority list: force-reset these 3 immediately, notify these 44 via IT policy enforcement." |
| **Integration** | Findings cross-referenced with BloodHound attack path analysis — accounts with weak passwords that also have short paths to Domain Admin become P0 remediations; results tracked in CISO Assistant for credential policy evidence |
**The conversation**:
> *"Your password policy says minimum 12 characters. That tells you the length. It tells you nothing about whether your employees chose 'Summer2024!' or an actual strong password. Elysium tests every account's hash against a database of 800 million known-compromised credentials. We run it on a dedicated host inside your network. No username ever leaves your building. What we find is a list of accounts a standard password spray tool would crack in under an hour. Last time we ran this, three privileged accounts were on the list."*
---
### Governance, Risk, and Compliance
#### CISO Assistant
@@ -121,6 +140,14 @@ This document provides the complete capability map for our consulting practice:
> *"Your M365 tenant has 400 configuration objects and no version control. When an admin accidentally deletes a conditional access policy at 2 AM, you discover it 6 hours later because users are complaining. ASTRAL detects the deletion in 60 seconds, attributes it to the specific admin session, and offers one-click rollback. This is not backup. This is configuration immunity."*
**ASTRAL companion utilities (CQRE)**:
| Tool | What it does | When to use |
|------|-------------|------------|
| **macOS_IntuneManagement** | Cross-platform headless PowerShell toolkit for Intune policy export/import and baseline deployment across tenants. Supports baseline manifests, bulk device operations, and cross-tenant dependency mapping. | Brownfield tenant migrations; deploying a clean Intune baseline into a new acquisition; cross-platform (macOS, Linux, Windows) policy management |
| **IntunePolicyParser** | Converts Intune documentation exports to flat CSV/Excel for policy analysis, deduplication, and Power BI dashboards. | Auditing existing policy sets before rationalisation; generating a readable flat register from an ASTRAL snapshot; compliance evidence |
| **M365-Scripts** | Operational PowerShell scripts for MDE device lifecycle management. Current focus: bulk offboarding of devices by tag via the Defender for Endpoint API with dry-run mode and retry logic. | Module 1 device lifecycle cleanup; decommissioning campaigns; offboarding projects |
---
### M365 Audit Log Intelligence
@@ -134,7 +161,7 @@ This document provides the complete capability map for our consulting practice:
| **Antifragile pillar** | Sovereign Intelligence, Stress-to-Signal Conversion |
| **Engagement modules** | Module 12 (Blue/Purple Team Foundation); retained capability (Detection Engineering); all M365 hardening engagements |
| **Typical output** | Daily brief: "3 anomalous events flagged: Global Admin [X] added external user at 03:14; Exchange Admin [Y] exported 12,000 mailboxes; Service Principal [Z] granted Mail.Read to unverified publisher. All require validation within 4 hours." |
| **Integration** | Receives alerts from osquery/FleetDM, Wazuh, and Prowler; pushes cases to CISO Assistant for risk register tracking; enriches AI-assisted TVM with insider-threat context |
| **Integration** | Receives alerts from osquery/FleetDM, Wazuh, and Prowler; pushes cases to CISO Assistant for risk register tracking; enriches AI-assisted TVM with insider-threat context; **MCP server** enables Claude and other AI clients to query audit logs in natural language directly from the analyst's desktop |
**The conversation**:
@@ -142,6 +169,25 @@ This document provides the complete capability map for our consulting practice:
---
### Conditional Access Policy Documentation
#### CAExporter (Our Platform)
| Attribute | Detail |
|-----------|--------|
| **What it does** | Documents Entra ID Conditional Access policies and translates cryptic directory object IDs into human-readable names for targeted users, groups, and applications. Exports a complete, structured CA policy register to CSV and formatted Excel workbooks. |
| **Why we built it** | Organisations with 30–200 CA policies have no readable documentation of what those policies actually cover. Object IDs in the Entra admin centre are opaque — group names are invisible, app names are GUIDs. Before you can harden, rationalise, or audit CA policies, you need to know what each one actually does. CAExporter produces that picture in under 10 minutes. |
| **Antifragile pillar** | Structural Decoupling, Stress-to-Signal Conversion |
| **Engagement modules** | Module 2 (M365 Identity Security); Module 3 (M365 Security Hardening); compliance audits requiring CA policy evidence (NIS2, ISO 27001, DORA) |
| **Typical output** | Excel workbook with one row per policy: policy name, conditions, controls, named groups and apps (not object IDs), assignment scope, current state (enabled/disabled/report-only), and export timestamp. Audit-ready without a single screenshot. |
| **Integration** | Export feeds into ASTRAL as the human-readable CA policy baseline (state at engagement start); CISO Assistant links the workbook as evidence for Entra ID hardening controls; AOC change alerts are cross-referenced against the export to identify which named policy changed |
**The conversation**:
> *"Your Entra tenant has 67 Conditional Access policies. Nobody in this room can tell me, right now, what all 67 of them do. Three of them reference groups that no longer exist. Two claim to block legacy authentication — but only for a subset of users. CAExporter generates a readable register in 10 minutes. We use it to find the gaps, document the baseline, and give your auditor evidence that your CA policies are intentional — not the accumulated result of six admins making changes over four years."*
---
## The Stack Architecture
```
@@ -300,6 +346,10 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
| GRC and compliance | **CISO Assistant** | OpenGRC, SimpleRisk | ServiceNow GRC, RSA Archer | DORA, NIS2, SOC 2 clients |
| M365 backup/change mgmt | **ASTRAL** | — (no open-source equivalent) | Veeam, AvePoint, SkyKick | All M365 clients; retained capability |
| M365 audit intelligence | **AOC** | — (no open-source equivalent) | Microsoft Sentinel, ManageEngine | All M365 clients; SOC co-management |
| CA policy documentation | **CAExporter** | — (no equivalent) | — | Every Module 2 engagement; CA audits |
| AD password audit | **Elysium** | — (DSInternals manual use) | Netwrix Password Policy, Specops | Every AD engagement; Module 6 |
| Intune baseline deployment | **macOS_IntuneManagement** | — (no cross-platform equivalent) | — | Tenant migrations; brownfield baseline |
| Endpoint hardening baseline | **E8-CAT** | CIS-CAT Lite (Windows only) | CIS-CAT Pro | Module 1/3 pre/post hardening scoring |
| Endpoint inventory | **osquery + FleetDM** | Wazuh (limited), Zentral | Tenable, Qualys | 50-5,000 endpoints; sovereign preference |
| Endpoint detection (EDR) | **Wazuh + Sysmon** | — | CrowdStrike, SentinelOne, Defender P2 | E3 clients without Defender P2; air-gapped environments |
| SIEM / log aggregation | **Wazuh** | Graylog, Grafana Loki, ELK | Splunk, Sentinel, QRadar | All environments needing centralised alerting |
@@ -329,18 +379,22 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
### Module 1: Endpoint Management Foundation
**Primary**: ASTRAL (Intune configuration backup and drift detection) + osquery/FleetDM (endpoint inventory)
**Augmentation**: Wazuh + Sysmon (for E3 clients without Defender P2)
**CQRE utilities**: macOS_IntuneManagement (baseline deployment, cross-tenant migration); IntunePolicyParser (policy audit register); M365-Scripts (MDE device lifecycle); E8-CAT (pre/post hardening Essential Eight score)
### Module 2: M365 Identity Security
**Primary**: AOC (audit log intelligence) + BloodHound (hybrid identity attack paths)
**Augmentation**: Purple Knight (AD security baseline)
**CQRE utilities**: CAExporter (CA policy documentation baseline — run first, before any CA hardening)
### Module 3: M365 Security Hardening
**Primary**: ASTRAL (configuration state) + Prowler (Azure posture)
**Augmentation**: AOC (continuous monitoring of security control changes)
**CQRE utilities**: CAExporter (CA policy register as audit evidence); E8-CAT (macro restriction and application hardening verification)
### Module 6: On-Premise AD Hardening
**Primary**: BloodHound + Purple Knight / Forest Druid
**Augmentation**: osquery (endpoint state of domain controllers)
**CQRE utilities**: Elysium (weak/compromised password audit — run alongside BloodHound; weak-password accounts on high-value attack paths become P0)
### Module 9: Organisational Resilience and DevSecOps
**Primary**: Falco (container runtime security) + Semgrep (static code analysis) + GitLeaks (secrets detection)
@@ -370,6 +424,10 @@ Our current stack covers cloud posture, AD security, GRC, M365 configuration, an
| CISO Assistant | 1 day | Docker host or VM | Low | Low-Medium (compliance data) |
| ASTRAL | 2 hours | SaaS or client-hosted | Low | High (M365 configuration) |
| AOC | 4 hours | SaaS or client-hosted | Medium | High (audit logs, identity data) |
| CAExporter | 30 minutes | None (runs from PowerShell) | Low | Low (read-only CA policy export) |
| Elysium | 1–2 hours | Dedicated secure host (on-premises) | Medium | High (domain password hashes — stays on-prem) |
| macOS_IntuneManagement | 1 hour | None (PowerShell 7+) | Low | Medium (Intune policy data) |
| E8-CAT | 30 minutes | None (runs on target endpoint) | Low | Low (compliance scan results) |
| osquery + FleetDM | 4 hours | FleetDM server + agents | Medium | High (endpoint data) |
| Wazuh + Sysmon | 1 day | Wazuh server + agents | Medium | High (endpoint + network data) |
| Shuffle | 4 hours | Docker host | Medium | High (SOAR playbooks) |
@@ -538,6 +596,25 @@ Beyond the core stack, these tools address specific niches that arise in sophist
---
### Endpoint Hardening Baseline Verification
#### E8-CAT (Our Platform)
| Attribute | Detail |
|-----------|--------|
| **What it does** | Lightweight PowerShell-based compliance scanner for Windows workstations and servers. Evaluates four Essential Eight strategies — restricting macros, hardening applications, enforcing application control, and limiting administrator privileges — across maturity levels 1–3. Produces JSON, CSV, and HTML compliance reports with pass/fail evidence for each check. |
| **Why we built it** | CIS-CAT Pro costs money and requires a licence; CIS-CAT Lite is Windows-only and limited. The Essential Eight (ACSC) overlaps heavily with what Modules 1 and 3 deliver. Running E8-CAT before and after a hardening engagement produces a concrete, evidence-backed maturity level improvement score that clients and auditors can read. It is lightweight, free, and runs from the target system without an agent. |
| **Antifragile pillar** | Stress-to-Signal Conversion, Asymmetric Payoff Design |
| **Engagement modules** | Module 1 (Endpoint Management) and Module 3 (M365 Security Hardening) as pre/post hardening verification; any engagement that requires documented baseline improvement evidence |
| **Typical output** | "Pre-hardening: Maturity Level 1 across 3 of 4 strategies, Maturity Level 0 on application control. Post-hardening: Maturity Level 2 across all 4 strategies. Evidence: 47 individual check results with registry keys, feature states, and policy values." |
| **Integration** | Results stored in CISO Assistant as control evidence; trends tracked over time for continuous improvement reporting |
**The conversation**:
> *"Before we change anything, E8-CAT scores your endpoints against the Essential Eight hardening framework. You are at Maturity Level 1 on two strategies and Level 0 on two others. When we are done with Module 1 and Module 3, we run it again. That before-and-after score is your evidence: not our word, not screenshots, but a reproducible scan result you can show your auditor and your board."*
---
### Certificate and Subdomain Monitoring
#### CertStream + Crt.sh
@@ -567,6 +644,7 @@ Beyond the core stack, these tools address specific niches that arise in sophist
| Static code analysis | **Semgrep** | Vulnerability detection without cloud dependency | CI/CD security gates |
| Phishing simulation | **GoPhish** | User susceptibility measurement and training | Awareness programmes |
| Certificate monitoring | **CertStream + crt.sh** | Subdomain discovery and unauthorised certs | Continuous perimeter monitoring |
| Endpoint hardening baseline | **E8-CAT** | Free Essential Eight scanner; pre/post hardening maturity score | Module 1/3 hardening evidence |
---