252 lines
21 KiB
Markdown
252 lines
21 KiB
Markdown
# 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).*
|