feat: Add vulnerability-management arc — Book VII, quantum framework, ORION, and kill-chain assessment tool
This commit is contained in:
@@ -34,11 +34,13 @@ Most security and resilience frameworks optimize for **robustness**—the abilit
|
||||
│ ├── executive-summary.md # One-page board brief
|
||||
│ ├── executive-summary-cs.md # Czech version of board brief (Výkonné shrnutí)
|
||||
│ ├── c-suite-conversation-guide.md # Persuasion scripts for top management
|
||||
│ └── t0-asset-framework.md # Tier 0 asset classification and protection
|
||||
│ ├── t0-asset-framework.md # Tier 0 asset classification and protection
|
||||
│ └── quantum-vulnerability-management.md # Time-budgeted quanta model for the exploitation-first era (Book VII companion)
|
||||
├── playbooks/ # Executable modernisation and response plans
|
||||
│ ├── rapid-modernisation-plan.md # 30-60-90-180 day transformation roadmap
|
||||
│ ├── endpoint-management-entry-vector.md # Intune/device management as engagement entry point
|
||||
│ ├── ai-assisted-tvm.md # AI-powered vulnerability management blueprint
|
||||
│ ├── kill-chain-assessment-app.md # Spec for the offline kill-chain mapping tool (tools/kill-chain-assessment.html)
|
||||
│ ├── zero-budget-vulnerability-discovery.md # Script-based vuln discovery without commercial scanners
|
||||
│ ├── perimeter-scanning-capability.md # External attack surface scanning strategy
|
||||
│ ├── osquery-custom-platform.md # Build a sovereign vuln/asset discovery platform on osquery
|
||||
@@ -66,6 +68,10 @@ Most security and resilience frameworks optimize for **robustness**—the abilit
|
||||
│ ├── vertical-power-utilities.md # Power generation, transmission, water utilities
|
||||
│ ├── vertical-telco.md # Telecommunications and mobile operators
|
||||
│ └── vertical-banking.md # Financial services regulatory alignment
|
||||
├── tools/ # Standalone runnable instruments (offline, single-file)
|
||||
│ ├── README.md # Tool index and design constraints
|
||||
│ └── kill-chain-assessment.html # Maps unknown estates → shortest existential path → quanta
|
||||
├── books/ # The Antifragile Handbook (Books I–VII + field guides)
|
||||
└── assets/ # Diagrams, visuals, and presentation materials
|
||||
```
|
||||
|
||||
|
||||
@@ -0,0 +1,203 @@
|
||||
# The Antifragile Handbook for M365 & Active Directory
|
||||
|
||||
## Book VII — Vulnerability Management
|
||||
|
||||
> *The patch cycle was built for a world where you had weeks. That world is gone. Exploitation now arrives in hours, the patch arrives in days, and no amount of "patch faster" closes a gap that runs the wrong way by two orders of magnitude. Stop racing the attacker to the patch. Change the race.*
|
||||
|
||||
---
|
||||
|
||||
## The governing question
|
||||
|
||||
The first six books were written for a world in which the dominant way into an estate was a person — phished, tricked, talked past the controls. That assumption is now wrong. As of the 2026 Verizon DBIR, **exploitation of vulnerabilities is the leading initial-access vector in confirmed breaches — roughly twice phishing, for the first time in the report's history.** The front door changed. This book changes the lens to match.
|
||||
|
||||
The governing question is the same as everywhere else in the handbook, pointed at the vulnerability surface:
|
||||
|
||||
> **When — not if — a vulnerability on your estate is exploited, does the estate come back weaker, the same, or stronger?**
|
||||
|
||||
A fragile estate treats every CVE as a race it has already lost and patches by score until the analyst burns out. A robust estate patches the important ones fast and survives. An antifragile estate **stops treating the vulnerability list as the unit of work at all** — it asks where the vulnerability sits on the kill chain, removes the false urgency that hides the real targets, contains the few that matter in hours, and feeds every exploited path back into architecture so the *next* vulnerability on that path is a non-event.
|
||||
|
||||
The reframe that powers the book: **you cannot win a speed race against machine-speed exploitation by moving your humans faster, and you do not have to.** The winning move is not to patch the long tail before the attacker reaches it — that is arithmetically impossible and getting worse. The winning move is to make most vulnerabilities not matter (blast-radius and reachability), contain the few that do in the time you actually have (hours, not weeks), and convert every near-miss into a permanently shorter kill chain.
|
||||
|
||||
---
|
||||
|
||||
## Why the old model is finished — the arithmetic
|
||||
|
||||
Four numbers end the debate, and they are worth saying out loud to a client in a room:
|
||||
|
||||
- **Time-to-exploit has collapsed** from a median of 771 days in 2018 to roughly **4 hours** by 2024. The window the entire patch-management model was built around — the weeks between disclosure and exploitation — has effectively closed.
|
||||
- **Patching still takes weeks.** The 2026 DBIR puts median remediation of edge-device vulnerabilities at **43 days**, with only **54% remediated within a year.** 43 days versus 4 hours is the whole story.
|
||||
- **Volume has gone vertical.** ~59,000 new CVEs were projected for 2025, a ~50% year-on-year increase, and 2026 is on pace to exceed it. The enrichment infrastructure has buckled under the load — NIST reclassified ~29,000 backlogged CVEs to "Not Scheduled," meaning the data you relied on to prioritise is arriving late or never.
|
||||
- **Exploitation is being automated.** Autonomous exploitation research has demonstrated AI systems exploiting 174 of 178 CISA Known-Exploited Vulnerabilities at an average of ~21 minutes each, with no human in the loop, and an ~87% success rate against one-day vulnerabilities in real software. The attacker side automates faster than the defender side because generating a working exploit for a known bug is a clean, verifiable, deterministic problem — exactly what machines are good at — while *defending* requires environmental context, which is exactly what they have historically been bad at.
|
||||
|
||||
The honest conclusion: **a human-paced, score-sorted patch programme is now structurally incapable of keeping pace.** This is not a maturity problem to be solved with more analysts. It is a model that has run out of road. Everything below is the replacement.
|
||||
|
||||
One piece of good news hides in the data, and the whole framework leans on it: **roughly 90% of "critical" vulnerabilities are not actually exploitable in a given environment once compensating controls, reachability, and segmentation are properly mapped.** The fragility is not that you have 40,000 criticals. It is that you cannot yet tell which ~10% are real, so you treat all 40,000 as equally urgent and drown. Antifragile vulnerability management is, before anything else, the discipline of removing the 90% of false urgency so the real targets become visible.
|
||||
|
||||
---
|
||||
|
||||
## 1. Fragility inventory — where vulnerability management rots
|
||||
|
||||
### CVSS as the prioritisation engine
|
||||
|
||||
The original sin. 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, or whether an existing control already neutralises it. A 9.8 on a segmented, non-privileged, unreachable host is noise; a 7.5 on an internet-facing box one hop from a domain controller is a P0. Sorting 40,000 findings by CVSS produces a list that is precisely uncorrelated with where the attacker will actually go. It feels like prioritisation. It is sorting by the wrong key.
|
||||
|
||||
### The infinite, undifferentiated backlog
|
||||
|
||||
"We have 40,000 criticals" is not a vulnerability problem; it is a *triage* problem wearing a vulnerability costume. An undifferentiated backlog has no front — every item looks equally urgent and equally hopeless — so the team either patches by score (wrong key) or freezes. The backlog grows faster than any human process can drain it, which means a backlog-draining strategy is a strategy to fall behind forever.
|
||||
|
||||
### Patch velocity treated as the only lever
|
||||
|
||||
The reflex when the AI-exploitation story lands is "we need to patch faster." It is the wrong reflex, and it is the most expensive one. You cannot out-patch a 4-hour exploitation window with a 43-day cycle by trimming the cycle to 30 days. Velocity is a real lever for the long tail, but as the *primary* response to the speed problem it is a fragilizing illusion — it consumes the entire budget defending a race you mathematically cannot win, and leaves nothing for the moves that actually change the outcome (reachability, blast radius, containment, architecture).
|
||||
|
||||
### The half-done remediation — the ghost patch
|
||||
|
||||
Book I's ghost-policy corollary, applied to vulnerabilities. A patch deployed to 80% of the fleet, a compensating rule applied but never verified to actually block, a "remediated" ticket closed against a host that quietly rolled back — these are *worse* than an open finding, because the open finding is at least honest. A remediation that displays as done while enforcing nothing is a vulnerability with a clean bill of health. **A vulnerability that is partly fixed is not partly safe; it is fully exploitable and now invisible.**
|
||||
|
||||
### The unscanned and the unscannable
|
||||
|
||||
You cannot prioritise what you cannot see. The fleet you don't scan (Book IV's shadow and dark device populations), the appliance whose firmware no scanner reads, the SaaS you don't own, the dependency buried three layers into a container image — these are the dangerous quanta precisely because they carry no score at all. An estate that congratulates itself on draining the *known* backlog while the unknown surface grows is optimising the lit area under the streetlight.
|
||||
|
||||
### Reachability and compensating controls left unmapped
|
||||
|
||||
If you have not mapped which assets are internet-reachable, which sit behind a WAF or EDR, which are segmented away from the crown jewels, then you have no way to perform the one subtraction that matters — collapsing 40,000 criticals to the ~10% that are genuinely exploitable here. Without reachability and control context, every finding is theoretically critical and therefore practically un-prioritisable.
|
||||
|
||||
### Remediation as the silent bottleneck
|
||||
|
||||
Detection is largely solved — most teams are *drowning* in findings, not short of them. The bottleneck is everything after: triage, ownership, change windows, approvals, deployment, verification. Each human handoff in that chain costs hours or days, and there are usually five or six of them. In a world of 4-hour exploitation, a six-handoff remediation pipeline *is* the vulnerability.
|
||||
|
||||
### Detection without a feedback path to architecture
|
||||
|
||||
A vuln gets exploited (or nearly), it gets patched, the ticket closes, and the *path* the attacker used — the flat segment, the over-privileged service account, the reachable management interface — stays exactly as it was, waiting for the next CVE to land on it. The incident produced a patch but no structural change. The disorder was wasted. This is the Book VI failure mode pointed at the vulnerability layer, and it is the difference between a programme that gets stronger and one that runs in place forever.
|
||||
|
||||
---
|
||||
|
||||
## 2. Via negativa — what to remove
|
||||
|
||||
The defining act of antifragile vulnerability management is **subtraction before addition.** You remove false urgency, false comfort, and false work before you add a single new tool.
|
||||
|
||||
1. **Remove CVSS as the sort key.** It does not go away — it stays as one input — but it stops being the thing that orders the queue. The queue is ordered by kill-chain position and exploitability in *this* environment.
|
||||
2. **Remove the ~90% of criticals that aren't exploitable here.** Map reachability and compensating controls and *delete the false urgency* on everything segmented, unreachable, or already neutralised. This is the single highest-leverage move in the entire programme: it turns "40,000 criticals" into "400 that are real and 40 that are on fire," and it is pure subtraction.
|
||||
3. **Remove the undifferentiated backlog.** A backlog with no structure is itself a fragility. Replace it with quanta (Section 3) — time-budgeted, atomic, completable units. An item that cannot be placed in a quantum is either not real (delete it) or not yet understood (route it to discovery).
|
||||
4. **Remove "patch faster" as the headline strategy.** Demote velocity to what it is — a lever for the long tail — and stop letting it consume the budget that belongs to reachability, blast radius, and containment.
|
||||
5. **Remove the half-done remediation from the "done" column.** A fix is not done until it is *verified to enforce* against a real test, not until the ticket is closed. Every quantum closes with a signal or it does not close. (Book I: validate by observation, never by inspection.)
|
||||
6. **Remove human handoffs from the hours-lane.** The steps in the critical-quantum pipeline that require no judgement — detection, reachability assessment, work-item generation, routing — get automated within policy guardrails so the scarce human judgement is spent only where judgement is actually required. You are not removing the human; you are removing the human from the steps that were only ever latency.
|
||||
|
||||
---
|
||||
|
||||
## 3. Quantum vulnerability management — the core model
|
||||
|
||||
Here is the model the rest of the book turns on, and the direct answer to "how do we size remediation to a world that moves in hours."
|
||||
|
||||
A **quantum** is the smallest unit of remediation that (a) fully closes a specific exploitable path, (b) is sized to a time budget it can *actually be completed within*, and (c) ends in a verifiable signal. The word is deliberate. A quantum is *atomic* — you cannot ship half of it and claim half the protection (that is the ghost patch). And it is *discrete* — work is packetised into units that fit the time you have, not smeared across an infinite backlog.
|
||||
|
||||
The sort key is not severity. It is **time-to-existential-impact**, which is a function of three things the estate actually determines:
|
||||
|
||||
> **kill-chain position × reachability × exploit availability**
|
||||
|
||||
A vulnerability that sits on the path to existential compromise, is reachable by the adversary, and has a working exploit in the wild has a time-to-impact measured in hours. The same vulnerability, segmented away and unreachable, has a time-to-impact measured in months — or never. **The vulnerability is identical; its quantum is different, because its position is different.** This is the Book I principle (kill-chain position changes priority, not the CVE) made operational.
|
||||
|
||||
That sort produces three live quanta and one that is more dangerous than all of them:
|
||||
|
||||
### Critical quantum — the hours lane
|
||||
|
||||
On the kill chain, reachable, exploitable now. The time budget is **hours**, and that fact dictates the response: **you cannot wait for a patch cycle, so the critical quantum is closed by a compensating control, not necessarily the patch.** Block it at the edge, sever the reachability, disable the vulnerable feature, isolate the host, pull it behind the WAF. The patch follows later in the standard lane on the normal change calendar. The critical quantum's job is to **move the asset out of the hours-window** — to convert a 4-hour time-to-impact into a non-urgent one — by the cheapest fast control available. This is the lane that must be partly autonomous (Section 6), because human-paced execution cannot meet an hours budget.
|
||||
|
||||
### Severe quantum — the days lane
|
||||
|
||||
Material risk, reachable with friction, or where a compensating control already buys partial cover. The time budget is **days**. These are batched into a days-sized packet of work that can be fully completed and verified inside a single short change window — not started and left at 80%.
|
||||
|
||||
### Standard quantum — the sprint lane
|
||||
|
||||
The long, real, non-urgent tail. The time budget is a **sprint**. The discipline here is batching: the long tail is drained in sprint-sized quanta of work that *can actually be finished*, each one atomic and verified, rather than as an ever-growing list nobody ever reaches the bottom of. This is the only lane where "patch velocity" is the right tool, and it is fine for it to be slow, because by definition nothing in it is on fire.
|
||||
|
||||
### Dark quantum — the unsized unknown
|
||||
|
||||
The most dangerous quantum is the one you cannot size, because you cannot yet see the asset, cannot establish reachability, or cannot determine exploitability. An unsized quantum is not a low priority — it is an *uncharacterised* one, and uncharacterised risk on an unknown asset is exactly how estates die. The antifragile response is not to ignore it (it has no score, so the old model does) but to **route it to discovery and to the Kill Chain Assessment** — to spend effort turning a dark quantum into a sized one, because a known severe is safer than an unknown nothing. This lane is why discovery (Book IV, the zero-budget discovery playbooks, the Kill Chain Assessment app) is part of vulnerability management and not separate from it.
|
||||
|
||||
**The quantum discipline in one line:** size every remediation to the time you actually have, make each unit atomic and verifiable, and spend your scarce judgement converting dark quanta into sized ones — not re-sorting the known list by the wrong key.
|
||||
|
||||
---
|
||||
|
||||
## 4. The barbell — fast containment and deep architecture, nothing in the fragile middle
|
||||
|
||||
The vulnerability barbell has two ends and a lethal middle.
|
||||
|
||||
**One end: cheap, fast, reversible containment.** The hours-lane compensating controls — edge blocks, reachability cuts, feature disables, isolation. Low cost, high speed, applied within policy, reversible when the patch lands. This end exists to win the time race the patch can never win.
|
||||
|
||||
**The other end: slow, structural, blast-radius reduction.** Segmentation, least privilege, T0 protection, assume-breach architecture (the whole of Books II–V). This is the end that makes the ~90% of vulnerabilities *not matter*, because a vulnerability that cannot reach anything important and cannot pivot is a finding, not an incident. It is slow and expensive and it is the only durable bet — architecture beats velocity in the vulnerability race, and it is the only race you can actually win.
|
||||
|
||||
**The fragile middle to avoid: the aging critical-patch backlog.** A months-long queue of "critical" patches is neither fast containment nor structural fix. It is the worst of both — it carries the urgency of the hours-lane but moves at the speed of the sprint-lane, so it spends maximum anxiety for minimum protection while the attacker clears it for you, one exploited host at a time. The barbell says: contain it fast *or* architect it away. Do not let it sit in the middle, aging, pretending that "we're working through the criticals" is a posture.
|
||||
|
||||
The asymmetric-payoff reading (Pillar 5): a few hours of compensating-control work on a kill-chain node prevents a catastrophe, and a segmentation project that costs a quarter makes a thousand future CVEs irrelevant. Both ends of the barbell are convex. The fragile middle is concave — maximum cost, minimum return.
|
||||
|
||||
---
|
||||
|
||||
## 5. Optionality & recovery — designing so most vulnerabilities can't matter
|
||||
|
||||
- **Reachability as a control surface.** If you can cut a vulnerable asset off from the adversary faster than you can patch it — and you almost always can — then reachability *is* your fastest remediation. Build the capability to sever reachability quickly (edge policy as code, network isolation on demand) and you have an answer to every hours-lane finding that does not depend on a vendor patch existing yet.
|
||||
- **Compensating-control inventory, mapped in advance.** The ~90% reduction only works if you already know, per asset, what controls are in front of it. Map EDR coverage, WAF rules, segmentation, and internet reachability *before* the incident, so that when a zero-day drops you can answer "are we actually exposed?" in minutes instead of days. This map is the single most valuable artefact in the programme.
|
||||
- **Blast-radius limitation as vulnerability management.** Every segmentation boundary and every collapsed standing privilege is a vulnerability-management control, because it converts "exploit one thing, own everything" into "exploit one thing, contain it." The cheapest way to manage a vulnerability is to have already made it survivable.
|
||||
- **Known-good baselines and config-as-code (ASTRAL).** When a vulnerability is exploited, the ability to restore the affected control plane to a verified baseline collapses the cost of exploitation. A reachable, recoverable, version-controlled estate treats a successful exploit as an inconvenience, not a catastrophe.
|
||||
- **The pre-made "isolate vs patch vs rebuild" decision.** Decide the criteria before the incident: when do we contain-and-wait, when do we emergency-patch, when do we rebuild from known-good? Deciding under fire is how the half-done remediation gets created.
|
||||
|
||||
---
|
||||
|
||||
## 6. Stressor — the autonomy and the feedback loop
|
||||
|
||||
Two stressors run this book, and the second is the one that makes it antifragile rather than merely fast.
|
||||
|
||||
### Autonomy in the hours-lane — matching machine speed with machine speed
|
||||
|
||||
The article that prompted this book is right about the core asymmetry: **attackers are executing at machine speed and defenders are still running remediation through human-paced processes designed for a world with weeks of lead time.** The hours-lane cannot be served by a pipeline with five human handoffs. So the critical quantum's execution — detect the new exposure, cross-reference the asset inventory, assess reachability and compensating controls, generate the work item with context, route it, and in the clear cases *apply the compensating control* — runs autonomously **within human-defined guardrails.**
|
||||
|
||||
The repo's standing scepticism applies and sharpens the point rather than contradicting it: **AI on a broken foundation is expensive noise.** Autonomy without environmental context just generates tickets faster — "faster noise," the exact toil that makes developers dread security. The autonomy only works *because* the foundation is in place: the compensating-control map, the reachability model, the known-good baseline, the segmented architecture. Autonomy is the accelerator on the hours-lane; architecture is still the durable bet. The human role moves up a level — from doing the remediation to **governing the policy**: which classes of action the system may take, which severity thresholds trigger automated containment, which changes still require a human. That is a better use of scarce security talent and the only operating model that survives the volume. The concrete blueprint for this lane is in [AI-Assisted TVM](../playbooks/ai-assisted-tvm.md); this book is the principle, that playbook is the build.
|
||||
|
||||
The guardrail is the whole game. Autonomous does not mean uncontrolled. The most defensible implementations keep the human at the policy boundary and delegate only execution — and they apply compensating controls (reversible, contained) far more readily than irreversible changes. Start the autonomy on the safest, highest-value action: cutting reachability on a confirmed-exploitable, internet-facing, kill-chain asset.
|
||||
|
||||
### The feedback loop — every exploited path becomes a shorter kill chain
|
||||
|
||||
This is the climax, and it is the same machine as Book VI. A vulnerability that was exploited, or nearly exploited, is the cheapest penetration test you will ever get — honest, real-world data about exactly where a path to the crown jewels was open. Patching the CVE wastes that data. The antifragile move is to **sever the path**: the flat segment gets a boundary, the over-privileged service account gets collapsed, the reachable management interface gets pulled behind the bastion — so that the *next* vulnerability that lands on that path is a non-event before it is ever disclosed.
|
||||
|
||||
Measure the loop, not just the lane. MTTR tells you how fast you patch; it does not tell you whether you are getting stronger. The antifragile metric is: **after each exploited-or-near vulnerability, did the kill chain get shorter?** If the last ten vulnerability incidents produced ten patches and zero severed paths, the loop is broken and you are merely fast. If they produced ten patches and six structurally shortened kill chains, the estate is getting harder to compromise every time it is tested — which is the only honest definition of antifragile.
|
||||
|
||||
---
|
||||
|
||||
## Honest uncertainty (verify the moving parts)
|
||||
|
||||
Stable and Lindy (teach with confidence): CVSS is not a priority; kill-chain position is. Most criticals aren't reachable. A half-done remediation is a hidden full vulnerability. You cannot out-patch machine-speed exploitation; you can make most vulnerabilities not matter and contain the few that do. Every exploited path should shorten the kill chain. None of that churns — it is the architecture-beats-velocity thesis applied to vulnerabilities, and it will outlive every tool named here.
|
||||
|
||||
What moves, and what you must verify:
|
||||
|
||||
- **The headline statistics churn annually.** The "exploitation is #1, ~2× phishing" finding is the 2026 DBIR; the 4-hour and 43-day figures, the ~59,000-CVE projection, the autonomous-exploitation benchmarks — all of these are point-in-time and will move. The *direction* (exploitation rising, time-to-exploit collapsing, volume exploding) is the stable signal; the specific numbers need re-checking against the current year's DBIR, M-Trends, and FIRST/CVE data before you put them on a slide.
|
||||
- **The enrichment infrastructure is actively degrading.** NVD's backlog and the "Not Scheduled" reclassification mean the data you use to prioritise is itself unreliable and getting worse. Verify what enrichment you can actually trust *today*, and lean harder on your own reachability and exploitability signals precisely because the public ones are thinning.
|
||||
- **The autonomous-execution tooling is immature and fast-moving.** The Zero-Day-Agent-class pattern (autonomous detect → reachability assessment → compensating control) is real and operational but the products, their accuracy, and their guardrail models are evolving monthly. Verify current capability and, more importantly, current *failure modes* before you delegate any action — and start with reversible compensating controls, never irreversible change.
|
||||
- **The ~90%-not-exploitable figure is environment-specific.** It is a defensible industry estimate, not a law. The real number depends entirely on how well your compensating controls are actually mapped and enforced — and a mapped control that has rotted into a ghost is a false negative that will hurt you. Test the controls you are counting on, do not trust the map.
|
||||
- **Exploit-availability and threat-intelligence feeds** (CISA KEV, exploit databases, vendor advisories) are reliable in principle but vary in latency and coverage — verify which feeds are current and how fast they update before you wire them into the hours-lane.
|
||||
|
||||
If a prioritisation decision hinges on a current specific, verify it and test it. "We confirmed this asset is internet-reachable and the EDR rule actually blocks the exploit" beats any CVSS score ever published.
|
||||
|
||||
---
|
||||
|
||||
## Consolidated judgement prompts
|
||||
|
||||
- When a vulnerability on this estate is exploited, do we come back weaker, the same, or stronger? What's the mechanism that makes it stronger?
|
||||
- Are we sorting by CVSS, or by kill-chain position × reachability × exploit availability?
|
||||
- Of our "criticals," how many are actually reachable by an adversary right now? If we don't know, that is the first finding.
|
||||
- For our top exploitable findings: can we sever reachability faster than we can patch? If yes, why are we waiting for the patch?
|
||||
- Is anything in the "done" column a ghost patch — closed but never verified to enforce?
|
||||
- What is sitting in the fragile middle — the aging critical-patch backlog that is neither contained fast nor architected away?
|
||||
- How many human handoffs are in our hours-lane, and which of them require actual judgement versus just adding latency?
|
||||
- What's in the dark quantum — the unscanned, the unscannable, the unowned — and what are we doing to size it?
|
||||
- For the last ten vulnerability incidents: how many produced a severed path versus just a patch? Is the kill chain getting shorter?
|
||||
|
||||
---
|
||||
|
||||
## Where this book sits in the arc
|
||||
|
||||
Books II–V harden the containers and contents; Book VI builds the loop that makes shocks pay. Book VII is what happens when the dominant shock stops being a phished human and becomes an exploited vulnerability arriving at machine speed. The answer is not a seventh thing bolted on — it is the same antifragile lens (subtract the false, protect the irreplaceable, contain the few that matter, feed every shock back into structure) applied to the surface the attacker now prefers. The vulnerability list was never the unit of work. The kill chain always was.
|
||||
|
||||
Move fast and fix things.
|
||||
|
||||
---
|
||||
|
||||
*Book VII of the Antifragile Handbook. Pairs with the [Quantum Vulnerability Management](../core/quantum-vulnerability-management.md) framework and the [Kill Chain Assessment app](../playbooks/kill-chain-assessment-app.md); the build-level companion is the [AI-Assisted TVM Blueprint](../playbooks/ai-assisted-tvm.md).*
|
||||
@@ -68,7 +68,17 @@ For most estates the honest answer to "can you see where it went?" is no. That's
|
||||
|
||||
The capstone, because it decides whether everything before it was merely robust or genuinely antifragile. Detection and recovery are not the sad afterthought — they're the feedback loop that changes the structure of the estate after every shock. An org that buries incidents stays fragile. An org that treats them as fuel becomes antifragile. This book covers the recovery lies the industry tells itself (untested backups, undocumented break-glass, AD forest recovery nobody has practised), builds the detection architecture, and — most importantly — describes the machine that turns incidents, alerts, and near-misses into structural improvement.
|
||||
|
||||
Read this last. It only makes sense once you've built something worth protecting.
|
||||
Read this once you've built something worth protecting — it closes the original defensive arc (Books I–VI).
|
||||
|
||||
---
|
||||
|
||||
### [Book VII — Vulnerability Management](06-vulnerability-management.md)
|
||||
|
||||
*The patch cycle was built for a world where you had weeks. That world is gone. Stop racing the attacker to the patch — change the race.*
|
||||
|
||||
The first six books assume the dominant way into an estate is a phished human. As of the 2026 Verizon DBIR that assumption is wrong: **exploitation of vulnerabilities is now the leading initial-access vector, roughly twice phishing.** This book changes the lens to match. It refuses the two losing moves — sorting 40,000 findings by CVSS, and trying to "patch faster" against a 4-hour exploitation window — and replaces them with the antifragile alternative: subtract the ~90% of criticals that aren't actually reachable, size the rest into **quanta** by time-to-existential-impact (hours / days / sprint, plus the dangerous *dark* quantum you can't yet size), contain the few that matter with compensating controls rather than waiting for a patch, and feed every exploited path back into a shorter kill chain.
|
||||
|
||||
It pairs with the [Quantum Vulnerability Management](../core/quantum-vulnerability-management.md) framework and the [Kill Chain Assessment app](../playbooks/kill-chain-assessment-app.md). Read it when the threat landscape — not the maturity model — forces the question.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,133 @@
|
||||
# Quantum Vulnerability Management
|
||||
|
||||
> *"You do not have 40,000 critical vulnerabilities. You have ~400 that are real, ~40 that are on fire, and a process that cannot tell them apart. Quantum vulnerability management is the discipline of sizing remediation to the time you actually have — and of admitting that the unit of work was never the vulnerability. It was the path."*
|
||||
|
||||
This is the operating framework behind [Book VII — Vulnerability Management](../books/06-vulnerability-management.md). Book VII is the philosophy; this is the model a consultant runs in an engagement. It pairs with the [Kill Chain Assessment app](../playbooks/kill-chain-assessment-app.md) (which sizes the quanta) and the [AI-Assisted TVM Blueprint](../playbooks/ai-assisted-tvm.md) (which automates the hours-lane).
|
||||
|
||||
---
|
||||
|
||||
## The problem in one paragraph
|
||||
|
||||
Time-to-exploit has collapsed to roughly **4 hours** while median remediation sits at **43 days**; CVE volume has gone past **59,000/year** and the public enrichment data (NVD) is degrading; and as of the **2026 Verizon DBIR, vulnerability exploitation is the #1 initial-access vector, roughly twice phishing.** A human-paced, CVSS-sorted patch programme cannot close a gap that runs the wrong way by two orders of magnitude. The answer is not "patch faster." It is to **stop using the vulnerability list as the unit of work**, size remediation into time-budgeted quanta, contain the few that matter in hours, make the rest not matter through architecture, and feed every exploited path back into a shorter kill chain.
|
||||
|
||||
---
|
||||
|
||||
## What a quantum is
|
||||
|
||||
A **quantum** is the smallest unit of remediation that:
|
||||
|
||||
1. **Fully closes a specific exploitable path** — not a CVE in the abstract, a path an adversary could actually walk.
|
||||
2. **Is sized to a time budget it can actually be completed within** — hours, days, or a sprint.
|
||||
3. **Ends in a verifiable signal** — a test that proves the path is closed, not a ticket marked done.
|
||||
|
||||
The word is chosen deliberately:
|
||||
|
||||
- **Atomic.** You cannot ship half a quantum and claim half the protection. A patch on 80% of the fleet, or a rule applied but never verified to block, is a *ghost patch* — fully exploitable and now invisible. A quantum is all-or-nothing.
|
||||
- **Discrete.** Work is packetised into units that fit the time available, not smeared across an infinite backlog. An undifferentiated backlog has no front; quanta give it one.
|
||||
|
||||
---
|
||||
|
||||
## The sort key: time-to-existential-impact
|
||||
|
||||
Quanta are ordered not by severity but by **time-to-existential-impact**, a function of three things the *environment* determines — not the CVE:
|
||||
|
||||
> **time-to-existential-impact = f( kill-chain position, reachability, exploit availability )**
|
||||
|
||||
| Factor | Question | Where it comes from |
|
||||
|--------|----------|---------------------|
|
||||
| **Kill-chain position** | Does this sit on a path to existential compromise? | [Kill Chain Assessment app](../playbooks/kill-chain-assessment-app.md), BloodHound, the diagnostic |
|
||||
| **Reachability** | Can the adversary actually get to it (internet-facing, one hop from T0, behind segmentation)? | Network topology, external scan, [Perimeter Scanning](../playbooks/perimeter-scanning-capability.md) |
|
||||
| **Exploit availability** | Is there a working exploit in the wild now? | CISA KEV, exploit databases, threat intel |
|
||||
|
||||
The same CVE has a different quantum on different assets, because position, not severity, sets the clock. **A 9.8 on a segmented, unreachable, non-privileged host is a sprint quantum. A 7.5 on an internet-facing box one hop from a domain controller is an hours quantum.** This is the Book I principle — kill-chain position changes the priority, not the score — made operational.
|
||||
|
||||
---
|
||||
|
||||
## The four quanta
|
||||
|
||||
| Quantum | Time budget | What's in it | The response | Lane character |
|
||||
|---------|-------------|--------------|--------------|----------------|
|
||||
| **Critical** | **Hours** | On the kill chain, reachable, exploit available now | **Compensating control, not the patch** — sever reachability, edge-block, isolate, disable feature. Patch follows later. | Must be partly **autonomous**; human at policy boundary |
|
||||
| **Severe** | **Days** | Material risk; reachable with friction, or partial compensating cover | Batched, completed and verified inside one short change window | Human-run, tightly scheduled |
|
||||
| **Standard** | **Sprint** | The long, real, non-urgent tail | Drained in sprint-sized batches that can actually be finished; this is where patch velocity is the right tool | Routine engineering rhythm |
|
||||
| **Dark** | **Unsized** | Can't see the asset, can't establish reachability, can't determine exploitability | **Route to discovery** — turn an uncharacterised risk into a sized quantum | Discovery, not remediation |
|
||||
|
||||
### Why "compensating control, not the patch" for the critical quantum
|
||||
|
||||
You cannot meet an hours budget with a vendor patch cycle, and often the patch does not exist yet. So the critical quantum's job is **not to fix the vulnerability — it is to move the asset out of the hours-window** by the cheapest fast control available: cut the reachability, block at the edge, isolate the host, disable the vulnerable feature, pull it behind the WAF. A 4-hour time-to-impact becomes a non-urgent one, and the actual patch drops into the standard lane on the normal change calendar. Reachability is almost always faster to change than a patch is to ship — which makes **reachability the fastest remediation you own.**
|
||||
|
||||
### Why the dark quantum is the most dangerous
|
||||
|
||||
The old model ignores the dark quantum because it has no score. That is exactly backwards: an uncharacterised risk on an unknown asset is how estates die. A *known* severe is safer than an *unknown* nothing, because you can plan around the known one. The antifragile move is to spend judgement converting dark quanta into sized ones — which is why discovery (the [Kill Chain Assessment app](../playbooks/kill-chain-assessment-app.md), [zero-budget discovery](../playbooks/zero-budget-vulnerability-discovery.md), osquery) is part of vulnerability management, not separate from it.
|
||||
|
||||
---
|
||||
|
||||
## The barbell: contain fast or architect away — never the fragile middle
|
||||
|
||||
```
|
||||
CHEAP / FAST / REVERSIBLE SLOW / STRUCTURAL / DURABLE
|
||||
Hours-lane compensating controls Segmentation, least privilege,
|
||||
(edge block, isolate, cut reachability) T0 protection, assume-breach
|
||||
── wins the time race the patch can't ── ── makes ~90% of vulns not matter ──
|
||||
◄────────────── THE FRAGILE MIDDLE TO AVOID ──────────────►
|
||||
The aging "critical patch backlog": carries hours-lane urgency,
|
||||
moves at sprint-lane speed. Max anxiety, min protection,
|
||||
and the attacker clears it for you one exploited host at a time.
|
||||
```
|
||||
|
||||
Both ends of the barbell are convex (small cost, large payoff — Pillar 5). The fragile middle is concave (maximum cost, minimum return). The rule: **contain it fast, or architect it away. Never let it age in the middle.**
|
||||
|
||||
---
|
||||
|
||||
## The ~90% subtraction — via negativa applied to the list
|
||||
|
||||
The single highest-leverage move, and it is pure subtraction. Industry data suggests **roughly 90% of "critical" vulnerabilities are not exploitable in a given environment** once compensating controls, reachability, and segmentation are mapped. So before adding any work:
|
||||
|
||||
1. Map, per asset: internet reachability, EDR coverage, WAF rules, segmentation distance from T0.
|
||||
2. Delete the false urgency on everything segmented, unreachable, or already neutralised.
|
||||
3. What remains — the genuinely reachable, genuinely exploitable ~10% — is the only thing the hours- and days-lanes ever touch.
|
||||
|
||||
This turns "40,000 criticals" into a few hundred real findings and a few dozen on fire. The compensating-control map that makes it possible is **the single most valuable artefact in the programme** — build it before the incident, because during a zero-day it answers "are we actually exposed?" in minutes instead of days. The caveat (Book I): a mapped control that has rotted into a ghost is a false negative. **Test the controls you are counting on; do not trust the map.**
|
||||
|
||||
---
|
||||
|
||||
## The feedback loop — the antifragile difference
|
||||
|
||||
A vulnerability that was exploited or nearly exploited is the cheapest penetration test you will ever get. Patching the CVE wastes the data. The antifragile move is to **sever the path** the attacker used — boundary the flat segment, collapse the over-privileged service account, pull the reachable management interface behind the bastion — so the *next* vulnerability that lands there is a non-event before it is even disclosed.
|
||||
|
||||
**The metric is not MTTR. It is: did the kill chain get shorter?** Ten incidents that produce ten patches and zero severed paths mean you are merely fast. Ten incidents that produce six structurally shortened kill chains mean the estate is getting harder to compromise every time it is tested — the only honest definition of antifragile.
|
||||
|
||||
---
|
||||
|
||||
## Running it in an engagement — the sequence
|
||||
|
||||
1. **Discover** — run the [Kill Chain Assessment app](../playbooks/kill-chain-assessment-app.md) to map assets, reachability, and the shortest existential path. Anything you cannot characterise is a dark quantum; route it to deeper discovery.
|
||||
2. **Subtract** — apply the ~90% reduction using the compensating-control and reachability map. Delete false urgency.
|
||||
3. **Size** — place every remaining real finding into a quantum (critical / severe / standard) by time-to-existential-impact.
|
||||
4. **Contain the hours-lane** — apply compensating controls to the critical quantum *today*, autonomously where guardrails allow ([AI-Assisted TVM](../playbooks/ai-assisted-tvm.md)). Verify each closes with a signal.
|
||||
5. **Batch the rest** — days-lane in the next change window, sprint-lane in the engineering rhythm.
|
||||
6. **Architect away the middle** — feed the recurring paths into segmentation and least-privilege work (Books II–V) so the same class of vulnerability stops mattering.
|
||||
7. **Close the loop** — after every exploited-or-near finding, ask what path got shorter, and track that number over time.
|
||||
|
||||
---
|
||||
|
||||
## What to measure
|
||||
|
||||
| Metric | Why it matters | Antifragile target |
|
||||
|--------|----------------|--------------------|
|
||||
| Critical-quantum containment time | The hours-lane is the race you must not lose | Hours, trending down |
|
||||
| % of "criticals" confirmed reachable | Proves the ~90% subtraction is real, not assumed | Known, not "unknown" |
|
||||
| Ghost-patch rate (closed-but-unverified) | Half-done remediation is hidden full exposure | Zero — every quantum closes with a signal |
|
||||
| Dark-quantum count | Uncharacterised risk is the dangerous kind | Shrinking; each one converted to sized |
|
||||
| **Kill-chain length after incidents** | The only measure of getting *stronger* | Shorter after each exploited-or-near event |
|
||||
| Items aging in the fragile middle | The concave zone the barbell forbids | Zero — contained or architected, never aging |
|
||||
|
||||
---
|
||||
|
||||
## Honest uncertainty
|
||||
|
||||
The headline statistics (the 4-hour, 43-day, ~59,000-CVE, ~90%-not-exploitable, and "#1, ~2× phishing" figures) are point-in-time and churn annually — re-check them against the current DBIR, M-Trends, and FIRST/CVE data before putting them on a slide. The *direction* is the stable signal; the numbers move. The autonomous-execution tooling for the hours-lane is real but immature and fast-moving — verify current capability and failure modes, and start with reversible compensating controls, never irreversible change. What does not churn: kill-chain position beats CVSS, most criticals aren't reachable, a half-done remediation is a hidden full vulnerability, and every exploited path should shorten the chain.
|
||||
|
||||
---
|
||||
|
||||
*See [Book VII — Vulnerability Management](../books/06-vulnerability-management.md) for the full philosophy, [Kill Chain Assessment app](../playbooks/kill-chain-assessment-app.md) for sizing the quanta in unknown territory, and [AI-Assisted TVM Blueprint](../playbooks/ai-assisted-tvm.md) for automating the hours-lane.*
|
||||
@@ -42,6 +42,7 @@ Operational and persuasion documents used in engagements. **Start every new clie
|
||||
| [Antifragile Manifest](core/antifragile-manifest.md) | Five pillars of antifragile enterprise | Executives, Architects, Consultants |
|
||||
| [AI Sovereignty Framework](core/ai-sovereignty-framework.md) | Strategic arguments and implementation for local AI | CISOs, CTOs, Security Architects |
|
||||
| [T0 Asset Framework](core/t0-asset-framework.md) | Tier 0 classification and protection for critical assets | Security Architects, Infrastructure Leads |
|
||||
| [Quantum Vulnerability Management](core/quantum-vulnerability-management.md) | Sizing remediation into time-budgeted quanta (hours/days/sprint/dark) for the exploitation-first era; companion to Book VII | CISOs, Vulnerability Management, Consultants |
|
||||
| [Spontaneous Order Principles](core/spontaneous-order-principles.md) | Philosophical foundation for the five pillars | Executives, Architects, Strategists |
|
||||
|
||||
## Playbooks
|
||||
@@ -51,6 +52,7 @@ Operational and persuasion documents used in engagements. **Start every new clie
|
||||
| [Rapid Modernisation Plan](playbooks/rapid-modernisation-plan.md) | 30-60-90-180 day transformation roadmap | Program Managers, Consultants, CISOs |
|
||||
| [Endpoint Management Entry Vector](playbooks/endpoint-management-entry-vector.md) | Intune/device management as the ideal engagement entry point | M365 Consultants, Account Managers |
|
||||
| [AI-Assisted TVM Blueprint](playbooks/ai-assisted-tvm.md) | AI-powered vulnerability management for AI-powered adversaries | CTOs, CISOs, Vulnerability Management |
|
||||
| [Kill Chain Assessment App](playbooks/kill-chain-assessment-app.md) | Spec for the offline tool that maps unknown estates into an attack graph, computes the shortest existential path, and sizes quanta. Tool: [`tools/kill-chain-assessment.html`](tools/kill-chain-assessment.html) | Consultants, Assessors, Security Architects |
|
||||
| [Zero-Budget Vulnerability Discovery](playbooks/zero-budget-vulnerability-discovery.md) | Script-based and osquery-based server/container vuln discovery without Tenable/Qualys | Security Engineers, Consultants |
|
||||
| [Perimeter Scanning Capability](playbooks/perimeter-scanning-capability.md) | External attack surface strategy: build, partner, or hybrid | Security Architects, Consultants |
|
||||
| [Osquery: The Sovereign Discovery Platform](playbooks/osquery-custom-platform.md) | Build a custom vulnerability and asset inventory platform on osquery | Security Engineers, Consultants, CTOs |
|
||||
|
||||
@@ -0,0 +1,93 @@
|
||||
# Kill Chain Assessment App
|
||||
|
||||
> *"We say it in every engagement: find the kill chain first. But how do you find it in territory you've never seen? You don't start with the chain — you start with the questions that surface the edges, and you let the graph tell you where the shortest path to the end of the company actually runs."*
|
||||
|
||||
This document specifies the **Kill Chain Assessment app** — a single-file, offline browser tool a consultant runs during the diagnostic to turn an unknown estate into a mapped attack graph, compute the shortest existential path (the kill chain), and size every node on it into a remediation [quantum](../core/quantum-vulnerability-management.md).
|
||||
|
||||
**The tool:** [`tools/kill-chain-assessment.html`](../tools/kill-chain-assessment.html) — open it in any browser. No install, no network, no data leaves the machine. State persists locally and exports to `.json` (to resume) and `.md` (to drop straight into the report or the [Findings Backlog](../assessment-templates/findings-backlog.md)).
|
||||
|
||||
---
|
||||
|
||||
## Why this needed to be built
|
||||
|
||||
The handbook and the [Move Fast and Fix Things](../core/move-fast-and-fix-things.md) posture both rest on a single instruction: *fix the kill chain first.* The [assessment team guide](../assessment-templates/assessment-team-guide.md) tells you what to run (BloodHound, Purple Knight, Elysium, Entra checks); the [sample engagement](sample-engagement-mid-market.md) shows a finished kill chain drawn as an ASCII path. But between "run the tools" and "here is the finished chain" there is a synthesis step that has always lived only in the consultant's head: **taking a pile of findings about an unfamiliar estate and working out which sequence of them actually ends the company.**
|
||||
|
||||
In unknown territory that synthesis is hard, inconsistent between consultants, and easy to get wrong — the obvious 9.8 grabs attention while the cheap two-hop path to the backups goes unseen. The app makes the synthesis explicit and repeatable: capture what you find as nodes and attacker moves, and let a shortest-path computation surface the chain you'd otherwise have to spot by eye. It is the missing instrument for the first and most important act of every engagement.
|
||||
|
||||
---
|
||||
|
||||
## The model
|
||||
|
||||
### Nodes
|
||||
|
||||
A **node** is any asset, foothold, identity, or system. Each carries the attributes that determine its position in the chain:
|
||||
|
||||
| Attribute | Meaning | Drives |
|
||||
|-----------|---------|--------|
|
||||
| **Layer** | entry / identity / privilege / device / data / infra-OT / recovery | Orientation, report grouping |
|
||||
| **Tier** | T0 / T1 / T2 ([T0 Asset Framework](../core/t0-asset-framework.md)) | Blast-radius weighting |
|
||||
| **Entry point** | Internet-reachable or unauth foothold | Source of the chain |
|
||||
| **Crown jewel** | Existential — the org cannot operate without it | End of the chain |
|
||||
| **Reachable?** | Can the adversary actually get to it (yes/no/**unknown**) | Quantum sizing |
|
||||
| **Exploit available?** | Working path/exploit in the wild (yes/no/**unknown**) | Quantum sizing |
|
||||
| **Compensating control** | EDR / WAF / segmentation already in front | Quantum sizing (the ~90% subtraction) |
|
||||
|
||||
The "unknown" values are first-class, not placeholders: a node you cannot characterise is a **dark quantum**, and capturing it honestly is the point.
|
||||
|
||||
### Moves (edges)
|
||||
|
||||
A **move** is one directed attacker step — "from here, an attacker can reach there" — with a *mechanism* (how: DCSync, NTLM relay, password spray, reused credential, OAuth consent) and an *effort* weight from 1 (trivial) to 5 (very hard). Effort is the consultant's judgement of how hard that single hop is for the adversary.
|
||||
|
||||
### The computation
|
||||
|
||||
The app runs a **multi-source Dijkstra** from every entry point across the move graph, and finds the **lowest-total-effort path to any crown jewel.** That path *is* the kill chain — the cheapest route from foothold to existential impact. The tool then classifies every node:
|
||||
|
||||
- **P0** — on the shortest chain. Break any one link and the existential path is severed.
|
||||
- **P1** — on *some* path from an entry to a jewel (reachable-from-entry ∧ can-reach-a-jewel), but not on the cheapest one.
|
||||
- **P2 / off-chain** — not on any path to a crown jewel. Real, but not existential — housekeeping, not kill chain.
|
||||
|
||||
This is the [Move Fast](../core/move-fast-and-fix-things.md) doctrine made computable: *kill-chain position sets priority, not CVSS.*
|
||||
|
||||
### Quantum sizing
|
||||
|
||||
Each node on a chain is sized into a [quantum](../core/quantum-vulnerability-management.md) by the same logic the framework defines:
|
||||
|
||||
| Quantum | Condition | Budget / action |
|
||||
|---------|-----------|-----------------|
|
||||
| **Critical** | On shortest chain, reachable **yes**, exploit **yes**, not compensated | **Hours** — sever reachability / compensating control now |
|
||||
| **Severe** | On a chain, reachable **or** exploit = yes | **Days** — one change window, verify enforcement |
|
||||
| **Standard** | On a chain, neither reachable nor exploitable yet | **Sprint** — batch; patch velocity fits here |
|
||||
| **Dark** | On a chain but reachability **or** exploit = unknown | **Unsized** — route to discovery; characterise first |
|
||||
|
||||
---
|
||||
|
||||
## How to run it in an engagement
|
||||
|
||||
1. **Open the tool** and clear the sample (or keep it as a worked reference). Switch to the **Discovery** tab — it lists, per layer, the questions and commands that surface edges (external scan for entries, the Connect sync account for the cloud↔on-prem bridge, BloodHound `shortestPath` for privilege, "what stops the business operating?" for jewels, flat-network checks for blast radius). This is the unknown-territory protocol.
|
||||
2. **Capture as you go.** Every finding from the [assessment team guide](../assessment-templates/assessment-team-guide.md) becomes a node; every "an attacker could move from X to Y" becomes a move. Mark entries and jewels. Leave reachability/exploit as *unknown* when you genuinely don't know — that flags the dark quanta to chase.
|
||||
3. **Read the chain.** The centre panel draws the attack graph and highlights the shortest existential path in red. The right panel sizes the quanta. If no path is found, either the estate is genuinely segmented there (note it as a win) or you haven't mapped the connecting moves yet — in unknown territory, assume the latter until proven.
|
||||
4. **Export.** `Export report .md` produces a kill-chain section, quantum-bucketed remediation, and a priority table ready to paste into the diagnostic deliverable. `Save .json` lets you resume or hand off.
|
||||
5. **Close the loop.** After remediation, reload the `.json` and ask the antifragile question the framework demands: *did the chain get shorter?* A severed link or a collapsed privilege should visibly lengthen the shortest path or remove it entirely.
|
||||
|
||||
---
|
||||
|
||||
## What it is and is not
|
||||
|
||||
It is a **synthesis and prioritisation instrument** — it makes the consultant's kill-chain judgement explicit, repeatable, and exportable, and it removes the human error of eyeballing the cheapest path. It is deliberately **offline and dependency-free** (Pillar 4, Sovereign Intelligence: the attack graph of a client estate must never leave the consultant's machine for a vendor cloud).
|
||||
|
||||
It is **not** a scanner and not an autonomous agent. It does not discover assets for you — it structures what you discover. The discovery still comes from the tools in the [assessment team guide](../assessment-templates/assessment-team-guide.md) and the [zero-budget discovery](zero-budget-vulnerability-discovery.md) playbooks; the autonomous hours-lane execution lives in [AI-Assisted TVM](ai-assisted-tvm.md). This tool is the bridge between them: it turns raw discovery into a sized, prioritised chain that the rest of the programme acts on.
|
||||
|
||||
---
|
||||
|
||||
## Roadmap (build-later)
|
||||
|
||||
The current tool is a self-contained synthesis instrument. Natural extensions, in priority order:
|
||||
|
||||
1. **Import from BloodHound / Purple Knight** — ingest exported attack paths directly as nodes and moves, rather than hand-entry.
|
||||
2. **PULSAR / ASTRAL signal overlay** — pull live reachability and config-drift signal so "reachable?" is answered by observation, not assertion (Book I: validate by observation).
|
||||
3. **Chain-shortening tracker** — store successive `.json` snapshots and chart kill-chain length over time, making the antifragile feedback loop a number on a dashboard.
|
||||
4. **Multi-chain view** — surface the top-N existential paths, not just the cheapest, so secondary chains (the [sample engagement](sample-engagement-mid-market.md) on-prem path) aren't hidden behind the primary.
|
||||
|
||||
---
|
||||
|
||||
*Specified for [Book VII — Vulnerability Management](../books/06-vulnerability-management.md) and the [Quantum Vulnerability Management](../core/quantum-vulnerability-management.md) framework. The tool: [`tools/kill-chain-assessment.html`](../tools/kill-chain-assessment.html).*
|
||||
@@ -0,0 +1,251 @@
|
||||
# ORION — Technical Proposition
|
||||
|
||||
> *"The kill chain exists before you have access to a single system. It's already drawn — in the org chart, the procurement history, the sector's threat landscape, and the things people will tell you in a room if you ask the right questions. ORION is the instrument for reading that chain on day zero, before a single tool has touched the estate."*
|
||||
|
||||
**Codename:** ORION (the Hunter — it hunts the kill chain). Celestial, consistent with ASTRAL / PULSAR / AURORA. Rename freely.
|
||||
|
||||
**Status:** Technical proposition — pre-build. This document exists to be argued with before any code is written.
|
||||
|
||||
**One line:** ORION is the pre-engagement intake, interview, and threat-intelligence layer that produces the input the [Kill Chain Assessment app](kill-chain-assessment-app.md) (L1) consumes — turning structured human answers and public intelligence into a *hypothesised* attack graph, without ever touching client infrastructure.
|
||||
|
||||
---
|
||||
|
||||
## 1. Why this needs to exist
|
||||
|
||||
The L1 [Kill Chain Assessment app](kill-chain-assessment-app.md) is a synthesis instrument: you feed it nodes and attacker moves you've already discovered, and it computes the shortest existential path and sizes the [quanta](../core/quantum-vulnerability-management.md). It assumes you already have findings — BloodHound paths, Entra checks, the [assessment team guide](../assessment-templates/assessment-team-guide.md) output.
|
||||
|
||||
But on **day zero of a new engagement** you have none of that. You may not even have access yet — the contract may not permit infrastructure contact, the change-advisory board hasn't met, the client's legal team is still reviewing the scope. And yet this is exactly the moment the consultant most needs a hypothesis: *where is this company's kill chain likely to run, what should we ask, and what should we look at first when access arrives?*
|
||||
|
||||
Today that reasoning lives entirely in the experienced consultant's head. It is the single least reproducible, least scalable part of the practice — a senior consultant walks in, asks fifteen sharp questions, and forms a mental model of the likely kill chain; a junior consultant asks the obvious questions and misses it. ORION makes that reasoning **explicit, structured, intel-informed, and repeatable** — and it does so in the window before fieldwork is even possible.
|
||||
|
||||
ORION is, deliberately, the "What If" tool of the assessment world (Book I). It produces a *declared* picture — what the client says, what public intel suggests — which is precisely the picture the rest of the engagement exists to validate by observation. Naming that honestly is the whole design (see §7).
|
||||
|
||||
---
|
||||
|
||||
## 2. The hard boundary: ORION never touches client infrastructure
|
||||
|
||||
This is the defining constraint and the primary selling point, not a limitation to apologise for.
|
||||
|
||||
ORION works from exactly two input classes:
|
||||
|
||||
1. **What humans tell it** — structured intake and questionnaire responses from the client.
|
||||
2. **Passive public intelligence** — sector threat landscape, CISA KEV, vendor advisories, exploited-CVE feeds, public OSINT about the named technology stack. **Passive only**: ORION reads public and threat-intelligence sources. It does *not* perform active external scanning — that is a separate, consented capability (see [Perimeter Scanning Capability](perimeter-scanning-capability.md)) and explicitly out of ORION's scope.
|
||||
|
||||
What this buys:
|
||||
|
||||
- **Zero onboarding friction.** No credentials, no agent, no firewall change, no data-processing agreement for telemetry. ORION can run during the sales conversation, in the pre-contract phase, or in a sector where the client cannot yet grant access.
|
||||
- **No incident risk.** A tool that touches nothing breaks nothing and triggers no alerts. It can never be the cause of an outage or a "who ran that scan?" conversation.
|
||||
- **Clean legal posture.** The only client data ORION holds is what the client deliberately typed into a questionnaire. That is a categorically simpler privacy and liability position than any tool that ingests infrastructure data.
|
||||
|
||||
The boundary is also the honest limit: because ORION observes nothing, everything it produces is a hypothesis (§7).
|
||||
|
||||
---
|
||||
|
||||
## 3. The three-stage workflow
|
||||
|
||||
### Stage 1 — Intake (minutes)
|
||||
|
||||
A short structured form establishes the engagement's shape. The consultant fills this, usually from the first call:
|
||||
|
||||
- Sector and sub-sector (drives the threat-landscape lookup and the regulatory profile)
|
||||
- Size, geography, and regulatory exposure (NIS2 / DORA / GDPR / sector-specific)
|
||||
- Technology footprint at a coarse level: M365 (E3/E5/BP), hybrid AD vs cloud-only, major cloud, OT/ICS presence, internet-facing services they'll admit to
|
||||
- Business-level crown jewels: "what stops the company operating?" — ERP, payment rails, OT control, the customer database
|
||||
- Known history: prior incidents, prior pentest, known pain points
|
||||
|
||||
### Stage 2 — Generate the tailored questionnaire (the core trick)
|
||||
|
||||
ORION's LLM expands the intake into a **detailed, role-targeted, adaptive questionnaire**, and this is where it earns its keep. The questionnaire is:
|
||||
|
||||
- **Role-segmented** — separate tracks for the identity/AD admin, the M365 admin, the network/OT lead, and the business owner. Each person answers only what they'd know.
|
||||
- **Adaptive** — questions branch on prior answers. Hybrid AD declared → the Entra Connect sync-account and DCSync questions appear. OT declared → Purdue-model and remote-vendor-access questions appear. Cloud-only → the questionnaire skips on-prem forest-recovery questions entirely.
|
||||
- **Framed against the kill chain, not compliance** — every question maps to a candidate node or edge ("Do any standing Domain Admins log into normal workstations for email?" targets a known privilege-path edge), not to a control checkbox. This is the inversion the whole practice rests on.
|
||||
|
||||
The client fills it via a shared per-engagement link, partially and over time, with their own people answering their own sections.
|
||||
|
||||
### Stage 3 — Synthesis → hypothesised kill chain → L1 export
|
||||
|
||||
From the responses plus the threat intel, ORION proposes:
|
||||
|
||||
- **Candidate entry points** (internet-facing services, legacy auth, the contractor-access pattern), each with the intel that suggests it.
|
||||
- **Candidate crown jewels** (from the business answers).
|
||||
- **Hypothesised moves** between them, each with a *mechanism*, a *confidence*, and a *rationale citing its source* ("hybrid AD + unrotated KRBTGT declared → likely Entra-Connect→on-prem DCSync edge").
|
||||
- **A prioritised "look here first" list** for when fieldwork begins — what to point BloodHound, the Entra review, and the L1 app at on day one.
|
||||
|
||||
The synthesis exports directly to the **L1 Kill Chain Assessment app's `.json` schema**, so the consultant opens L1 with the hypothesised graph already drawn and spends fieldwork *validating and correcting* it rather than building from a blank canvas. ORION hypothesises; L1 plus fieldwork confirm or kill each hypothesis by observation.
|
||||
|
||||
---
|
||||
|
||||
## 4. Threat-intelligence layer
|
||||
|
||||
ORION continuously contextualises the client against the *current* threat environment — the dimension a static questionnaire can't capture and the one that feeds the [quantum](../core/quantum-vulnerability-management.md) sort key's "exploit availability" axis:
|
||||
|
||||
- **CISA KEV and exploited-CVE feeds** — for the client's named technologies, what is being exploited *now*.
|
||||
- **Vendor advisories** — current critical advisories for their declared stack (the VPN appliance, the mail gateway, the ERP).
|
||||
- **Sector threat landscape** — which actors and ransomware groups are currently targeting their vertical, drawn from public reporting.
|
||||
|
||||
Each intel item carries **provenance** (source, date, URL) because ORION's output is advisory and the consultant must be able to trace and re-verify every claim. Threat intel ages fast; ORION timestamps everything and treats stale intel as a prompt to re-check, never as fact.
|
||||
|
||||
---
|
||||
|
||||
## 5. Architecture
|
||||
|
||||
Deliberately mirrors CISO Assistant and the AURORA model so it's familiar to operate and fits the suite.
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ ORION (Docker Compose, consultant self-hosted) │
|
||||
│ │
|
||||
│ ┌────────────┐ ┌──────────────┐ ┌───────────────────┐ │
|
||||
│ │ Web UI │ │ API backend │ │ PostgreSQL │ │
|
||||
│ │ (SvelteKit │◄─►│ (FastAPI or │◄─►│ engagements, │ │
|
||||
│ │ or React) │ │ Django/DRF) │ │ responses, │ │
|
||||
│ └────────────┘ └──────┬───────┘ │ hypotheses │ │
|
||||
│ client fills │ └───────────────────┘ │
|
||||
│ questionnaire │ │
|
||||
│ via shared link ▼ │
|
||||
│ ┌──────────────────────┐ │
|
||||
│ │ LLM abstraction │ pluggable backend │
|
||||
│ │ layer │──► Ollama (default) │
|
||||
│ └──────────────────────┘──► Azure OpenAI (opt) │
|
||||
│ │ └──► llm.cqre.net (opt) │
|
||||
│ ▼ │
|
||||
│ ┌──────────────────────┐ │
|
||||
│ │ Threat-intel │ passive fetch only: │
|
||||
│ │ connector module │──► CISA KEV, advisories│
|
||||
│ └──────────────────────┘──► curated OSINT/search│
|
||||
│ │ │
|
||||
│ ┌──────────┴───────────┐ ┌─────────────────┐ │
|
||||
│ │ L1 export adapter │──►│ kill-chain .json│ │
|
||||
│ └──────────────────────┘ └─────────────────┘ │
|
||||
│ ┌──────────────────────┐ │
|
||||
│ │ MCP server │ AURORA / Claude can │
|
||||
│ │ (query ORION) │ query engagements │
|
||||
│ └──────────────────────┘ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
NO connection to client infrastructure
|
||||
```
|
||||
|
||||
Components:
|
||||
|
||||
- **Backend** — FastAPI (Python) or Django REST, matching CISO Assistant's proven stack. Houses the questionnaire engine, synthesis orchestration, and export.
|
||||
- **Frontend** — SvelteKit or React. Two surfaces: the consultant console and the client-facing questionnaire (shareable per-engagement link, no client login burden beyond a token).
|
||||
- **LLM abstraction layer** — single internal interface, swappable backend. **Default: local Ollama** so sensitive intake data never leaves the box (§6). Optional: Azure OpenAI (EU) or managed `llm.cqre.net`, exactly as ASTRAL/AURORA offer.
|
||||
- **Questionnaire engine — questions-as-data** — adopting CISO Assistant's "frameworks as data, not code" principle: questionnaire templates, branching rules, and node/edge mappings live in the database as editable data, so new sector packs and question sets ship without code changes.
|
||||
- **Threat-intel connector** — passive fetchers for KEV, advisories, and curated search, each normalised into a provenance-tagged `ThreatIntelItem`.
|
||||
- **L1 export adapter** — emits the exact `.json` schema the L1 app imports.
|
||||
- **MCP server** — exposes ORION engagement state to AURORA and to AI assistants, consistent with the rest of the suite.
|
||||
|
||||
### Data model (sketch)
|
||||
|
||||
| Entity | Holds | Notes |
|
||||
|--------|-------|-------|
|
||||
| `Engagement` | Client, scope, status | Per-engagement isolation boundary |
|
||||
| `IntakeProfile` | Stage-1 answers | Drives questionnaire generation |
|
||||
| `QuestionnaireTemplate` | Questions, branching rules, node/edge mappings | Questions-as-data; sector packs |
|
||||
| `Response` | Client answers, respondent role, timestamp | Sensitive — encrypted at rest |
|
||||
| `ThreatIntelItem` | Intel + source + date + URL | Provenance mandatory |
|
||||
| `Hypothesis` | Candidate node/edge + confidence + rationale + sources | The advisory output; never a "finding" |
|
||||
| `Export` | Generated L1 `.json` snapshots | Versioned, so you can diff intake-time vs post-fieldwork |
|
||||
|
||||
---
|
||||
|
||||
## 6. Sovereignty and data handling
|
||||
|
||||
ORION holds something genuinely sensitive: a client's own description of where they are weak. That is a map of the kill chain drawn by the victim. The data posture must be uncompromising and is a direct expression of Pillar 4 (Sovereign Intelligence — never rent your ability to think) and Pillar 1.
|
||||
|
||||
- **Local LLM by default.** Ollama runs in the same Compose stack; intake and responses never leave the consultant's host unless a backend is *explicitly* switched. The default must be the safe one.
|
||||
- **Encryption at rest** for `Response` and `Hypothesis` data; per-engagement key isolation.
|
||||
- **Retention and deletion.** Each engagement has a retention clock and a hard "right to delete" — when the engagement closes, the client's answers can be destroyed and the destruction evidenced (GDPR-friendly, and the right thing).
|
||||
- **No telemetry, no phone-home.** Consistent with the offline ethos of the L1 tool.
|
||||
- **Untrusted-content handling.** Threat-intel fetched from the web is untrusted input — treated as data, never as instructions to the LLM (prompt-injection defence, §8).
|
||||
|
||||
---
|
||||
|
||||
## 7. The epistemic honesty layer (the most important section)
|
||||
|
||||
ORION's single greatest risk is that its confident, well-written output gets mistaken for fact. The repo's founding principle (Book I) is *validate by observation, never by inspection* — and ORION, by design, observes nothing. So the design must make its own uncertainty impossible to ignore:
|
||||
|
||||
- **Everything ORION emits is a `Hypothesis`, never a `Finding`.** The vocabulary is enforced in the data model and the UI. A finding comes from the [assessment team guide](../assessment-templates/assessment-team-guide.md) fieldwork and lands in the [Findings Backlog](../assessment-templates/findings-backlog.md); a hypothesis comes from ORION and lands in L1 as something *to test*.
|
||||
- **Confidence and provenance on every claim.** No hypothesis without a stated confidence and the source(s) — the client answer or the intel item — that produced it.
|
||||
- **The "ghost-assessment" trap, named.** Just as a ghost CA policy displays correct config while enforcing nothing (Book I corollary), a client questionnaire can describe a control that has rotted into a ghost. ORION's hypotheses inherit the client's blind spots. The output must say so, loudly, and route every load-bearing claim to observation.
|
||||
- **The handoff is explicit.** ORION's deliverable is not "here is your kill chain." It is "here is the kill chain we *expect*, ranked by where to look first — now go and prove or disprove each link." That handoff into L1 and fieldwork is the product, not the hypothesis itself.
|
||||
|
||||
Get this section right and ORION strengthens the practice. Get it wrong and it becomes the most dangerous thing in the toolkit: a confident map of a territory no one checked.
|
||||
|
||||
---
|
||||
|
||||
## 8. LLM guardrails
|
||||
|
||||
- **Human-in-the-loop, always.** ORION proposes; the consultant disposes. No hypothesis auto-promotes to a finding, and ORION takes no action on anything.
|
||||
- **Prompt-injection defence.** Web/threat-intel content is wrapped and labelled as untrusted data; the system prompt instructs the model to treat fetched content as evidence to summarise, never as commands.
|
||||
- **Hallucination control.** Provenance is mandatory; a claim with no traceable source is flagged, not shown as fact. The consultant can click any hypothesis through to its sources.
|
||||
- **Quality floor.** Local models are weaker; the proposition should set an expectation that the default Ollama model is adequate for questionnaire generation and basic synthesis, with Azure OpenAI recommended where deeper reasoning materially helps — and the UI should make the active model and its limits visible.
|
||||
|
||||
---
|
||||
|
||||
## 9. How it fits the engagement
|
||||
|
||||
| Phase | ORION's role |
|
||||
|-------|--------------|
|
||||
| Pre-contract / sales | Stage-1 intake during the first conversation; instant sector threat-landscape briefing as a credibility opener |
|
||||
| [Brownhat Diagnostic](../assessment-templates/nist-csf-baseline.md) intake | Generate and distribute the tailored questionnaire; collect responses before the on-site half-days |
|
||||
| Fieldwork ([assessment team guide](../assessment-templates/assessment-team-guide.md)) | Hand the consultant a hypothesised graph and a "look here first" list; fieldwork validates by observation |
|
||||
| L1 mapping | Import ORION's `.json`; correct and confirm; compute the real shortest existential path |
|
||||
| Reporting | Diff intake-time hypotheses against confirmed findings — a powerful "what you told us vs what we found" narrative for the client |
|
||||
|
||||
---
|
||||
|
||||
## 10. Regulatory alignment (EU)
|
||||
|
||||
| Regulation | Requirement | ORION relevance |
|
||||
|------------|-------------|-----------------|
|
||||
| **NIS2** Art. 21 | Risk analysis, supply-chain and access governance | Structured intake produces documented evidence of risk-analysis scoping at engagement start |
|
||||
| **DORA** | ICT risk identification | The hypothesised kill chain is an ICT-risk-identification artefact (clearly marked as preliminary) |
|
||||
| **GDPR** Art. 5/32 | Data minimisation, appropriate measures, accountability | Local-LLM default, encryption, retention/deletion — minimal, sovereign handling of the only PII it holds |
|
||||
|
||||
---
|
||||
|
||||
## 11. Phased build (proposed MVP → product)
|
||||
|
||||
1. **Phase 1 — MVP.** Stage-1 intake, LLM questionnaire generation (Ollama), manual-assisted synthesis, L1 `.json` export. No threat intel yet. Proves the core loop.
|
||||
2. **Phase 2 — Threat intel.** KEV / advisory / curated-search connectors with provenance; exploit-availability enrichment of hypotheses.
|
||||
3. **Phase 3 — Adaptive + integrated.** Full branching questionnaire engine (questions-as-data), MCP server, AURORA integration, sector question packs.
|
||||
4. **Phase 4 — Productisation.** Hosted tier, multi-engagement console, RBAC, retention automation.
|
||||
|
||||
---
|
||||
|
||||
## 12. Provisional commercial framing
|
||||
|
||||
Positioned like AURORA — self-hosted and hosted tiers — though pricing is a placeholder pending the build decision:
|
||||
|
||||
| Tier | Self-hosted | Hosted (managed) |
|
||||
|------|-------------|------------------|
|
||||
| Per-consultant / small practice | TBD | TBD |
|
||||
| Practice / multi-seat | TBD | TBD |
|
||||
|
||||
Self-hosters bring their own LLM (Ollama / Azure OpenAI); hosted tier includes a managed model. Note the natural bundling: ORION (pre-engagement) → L1 Kill Chain Assessment (synthesis) → ASTRAL/PULSAR/AURORA (the operational layer once access exists).
|
||||
|
||||
---
|
||||
|
||||
## 13. What ORION is NOT
|
||||
|
||||
- **Not a scanner and not an agent.** It touches no client system, active-scans nothing, and runs nothing in the client environment.
|
||||
- **Not autonomous.** It proposes hypotheses for a consultant; it never acts and never self-promotes a hypothesis to a finding.
|
||||
- **Not a replacement for fieldwork or for L1.** It is the layer *before* them — it tells you where to look, it does not tell you what is true.
|
||||
- **Not a compliance questionnaire tool.** The questions target the kill chain, not a control checklist; CISO Assistant covers the GRC/framework job and ORION should integrate with it, not duplicate it.
|
||||
|
||||
---
|
||||
|
||||
## 14. Open questions for the build decision
|
||||
|
||||
1. **Backend choice** — FastAPI (lighter, our synthesis is bespoke) vs Django/DRF (matches CISO Assistant, more batteries). Leaning FastAPI.
|
||||
2. **Client-facing surface** — shared tokenised link (low friction) vs lightweight client login (more control). Leaning tokenised link with per-engagement expiry.
|
||||
3. **Where is the OSINT/active line drawn exactly?** Confirm ORION stays strictly passive and that any external scanning is deferred to the consented [Perimeter Scanning Capability](perimeter-scanning-capability.md).
|
||||
4. **CISO Assistant integration depth** — loose (export/import) vs deep (shared data model). Loose first.
|
||||
5. **Default Ollama model and the quality floor** — which local model is "good enough" for questionnaire generation, and where do we tell consultants to switch to Azure OpenAI.
|
||||
6. **Hypothesis accuracy expectations** — how do we measure and communicate that ORION's day-zero map is a starting hypothesis, and track how often it was right once fieldwork closed the loop?
|
||||
|
||||
---
|
||||
|
||||
*Companion to the [Kill Chain Assessment app](kill-chain-assessment-app.md) (L1), [Book VII — Vulnerability Management](../books/06-vulnerability-management.md), and the [Quantum Vulnerability Management](../core/quantum-vulnerability-management.md) framework. Positioned in the suite alongside [ASTRAL, PULSAR, and AURORA](cqre-product-suite.md).*
|
||||
@@ -0,0 +1,15 @@
|
||||
# Tools
|
||||
|
||||
Standalone, runnable instruments that support the engagement — as distinct from the markdown frameworks and playbooks elsewhere in the repository.
|
||||
|
||||
| Tool | What it does | How to run |
|
||||
|------|--------------|------------|
|
||||
| [`kill-chain-assessment.html`](kill-chain-assessment.html) | Maps an unknown estate into an attack graph, computes the shortest existential path (the kill chain), and sizes every node into a remediation quantum. The synthesis instrument for the first act of every engagement. | Open in any browser. Offline, no install, no network. State persists locally; exports to `.json` and `.md`. |
|
||||
|
||||
## Design constraints for tools in this directory
|
||||
|
||||
- **Offline and sovereign.** Client attack-surface data must never leave the consultant's machine for a vendor cloud (Antifragile Manifest, Pillar 4). Tools here are single-file and dependency-free wherever possible.
|
||||
- **Exportable.** Output drops into the engagement deliverables — the [diagnostic report](../assessment-templates/nist-csf-baseline.md) and the [Findings Backlog](../assessment-templates/findings-backlog.md) — not into a proprietary format.
|
||||
- **Explicit, not magic.** A tool makes the consultant's judgement repeatable; it does not replace it.
|
||||
|
||||
See the [Kill Chain Assessment App spec](../playbooks/kill-chain-assessment-app.md) for the model behind the first tool.
|
||||
@@ -0,0 +1,642 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Kill Chain Assessment — Brownhat / CQRE</title>
|
||||
<style>
|
||||
:root{
|
||||
--bg:#0d1117; --panel:#161b22; --panel2:#1c2330; --line:#30363d; --line2:#3d4654;
|
||||
--ink:#e6edf3; --muted:#9aa6b2; --faint:#6e7781;
|
||||
--p0:#ff4d4f; --p1:#ff9f0a; --p2:#3fb950; --dark:#a371f7; --entry:#58a6ff; --jewel:#f7c948;
|
||||
--accent:#58a6ff; --accent2:#1f6feb;
|
||||
--crit:#ff4d4f; --sev:#ff9f0a; --std:#3fb950; --darkq:#a371f7; --house:#6e7781;
|
||||
}
|
||||
*{box-sizing:border-box}
|
||||
body{margin:0;background:var(--bg);color:var(--ink);font:14px/1.5 -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Helvetica,Arial,sans-serif}
|
||||
header{padding:16px 22px;border-bottom:1px solid var(--line);display:flex;align-items:center;gap:16px;flex-wrap:wrap;background:linear-gradient(180deg,#11161d,#0d1117)}
|
||||
header h1{font-size:18px;margin:0;letter-spacing:.3px}
|
||||
header .tag{font-size:11px;color:var(--faint);border:1px solid var(--line);padding:2px 8px;border-radius:20px}
|
||||
header .sub{color:var(--muted);font-size:12.5px;margin-left:auto;max-width:520px;text-align:right}
|
||||
.wrap{display:grid;grid-template-columns:340px 1fr 360px;gap:0;height:calc(100vh - 59px)}
|
||||
.col{overflow-y:auto;padding:16px}
|
||||
.col.left{border-right:1px solid var(--line)}
|
||||
.col.right{border-left:1px solid var(--line);background:#0b0f14}
|
||||
h2{font-size:12px;text-transform:uppercase;letter-spacing:1px;color:var(--muted);margin:4px 0 10px;font-weight:600}
|
||||
h2 .hint{text-transform:none;letter-spacing:0;font-weight:400;color:var(--faint);display:block;font-size:11.5px;margin-top:3px}
|
||||
.panel{background:var(--panel);border:1px solid var(--line);border-radius:10px;padding:13px;margin-bottom:14px}
|
||||
label{display:block;font-size:11.5px;color:var(--muted);margin:9px 0 3px}
|
||||
input,select,textarea,button{font:inherit;color:var(--ink)}
|
||||
input[type=text],select,textarea{width:100%;background:var(--panel2);border:1px solid var(--line2);border-radius:7px;padding:7px 9px}
|
||||
input[type=text]:focus,select:focus,textarea:focus{outline:none;border-color:var(--accent)}
|
||||
textarea{resize:vertical;min-height:34px}
|
||||
.row{display:flex;gap:8px}
|
||||
.row>*{flex:1}
|
||||
.chk{display:flex;align-items:center;gap:7px;margin:8px 0;font-size:12.5px;color:var(--ink)}
|
||||
.chk input{width:auto}
|
||||
button{cursor:pointer;background:var(--panel2);border:1px solid var(--line2);border-radius:7px;padding:8px 12px;transition:.12s}
|
||||
button:hover{border-color:var(--accent);color:#fff}
|
||||
button.primary{background:var(--accent2);border-color:var(--accent2);color:#fff;font-weight:600}
|
||||
button.primary:hover{background:#388bfd}
|
||||
button.ghost{background:transparent}
|
||||
button.danger:hover{border-color:var(--p0);color:var(--p0)}
|
||||
.btnrow{display:flex;gap:8px;flex-wrap:wrap;margin-top:10px}
|
||||
.btnrow button{flex:1;min-width:0}
|
||||
.pill{display:inline-block;font-size:10px;font-weight:700;letter-spacing:.5px;padding:2px 7px;border-radius:20px;text-transform:uppercase}
|
||||
.pill.entry{background:rgba(88,166,255,.16);color:var(--entry);border:1px solid var(--entry)}
|
||||
.pill.jewel{background:rgba(247,201,72,.14);color:var(--jewel);border:1px solid var(--jewel)}
|
||||
.node-item{background:var(--panel2);border:1px solid var(--line);border-radius:8px;padding:9px 10px;margin-bottom:7px;cursor:pointer}
|
||||
.node-item:hover{border-color:var(--accent)}
|
||||
.node-item.sel{border-color:var(--accent);box-shadow:0 0 0 1px var(--accent) inset}
|
||||
.node-item .nm{font-weight:600;display:flex;justify-content:space-between;align-items:center;gap:6px}
|
||||
.node-item .meta{font-size:11px;color:var(--faint);margin-top:3px;display:flex;gap:6px;flex-wrap:wrap}
|
||||
.edge-item{font-size:12px;background:var(--panel2);border:1px solid var(--line);border-radius:7px;padding:7px 9px;margin-bottom:6px;display:flex;justify-content:space-between;gap:8px;align-items:flex-start}
|
||||
.edge-item .x{cursor:pointer;color:var(--faint);flex-shrink:0}
|
||||
.edge-item .x:hover{color:var(--p0)}
|
||||
.tabs{display:flex;gap:4px;margin-bottom:12px;border-bottom:1px solid var(--line)}
|
||||
.tabs button{border:none;border-bottom:2px solid transparent;border-radius:0;background:none;color:var(--muted);padding:8px 12px}
|
||||
.tabs button.on{color:#fff;border-bottom-color:var(--accent)}
|
||||
svg{width:100%;display:block}
|
||||
.empty{color:var(--faint);font-size:12.5px;text-align:center;padding:30px 10px;border:1px dashed var(--line2);border-radius:10px}
|
||||
.kc-box{background:var(--panel);border:1px solid var(--line);border-radius:10px;padding:14px;margin-bottom:14px}
|
||||
.kc-step{display:flex;align-items:center;gap:10px;padding:7px 0}
|
||||
.kc-arrow{color:var(--p0);font-size:18px;text-align:center;margin:-2px 0}
|
||||
.kc-node{flex:1;background:var(--panel2);border:1px solid var(--line2);border-left:3px solid var(--p0);border-radius:6px;padding:7px 10px}
|
||||
.kc-node .n{font-weight:600;font-size:13px}
|
||||
.kc-node .m{font-size:11px;color:var(--muted)}
|
||||
.kc-mech{font-size:11px;color:var(--faint);font-style:italic;padding-left:14px}
|
||||
.stat{display:flex;justify-content:space-between;padding:5px 0;border-bottom:1px solid var(--line);font-size:13px}
|
||||
.stat:last-child{border:none}
|
||||
.stat b{font-variant-numeric:tabular-nums}
|
||||
.q{border-radius:8px;border:1px solid var(--line);padding:10px 12px;margin-bottom:9px;background:var(--panel)}
|
||||
.q .qh{display:flex;justify-content:space-between;align-items:center;font-weight:700;font-size:12px;letter-spacing:.5px;text-transform:uppercase}
|
||||
.q.crit{border-left:4px solid var(--crit)} .q.crit .qh{color:var(--crit)}
|
||||
.q.sev{border-left:4px solid var(--sev)} .q.sev .qh{color:var(--sev)}
|
||||
.q.std{border-left:4px solid var(--std)} .q.std .qh{color:var(--std)}
|
||||
.q.darkq{border-left:4px solid var(--darkq)} .q.darkq .qh{color:var(--darkq)}
|
||||
.q .ql{font-size:12.5px;margin-top:7px}
|
||||
.q .qi{padding:4px 0;border-top:1px solid var(--line);margin-top:5px}
|
||||
.q .qi:first-of-type{border:none}
|
||||
.q .qi .qn{font-weight:600}
|
||||
.q .qi .qd{font-size:11px;color:var(--muted)}
|
||||
.q .budget{font-size:10.5px;color:var(--faint);font-weight:400;text-transform:none;letter-spacing:0}
|
||||
.discovery h3{font-size:12.5px;margin:12px 0 5px;color:var(--accent)}
|
||||
.discovery ul{margin:0 0 6px;padding-left:18px;color:var(--muted);font-size:12px}
|
||||
.discovery li{margin-bottom:3px}
|
||||
.discovery code{background:var(--panel2);border:1px solid var(--line);border-radius:4px;padding:1px 5px;color:#e6edf3;font-size:11px}
|
||||
.note{font-size:11.5px;color:var(--faint);margin-top:6px}
|
||||
.legend{display:flex;gap:12px;flex-wrap:wrap;font-size:11px;color:var(--muted);margin-bottom:8px}
|
||||
.legend span{display:flex;align-items:center;gap:5px}
|
||||
.dot{width:10px;height:10px;border-radius:50%}
|
||||
.topbtns{display:flex;gap:8px}
|
||||
.file-in{display:none}
|
||||
::-webkit-scrollbar{width:10px;height:10px}
|
||||
::-webkit-scrollbar-thumb{background:#222b36;border-radius:6px}
|
||||
::-webkit-scrollbar-track{background:transparent}
|
||||
.muted{color:var(--muted)} .small{font-size:11.5px}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<h1>⛓ Kill Chain Assessment</h1>
|
||||
<span class="tag">Brownhat · CQRE</span>
|
||||
<div class="topbtns">
|
||||
<button class="ghost" onclick="loadSample()">Load sample</button>
|
||||
<button class="ghost" onclick="exportJSON()">Save .json</button>
|
||||
<button class="ghost" onclick="document.getElementById('imp').click()">Open .json</button>
|
||||
<button class="primary" onclick="exportMD()">Export report .md</button>
|
||||
<input type="file" id="imp" class="file-in" accept=".json" onchange="importJSON(event)">
|
||||
</div>
|
||||
<div class="sub">Map unknown territory into nodes and attacker moves. The tool finds the shortest path from a foothold to an existential asset — that path <b>is</b> the kill chain — and sizes each node into a remediation quantum.</div>
|
||||
</header>
|
||||
|
||||
<div class="wrap">
|
||||
<!-- LEFT: capture -->
|
||||
<div class="col left">
|
||||
<div class="tabs">
|
||||
<button id="t-node" class="on" onclick="tab('node')">Nodes</button>
|
||||
<button id="t-edge" onclick="tab('edge')">Moves</button>
|
||||
<button id="t-disc" onclick="tab('disc')">Discovery</button>
|
||||
</div>
|
||||
|
||||
<!-- NODE form -->
|
||||
<div id="pane-node">
|
||||
<div class="panel">
|
||||
<h2>Add / edit node<span class="hint">An asset, foothold, identity, or system in the estate.</span></h2>
|
||||
<label>Name</label>
|
||||
<input type="text" id="n-name" placeholder="e.g. Entra ID Connect sync server">
|
||||
<div class="row">
|
||||
<div>
|
||||
<label>Layer</label>
|
||||
<select id="n-type">
|
||||
<option value="entry">Entry / exposure</option>
|
||||
<option value="identity">Identity</option>
|
||||
<option value="privilege">Privilege</option>
|
||||
<option value="device">Device / endpoint</option>
|
||||
<option value="data">Data / collaboration</option>
|
||||
<option value="infra">Infrastructure / OT</option>
|
||||
<option value="recovery">Recovery / backup</option>
|
||||
</select>
|
||||
</div>
|
||||
<div>
|
||||
<label>Tier</label>
|
||||
<select id="n-tier">
|
||||
<option value="">— unknown —</option>
|
||||
<option value="T0">T0 (control plane)</option>
|
||||
<option value="T1">T1 (servers/apps)</option>
|
||||
<option value="T2">T2 (workstations)</option>
|
||||
</select>
|
||||
</div>
|
||||
</div>
|
||||
<div class="chk"><input type="checkbox" id="n-entry"><label style="margin:0;color:var(--entry)">Adversary entry point (internet-reachable / unauth foothold)</label></div>
|
||||
<div class="chk"><input type="checkbox" id="n-jewel"><label style="margin:0;color:var(--jewel)">Crown jewel (existential — org cannot operate if lost)</label></div>
|
||||
<div class="row">
|
||||
<div>
|
||||
<label>Reachable by adversary?</label>
|
||||
<select id="n-reach"><option value="unknown">Unknown</option><option value="yes">Yes</option><option value="no">No</option></select>
|
||||
</div>
|
||||
<div>
|
||||
<label>Exploit / path available?</label>
|
||||
<select id="n-expl"><option value="unknown">Unknown</option><option value="yes">Yes</option><option value="no">No</option></select>
|
||||
</div>
|
||||
</div>
|
||||
<div class="chk"><input type="checkbox" id="n-comp"><label style="margin:0">Compensating control already in front of it (EDR, WAF, segmentation)</label></div>
|
||||
<label>Finding / note (optional)</label>
|
||||
<textarea id="n-note" placeholder="What's wrong here, evidence, CVE…"></textarea>
|
||||
<div class="btnrow">
|
||||
<button class="primary" onclick="saveNode()">Save node</button>
|
||||
<button class="ghost" onclick="clearNodeForm()">Clear</button>
|
||||
</div>
|
||||
</div>
|
||||
<h2>Nodes <span id="n-count" class="muted small"></span></h2>
|
||||
<div id="node-list"></div>
|
||||
</div>
|
||||
|
||||
<!-- EDGE form -->
|
||||
<div id="pane-edge" style="display:none">
|
||||
<div class="panel">
|
||||
<h2>Add attacker move<span class="hint">A directed step: "from here, an attacker can reach there."</span></h2>
|
||||
<label>From</label>
|
||||
<select id="e-from"></select>
|
||||
<label>To</label>
|
||||
<select id="e-to"></select>
|
||||
<label>Mechanism (how)</label>
|
||||
<input type="text" id="e-mech" placeholder="e.g. DCSync via sync-account rights">
|
||||
<label>Adversary effort: <span id="e-wlabel">3 — moderate</span></label>
|
||||
<input type="range" id="e-weight" min="1" max="5" value="3" style="width:100%" oninput="document.getElementById('e-wlabel').textContent=effortLabel(this.value)">
|
||||
<div class="note">Lower effort = easier for the attacker. The kill chain is the <i>lowest-effort</i> path to a crown jewel.</div>
|
||||
<div class="btnrow"><button class="primary" onclick="saveEdge()">Add move</button></div>
|
||||
</div>
|
||||
<h2>Moves <span id="e-count" class="muted small"></span></h2>
|
||||
<div id="edge-list"></div>
|
||||
</div>
|
||||
|
||||
<!-- DISCOVERY -->
|
||||
<div id="pane-disc" style="display:none">
|
||||
<div class="panel discovery">
|
||||
<h2>Discovering the chain in unknown territory<span class="hint">What to ask and run to surface the edges you can't see yet. Each answer becomes a node or a move.</span></h2>
|
||||
|
||||
<h3>1 · Find the entry points (reachability)</h3>
|
||||
<ul>
|
||||
<li>What does the internet see? External scan / Shodan / attack-surface mapping → every internet-facing service is a candidate entry node.</li>
|
||||
<li>Internet-facing VPN, RDP, mail, web apps, appliances — firmware current? MFA enforced?</li>
|
||||
<li>Legacy auth still enabled? (bypasses MFA — a silent entry edge)</li>
|
||||
</ul>
|
||||
|
||||
<h3>2 · Find the identity bridges (Book II)</h3>
|
||||
<ul>
|
||||
<li><code>Entra Connect sync account</code> — does it hold DCSync rights on-prem? That's a cloud→on-prem edge.</li>
|
||||
<li>Federation / PTA / PHS path, writeback, seamless SSO — map the bridge.</li>
|
||||
</ul>
|
||||
|
||||
<h3>3 · Find privilege paths (Book III)</h3>
|
||||
<ul>
|
||||
<li>BloodHound: <code>shortestPath</code> to Domain Admins from non-admins — every path is a chain of edges.</li>
|
||||
<li>Kerberoastable / AS-REP-roastable high-priv accounts; KRBTGT last-set date.</li>
|
||||
<li>App registrations with <code>RoleManagement.ReadWrite.Directory</code>, <code>Mail.ReadWrite</code> — OAuth consent edges.</li>
|
||||
</ul>
|
||||
|
||||
<h3>4 · Find the crown jewels (existential nodes)</h3>
|
||||
<ul>
|
||||
<li>Ask the business, not IT: "what stops the company operating?" ERP, payment rails, OT control, the customer DB.</li>
|
||||
<li>Backups & recovery — are they reachable from the estate they protect? If yes, that's an edge into your lifeboat.</li>
|
||||
</ul>
|
||||
|
||||
<h3>5 · Map blast radius (the edges between)</h3>
|
||||
<ul>
|
||||
<li>Flat network? NTLM relay, lateral movement → dense edges, short chains.</li>
|
||||
<li>Segmentation, least privilege, T0 isolation → sparse edges, long chains. Note where they're <i>missing</i>.</li>
|
||||
</ul>
|
||||
|
||||
<p class="note">Anything you can't characterise (reachable? unknown) becomes a <span style="color:var(--darkq)">dark quantum</span> — capture the node anyway and mark reachability/exploit "unknown". An uncharacterised asset is the dangerous kind.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- CENTER: graph + chain -->
|
||||
<div class="col center">
|
||||
<h2>Attack graph & kill chain</h2>
|
||||
<div class="legend">
|
||||
<span><span class="dot" style="background:var(--entry)"></span>entry</span>
|
||||
<span><span class="dot" style="background:var(--jewel)"></span>crown jewel</span>
|
||||
<span><span class="dot" style="background:var(--p0)"></span>on shortest chain (P0)</span>
|
||||
<span><span class="dot" style="background:var(--p1)"></span>on a chain (P1)</span>
|
||||
<span><span class="dot" style="background:var(--p2)"></span>off-chain (P2)</span>
|
||||
</div>
|
||||
<div class="panel" style="padding:6px"><div id="graph"></div></div>
|
||||
<div id="chain-out"></div>
|
||||
</div>
|
||||
|
||||
<!-- RIGHT: results -->
|
||||
<div class="col right">
|
||||
<h2>Assessment</h2>
|
||||
<div class="panel" id="summary"></div>
|
||||
<h2>Remediation quanta<span class="hint">Sized by time-to-existential-impact, not CVSS.</span></h2>
|
||||
<div id="quanta"></div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<script>
|
||||
/* ---------------- state ---------------- */
|
||||
let nodes = []; // {id,name,type,tier,entry,jewel,reach,expl,comp,note}
|
||||
let edges = []; // {id,from,to,mech,w}
|
||||
let editingId = null;
|
||||
let uid = () => 'n'+Math.random().toString(36).slice(2,8);
|
||||
|
||||
const STORE='brownhat-killchain-v1';
|
||||
function persist(){ try{localStorage.setItem(STORE,JSON.stringify({nodes,edges}));}catch(e){} }
|
||||
function restore(){ try{const s=JSON.parse(localStorage.getItem(STORE));if(s&&s.nodes){nodes=s.nodes;edges=s.edges||[];}}catch(e){} }
|
||||
|
||||
function effortLabel(v){return {1:'1 — trivial',2:'2 — easy',3:'3 — moderate',4:'4 — hard',5:'5 — very hard'}[v];}
|
||||
|
||||
/* ---------------- tabs ---------------- */
|
||||
function tab(t){
|
||||
['node','edge','disc'].forEach(x=>{
|
||||
document.getElementById('pane-'+x).style.display = x===t?'block':'none';
|
||||
document.getElementById('t-'+x).classList.toggle('on',x===t);
|
||||
});
|
||||
if(t==='edge') refreshEdgeSelects();
|
||||
}
|
||||
|
||||
/* ---------------- node CRUD ---------------- */
|
||||
function saveNode(){
|
||||
const name=document.getElementById('n-name').value.trim();
|
||||
if(!name){alert('Name the node first.');return;}
|
||||
const data={
|
||||
name,
|
||||
type:document.getElementById('n-type').value,
|
||||
tier:document.getElementById('n-tier').value,
|
||||
entry:document.getElementById('n-entry').checked,
|
||||
jewel:document.getElementById('n-jewel').checked,
|
||||
reach:document.getElementById('n-reach').value,
|
||||
expl:document.getElementById('n-expl').value,
|
||||
comp:document.getElementById('n-comp').checked,
|
||||
note:document.getElementById('n-note').value.trim()
|
||||
};
|
||||
if(editingId){ Object.assign(nodes.find(n=>n.id===editingId),data); }
|
||||
else { nodes.push(Object.assign({id:uid()},data)); }
|
||||
clearNodeForm(); render();
|
||||
}
|
||||
function editNode(id){
|
||||
const n=nodes.find(x=>x.id===id); if(!n)return;
|
||||
editingId=id;
|
||||
document.getElementById('n-name').value=n.name;
|
||||
document.getElementById('n-type').value=n.type;
|
||||
document.getElementById('n-tier').value=n.tier||'';
|
||||
document.getElementById('n-entry').checked=n.entry;
|
||||
document.getElementById('n-jewel').checked=n.jewel;
|
||||
document.getElementById('n-reach').value=n.reach;
|
||||
document.getElementById('n-expl').value=n.expl;
|
||||
document.getElementById('n-comp').checked=n.comp;
|
||||
document.getElementById('n-note').value=n.note||'';
|
||||
tab('node'); window.scrollTo(0,0);
|
||||
}
|
||||
function delNode(id){
|
||||
if(!confirm('Delete this node and its moves?'))return;
|
||||
nodes=nodes.filter(n=>n.id!==id);
|
||||
edges=edges.filter(e=>e.from!==id&&e.to!==id);
|
||||
if(editingId===id)clearNodeForm();
|
||||
render();
|
||||
}
|
||||
function clearNodeForm(){
|
||||
editingId=null;
|
||||
['n-name','n-note'].forEach(i=>document.getElementById(i).value='');
|
||||
document.getElementById('n-type').value='entry';
|
||||
document.getElementById('n-tier').value='';
|
||||
['n-entry','n-jewel','n-comp'].forEach(i=>document.getElementById(i).checked=false);
|
||||
document.getElementById('n-reach').value='unknown';
|
||||
document.getElementById('n-expl').value='unknown';
|
||||
}
|
||||
|
||||
/* ---------------- edge CRUD ---------------- */
|
||||
function refreshEdgeSelects(){
|
||||
const opts=nodes.map(n=>`<option value="${n.id}">${esc(n.name)}</option>`).join('');
|
||||
document.getElementById('e-from').innerHTML=opts;
|
||||
document.getElementById('e-to').innerHTML=opts;
|
||||
}
|
||||
function saveEdge(){
|
||||
const from=document.getElementById('e-from').value, to=document.getElementById('e-to').value;
|
||||
if(!from||!to){alert('Add at least two nodes first.');return;}
|
||||
if(from===to){alert('A move must go between two different nodes.');return;}
|
||||
edges.push({id:uid(),from,to,mech:document.getElementById('e-mech').value.trim(),w:+document.getElementById('e-weight').value});
|
||||
document.getElementById('e-mech').value='';
|
||||
render();
|
||||
}
|
||||
function delEdge(id){ edges=edges.filter(e=>e.id!==id); render(); }
|
||||
|
||||
/* ---------------- analysis: Dijkstra shortest existential path ---------------- */
|
||||
function analyse(){
|
||||
const entryIds=nodes.filter(n=>n.entry).map(n=>n.id);
|
||||
const jewelIds=new Set(nodes.filter(n=>n.jewel).map(n=>n.id));
|
||||
const adj={}; nodes.forEach(n=>adj[n.id]=[]);
|
||||
edges.forEach(e=>{ if(adj[e.from]) adj[e.from].push(e); });
|
||||
|
||||
// multi-source Dijkstra from all entry points
|
||||
const dist={}, prev={}, prevEdge={};
|
||||
nodes.forEach(n=>dist[n.id]=Infinity);
|
||||
const pq=[];
|
||||
entryIds.forEach(id=>{dist[id]=0; pq.push([0,id]);});
|
||||
while(pq.length){
|
||||
pq.sort((a,b)=>a[0]-b[0]);
|
||||
const [d,u]=pq.shift();
|
||||
if(d>dist[u])continue;
|
||||
(adj[u]||[]).forEach(e=>{
|
||||
const nd=d+e.w;
|
||||
if(nd<dist[e.to]){dist[e.to]=nd;prev[e.to]=u;prevEdge[e.to]=e;pq.push([nd,e.to]);}
|
||||
});
|
||||
}
|
||||
// best jewel = reachable jewel with min dist
|
||||
let best=null;
|
||||
jewelIds.forEach(j=>{ if(dist[j]<Infinity && (!best||dist[j]<dist[best])) best=j; });
|
||||
// reconstruct shortest chain
|
||||
let chain=[],chainEdges=[];
|
||||
if(best!=null){
|
||||
let cur=best;
|
||||
while(cur!=null){ chain.unshift(cur); if(prevEdge[cur]){chainEdges.unshift(prevEdge[cur]);cur=prev[cur];} else cur=null; }
|
||||
}
|
||||
const onShortest=new Set(chain);
|
||||
|
||||
// nodes on ANY existential path: reachable from entry AND can reach a jewel
|
||||
const reachFromEntry=new Set();
|
||||
(function(){const st=[...entryIds];entryIds.forEach(i=>reachFromEntry.add(i));
|
||||
while(st.length){const u=st.pop();(adj[u]||[]).forEach(e=>{if(!reachFromEntry.has(e.to)){reachFromEntry.add(e.to);st.push(e.to);}});}})();
|
||||
// reverse reachability to a jewel
|
||||
const radj={}; nodes.forEach(n=>radj[n.id]=[]); edges.forEach(e=>{if(radj[e.to])radj[e.to].push(e.from);});
|
||||
const canReachJewel=new Set();
|
||||
(function(){const st=[...jewelIds];jewelIds.forEach(i=>canReachJewel.add(i));
|
||||
while(st.length){const u=st.pop();(radj[u]||[]).forEach(f=>{if(!canReachJewel.has(f)){canReachJewel.add(f);st.push(f);}});}})();
|
||||
const onAnyChain=new Set(nodes.filter(n=>reachFromEntry.has(n.id)&&canReachJewel.has(n.id)).map(n=>n.id));
|
||||
|
||||
return {chain,chainEdges,onShortest,onAnyChain,dist,best,entryIds,jewelIds,reachable:reachFromEntry};
|
||||
}
|
||||
|
||||
/* priority + quantum per node */
|
||||
function priority(n,a){
|
||||
if(a.onShortest.has(n.id))return 'P0';
|
||||
if(a.onAnyChain.has(n.id))return 'P1';
|
||||
return 'P2';
|
||||
}
|
||||
function quantum(n,a){
|
||||
const onChain = a.onShortest.has(n.id)||a.onAnyChain.has(n.id);
|
||||
if(!onChain) return 'house';
|
||||
if(n.reach==='unknown'||n.expl==='unknown') return 'dark';
|
||||
if(a.onShortest.has(n.id) && n.reach==='yes' && n.expl==='yes' && !n.comp) return 'crit';
|
||||
if(n.reach==='yes' || n.expl==='yes') return 'sev';
|
||||
return 'std';
|
||||
}
|
||||
const QMETA={
|
||||
crit:{label:'Critical quantum',budget:'hours · compensating control, not the patch',cls:'crit'},
|
||||
sev:{label:'Severe quantum',budget:'days · batched into one change window',cls:'sev'},
|
||||
std:{label:'Standard quantum',budget:'sprint · drained in finishable batches',cls:'std'},
|
||||
dark:{label:'Dark quantum',budget:'unsized · route to discovery',cls:'darkq'},
|
||||
house:{label:'Housekeeping',budget:'off every kill chain — not urgent',cls:'std'}
|
||||
};
|
||||
|
||||
/* ---------------- render ---------------- */
|
||||
function esc(s){return (s||'').replace(/[&<>"]/g,c=>({'&':'&','<':'<','>':'>','"':'"'}[c]));}
|
||||
const TYPELBL={entry:'Entry',identity:'Identity',privilege:'Privilege',device:'Device',data:'Data',infra:'Infra/OT',recovery:'Recovery'};
|
||||
|
||||
function render(){
|
||||
persist();
|
||||
renderNodeList(); renderEdgeList(); refreshEdgeSelects();
|
||||
const a = analyse();
|
||||
renderGraph(a); renderChain(a); renderSummary(a); renderQuanta(a);
|
||||
}
|
||||
|
||||
function renderNodeList(){
|
||||
document.getElementById('n-count').textContent = nodes.length?`(${nodes.length})`:'';
|
||||
const el=document.getElementById('node-list');
|
||||
if(!nodes.length){el.innerHTML='<div class="empty">No nodes yet. Add the footholds and assets you find — or “Load sample”.</div>';return;}
|
||||
const a=analyse();
|
||||
el.innerHTML=nodes.map(n=>{
|
||||
const p=priority(n,a);
|
||||
const pc=p==='P0'?'var(--p0)':p==='P1'?'var(--p1)':'var(--p2)';
|
||||
return `<div class="node-item ${editingId===n.id?'sel':''}" onclick="editNode('${n.id}')">
|
||||
<div class="nm"><span>${esc(n.name)}</span>
|
||||
<span style="display:flex;gap:5px;align-items:center">
|
||||
${n.entry?'<span class="pill entry">entry</span>':''}
|
||||
${n.jewel?'<span class="pill jewel">jewel</span>':''}
|
||||
<span style="color:${pc};font-weight:700;font-size:11px">${(a.onShortest.has(n.id)||a.onAnyChain.has(n.id))?p:'—'}</span>
|
||||
<span class="x" onclick="event.stopPropagation();delNode('${n.id}')" style="cursor:pointer;color:var(--faint)">✕</span>
|
||||
</span>
|
||||
</div>
|
||||
<div class="meta"><span>${TYPELBL[n.type]||n.type}</span>${n.tier?`<span>· ${n.tier}</span>`:''}
|
||||
<span>· reach:${n.reach}</span><span>· exploit:${n.expl}</span>${n.comp?'<span>· compensated</span>':''}</div>
|
||||
</div>`;
|
||||
}).join('');
|
||||
}
|
||||
|
||||
function renderEdgeList(){
|
||||
document.getElementById('e-count').textContent = edges.length?`(${edges.length})`:'';
|
||||
const el=document.getElementById('edge-list');
|
||||
if(!edges.length){el.innerHTML='<div class="empty">No moves yet. A move is one attacker step from one node to another.</div>';return;}
|
||||
const nm=id=>{const n=nodes.find(x=>x.id===id);return n?esc(n.name):'?';};
|
||||
el.innerHTML=edges.map(e=>`<div class="edge-item">
|
||||
<div><b>${nm(e.from)}</b> → <b>${nm(e.to)}</b><br>
|
||||
<span class="muted small">${esc(e.mech)||'(mechanism unspecified)'} · effort ${e.w}</span></div>
|
||||
<span class="x" onclick="delEdge('${e.id}')">✕</span></div>`).join('');
|
||||
}
|
||||
|
||||
function renderGraph(a){
|
||||
const g=document.getElementById('graph');
|
||||
if(!nodes.length){g.innerHTML='<div class="empty" style="margin:10px">The attack graph renders here.</div>';return;}
|
||||
// simple layered layout by distance-from-entry (BFS depth), entries left → jewels right
|
||||
const depth={}; nodes.forEach(n=>depth[n.id]=n.entry?0:null);
|
||||
const adj={};nodes.forEach(n=>adj[n.id]=[]);edges.forEach(e=>{if(adj[e.from])adj[e.from].push(e.to);});
|
||||
let q=nodes.filter(n=>n.entry).map(n=>n.id),guard=0;
|
||||
while(q.length&&guard++<999){const u=q.shift();(adj[u]||[]).forEach(v=>{if(depth[v]==null||depth[v]>depth[u]+1){depth[v]=depth[u]+1;q.push(v);}});}
|
||||
let maxd=0;nodes.forEach(n=>{if(depth[n.id]==null)depth[n.id]=999;maxd=Math.max(maxd,depth[n.id]===999?0:depth[n.id]);});
|
||||
// orphans (no depth) put in a trailing column
|
||||
const cols={};nodes.forEach(n=>{const d=depth[n.id]===999?maxd+1:depth[n.id];(cols[d]=cols[d]||[]).push(n);});
|
||||
const colKeys=Object.keys(cols).map(Number).sort((x,y)=>x-y);
|
||||
const W=Math.max(640,colKeys.length*180), colW=W/colKeys.length;
|
||||
let maxRows=0;colKeys.forEach(k=>maxRows=Math.max(maxRows,cols[k].length));
|
||||
const H=Math.max(220,maxRows*72+40);
|
||||
const pos={};
|
||||
colKeys.forEach((k,ci)=>{cols[k].forEach((n,ri)=>{const rows=cols[k].length;
|
||||
pos[n.id]={x:colW*ci+colW/2,y:H/(rows+1)*(ri+1)};});});
|
||||
const col=n=>{if(a.onShortest.has(n.id))return'var(--p0)';if(a.onAnyChain.has(n.id))return'var(--p1)';if(n.jewel)return'var(--jewel)';if(n.entry)return'var(--entry)';return'#3fb95066';};
|
||||
const onChainEdge=new Set(a.chainEdges.map(e=>e.id));
|
||||
let svg=`<svg viewBox="0 0 ${W} ${H}" preserveAspectRatio="xMidYMid meet">
|
||||
<defs><marker id="arr" markerWidth="9" markerHeight="9" refX="8" refY="3" orient="auto"><path d="M0,0 L8,3 L0,6 Z" fill="#5b6675"/></marker>
|
||||
<marker id="arrR" markerWidth="10" markerHeight="10" refX="8" refY="3" orient="auto"><path d="M0,0 L8,3 L0,6 Z" fill="var(--p0)"/></marker></defs>`;
|
||||
edges.forEach(e=>{const a1=pos[e.from],b=pos[e.to];if(!a1||!b)return;
|
||||
const hot=onChainEdge.has(e.id);
|
||||
const mx=(a1.x+b.x)/2,my=(a1.y+b.y)/2-18;
|
||||
svg+=`<path d="M${a1.x},${a1.y} Q${mx},${my} ${b.x},${b.y}" fill="none" stroke="${hot?'var(--p0)':'#39414d'}" stroke-width="${hot?2.4:1.2}" marker-end="url(#${hot?'arrR':'arr'})" opacity="${hot?1:.7}"/>`;
|
||||
});
|
||||
nodes.forEach(n=>{const p=pos[n.id];if(!p)return;const c=col(n);
|
||||
const r=n.jewel||n.entry?20:16;
|
||||
svg+=`<g>
|
||||
<circle cx="${p.x}" cy="${p.y}" r="${r}" fill="${c}" fill-opacity="${a.onShortest.has(n.id)?0.95:0.18}" stroke="${c}" stroke-width="2"/>
|
||||
${n.jewel?`<text x="${p.x}" y="${p.y+4}" text-anchor="middle" font-size="14">★</text>`:''}
|
||||
${n.entry?`<text x="${p.x}" y="${p.y+4}" text-anchor="middle" font-size="12">▶</text>`:''}
|
||||
<text x="${p.x}" y="${p.y+r+13}" text-anchor="middle" font-size="11" fill="#c9d4df">${esc(n.name.length>22?n.name.slice(0,21)+'…':n.name)}</text>
|
||||
</g>`;});
|
||||
svg+='</svg>';
|
||||
g.innerHTML=svg;
|
||||
}
|
||||
|
||||
function renderChain(a){
|
||||
const el=document.getElementById('chain-out');
|
||||
if(!a.entryIds.length||!a.jewelIds.size){
|
||||
el.innerHTML=`<div class="kc-box"><b>No kill chain yet.</b><div class="note">Mark at least one node as an <span style="color:var(--entry)">entry point</span> and one as a <span style="color:var(--jewel)">crown jewel</span>, then connect them with moves.</div></div>`;return;}
|
||||
if(!a.chain.length){
|
||||
el.innerHTML=`<div class="kc-box"><b style="color:var(--p2)">No path found from any entry point to a crown jewel.</b><div class="note">Either the estate is genuinely segmented here (good — note it), or you haven't mapped the connecting moves yet. In unknown territory, assume the latter until proven.</div></div>`;return;}
|
||||
const nm=id=>nodes.find(n=>n.id===id);
|
||||
let html=`<div class="kc-box"><h2 style="color:var(--p0);margin-top:0">⛓ The kill chain<span class="hint">Lowest-effort path from foothold to existential impact. Total adversary effort: ${a.dist[a.best]}.</span></h2>`;
|
||||
a.chain.forEach((id,i)=>{
|
||||
const n=nm(id);
|
||||
html+=`<div class="kc-step"><div class="kc-node">
|
||||
<div class="n">${esc(n.name)} ${n.entry?'<span class="pill entry">entry</span>':''} ${n.jewel?'<span class="pill jewel">jewel</span>':''}</div>
|
||||
<div class="m">${TYPELBL[n.type]||n.type}${n.tier?' · '+n.tier:''}${n.note?' · '+esc(n.note):''}</div>
|
||||
</div></div>`;
|
||||
if(i<a.chainEdges.length){const e=a.chainEdges[i];
|
||||
html+=`<div class="kc-arrow">↓</div><div class="kc-mech">${esc(e.mech)||'move'} · effort ${e.w}</div>`;}
|
||||
});
|
||||
html+=`<div class="note" style="margin-top:10px">Every node on this path is a <b style="color:var(--p0)">P0</b>. Fix the chain first — break any single link and the existential path is severed. After the incident, ask: did this chain get <i>shorter</i>?</div></div>`;
|
||||
el.innerHTML=html;
|
||||
}
|
||||
|
||||
function renderSummary(a){
|
||||
const counts={P0:0,P1:0,P2:0};
|
||||
nodes.forEach(n=>{counts[priority(n,a)]++;});
|
||||
const qc={crit:0,sev:0,std:0,dark:0,house:0};
|
||||
nodes.forEach(n=>qc[quantum(n,a)]++);
|
||||
document.getElementById('summary').innerHTML=`
|
||||
<div class="stat"><span>Nodes mapped</span><b>${nodes.length}</b></div>
|
||||
<div class="stat"><span>Attacker moves</span><b>${edges.length}</b></div>
|
||||
<div class="stat"><span>Entry points</span><b>${a.entryIds.length}</b></div>
|
||||
<div class="stat"><span>Crown jewels</span><b>${a.jewelIds.size}</b></div>
|
||||
<div class="stat"><span style="color:var(--p0)">Kill-chain length</span><b style="color:var(--p0)">${a.chain.length||'—'}</b></div>
|
||||
<div class="stat"><span style="color:var(--p0)">P0 nodes (on shortest chain)</span><b style="color:var(--p0)">${counts.P0}</b></div>
|
||||
<div class="stat"><span style="color:var(--p1)">P1 nodes (on a chain)</span><b style="color:var(--p1)">${counts.P1}</b></div>
|
||||
<div class="stat"><span style="color:var(--darkq)">Dark quanta (unsized)</span><b style="color:var(--darkq)">${qc.dark}</b></div>`;
|
||||
}
|
||||
|
||||
function renderQuanta(a){
|
||||
const buckets={crit:[],sev:[],std:[],dark:[]};
|
||||
nodes.forEach(n=>{const q=quantum(n,a);if(buckets[q])buckets[q].push(n);});
|
||||
const order=['crit','sev','std','dark'];
|
||||
let html='';
|
||||
order.forEach(k=>{
|
||||
const list=buckets[k];if(!list.length)return;
|
||||
const m=QMETA[k];
|
||||
html+=`<div class="q ${m.cls}"><div class="qh"><span>${m.label}</span><span class="budget">${m.budget}</span></div>`;
|
||||
list.forEach(n=>{
|
||||
const action = k==='crit'?'Sever reachability / compensating control now'
|
||||
: k==='sev'?'Remediate in next change window, verify enforcement'
|
||||
: k==='std'?'Batch into sprint; this is where patch velocity fits'
|
||||
: 'Characterise: establish reachability & exploitability';
|
||||
html+=`<div class="qi"><div class="qn">${esc(n.name)}</div><div class="qd">${action}${n.note?' — '+esc(n.note):''}</div></div>`;
|
||||
});
|
||||
html+='</div>';
|
||||
});
|
||||
if(!html) html='<div class="empty">Quanta appear once nodes sit on a kill chain. Map entries, jewels, and the moves between.</div>';
|
||||
document.getElementById('quanta').innerHTML=html;
|
||||
}
|
||||
|
||||
/* ---------------- import / export ---------------- */
|
||||
function exportJSON(){
|
||||
dl('kill-chain-assessment.json', JSON.stringify({nodes,edges,exported:new Date().toISOString()},null,2));
|
||||
}
|
||||
function importJSON(ev){
|
||||
const f=ev.target.files[0];if(!f)return;
|
||||
const r=new FileReader();
|
||||
r.onload=()=>{try{const s=JSON.parse(r.result);nodes=s.nodes||[];edges=s.edges||[];clearNodeForm();render();}catch(e){alert('Could not read that file.');}};
|
||||
r.readAsText(f); ev.target.value='';
|
||||
}
|
||||
function exportMD(){
|
||||
const a=analyse();const nm=id=>{const n=nodes.find(x=>x.id===id);return n?n.name:'?';};
|
||||
let md=`# Kill Chain Assessment\n\n_Generated ${new Date().toLocaleString()} · Brownhat / CQRE_\n\n`;
|
||||
md+=`## Summary\n\n- Nodes mapped: ${nodes.length}\n- Attacker moves: ${edges.length}\n- Entry points: ${a.entryIds.length}\n- Crown jewels: ${a.jewelIds.size}\n- Kill-chain length: ${a.chain.length||'—'}\n\n`;
|
||||
if(a.chain.length){
|
||||
md+=`## The kill chain (shortest existential path)\n\nLowest-effort path from foothold to existential impact (total adversary effort ${a.dist[a.best]}):\n\n\`\`\`\n`;
|
||||
a.chain.forEach((id,i)=>{md+=`${nm(id)}`;if(i<a.chainEdges.length)md+=`\n → [${a.chainEdges[i].mech||'move'} · effort ${a.chainEdges[i].w}]\n`;});
|
||||
md+=`\n\`\`\`\n\nEvery node on this path is a **P0**. Break any single link to sever the existential path.\n\n`;
|
||||
} else {
|
||||
md+=`## The kill chain\n\nNo path from an entry point to a crown jewel was mapped. Either the estate is segmented here, or the connecting moves are not yet discovered.\n\n`;
|
||||
}
|
||||
// quanta
|
||||
const buckets={crit:[],sev:[],std:[],dark:[]};nodes.forEach(n=>{const q=quantum(n,a);if(buckets[q])buckets[q].push(n);});
|
||||
md+=`## Remediation quanta\n\n`;
|
||||
[['crit','Critical quantum — hours (compensating control, not the patch)'],
|
||||
['sev','Severe quantum — days (one change window)'],
|
||||
['std','Standard quantum — sprint (patch velocity fits here)'],
|
||||
['dark','Dark quantum — unsized (route to discovery)']].forEach(([k,t])=>{
|
||||
if(!buckets[k].length)return;
|
||||
md+=`### ${t}\n\n`;
|
||||
buckets[k].forEach(n=>{md+=`- **${n.name}**${n.tier?` (${n.tier})`:''}${n.note?` — ${n.note}`:''} _(reach:${n.reach}, exploit:${n.expl}${n.comp?', compensated':''})_\n`;});
|
||||
md+=`\n`;
|
||||
});
|
||||
// findings table
|
||||
md+=`## All nodes by priority\n\n| Node | Layer | Tier | Priority | Quantum | Reach | Exploit |\n|---|---|---|---|---|---|---|\n`;
|
||||
const pri=n=>priority(n,a);
|
||||
nodes.slice().sort((x,y)=>({P0:0,P1:1,P2:2}[pri(x)]-{P0:0,P1:1,P2:2}[pri(y)])).forEach(n=>{
|
||||
md+=`| ${n.name} | ${TYPELBL[n.type]||n.type} | ${n.tier||'—'} | ${(a.onShortest.has(n.id)||a.onAnyChain.has(n.id))?pri(n):'off-chain'} | ${QMETA[quantum(n,a)].label} | ${n.reach} | ${n.expl} |\n`;
|
||||
});
|
||||
md+=`\n---\n\n_See Book VII — Vulnerability Management and the Quantum Vulnerability Management framework for how to size and drain these quanta._\n`;
|
||||
dl('kill-chain-assessment.md', md);
|
||||
}
|
||||
function dl(name,content){
|
||||
const b=new Blob([content],{type:'text/plain'});const u=URL.createObjectURL(b);
|
||||
const a=document.createElement('a');a.href=u;a.download=name;a.click();URL.revokeObjectURL(u);
|
||||
}
|
||||
|
||||
/* ---------------- sample (repo: mid-market engagement) ---------------- */
|
||||
function loadSample(){
|
||||
if(nodes.length && !confirm('Replace current assessment with the sample engagement?'))return;
|
||||
nodes=[
|
||||
mk('Stale contractor credential','identity','',{entry:1,reach:'yes',expl:'yes',note:'Active 6 months after offboarding; no MFA'}),
|
||||
mk('Internet-facing VPN (legacy firmware)','entry','',{entry:1,reach:'yes',expl:'yes',note:'Cisco ASA, firmware 18mo stale, no MFA'}),
|
||||
mk('M365 / Entra ID','identity','T1',{reach:'yes',expl:'yes',note:'34% sign-ins without MFA; CA in report-only'}),
|
||||
mk('SharePoint / Teams / Exchange','data','T1',{reach:'yes',expl:'no',note:'All collaboration data + email'}),
|
||||
mk('Entra admin account','privilege','T0',{reach:'yes',expl:'yes',note:'Reachable via password spray'}),
|
||||
mk('Entra Connect sync account','privilege','T0',{reach:'yes',expl:'yes',note:'Has DCSync rights on-prem'}),
|
||||
mk('On-prem Active Directory','privilege','T0',{jewel:0,reach:'yes',expl:'yes',note:'KRBTGT never rotated (847d)'}),
|
||||
mk('SAP ERP','infra','T1',{jewel:1,reach:'unknown',expl:'unknown',note:'Financial + operational; default creds on secondary instance'}),
|
||||
mk('Backups (same segment as ERP)','recovery','T1',{jewel:1,reach:'yes',expl:'yes',comp:0,note:'Never restore-tested; reachable from estate'})
|
||||
];
|
||||
const id=n=>nodes.find(x=>x.name.startsWith(n)).id;
|
||||
edges=[
|
||||
ed('Stale contractor','M365','Credential valid, no MFA',1),
|
||||
ed('Internet-facing VPN','On-prem','VPN auth → internal network',1),
|
||||
ed('M365','SharePoint','Token grants data access',1),
|
||||
ed('M365','Entra admin','Password spray → privilege escalation',2),
|
||||
ed('Entra admin','Entra Connect','Admin controls sync identity',2),
|
||||
ed('Entra Connect','On-prem','DCSync via sync-account rights',2),
|
||||
ed('On-prem','SAP ERP','Domain creds reused on ERP',3),
|
||||
ed('On-prem','Backups','Backups reachable from domain',1),
|
||||
ed('SAP ERP','Backups','Same network segment',1)
|
||||
];
|
||||
function mk(name,type,tier,o){return Object.assign({id:uid(),name,type,tier,entry:!!o.entry,jewel:!!o.jewel,reach:o.reach||'unknown',expl:o.expl||'unknown',comp:!!o.comp,note:o.note||''},{});}
|
||||
function ed(a,b,mech,w){return {id:uid(),from:id(a),to:id(b),mech,w};}
|
||||
clearNodeForm();render();
|
||||
}
|
||||
|
||||
/* ---------------- boot ---------------- */
|
||||
restore();
|
||||
if(!nodes.length) loadSample(); else render();
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
Reference in New Issue
Block a user