21 KiB
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 (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 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. It assumes you already have findings — BloodHound paths, Entra checks, the assessment team guide 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:
- What humans tell it — structured intake and questionnaire responses from the client.
- 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) 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 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
.jsonschema 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
ResponseandHypothesisdata; 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 aFinding. The vocabulary is enforced in the data model and the UI. A finding comes from the assessment team guide fieldwork and lands in the Findings Backlog; 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 intake | Generate and distribute the tailored questionnaire; collect responses before the on-site half-days |
| Fieldwork (assessment team guide) | 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)
- Phase 1 — MVP. Stage-1 intake, LLM questionnaire generation (Ollama), manual-assisted synthesis, L1
.jsonexport. No threat intel yet. Proves the core loop. - Phase 2 — Threat intel. KEV / advisory / curated-search connectors with provenance; exploit-availability enrichment of hypotheses.
- Phase 3 — Adaptive + integrated. Full branching questionnaire engine (questions-as-data), MCP server, AURORA integration, sector question packs.
- 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
- Backend choice — FastAPI (lighter, our synthesis is bespoke) vs Django/DRF (matches CISO Assistant, more batteries). Leaning FastAPI.
- Client-facing surface — shared tokenised link (low friction) vs lightweight client login (more control). Leaning tokenised link with per-engagement expiry.
- 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.
- CISO Assistant integration depth — loose (export/import) vs deep (shared data model). Loose first.
- 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.
- 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 (L1), Book VII — Vulnerability Management, and the Quantum Vulnerability Management framework. Positioned in the suite alongside ASTRAL, PULSAR, and AURORA.