Initial commit: establishing the cqre.net perimeter
This commit is contained in:
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: "Antifragile Consulting"
|
||||
description: "The Brownhat methodology — modular security consulting that starts with what you own, closes the kill chain, and builds capability your team retains."
|
||||
eyebrow: "Brownhat Methodology"
|
||||
lead: "We help organisations close the gap between their security investments and their actual security posture. Every engagement starts with a diagnostic. No recommendations before we understand the environment."
|
||||
---
|
||||
|
||||
## The Antifragile Principle
|
||||
|
||||
Most security programmes optimise for robustness — the ability to withstand shocks. Antifragility goes further. An antifragile organisation does not merely survive disruptions. It grows stronger from them.
|
||||
|
||||
Every incident produces structural improvement. Every competitor's failure creates market opportunity. Every regulatory demand is met with evidence, not promises.
|
||||
|
||||
## The Five Pillars
|
||||
|
||||
<div class="pillars">
|
||||
<div class="pillar">
|
||||
<div class="pillar-num">01</div>
|
||||
<h4>Structural Decoupling</h4>
|
||||
<p>Identify and remove hidden dependencies before they become fatal. We do not add complexity that creates new ones.</p>
|
||||
</div>
|
||||
<div class="pillar">
|
||||
<div class="pillar-num">02</div>
|
||||
<h4>Optionality Preservation</h4>
|
||||
<p>Spend your budget on things that preserve your ability to change direction. Every unnecessary tool purchase reduces your strategic flexibility.</p>
|
||||
</div>
|
||||
<div class="pillar">
|
||||
<div class="pillar-num">03</div>
|
||||
<h4>Stress-to-Signal Conversion</h4>
|
||||
<p>Every incident, failure, and near-miss is intelligence. Build systems that learn from disruption rather than merely surviving it.</p>
|
||||
</div>
|
||||
<div class="pillar">
|
||||
<div class="pillar-num">04</div>
|
||||
<h4>Sovereign Intelligence</h4>
|
||||
<p>Your proprietary data should improve your own capability, not a vendor's model. Own the tools and systems you depend on.</p>
|
||||
</div>
|
||||
<div class="pillar">
|
||||
<div class="pillar-num">05</div>
|
||||
<h4>Asymmetric Payoff Design</h4>
|
||||
<p>Small, targeted investments on existential risks yield disproportionate protection. Concentrate effort where failure is fatal.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## How Engagements Work
|
||||
|
||||
We do not sell monolithic transformation projects. We sell **independent modules that stack**. Each module delivers measurable value in 30–90 days and creates natural appetite for the next phase.
|
||||
|
||||
Every engagement begins with the **Brownhat Diagnostic** — a structured two-day NIST CSF 2.0 baseline assessment that produces an honest, prioritised picture of where the organisation stands. We do not make module recommendations before we understand the environment.
|
||||
|
||||
**What every engagement produces:** a defined scope, a defined deliverable, and assets delivered to your own repository. Every script, detection rule, configuration, and runbook we produce belongs to you. When an engagement closes, you are operationally independent.
|
||||
|
||||
## What Makes Us Different
|
||||
|
||||
**We start with what you own.** Most consultants arrive with a shortlist of products. We arrive with a diagnostic. Before any purchase is discussed, we exhaust the capabilities of existing tools. If your Microsoft E3 tenant can close the gap, we configure it. We earn fees from expertise, not licence margins.
|
||||
|
||||
**We price by deliverable, not by the hour.** Every engagement has a defined scope and defined output before work begins. No open-ended retainers disguised as ongoing support.
|
||||
|
||||
**We disclose our commercial relationships.** We have partnerships with Huntress, Tailscale, Thinkst Canary, and Tenable. When we recommend one of these tools, we say so and explain why the open-source alternative does not meet the specific need.
|
||||
|
||||
**We tell you what we cannot do.** We are a specialist practice. We do not run a 24/7 SOC. We do not sign off on compliance audits. We do not replace your IT team. When a need falls outside our practice, we say so and point you to the right provider.
|
||||
|
||||
## Standards Alignment
|
||||
|
||||
The Brownhat module set maps directly onto major regulatory frameworks:
|
||||
|
||||
- **NIS2 (EU 2022/2555)** — Article 21 measures: configuration management (ASTRAL), logging and monitoring (PULSAR), access control, incident detection
|
||||
- **DORA (EU 2022/2554)** — ICT change management records (ASTRAL Git trail), incident log retention (PULSAR), ICT third-party risk governance
|
||||
- **GDPR Article 32** — Continuous configuration governance and audit log retention as "appropriate technical measures"
|
||||
- **ISO 27001** — A.8.9 configuration management, A.8.15 logging, control evidence produced as a natural output of the engagement
|
||||
- **CIS Controls v8** — IG1 as a non-negotiable 90-day floor, achieved primarily through existing tool configuration
|
||||
|
||||
## Brownfield Track
|
||||
|
||||
The main engagement model assumes a consultant walking into someone else's enterprise estate. The Brownfield Handbook applies the same methodology to the infrastructure you grew yourself — the self-hosted stack that accreted, the homelab that became production, the one box that quietly turned load-bearing. Discovery by observation, pruning, pets-versus-cattle, rebuildability, and deliberate stress: the antifragile five-part arc applied to the estate nobody designed.
|
||||
|
||||
This track is for self-hosters, small platforms, and teams that need to antifragile their own organically-grown infrastructure — and who want to validate the whole methodology by running it against something where the consequences are theirs.
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Start with the Brownhat Diagnostic</h2>
|
||||
<p>The entry point for every new client. A structured two-day assessment that produces a prioritised picture of where you stand and what matters most to fix.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: "Module 0 — Brownhat Diagnostic"
|
||||
description: "The entry point for every engagement. A structured two-day NIST CSF 2.0 baseline assessment that produces a prioritised security roadmap, a mapped kill chain, and sized remediation quanta."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "Before any module recommendation, we need an honest picture of where you actually stand. The Brownhat Diagnostic is a structured two-day workshop — no tools installed, no scanning — that produces the clearest picture of your security posture and what matters most to fix."
|
||||
actions:
|
||||
- label: "Book a Diagnostic"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What the Diagnostic Produces
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📋</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>NIST CSF 2.0 Gap Report</h4>
|
||||
<p>An honest scoring of your posture across all six CSF 2.0 functions — GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER — with the gaps that matter most clearly separated from the ones that don't.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🗺️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Kill Chain Map</h4>
|
||||
<p>Using the Kill Chain Assessment app, we model your environment as an attack graph during the diagnostic. The app computes the shortest path from an attacker's entry point to your crown jewels — the kill chain — and identifies exactly which links need breaking first.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">⚡</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Quantum-Sized Remediation Plan</h4>
|
||||
<p>Every finding on the kill chain is sized into a remediation quantum: Critical (hours), Severe (days), Standard (sprint), or Dark (needs discovery first). You leave with a plan ordered by time-to-existential-impact, not by CVSS score.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📦</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Prioritised Module Roadmap</h4>
|
||||
<p>A recommended sequence of modules derived directly from your gap picture and kill chain. Not a generic framework recommendation — a sequence built on what we actually found in your environment.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## How It Works
|
||||
|
||||
The Diagnostic is a two half-day structured workshop with your IT lead, a business process owner, and whoever is accountable for security decisions. No homework before. No questionnaire to fill in. Pre-filled questionnaires produce aspirational answers; the workshop produces honest ones.
|
||||
|
||||
**Session 1 — Context and Foundation:** GOVERN and IDENTIFY domains. Who is accountable for security, how decisions are made, what assets exist, and how risk is assessed. This is where the governance gaps surface — usually faster than clients expect.
|
||||
|
||||
**Session 2 — Controls, Detection, and Recovery:** PROTECT, DETECT, RESPOND, and RECOVER. What controls are actually in place and enforced (not just configured), how alerts are handled, how incidents are managed, and whether recovery has ever been tested. Kill chain synthesis runs in parallel as findings accumulate.
|
||||
|
||||
**What we do not do:** install tools, collect data from systems, or make recommendations before the picture is complete. We earn the right to recommend by understanding the environment first.
|
||||
|
||||
## Deliverables
|
||||
|
||||
Everything goes to your repository. At the end of the two days you receive:
|
||||
|
||||
- NIST CSF 2.0 gap report (strengths, gaps, severity ratings)
|
||||
- Kill chain diagram and shortest-path analysis
|
||||
- Quantum-bucketed remediation priorities (P0 / P1 / P2 with time budgets)
|
||||
- Module roadmap with recommended sequencing and rationale
|
||||
- Findings backlog seeded and ready for the housekeeping stream
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 2 half-days (4 hours each) |
|
||||
| **Format** | In-person strongly preferred; remote with camera-on acceptable |
|
||||
| **Who attends** | IT lead, executive sponsor (mandatory); business process owner (recommended) |
|
||||
| **Prerequisites** | None — this is the starting point |
|
||||
| **Follow-on** | Delivers a module roadmap; further modules are optional |
|
||||
|
||||
The Diagnostic is a bounded, fixed-price engagement. It delivers value regardless of whether further work follows. We have never run a diagnostic that did not surface something the client did not know.
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Start here</h2>
|
||||
<p>Every engagement begins with the Brownhat Diagnostic. It is the only honest way to select a module sequence.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Book a Diagnostic</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: "Module 1 — Endpoint Management Foundation"
|
||||
description: "Device inventory, Intune enrollment, compliance baseline, shadow IT discovery, and ASTRAL deployment for drift detection. Full device visibility in 30–45 days."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "You cannot govern what you cannot see. Endpoint management is almost always the right first module after the Diagnostic — it produces immediate visibility across every device and creates the foundation every other security control depends on."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📱</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Complete Device Inventory</h4>
|
||||
<p>Every managed device enrolled in Intune: OS version, patch level, encryption status, compliance state. Shadow IT devices flagged. You leave with a real picture of your fleet — not what should be there, but what is.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">✅</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Compliance Baseline</h4>
|
||||
<p>Encryption enforced, OS minimum versions set, antivirus required, screen lock configured. Devices that fail compliance are flagged in red and blocked from data access via Conditional Access integration.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔀</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>ASTRAL Deployment for Intune Drift</h4>
|
||||
<p>ASTRAL captures your Intune configuration as versioned snapshots in Git. Any policy change opens a pull request with a human-readable diff. Unauthorised changes are detected before they become incidents.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔍</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Shadow IT Discovery</h4>
|
||||
<p>Application inventory across all enrolled devices surfaces sanctioned and unsanctioned software — including consumer AI tools running on corporate devices. Every unsanctioned application is a potential data exfiltration or malware entry path.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔐</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Conditional Access Integration</h4>
|
||||
<p>Device compliance state wired into Conditional Access so non-compliant devices cannot reach email, SharePoint, or Teams. The device check becomes a real enforcement signal, not just a dashboard metric.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Why Endpoint Management First
|
||||
|
||||
Endpoint management is the entry vector that reveals everything else. Once enrollment runs, the consultant can see orphaned AD accounts (devices with no owner), unencrypted disks (the compliance gap nobody admitted), and consumer AI apps installed on devices that access regulated data. Every one of these becomes a natural conversation about what comes next.
|
||||
|
||||
**The Trojan horse:** the client asks to manage their laptops. You deliver that in 30 days. You also hand them a map of what you found — accounts that should not exist, devices that are not encrypted, applications leaking data. The device problem is solved. The picture that follows it is what turns a bounded engagement into a programme.
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 30–45 days |
|
||||
| **Environment** | M365 E3+ (Intune included) |
|
||||
| **Prerequisites** | Global Administrator access; device enrollment feasibility confirmed |
|
||||
| **Natural follow-on** | Module 2 (Identity Security) — identity gaps surface during enrollment |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Ready to see your fleet?</h2>
|
||||
<p>Full device visibility in 30 days. The foundation every other security control depends on.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: "Module 10 — Red Team & Adversarial Validation"
|
||||
description: "Adversary simulation against the specific kill chain identified in the Brownhat Diagnostic. Validates whether hardening modules produced real security improvement or compliance dashboard improvement."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "The client has MFA. They have Conditional Access. They have Intune. The dashboard is green. This is the most dangerous estate to walk into — not because it is badly configured, but because everyone believes it works. Module 10 finds out which controls are real and which are representations."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🎯</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Targeted Kill Chain Validation</h4>
|
||||
<p>Adversary simulation runs specifically against the kill chain identified in the Brownhat Diagnostic and modified by previous hardening modules. Not a broad-scope red team — a focused test of whether the paths we said we closed are actually closed. The attack surface is the attack surface your organisation faces, not a generic penetration test scope.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔐</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Identity and Privilege Assumption Testing</h4>
|
||||
<p>Kerberoasting, DCSync simulation, PIM bypass attempts, and OAuth consent abuse — the techniques that succeed on hardened estates because the hardening is present but not tested. A control that has never been exercised is a hypothesis. This engagement converts hypotheses to evidence.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🧪</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Detection Validation</h4>
|
||||
<p>Security alerts deliberately triggered to test whether detection rules fire, whether alerts reach a human, and whether that human knows what to do. Many estates generate the right alert into a queue nobody reads. Detection validation distinguishes between "we detect this" and "we detect this and respond to it."</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🏗️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Structural Finding, Not a CVE List</h4>
|
||||
<p>Every gap found produces a structural recommendation — not "patch this CVE" but "this path exists because of this architectural condition; severing it requires this change." The output is a shorter kill chain, not a longer remediation backlog. We do not add controls. We find why the existing ones do not work.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## When to Run This Module
|
||||
|
||||
Module 10 is a **post-hardening engagement**. It is the evidence check after the work — the test that distinguishes security improvement from compliance improvement. Run it after Modules 2, 3, 6, and 12 have had time to bed in. Running it before hardening is simply a penetration test; running it after hardening is adversarial validation.
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 15–30 days |
|
||||
| **Environment** | Any |
|
||||
| **Prerequisites** | Written authorisation covering all test activities; at least two hardening modules completed; initial kill chain from Module 0 documented |
|
||||
| **Natural follow-on** | Update kill chain map with validated findings; feed structural gaps back into the module roadmap |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Find out which controls are real</h2>
|
||||
<p>Green dashboards and untested reality are the most dangerous combination in security. Module 10 converts one to the other.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
title: "Module 11 — Blue/Purple Team Foundation"
|
||||
description: "Detection engineering, alert tuning, SIEM rule development, and threat hunting playbooks. Your existing tools, made to actually work."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "Most organisations own a Ferrari-grade security stack and drive it like a rental car. The tools are not the problem. This module builds the operating rhythm, detection rules, and hunting playbooks that turn security telemetry into security outcomes."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">⚙️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Capability Audit</h4>
|
||||
<p>The engagement begins by assessing not the tools, but the team's ability to use them. Defender for Endpoint alert coverage, Sentinel analytic rule quality, Defender for Office 365 review process, identity protection response time — each assessed against what the tool is capable of versus what is actually happening. The gap is almost always process, not technology.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔔</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Alert Tuning and Tiered Triage</h4>
|
||||
<p>High-fidelity alerts separated from noise. A tiered triage model deployed so analysts know which alerts require immediate response, which require investigation, and which are informational. The "200 alerts per day with no triage process" configuration — which produces analyst burnout and missed detections equally — replaced with something workable.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📐</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Detection Engineering</h4>
|
||||
<p>Custom detection rules built against the specific attack techniques relevant to your environment — not the vendor's default rules covering all industries, but rules tuned to your crown jewels, your identity topology, and the kill chain your Diagnostic identified. Rules are tested against real activity before deployment to verify they fire without drowning the queue.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🎯</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Threat Hunting Playbooks</h4>
|
||||
<p>Structured hunt hypotheses and execution playbooks for the techniques most likely to succeed against your environment. Analysts stop waiting for alerts and start looking for evidence of compromise that has not yet triggered one. The hunt is repeatable and scheduled, not ad-hoc and occasional.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔄</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Continuous Improvement Loop</h4>
|
||||
<p>Every alert, every hunt, and every incident feeds a tuning cycle. Detection misses produce new rules. False positives are suppressed with scope, not silence. The SIEM improves over time rather than drifting toward irrelevance as the environment changes around it.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 45–90 days |
|
||||
| **Environment** | Microsoft Defender stack and/or Sentinel |
|
||||
| **Prerequisites** | PULSAR deployed for audit log intelligence; initial kill chain from Module 0 to anchor detection scope |
|
||||
| **Natural follow-on** | Module 10 (Red Team & Validation) to test whether detection catches simulated attacks |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Make your existing tools work</h2>
|
||||
<p>The tooling you already own can detect the attacks you actually face. Module 11 builds the capability to use it.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: "Module 12 — T0 Asset Protection"
|
||||
description: "Tier 0 asset classification across identity, infrastructure, and data. Protection architecture ensuring crown jewels are never reachable from a Tier 1 or Tier 2 compromise."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "A T0 asset is not merely important. It is existential — its compromise does not cause downtime, it causes dissolution. Most organisations have never explicitly classified which assets belong here, which means they have never specifically protected them."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🏆</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>T0 Asset Classification</h4>
|
||||
<p>Every asset classified into tiers: T0 (existential — compromise destroys the operation), T1 (critical — material harm), T2 (important — significant disruption), T3 (standard). Classification is not a spreadsheet exercise — it is a conversation about what the organisation genuinely cannot operate without. Domain controllers, ADCS, the Entra Connect sync server, cryptographic key material, and the systems that hold sovereign intelligence all belong at T0.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🛡️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Crown Jewel Protection Architecture</h4>
|
||||
<p>A protection design for each T0 asset: access controls, network segmentation, monitoring requirements, and privilege boundaries. The architecture's primary constraint is that T0 must never be reachable from the compromise of a T1 or T2 system. If an attacker owns a member server, they should not be able to reach a domain controller. If they compromise an admin laptop, they should not reach the ADCS root.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔒</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Privilege Tier Enforcement</h4>
|
||||
<p>Administrative access enforced per tier — T0 administrators use dedicated, hardened workstations and dedicated accounts that do not log in to T1 or T2 systems. Service accounts that currently span tiers identified and decomposed. Entra Connect sync server permissions tightened so the bridge between on-premises T0 and the cloud tenant cannot be weaponised.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📡</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>T0 Monitoring and Alert Design</h4>
|
||||
<p>Custom detection rules scoped specifically to T0 assets — any authentication attempt, any privilege escalation, any configuration change on a T0 system generates a high-fidelity alert that reaches a human immediately. Noise from T1 and T2 does not bury T0 signals.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## The Kill Chain Connection
|
||||
|
||||
The Kill Chain Assessment app from Module 0 identifies which assets are crown jewels — the end of the kill chain. Module 12 builds the architecture that ensures an attacker cannot reach them even after compromising entry-level systems. Together, Module 0 finds the path and Module 12 removes it at the structural level.
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 30–60 days |
|
||||
| **Environment** | Any |
|
||||
| **Prerequisites** | Module 0 (Diagnostic) to identify crown jewels; Module 6 if on-premises AD is in scope |
|
||||
| **Natural follow-on** | Module 13 (Privileged Access Architecture) for the PAM layer that enforces the tier boundaries in practice |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Protect what the organisation cannot lose</h2>
|
||||
<p>Everything else can be rebuilt. T0 assets cannot. Module 12 ensures the architecture reflects that distinction.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
title: "Module 13 — Privileged Access Architecture"
|
||||
description: "PAM design using Teleport, Tailscale/Headscale, and JIT access. Vendor remote access governance, ephemeral credentials, session recording, and zero standing access."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "Your VPN authenticates people to your network. PAM authenticates people to specific resources inside it. Most organisations solve the first problem badly and ignore the second entirely. The result: a compromised VPN credential reaches everything. This module closes that gap with a two-layer architecture."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🌐</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Network Access Layer — Tailscale or Headscale</h4>
|
||||
<p>Tailscale (or Headscale for sovereign deployments) replaces legacy VPN for T1 workloads — cloud resources, Kubernetes clusters, multi-cloud management planes. Per-node ACLs, Entra OIDC integration, and per-session MFA via key expiry. An attacker with a stolen credential reaches only the specific resources that credential is scoped to, not the entire network.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔐</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Privileged Access Layer — Teleport</h4>
|
||||
<p>Teleport deployed as the protocol-aware access layer for SSH, RDP, Kubernetes, and database access. Every privileged session is proxied, recorded, and auditable. Ephemeral certificates replace long-lived credentials — there are no SSH keys to steal, no saved RDP passwords, no standing database credentials. Access is approved, time-bounded, and logged by default.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">⏱️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>JIT Access and Zero Standing Privilege</h4>
|
||||
<p>Just-in-time access workflows so privileged access to critical systems requires an approval request, grants time-bounded access, and expires automatically. No standing admin sessions, no persistent elevated accounts with broad reach. The attacker who compromises an admin account at 3am finds it has no current access to anything significant.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🏢</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Vendor Remote Access Governance</h4>
|
||||
<p>Third-party vendors — managed service providers, hardware suppliers, software vendors with remote support access — brought under the same PAM architecture. Every vendor session scoped to the specific resources they need, recorded, and revokable instantly. Vendor access is a significant and frequently overlooked attack surface.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🏔️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>T0 Overlay — Nebula (Optional)</h4>
|
||||
<p>For T0 systems (domain controllers, ADCS, Entra Connect sync server), an optional Nebula overlay provides a management network with no external coordinator dependency — once certificates are distributed, the overlay functions with zero cloud service availability dependency. The Nebula CA is the only T0 component and can be kept offline.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 45–60 days |
|
||||
| **Environment** | Any (cloud, on-premises, hybrid, multi-cloud) |
|
||||
| **Prerequisites** | Module 12 (T0 Asset Protection) to establish the tier boundaries the PAM architecture enforces; inventory of privileged access requirements |
|
||||
| **Natural follow-on** | Module 11 (Blue/Purple Team) to build detection for privileged access anomalies |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>No standing access. No standing risk.</h2>
|
||||
<p>Every privileged session scoped, recorded, and time-bounded. An attacker who steals a credential finds it grants nothing by default.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: "Module 14 — Sovereign Communications"
|
||||
description: "Delta Chat chatmail relay, Matrix/Element deployment, and crisis out-of-band channel design. Communication infrastructure that stays available and private when your primary platform is compromised."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "Your incident response plan assumes your communication platform is available. Your incident response plan is wrong. When ransomware takes down corporate IT, Teams goes down too. When Active Directory is compromised, the attacker can monitor your response in real time. This module builds the alternative."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">💬</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Delta Chat — Crisis Out-of-Band Channel</h4>
|
||||
<p>Delta Chat deployed on independent chatmail relay infrastructure in under 10 minutes per user. Encrypted, works on mobile, requires no corporate account or corporate network to operate. When the corporate identity provider is down or compromised, your incident response team still has a secure, verified channel. Used as the crisis fallback that is always independent from whatever is failing.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🏠</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Matrix/Element — Sovereign Primary Platform (Optional)</h4>
|
||||
<p>For organisations that want to own their primary communications entirely: a self-hosted Matrix homeserver with Element client. No vendor dependency, no Microsoft or Google account required for access, fully federated if needed. Your communication infrastructure becomes sovereign in the same way your authentication infrastructure should be.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📋</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Crisis Communication Runbook</h4>
|
||||
<p>A documented, tested out-of-band communication protocol — who contacts whom, on which channel, in which sequence, for which incident types. The runbook exists on paper and on every responder's personal device, independent of corporate infrastructure. Tested in the tabletop exercise so the first time it is used under pressure is not the first time it is used at all.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔑</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Key Verification and Trust Establishment</h4>
|
||||
<p>Encryption keys verified out-of-band before the incident, so responders know they are talking to each other and not to an attacker who has compromised the corporate directory. Trust established in advance is the only trust that holds under incident pressure.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Why Communications Infrastructure Is a Security Control
|
||||
|
||||
An incident response that depends on the infrastructure the incident might destroy is not a response capability — it is a hope. For OT environments and critical infrastructure, the dependency is even more direct: control room operators cannot rely on a communication tool that depends on corporate IT when the incident is in the corporate IT.
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 15–30 days |
|
||||
| **Environment** | Any |
|
||||
| **Prerequisites** | None — this module can be delivered standalone as crisis preparedness |
|
||||
| **Natural follow-on** | Module 7 (Recovery & Resilience) — sovereign communications integrates with the full incident response capability |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Keep talking when everything else is down</h2>
|
||||
<p>The crisis communication channel must be independent from the infrastructure that might fail during the crisis. Module 14 builds it.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: "Module 2 — M365 Identity Security"
|
||||
description: "Full identity census, Conditional Access architecture, MFA enforcement, legacy auth elimination, PIM deployment, and PULSAR audit log intelligence for your M365 tenant."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "Identity is the perimeter. Every other control you deploy is downstream of whether the right people — and only the right people — can authenticate. This module makes your identity architecture explicit, enforced, and auditable."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">👥</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Full Identity Census</h4>
|
||||
<p>Every user account, admin account, service principal, app registration, and guest identity enumerated and assessed. Orphaned accounts, over-privileged roles, and never-used service principals flagged and queued for remediation.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🏗️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Conditional Access Architecture</h4>
|
||||
<p>A complete, documented CA policy set covering MFA enforcement, legacy auth blocking, device compliance signals, named locations, and phishing-resistant authentication for admins. Staged deployment with report-only period before enforcement to prevent lockout.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔒</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>MFA Enforcement and Legacy Auth Elimination</h4>
|
||||
<p>MFA enforced via Conditional Access (not per-user MFA). Legacy authentication protocols — IMAP, POP, SMTP AUTH, basic auth — blocked at the tenant level. These protocols bypass MFA entirely and are the entry point for the majority of credential-based attacks.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">⏱️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>PIM Deployment or JIT Process</h4>
|
||||
<p>Privileged Identity Management deployed so admin roles are activated on-demand with approval workflow and time-bounded access, rather than permanently assigned. Zero standing Global Admin access where feasible. Break-glass accounts established and documented.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📡</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>PULSAR Audit Log Intelligence</h4>
|
||||
<p>PULSAR deployed for continuous M365 audit log ingestion with indefinite retention. Search UI, alerting on high-risk events, and MCP server for AI-assisted queries. You gain the ability to answer "what happened, when, and by whom" — retrospectively and in real time.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🧹</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Guest Access Audit and Governance</h4>
|
||||
<p>All guest identities enumerated. Stale guests (inactive, unknown owner, no project association) flagged and removed. External collaboration settings tightened. Guest access policy documented and a review cadence established.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 30–60 days |
|
||||
| **Environment** | M365 E3+ |
|
||||
| **Prerequisites** | Global Administrator access; existing CA policies inventoried |
|
||||
| **Natural follow-on** | Module 3 (M365 Security Hardening) builds on the identity baseline |
|
||||
|
||||
## Standards Alignment
|
||||
|
||||
Conditional Access and audit log retention map directly onto NIS2 Article 21 (access control, monitoring), DORA Article 9 (ICT security — identity and access management), GDPR Article 32 (appropriate technical measures), and ISO 27001 A.5.15–A.5.18 (access control).
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Close the identity gaps</h2>
|
||||
<p>The most common kill chain starts with a compromised credential. Module 2 ensures that credential alone is not enough.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: "Module 3 — M365 Security Hardening"
|
||||
description: "Exchange Online Protection tuning, mailbox auditing, Unified Audit Log forwarding, Secure Score baseline, ASR rules, and ASTRAL configuration capture — no new licensing required for E3 clients."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "Most M365 E3 tenants are running at a fraction of the security their licence already includes. This module extracts that value systematically — tightening the controls that exist, enabling the logging that should be on, and capturing the baseline so drift is detectable from day one."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📧</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Exchange Online Protection Tuning</h4>
|
||||
<p>Anti-phishing, anti-malware, and anti-spam policies reviewed and tightened. DKIM, DMARC, and SPF validated. External sender tagging enabled. Auto-forwarding to external addresses blocked — one of the most reliable business email compromise persistence mechanisms.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📒</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Mailbox Auditing and UAL Forwarding</h4>
|
||||
<p>Mailbox auditing enabled tenant-wide for all user and admin actions. Unified Audit Log configured for forwarding to SIEM or PULSAR. Every mailbox access, calendar sharing change, and permission modification becomes a searchable, retained event.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📊</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Secure Score Baseline and Improvement Plan</h4>
|
||||
<p>Current Secure Score documented with every open recommendation classified: accept, remediate, or mitigate. A realistic 90-day improvement plan targets the highest-impact items within the existing E3 licence — no new spend required to close most gaps.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🛡️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Attack Surface Reduction Rules</h4>
|
||||
<p>ASR rules deployed via Intune in audit mode first, then staged to enforcement. Rules targeting Office macro abuse, credential theft from LSASS, and suspicious process creation — covering the most common malware execution paths without blocking legitimate business workflows.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📸</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>ASTRAL Baseline Capture</h4>
|
||||
<p>ASTRAL deployed to take a Git-tracked snapshot of the post-hardening configuration. Every subsequent change opens a pull request with a diff and an AI-generated narrative. The hardened state becomes the recoverable baseline — if anything drifts, you know immediately and can restore deterministically.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## No New Licensing Required
|
||||
|
||||
The full scope of this module is deliverable on Microsoft 365 E3. We do not recommend upgrading to E5 as a condition of delivery. If E5 features would materially improve a specific control, we say so and explain the trade-off — but we do not use the engagement as a licence upsell.
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 30–60 days |
|
||||
| **Environment** | M365 E3+ |
|
||||
| **Prerequisites** | Global Administrator access; Module 2 (Identity Security) completed or in parallel |
|
||||
| **Natural follow-on** | Module 4 (Data Governance) for sensitivity labels and DLP |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Extract the security your licence already includes</h2>
|
||||
<p>Most E3 tenants leave the majority of their security value unconfigured. This module closes that gap systematically.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: "Module 4 — Data Governance & Compliance"
|
||||
description: "Sensitivity label deployment, retention policies, DLP, eDiscovery readiness, Teams governance, and SharePoint external sharing controls. Regulatory evidence produced as a natural output."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "Data does not stay where you put it. It is copied, forwarded, synced, and shared — and in most tenants, nobody can enumerate where it went or pull it back. This module makes data flows visible, governable, and auditable."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🏷️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Sensitivity Label Deployment</h4>
|
||||
<p>A practical label taxonomy deployed across M365 — not the six-tier compliance architecture that nobody uses, but a scheme your organisation will actually apply. Labels flow through email, Teams, SharePoint, and Office applications. Classification becomes a signal every downstream control can act on.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📅</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Retention Policies for All M365 Workloads</h4>
|
||||
<p>Retention configured for Exchange, SharePoint, OneDrive, Teams messages, and Teams meeting recordings. Regulatory minimums met. Over-retained data that creates unnecessary eDiscovery scope identified and scheduled for deletion. Retention gaps that expose you to "we don't have it" responses closed.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🚫</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>DLP Policies</h4>
|
||||
<p>Data Loss Prevention policies targeting your actual regulated data — payment card numbers, national IDs, health data, or proprietary classifications — with alert-before-block staged deployment. Auto-forward to external addresses blocked. "Anyone with the link" sharing scoped or removed.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">⚖️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>eDiscovery Readiness</h4>
|
||||
<p>Content search scope validated, custodian identification process documented, legal hold workflow tested. If you receive a regulatory request or litigation hold tomorrow, you can respond without improvising under pressure.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">👥</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Teams Governance and Guest Access Controls</h4>
|
||||
<p>Teams lifecycle policy deployed so abandoned Teams do not accumulate as forgotten data stores. Guest access permissions tightened. External sharing settings reconciled across tenant, site, and Teams channel levels — the three layers that routinely disagree and produce unexpected exposure.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Standards Alignment
|
||||
|
||||
This module produces direct compliance evidence for NIS2 Article 21 (data security, access control), DORA Article 9 (ICT security policies — data classification and handling), GDPR Articles 5 and 25 (data minimisation, privacy by design), and ISO 27001 A.5.12–A.5.13 (classification, labelling). External auditors receive the retention logs, sensitivity label reports, and DLP policy documentation as artefacts — not manual screenshots.
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 45–90 days |
|
||||
| **Environment** | M365 E3+ |
|
||||
| **Prerequisites** | Module 2 (Identity) completed — guest access and external sharing controls depend on a clean identity baseline |
|
||||
| **Natural follow-on** | Module 7 (Recovery) to ensure retained data is backed up independently of Microsoft's native retention |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Make your data flows visible</h2>
|
||||
<p>Every share is a copy of your blast radius handed to a party you do not fully control. Module 4 makes that visible and governable.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: "Module 5 — AI Sovereignty Bridge"
|
||||
description: "Shadow AI inventory, Azure OpenAI deployment with private endpoints, Conditional Access for AI tools, first RAG pipeline on proprietary data, and AI governance policy."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "Most organisations already have employees using cloud AI. The question is not whether it happens — it is whether the data flowing through those tools is yours to audit, yours to withdraw, and yours to keep sovereign. This module closes that gap."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔍</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Shadow AI Inventory</h4>
|
||||
<p>Endpoint and proxy data used to enumerate AI tools actually in use — not what the acceptable-use policy permits, but what employees are running. Consumer AI assistants, code completion tools, browser extensions, and embedded SaaS AI features all leave traces. You cannot govern a tool you do not know exists.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔒</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Azure OpenAI on Private Endpoints</h4>
|
||||
<p>Azure OpenAI deployed within your tenant boundary with private endpoint networking — inference traffic stays inside your Azure virtual network, never traverses the public internet. Your data residency requirements are met structurally, not by contractual assurance alone.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🚦</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Conditional Access for AI Tools</h4>
|
||||
<p>CA policies that restrict sanctioned AI tool access to compliant, managed devices and approved users. Consumer AI tool access from corporate devices blocked or scoped via proxy policy. The boundary between sanctioned and unsanctioned AI becomes enforceable.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🧠</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>First RAG Pipeline or Fine-Tuned Model</h4>
|
||||
<p>A working retrieval-augmented generation pipeline — or a fine-tuned model — built on your proprietary data. A general cloud model improves at everyone's tasks. A model trained on your data improves at your tasks alone. That gap compounds and is not recoverable by a vendor.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📜</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>AI Governance Policy</h4>
|
||||
<p>A documented, practical AI governance policy covering sanctioned tools, acceptable data classifications for AI input, human-review requirements for AI-assisted decisions, and a vendor assessment process for new AI procurement. Designed to be enforced, not filed.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## The Economic Case
|
||||
|
||||
At meaningful usage scale, cloud AI inference is priced to grow with usage. Fixed-cost sovereign infrastructure — local models, private Azure endpoints, or auditable sovereign cloud — produces predictable economics. Organisations spending €5,000–€15,000 monthly on cloud AI APIs typically reach break-even within 12–18 months. Module 5 creates the infrastructure that makes that transition feasible.
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 30–60 days |
|
||||
| **Environment** | Azure subscription; M365 E3+ for CA integration |
|
||||
| **Prerequisites** | Module 2 (Identity) for CA enforcement; Module 1 (Endpoint Management) for shadow AI discovery from device telemetry |
|
||||
| **Natural follow-on** | AURORA for cross-tool AI operations once PULSAR and ASTRAL are deployed |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Your intelligence should stay yours</h2>
|
||||
<p>Proprietary data run through a cloud model trains that model — not yours. Module 5 builds the alternative.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: "Module 6 — On-Premises AD & Endpoint Hardening"
|
||||
description: "Full AD identity census, password audit of compromised credentials, KRBTGT rotation, LAPS, Sysmon, PAW architecture, and Entra Connect hardening for hybrid environments."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "The cloud gets the headlines. Active Directory gets compromised. Most AD forests carry a decade of accumulated privilege, service accounts with passwords that predate the organisation's current security team, and group policies nobody dares to touch. This module fixes the kill chain in the on-premises layer."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🗂️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Full AD Identity Census</h4>
|
||||
<p>Every user, computer, service account, and admin group enumerated and assessed. Stale accounts (no logon in 90+ days), orphaned objects (owner departed), and service accounts with non-expiring passwords flagged. The privilege map you didn't know you had.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔑</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Compromised Credential Audit</h4>
|
||||
<p>AD password hashes compared against known-breached credential databases (Elysium / Have I Been Pwned corpus). Accounts using passwords that appear in breach databases identified and forced to reset — before an attacker uses them. This consistently surfaces accounts that have been silently compromised for months.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔄</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>KRBTGT Rotation and Golden Ticket Invalidation</h4>
|
||||
<p>KRBTGT account rotated twice in sequence (required to invalidate any existing Kerberos tickets, including forged golden tickets). Procedure documented for future rotations. A non-rotated KRBTGT is a persistent attacker foothold that survives every other remediation you run.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">💻</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>LAPS and Privileged Access Workstations</h4>
|
||||
<p>Local Administrator Password Solution deployed so every machine has a unique, rotating local admin password — eliminating the lateral movement path of a shared local admin credential. PAW architecture designed for admin tasks to prevent credential theft from the workstations used to manage Tier 0 systems.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📡</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Sysmon Deployment and Entra Connect Hardening</h4>
|
||||
<p>Sysmon deployed to endpoints for detailed process creation, network connection, and registry change logging — the telemetry source that turns a security incident from "we don't know what happened" to "we have the full timeline." Entra Connect sync account permissions tightened and sync server isolated: the bridge between on-premises and cloud is a Tier 0 asset and must be protected as one.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## The Hybrid Identity Risk
|
||||
|
||||
In a hybrid environment, the on-premises AD and the cloud tenant are linked. Compromise of the Entra Connect sync account — a common, often overlooked target — gives an attacker the ability to manipulate cloud identities from on-premises. The on-premises security posture is a cloud security question. This module treats it as one.
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 45–60 days |
|
||||
| **Environment** | On-premises AD with or without hybrid M365 |
|
||||
| **Prerequisites** | Domain Admin access; Module 2 (Identity) for cloud-side alignment if hybrid |
|
||||
| **Natural follow-on** | Module 12 (T0 Asset Protection) for crown-jewel isolation; Module 13 (Privileged Access Architecture) for PAM |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>The cloud is only as secure as the AD behind it</h2>
|
||||
<p>Most kill chains pass through on-premises AD even when the target is cloud resources. Module 6 closes the path.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: "Module 7 — Recovery & Resilience"
|
||||
description: "Backup architecture review, immutable backup deployment, disaster recovery runbooks, tabletop exercise, and ASTRAL baseline as rebuild blueprint. Tested recovery, not assumed."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "The most common recovery lie in the industry: 'we have backups.' Having a backup is not the same as being able to recover. This module replaces the assumption with a tested, documented, and rehearsed capability — so when the incident happens, recovery is a procedure, not an improvisation."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔍</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Backup Architecture Review</h4>
|
||||
<p>Current backup coverage assessed for every workload: M365 data, on-premises systems, cloud VMs, and critical databases. The gaps that consistently appear — M365 data that employees believe Microsoft backs up but that has no independent point-in-time backup, backup systems reachable from the same network as production, backup credentials stored in the same password manager as everything else — are found and documented before an attacker finds them first.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🧱</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Immutable Backup Deployment</h4>
|
||||
<p>Immutable, off-network backup deployed for critical workloads. Ransomware operators delete or encrypt backups before they hit production — a backup reachable from the compromised estate is not a backup. Immutability ensures the backup cannot be modified or deleted even by a fully compromised admin account.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📖</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Disaster Recovery Runbooks</h4>
|
||||
<p>Step-by-step recovery procedures written for every critical workload — including the scenarios nobody documents: AD forest recovery, M365 tenant configuration restore, and cloud infrastructure rebuild from ASTRAL baseline. Each runbook is tested, not just written. A runbook that has never been executed is a hypothesis.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🎯</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Tabletop Exercise</h4>
|
||||
<p>A structured scenario walkthrough — typically a ransomware incident or identity compromise — run with the actual response team. Gaps in communication, decision authority, and technical procedure surface in a tabletop, not in a live incident. Every gap found in the exercise is a gap not found under pressure.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔀</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>ASTRAL Baseline as Rebuild Blueprint</h4>
|
||||
<p>The ASTRAL Git repository — capturing your M365 and Intune configuration — becomes your authoritative rebuild baseline. After a catastrophic configuration failure or tenant compromise, "what do we restore to?" has a deterministic answer. The restore pipeline applies the known-good state without manual reconstruction from memory.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## The Antifragile Recovery Principle
|
||||
|
||||
A robust organisation survives an incident and comes back the same. An antifragile one comes back different — with a shorter kill chain, a tested runbook it now knows works, and one more scenario it has rehearsed. Every incident that runs through this module's feedback loop makes the next one cheaper. The tabletop is not a compliance checkbox; it is the cheapest incident you will ever have.
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 30–60 days |
|
||||
| **Environment** | M365 and/or on-premises |
|
||||
| **Prerequisites** | ASTRAL deployed (Module 1 or 3) for the configuration baseline; inventory of critical workloads |
|
||||
| **Natural follow-on** | Module 11 (Blue/Purple Team) to build the detection capability that feeds the recovery loop |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Know you can recover before you need to</h2>
|
||||
<p>An untested backup is simultaneously fine and worthless. Module 7 tells you which one yours is — before the incident does.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: "Module 8 — Threat & Vulnerability Management"
|
||||
description: "Quantum vulnerability management for the exploitation-first era. Kill-chain-based prioritisation, the ~90% subtraction, four time-budgeted quanta, and the Kill Chain Assessment app."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "Time-to-exploit has collapsed to roughly four hours. Median remediation sits at 43 days. No amount of 'patch faster' closes a gap that runs the wrong way by two orders of magnitude. The answer is not to patch faster — it is to stop using the vulnerability list as the unit of work."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## The Problem with the Old Model
|
||||
|
||||
CVSS scores severity in the abstract. It knows nothing about whether the vulnerable asset is internet-reachable, whether it sits on the kill chain, whether an exploit exists in the wild, or whether a compensating control already neutralises it. Sorting 40,000 findings by CVSS produces a list precisely uncorrelated with where an attacker will actually go.
|
||||
|
||||
The 2026 Verizon DBIR confirms vulnerability exploitation is now the leading initial-access vector — roughly twice phishing. This is not a maturity problem solved with more analysts. It is a model that has run out of road.
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🗺️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Kill Chain Assessment</h4>
|
||||
<p>The Kill Chain Assessment app maps your environment as an attack graph and runs a shortest-path computation across every entry point to every crown jewel. The result is the kill chain — the cheapest route from attacker foothold to existential impact. Every finding is classified P0 (on the shortest chain), P1 (on some path), or P2 (off-chain entirely).</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">✂️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>The ~90% Subtraction</h4>
|
||||
<p>Roughly 90% of "critical" vulnerabilities are not exploitable in a given environment once compensating controls, reachability, and segmentation are mapped. This subtraction — removing false urgency before adding any work — turns "40,000 criticals" into the few hundred that are real and the few dozen that are on fire. It is the highest-leverage move in the programme and it is pure deletion.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">⚡</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Four Time-Budgeted Quanta</h4>
|
||||
<p><strong>Critical (hours):</strong> On the kill chain, reachable, exploit available now. Response is a compensating control — sever reachability, block at the edge, isolate — not the patch. You cannot meet a four-hour window with a vendor patch cycle.<br><strong>Severe (days):</strong> Material risk; reachable with friction. One change window, verify enforcement.<br><strong>Standard (sprint):</strong> The real, non-urgent tail. Drain in sprint-sized batches on the normal change calendar.<br><strong>Dark (unsized):</strong> Reachability or exploitability unknown. Route to discovery — characterise before remediating.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔍</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Zero-Budget Vulnerability Discovery</h4>
|
||||
<p>osquery deployed as a sovereign discovery platform alongside scripted checks for the findings scanners miss — service account privileges, unpatched firmware, container base image CVEs, exposed management interfaces. Discovery before scanner procurement is almost always sufficient to find the kill chain.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">📉</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Kill Chain Length as the Metric</h4>
|
||||
<p>The programme does not measure MTTR. It measures whether the kill chain got shorter. Ten incidents that produce ten patches leave the estate equally fragile. Ten incidents that each sever one structural path leave an estate that is genuinely harder to compromise every time it is tested. That is the only honest definition of improvement.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## The Barbell
|
||||
|
||||
The antifragile TVM programme has two ends and a middle to avoid. **Fast end:** hours-lane compensating controls — edge blocks, isolation, reachability cuts — that win the time race a patch cannot. **Structural end:** segmentation, least privilege, and T0 protection that make most vulnerabilities irrelevant before they are disclosed. **The fragile middle to avoid:** the aging critical-patch backlog that carries hours-lane urgency while moving at sprint-lane speed. Maximum anxiety, minimum protection.
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 45–90 days |
|
||||
| **Environment** | Any (cloud, on-premises, hybrid) |
|
||||
| **Prerequisites** | Module 0 (Diagnostic) to establish the initial kill chain; asset inventory from Modules 1 or 6 |
|
||||
| **Natural follow-on** | Module 10 (Red Team & Validation) to validate that severed paths stay severed |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Stop racing an attacker you cannot outrun</h2>
|
||||
<p>The winning move is not to patch the long tail faster. It is to make most of it not matter — and contain the few that do in hours, not weeks.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "Module 9 — Organisational Resilience"
|
||||
description: "Dev/Sec/Ops merger, shift-left security integration, process assurance for teams feeling out of control, and embedded security review in the delivery pipeline."
|
||||
eyebrow: "Consulting Module"
|
||||
lead: "You do not have a tools problem. You have a handoff problem. Every boundary between development, security, and operations is a boundary where accountability disappears and fragility accumulates. This module removes those boundaries structurally."
|
||||
actions:
|
||||
- label: "Get in Touch"
|
||||
url: "/about/#contact"
|
||||
primary: true
|
||||
- label: "View All Modules"
|
||||
url: "/consulting/skills/"
|
||||
---
|
||||
|
||||
## What It Delivers
|
||||
|
||||
<div class="feature-list">
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔗</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Dev/Sec/Ops Merger</h4>
|
||||
<p>The structural design work to merge development, security, and operations into shared ownership. Shared accountability means one team owns a system from commit to retirement — which means they design it not to fail, because failure is their problem. The alternative is a system designed to pass demo day.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">⬅️</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Shift-Left Security Integration</h4>
|
||||
<p>Security checks embedded in the development pipeline — SAST, dependency scanning, container image scanning, IaC linting — so findings surface at commit time, when they cost a developer ten minutes to fix, rather than in production, where they cost the organisation weeks and significant reputational damage. Security findings fixed in development cost roughly 1% of what they cost in production.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🧭</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Process Assurance for Teams Feeling Out of Control</h4>
|
||||
<p>Structured for teams who have the tools and the people but feel like security is not working — alerts nobody acts on, findings nobody owns, incidents that keep recurring. The engagement maps the handoff failures, assigns ownership, and establishes the operating rhythm that converts activity into outcomes.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="feature-item">
|
||||
<div class="feature-item-icon">🔄</div>
|
||||
<div class="feature-item-body">
|
||||
<h4>Embedded Security Review in the Delivery Pipeline</h4>
|
||||
<p>Security architecture review embedded as a gate in the project lifecycle — not a checkbox at the end of delivery, but a structured checkpoint at design phase when changes are still cheap. Threat models produced as natural artefacts of the delivery process, not as separate compliance documents written by someone who did not build the system.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
## Scope and Prerequisites
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Duration** | 60–90 days |
|
||||
| **Environment** | Any organisation with a development or change delivery function |
|
||||
| **Prerequisites** | Executive sponsor with authority to change team structures; willingness to examine the organisational design honestly |
|
||||
| **Natural follow-on** | Module 11 (Blue/Purple Team) — once the delivery pipeline is secure, build the detection capability that catches what gets through |
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Security is an organisational design problem</h2>
|
||||
<p>No tool fixes a handoff. Module 9 addresses the structure that tools cannot reach.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Get in Touch</a>
|
||||
<a href="/consulting/skills/" class="btn btn-outline">View All Modules</a>
|
||||
</div>
|
||||
</div>
|
||||
@@ -0,0 +1,171 @@
|
||||
---
|
||||
title: "Consulting Modules"
|
||||
description: "14 independent, self-contained security modules. Start where the pain is highest — each module delivers measurable value and creates natural appetite for the next."
|
||||
eyebrow: "Modular Engagements"
|
||||
lead: "Every module stands alone. Every module makes the next one easier. Start where the pain is highest — not where the framework says you should."
|
||||
---
|
||||
|
||||
Every engagement begins with the **Brownhat Diagnostic** (Module 0): a structured two-day NIST CSF 2.0 baseline assessment that produces a prioritised module roadmap. The diagnostic is a paid, bounded engagement and delivers value regardless of whether further work follows.
|
||||
|
||||
<div class="modules-grid">
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 0</div>
|
||||
<h3><a href="/consulting/module-0/">Brownhat Diagnostic</a></h3>
|
||||
<p>Structured two-day NIST CSF 2.0 baseline assessment. Honest picture of your security posture, prioritised gap list, and recommended module sequence. Kill chain synthesis using the Kill Chain Assessment app — maps the unknown estate into an attack graph, computes the shortest path to existential impact, and sizes every finding into a remediation quantum. Entry point for every new client.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">2 days</span>
|
||||
<span class="badge badge-blue">All clients</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 1</div>
|
||||
<h3><a href="/consulting/module-1/">Endpoint Management Foundation</a></h3>
|
||||
<p>Device inventory and enrollment, compliance baseline, shadow IT discovery, basic conditional access integration, ASTRAL deployment for Intune drift detection. Full device visibility in 30–45 days.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">30–45 days</span>
|
||||
<span class="badge badge-green">M365 E3+</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 2</div>
|
||||
<h3><a href="/consulting/module-2/">M365 Identity Security</a></h3>
|
||||
<p>Full identity census, Conditional Access policy register, MFA enforcement, legacy auth blocked, PIM deployment or JIT process, PULSAR for audit log intelligence, guest access audit and governance.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">30–60 days</span>
|
||||
<span class="badge badge-green">M365 E3+</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 3</div>
|
||||
<h3><a href="/consulting/module-3/">M365 Security Hardening</a></h3>
|
||||
<p>Exchange Online Protection tuning, mailbox auditing, Unified Audit Log forwarding, Secure Score baseline and improvement plan, ASR rules, ASTRAL baseline capture. No new licensing required for E3 clients.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">30–60 days</span>
|
||||
<span class="badge badge-green">No new spend</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 4</div>
|
||||
<h3><a href="/consulting/module-4/">Data Governance & Compliance</a></h3>
|
||||
<p>Sensitivity label deployment, retention policies for all M365 workloads, DLP policies, eDiscovery readiness, Teams governance, SharePoint site provisioning. Regulatory evidence produced as a natural output.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">45–90 days</span>
|
||||
<span class="badge badge-orange">NIS2 · DORA · GDPR</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 5</div>
|
||||
<h3><a href="/consulting/module-5/">AI Sovereignty Bridge</a></h3>
|
||||
<p>Shadow AI inventory, Azure OpenAI deployment with private endpoints, conditional access for AI tools, first RAG pipeline or fine-tuned model on proprietary data, AI governance policy. Your intelligence stays yours.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">30–60 days</span>
|
||||
<span class="badge badge-blue">Azure</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 6</div>
|
||||
<h3><a href="/consulting/module-6/">On-Premise AD & Endpoint Hardening</a></h3>
|
||||
<p>Full AD identity census with orphan and privilege analysis, password audit of compromised credentials (Elysium), KRBTGT rotation, LAPS, Sysmon, PAW architecture, Azure AD Connect hardening.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">45–60 days</span>
|
||||
<span class="badge badge-blue">Hybrid identity</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 7</div>
|
||||
<h3><a href="/consulting/module-7/">Recovery & Resilience</a></h3>
|
||||
<p>Backup architecture review and remediation, immutable backup deployment, disaster recovery runbooks, tabletop exercise, ASTRAL baseline as rebuild blueprint. Tested recovery, not assumed.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">30–60 days</span>
|
||||
<span class="badge badge-orange">Ransomware-resilient</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 8</div>
|
||||
<h3><a href="/consulting/module-8/">Threat & Vulnerability Management</a></h3>
|
||||
<p>Quantum vulnerability management for the exploitation-first era. Kill-chain position, reachability, and exploit availability replace CVSS as the sort key. The ~90% subtraction removes false urgency — leaving the 10% genuinely exploitable in your environment. Four time-budgeted quanta: Critical (hours — compensating control, not the patch), Severe (days), Standard (sprint), Dark (unsized — routed to discovery). Zero-budget discovery with osquery and scripts. The Kill Chain Assessment app maps the attack graph and sizes every node automatically.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">45–90 days</span>
|
||||
<span class="badge badge-green">Open-source first</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 9</div>
|
||||
<h3><a href="/consulting/module-9/">Organisational Resilience</a></h3>
|
||||
<p>Dev/Sec/Ops merger, shift-left security integration, process assurance for teams feeling "not in control", quality management engagement, embedded security review in the delivery pipeline.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">60–90 days</span>
|
||||
<span class="badge badge-blue">Culture + process</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 10</div>
|
||||
<h3><a href="/consulting/module-10/">Red Team & Validation</a></h3>
|
||||
<p>Assumption validation after hardening modules. Targeted adversary simulation against the specific kill chain identified in the Brownhat Diagnostic. Measures real security improvement, not compliance scores.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">15–30 days</span>
|
||||
<span class="badge badge-orange">Post-hardening</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 11</div>
|
||||
<h3><a href="/consulting/module-11/">Blue/Purple Team Foundation</a></h3>
|
||||
<p>Building defensive capability from existing tool investments. Detection engineering, alert tuning, SIEM rule development, threat hunting playbooks. Your existing tools, made to actually work.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">45–90 days</span>
|
||||
<span class="badge badge-blue">Existing tools</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 12</div>
|
||||
<h3><a href="/consulting/module-12/">T0 Asset Protection</a></h3>
|
||||
<p>Tier 0 asset classification across identity, infrastructure, and data. Protection architecture for crown-jewel assets. Privileged access design ensuring Tier 0 is never reachable from Tier 1 or 2 compromise.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">30–60 days</span>
|
||||
<span class="badge badge-orange">Architecture</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 13</div>
|
||||
<h3><a href="/consulting/module-13/">Privileged Access Architecture</a></h3>
|
||||
<p>PAM design using Teleport, Tailscale/Headscale, and JIT access. Vendor remote access governance. Ephemeral credentials, session recording, and access reviews. Zero standing access where possible.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">45–60 days</span>
|
||||
<span class="badge badge-blue">Open-source PAM</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="module-card">
|
||||
<div class="module-num">Module 14</div>
|
||||
<h3><a href="/consulting/module-14/">Sovereign Communications</a></h3>
|
||||
<p>Delta Chat chatmail relay, Matrix/Element deployment, crisis out-of-band channel design. Communication infrastructure that remains available and private even if your primary collaboration platform is compromised.</p>
|
||||
<div class="module-meta">
|
||||
<span class="badge badge-blue">15–30 days</span>
|
||||
<span class="badge badge-green">Self-hosted</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="cta-strip">
|
||||
<h2>Not sure where to start?</h2>
|
||||
<p>The Brownhat Diagnostic maps your current posture to a prioritised module sequence. It is a bounded, fixed-price engagement and delivers value regardless of whether further work follows.</p>
|
||||
<div class="actions">
|
||||
<a href="/about/#contact" class="btn btn-primary">Book a Diagnostic</a>
|
||||
<a href="/consulting/" class="btn btn-outline">About Our Approach</a>
|
||||
</div>
|
||||
</div>
|
||||
Reference in New Issue
Block a user