# Move Fast and Fix Things

> *"The best time to plant a tree was 20 years ago. The second best time is now. The worst time is after the storm has already knocked it down."*

This document anchors the antifragile consulting practice in a single, actionable posture: **move fast and fix things**. It is not a contradiction of Taleb's philosophy—it is its operational expression. Antifragility is not achieved by standing still and theorizing. It is earned by rapid iteration, honest repair, and the refusal to let perfect be the enemy of resilient.

---

## The Brownhat Methodology

This practice operates under the **Brownhat** brand when engaging clients. The name is deliberate:

- **Brownfield** — industrial land that has been used, built on, and left with the legacy of past decisions. Every mature organisation's security environment is a brownfield: layers of partially implemented tools, forgotten configurations, and "temporary" solutions that became permanent.
- **Blackhat / Whitehat** — the security domain's language for attackers and defenders. Brownhat sits between them: we understand how attackers think, but we are here to recultivate the environment, not exploit it.

> *"Brownhat is not a methodology for greenfield deployments. It is for organisations that have been building, acquiring, and running for years — and need someone to recultivate what they have before adding anything new."*

**What Brownhat signals to clients**:
- We are not going to sell you a new platform to replace the one you already own.
- We are going to understand your environment as it actually is, not as it was designed to be.
- We are going to extract maximum value from existing investments before recommending anything new.
- We are going to be honest about what you have, what it costs, and what it would take to fix it.

The Brownhat Diagnostic — a structured [NIST CSF 2.0 baseline assessment](../assessment-templates/nist-csf-baseline.md) — is the named entry engagement for new clients. It is how we earn the right to recommend anything.

---

---

## The Philosophy

### Speed Is a Security Control

The organizations that survive are not the ones with the most comprehensive plans. They are the ones that **execute fastest** against the gaps that actually matter. A realistic engagement delivers 30–60% of an ideal posture in 180 days. That is the honest target. It is also, in almost every case, an enormous improvement over what existed before — and infinitely better than the 100% solution that stays in planning and never ships.

The correct comparison is not "30% today vs. 100% in six months." It is "30% today vs. the 0% that will still be there in two years if you wait for the perfect plan." Momentum beats completeness. Imperfect progress beats perfect paralysis.

### Fixing Things Is Strategic

Every unfixed vulnerability, orphaned account, and untested backup is a **compounding liability**. Technical debt in security does not accrue interest linearly. It accrues catastrophically. The longer a gap exists, the more likely it becomes the entry point for an existential incident.

Fixing things is not maintenance. It is **risk reduction at velocity**.

### Work Beats Purchases

Most organizations do not have a tools problem. They have a **utilization problem**. They own EDR but have 40% coverage. They own a SIEM but log only 20% of critical systems. They own a PAM solution but have not onboarded privileged accounts. They own backup software but have never tested a restore.

The antifragile consultant's first duty is not to recommend new spending. It is to **extract the value already paid for**.

---

## The Five Rules

### Rule 1: Start With What You Own

Before any new purchase is discussed, exhaust the capabilities of existing tooling. This is not cheapness. It is **optionality preservation**: every dollar not spent on redundant tooling is a dollar available for structural improvement.

| Common Underutilized Asset | What Most Organizations Do | What We Do |
|---------------------------|---------------------------|------------|
| Microsoft E5 / Defender suite | Buy additional EDR, SIEM, CASB | Maximize Defender for Endpoint, Sentinel, Entra ID PIM, Purview |
| Existing firewall / IDS | Buy another "next-gen" platform | Audit rules, enable logging, integrate with SOC workflow |
| Active Directory | Add third-party IAM | Cleanse accounts, implement PAWs, enforce conditional access |
| Backup solution | Buy additional DRaaS | Test restores, document runbooks, automate verification |
| CMDB / ITAM tool | Start a new discovery project | Populate with T0 assets, enforce ownership, feed security workflow |

### Rule 2: Fix the Kill Chain First

Not all debt is equal. We identify the shortest sequence of failures that would end the organization—the **kill chain**—and we fix those nodes with extreme prejudice. Everything else waits.

This requires brutal honesty:

- If your domain admins are logging in from workstations with email and browsing, that is the kill chain.
- If your backups have never been restored, that is the kill chain.
- If your cloud storage bucket is public and contains customer data, that is the kill chain.
- If your CEO's email has no MFA, that is the kill chain.

We do not fix everything. We fix the **existential** things. Fast.

### Rule 3: Every Fix Must Produce a Signal

A fix that does not generate intelligence is a fix that will rot. Every remediation must produce a **signal**: a metric, an alert, a log entry, or a structural change that prevents recurrence.

| Bad Fix | Good Fix |
|---------|----------|
| "We disabled the old account." | "We disabled the old account and implemented automated orphan detection." |
| "We patched the server." | "We patched the server and added it to automated vulnerability management." |
| "We rotated the password." | "We rotated the password and vaulted it in the PAM with checkout logging." |
| "We fixed the firewall rule." | "We fixed the firewall rule and added a monthly rule review to the change process." |

### Rule 4: Run Housekeeping as a Permanent Stream

This is the rule most often acknowledged and least often followed. In every engagement, cleanup is identified as necessary. In almost no engagement is it ever finished. Stale accounts accumulate. Orphaned permissions persist. Old devices stay enrolled. Legacy protocols remain enabled because removing them requires a change window that never gets scheduled.

The correct response is not to add cleanup to the project backlog. It is to **establish housekeeping as a dedicated, permanently resourced stream with its own queue, its own cadence, and its own accountability**.

Housekeeping is not janitorial work. It is attack surface reduction at a structural level. Every stale account is a credential that can be compromised without detection. Every orphaned permission is a privilege escalation path that BloodHound will find. Every legacy protocol still enabled is an authentication downgrade waiting to happen. The environment accumulates new objects continuously — every employee, every project, every vendor relationship adds accounts, permissions, and configurations. Almost nothing removes them automatically. Without a permanent housekeeping stream, the attack surface grows without bound regardless of what else you fix.

**What housekeeping covers:**

- Stale user accounts: departed employees, contractors, service accounts with no owner
- Orphaned group memberships and permissions that outlasted the project that created them
- Old app registrations and service principals — often the most overlooked and most dangerous
- Enrolled devices that are no longer in use
- Conditional Access policies with no named owner and no documented purpose
- Legacy protocols: NTLM, basic authentication, SMBv1, NTLMv1 — things that should have been disabled years ago
- DNS records for decommissioned services
- Firewall rules added for temporary access that became permanent
- Old GPOs, old admin rights, old certificates

**The engagement implication**: Every module scoping conversation must include a housekeeping component. It is not optional and not deferrable. The client names a resource, a cadence (minimum monthly), and a queue. The queue is populated from module findings and from continuous discovery. Progress is tracked and reviewed at every steering committee. If there is no resourcing for housekeeping, the engagement model must reflect that — because every fix we make will be partially undone within 18 months by new accumulation if the stream does not exist.

---

### Rule 5: Build Toward Greenfield Capability

The cheapest and fastest recovery from a serious breach is often a greenfield deployment — rebuilding the environment from scratch on clean infrastructure rather than remediating a compromised one. Most organisations treat this as a nightmare scenario. The goal is to treat it as a **standard operational capability exercised every five years or so** — not something that wakes you up at night, but something you have done before and know how to do again.

This is the ultimate defender's power move. An attacker's leverage in a breach depends largely on your inability to walk away from the compromised environment. If you can build the parallel company and burn the old one, that leverage disappears. Ransomware becomes an inconvenience rather than an existential event. The threat model changes fundamentally.

**What greenfield capability requires:**

- **Everything documented as code**: infrastructure configuration, security baselines, identity architecture, network topology. If you cannot rebuild it from documentation in a clean environment, you do not own it — you are renting it from accumulated history.
- **Configuration under version control**: M365 policy state in ASTRAL, infrastructure definitions in IaC, runbooks in a repository. The new environment can be provisioned from the same source of truth.
- **Clean data separation**: you know where your data is, what form it is in, and how to migrate it. Data that cannot be migrated cleanly is a dependency you have not acknowledged.
- **Tested migration procedures**: the greenfield capability is not real until it has been exercised. Partial migrations, parallel-environment tests, and recovery drills build the muscle. Each module completion should leave the client one step closer to a documented, tested rebuild path.
- **Vendor independence at critical layers**: you cannot rebuild greenfield if the new environment depends on the same compromised vendor. Optionality (Pillar 2) is the prerequisite.

**The cadence target**: An organisation that can execute a planned greenfield migration in 90 days — with data integrity, minimal service disruption, and full security posture — is in a structurally different risk position than one for which greenfield is theoretical. This is not a one-time project. It is a capability you build, test, and maintain.

**The controlled burn**: forests that are never burned accumulate the fuel for catastrophic fires. Organisations that are never greenfield-deployed accumulate technical debt, legacy dependencies, and accumulated compromise that makes eventual failure more severe. Planned greenfield on a 5-year cycle is the controlled burn that prevents the uncontrolled one.

---

## Mapping to Antifragile Pillars

| Antifragile Pillar | Move Fast and Fix Things Expression |
|-------------------|-------------------------------------|
| **Structural Decoupling** | Identify and eliminate hidden dependencies before they become fatal. Greenfield capability is the ultimate expression: if you can rebuild cleanly, no single vendor or compromise holds you hostage. |
| **Optionality Preservation** | Maximize existing investments to preserve budget for strategic optionality. Greenfield deployment requires vendor independence at every critical layer — build and maintain that independence now. |
| **Stress-to-Signal Conversion** | Every fix must generate telemetry. Incidents are not failures; they are unpaid penetration tests. Convert their lessons into structure. |
| **Sovereign Intelligence** | Use what you own first. Your data, your configurations, your runbooks — all under version control, all portable, all yours. Housekeeping keeps it clean. Greenfield capability proves it. |
| **Asymmetric Payoff Design** | Small, fast fixes on the kill chain yield disproportionate risk reduction. Housekeeping and greenfield capability are the highest-leverage long-term investments: small ongoing cost, enormous reduction in catastrophic risk. |

---

## Mapping to Standards

We do not treat compliance as the goal. We treat it as a **side effect of doing the right things fast**.

| Standard | How We Map |
|----------|-----------|
| **CIS Controls v8** | IG1 is the floor, not the ceiling. We aim for IG1 completeness in 90 days because it is the minimum viable security posture. See [CIS Controls Mapping](../reference/cis-controls-mapping.md). |
| **NIST CSF 2.0** | We align to Identify, Protect, Detect, Respond, Recover—but we emphasize GOVERN as the missing piece in most organizations. See [NIST CSF Mapping](../reference/nist-csf-mapping.md). |
| **ISO 27001** | Annex A controls are addressed through the kill chain-first methodology, not checklist compliance. |
| **DORA / NIS2** | Operational resilience and ICT risk management are natural outcomes of the antifragile rapid-modernisation approach. |

---

## The Consultant's Stance

When you walk into a client environment, bring these assumptions:

1. **They already own enough software.** Your job is to configure, integrate, and operationalize—not to shop.
2. **Their technical debt is worse than they admit.** Your job is to find the kill chain and fix it without shaming.
3. **Speed builds trust.** A visible fix in week one is worth more than a perfect report in week twelve.
4. **Honesty is the product.** You are not a reseller. You are an independent advisor. Say what you would do with your own company's data.

### The Opening Pitch

> *"Most consultants will sell you a shopping list. We start with what you already bought. Our job is to find the gaps that matter, fix them fast, and make sure they stay fixed. We move fast. We fix things. And we do it with the tools you already own."*

---

## Engagement Principles

### Week 1: Brutal Honesty Audit

- Inventory existing tooling and its utilization rate
- Identify the kill chain
- Pick three fixes that can be completed before the next steering committee
- Execute them

### Month 1: Momentum Through Visibility

- Show the client what they could not see before
- Close the highest-risk gaps
- Demonstrate value from existing tools
- Build political capital for harder changes

### Quarter 1: Structural Change

- Convert fixes into process
- Automate detection and response
- Establish the antifragile feedback loop: incident → learning → structure

---

## The AI Distraction

There is a recurring pattern in security consulting: a client opens with "we want AI-powered threat detection" or "can AI help us with our security posture?" and the instinct — especially from vendors — is to say yes and start selling.

The correct response is to ask: *"Do your domain admins have MFA enforced?"*

We call this pattern the **AI Mythos**: the belief that intelligence-layer tooling is the primary answer to security problems. It is not. AI is a multiplier. A multiplier applied to an absent foundation produces nothing. An AI-powered SOC that generates alerts from a network with no MFA, no patching cadence, and no tested backups is generating expensive noise about a patient who already has a terminal condition.

### The Multiplier Principle

Security capabilities stack in layers. Each layer requires the layer below it to function.

```
Foundation   → Identity hygiene, endpoint coverage, patching, tested backups, basic logging
Signal       → Logging turned on, SIEM ingesting the right sources, alerts with owners
Intelligence → Detection engineering, threat hunting, AI-assisted analysis
```

AI lives at layer three. Organisations that have not completed layer one do not benefit from layer three — they buy something that has nothing to amplify.

**The test**: Ask "what would have stopped this breach?" For the overwhelming majority of incidents — credential theft, ransomware, insider threat, misconfiguration exploitation — the answer is a layer-one control: MFA, patched systems, least-privilege accounts, a working backup. Not AI detection. Not an AI SOC. Not AI-powered SIEM correlation.

The CIS Controls make this explicit. IG1 — 56 safeguards covering basic inventory, secure configuration, data protection, account management, patching, and backup — is the minimum viable security posture. Every organisation should complete IG1 before spending money on anything above it. AI-powered security tools are not IG1 controls. They are IG3 multipliers applied to an IG1 foundation.

### What to Do When a Client Leads with AI

The client who opens with AI is not wrong to want it. They are wrong about sequencing. Your job is to redirect without dismissing.

**The redirect**:

> *"AI security tools are most valuable when you have a strong signal to amplify. The fastest path to benefiting from AI is making sure the basics are right first — because AI on a broken foundation is just expensive noise. Let's start with the Brownhat Diagnostic, find your kill chain, and close the gaps that AI can't compensate for. Then you'll actually get value from the AI layer on top."*

This reframes AI as a reward for good hygiene, not a substitute for it. It respects the client's interest in AI while directing the budget where it produces real risk reduction.

### The Sequencing Rule

The antifragile pillars are not equally weighted at the start of an engagement. They are sequenced:

1. **Structural Decoupling** (Pillar 1) and **Optionality Preservation** (Pillar 2) are foundations — you establish these first by mapping and removing dangerous dependencies.
2. **Stress-to-Signal Conversion** (Pillar 3) requires having something to instrument — logging, monitoring, telemetry. This is layer two.
3. **Sovereign Intelligence** (Pillar 4) — AI sovereignty, local models, owned cognitive infrastructure — presupposes that you have a foundation worth protecting and a signal worth amplifying. It is not the starting point.
4. **Asymmetric Payoff Design** (Pillar 5) is the lens applied throughout — concentrate effort where failure is existential.

A client excited about Pillar 4 who has not addressed Pillar 1 is building a sophisticated roof on a house with no walls.

### What "Move Fast" Means Here

Moving fast does not mean buying AI tools quickly. It means closing the kill chain quickly — with unglamorous, proven controls that stop breaches:

- Enforce MFA on every account. Today.
- Patch internet-facing systems. This week.
- Verify that backups restore. This month.
- Remove stale privileged accounts. In week one.
- Turn on logging where it is off. Before anything else.

These are not interesting. They are not cutting-edge. They are the interventions that would have prevented most of the incidents in the headlines. The AI tools that make headlines did not prevent those incidents.

---

## When the Vulnerability Surface Is Effectively Infinite

Recent AI-assisted security research — including large-scale automated vulnerability discovery across entire software stacks — has surfaced a reality that was always true but is now undeniable: **the number of exploitable vulnerabilities in any complex environment exceeds any organisation's capacity to patch them.** This is not a new problem. It is a shift in visibility. The vulnerabilities existed before. We can now find them faster than we can fix them.

The vendor response to this is predictable: "You need AI-assisted patching." Faster discovery paired with faster remediation, AI all the way down.

This is the wrong frame. It accepts a race you cannot win.

### The Architectural Response

The correct response to an effectively infinite vulnerability surface is not to patch faster. It is to **move to a realm where most vulnerabilities matter less** — by designing systems architecturally so that the exploitation of any single vulnerability does not lead to existential compromise.

This is not a new idea. It is the fundamental premise of defence in depth, blast radius limitation, and kill chain thinking. What has changed is the urgency: when AI can identify thousands of vulnerabilities across your stack in hours, the "patch-first" strategy is exposed as insufficient. The architectural strategy becomes the only viable long-term position.

The moves:

**Kill chain awareness** — Not every CVE is existential. The ones that matter are the ones that sit on the path from "nothing bad has happened yet" to "the organisation cannot operate." Concentrate protection there. A critical vulnerability in a segmented, non-privileged system is a low-priority finding. The same vulnerability on a domain controller, a backup server, or an OT control system is P0. The vulnerability is the same; the kill chain position is what changes the priority.

**Blast radius limitation** — Segmentation, least privilege, and structural decoupling mean that exploiting a vulnerability in one component cannot pivot freely through the environment. A flat network with over-privileged accounts converts every vulnerability into a potential total compromise. A segmented, least-privilege environment converts most vulnerabilities into limited-scope incidents.

**Assume breach posture** — Design for rapid detection and recovery rather than prevention of every entry. If architectural controls are in place, a compromised component is an isolated incident, not a catastrophe. The question shifts from "how do we keep attackers out?" to "how quickly do we detect, contain, and recover?" This is Pillar 3 (Stress-to-Signal Conversion) applied to the vulnerability layer.

**Known-good baseline** — Configuration management (ASTRAL) and system state tracking mean that after a compromise, you can restore to a verified baseline. The ability to rebuild rapidly from a known-good state reduces the cost of successful exploitation dramatically.

### What This Means for Prioritisation

When clients ask how to respond to the AI vulnerability discovery story, the answer is not a new patching tool. It is a sequenced architectural programme:

1. Map and close the kill chain — the vulnerabilities that sit on the path to existential compromise get patched first, regardless of CVSS score.
2. Reduce blast radius — segmentation and least privilege limit the value of any single exploit.
3. Build detection and recovery capability — assume some vulnerabilities will be exploited; make exploitation detectable and recoverable.
4. Then consider tooling to accelerate patch velocity for the long tail.

The correct posture is: **a well-segmented, least-privilege, T0-protected environment with fast recovery capability survives more CVEs than a flat, over-privileged environment with a fast patch programme.** Architecture beats velocity in the vulnerability race. It is the only bet you can actually win.

---

## Contrast With "Move Fast and Break Things"

The Silicon Valley mantra was an excuse for externalizing harm. "Move fast and fix things" is its responsible successor:

| Move Fast and Break Things | Move Fast and Fix Things |
|---------------------------|--------------------------|
| Ship now, fix later | Fix now, ship sustainably |
| Externalize risk to users | Internalize risk and reduce it |
| Growth at all costs | Resilience as the foundation of growth |
| Ignore technical debt | Pay down the highest-interest debt first |
| Disrupt without accountability | Build trust through visible repair |

---

*Next: [CIS Controls Mapping](../reference/cis-controls-mapping.md)*
*Previous: [Antifragile Manifest](antifragile-manifest.md)*