Bus-level attack classes fired at a live detection stack and scored honestly - including the ones nothing on the bus can see. The evidence a program office asks for, built as a working console.
The real DOWNRANGE readout, recreated - summary, operator, readiness, threat intel, PNT/EW, and provenance. Every program, bench, and score here is fictional; the engine, the scoring, and the honesty are real. Scroll the panel - each view is a working screen.
SUMMARY
01 / SUMMARY
Capability and proportion, at once
The headline read: multi-domain detection proven on a real pen-test range, grounded in real benign telemetry. Thirty-three attack techniques across eight families, ten control overlays, four alert dialects - and the honest framing that a program office needs before it spends a dollar.
Scope the rounds by attack class, toggle the control overlays, and fire down the bus against the detection engine. Green intercepts stop at PICKET; red escapes run through to egress. Every caught round emits its alert record - ECS, TAK CoT, or a program format - from one canonical event.
live tracers · caught vs escaped · one event, many dialects
03 / READINESS
What we catch, and where it matters
Two truths side by side. Layered defense climbs from ~75% to ~94% as rule layers stack - every gain data, not code. Ground truth shows the network tier carries ~95% of real alert volume, the avionics bus the smallest slice. Capability says what can be caught; proportion says what to fund first.
~75% → ~88% → ~94% · network ≈ 95%
04 / THREAT INTEL
One stack, three lanes
The unit under test runs the same stack this range exercises - the avionics IDS on the 1553/429 bus, Snort and Zeek on the network, Sagan on logs. The fleet alert picture, severity-ranked, in one live feed.
critical 8 · high 33 · medium 7
05 / PNT / EW
What each attack does to the nav solution
The strategic where-and-when of GPS interference, and the tactical per-attack EGI: figure-of-merit jump, nav-mode fallback, drift rate, and time-to-detect - per case, per tail. The console shows the honest residual too: attacks with no on-bus signal, scored missed rather than faked.
GPS jam: FOM 9 → 31 m · GPS-aided → INS-only · caught 1.2 s
06 / PROVENANCE
Every claim carries its source
Thirty-three validated, zero modeled. Real benign telemetry, zero false alarms. Every value on every screen is labeled - validated, computed, or modeled - and a hash-chained, append-only audit journal lets a test director replay the ledger and get the same numbers. That is what keeps it honest.
fidelity 33·0 · audit chain verifiable offline
Where this goes
The adaptive loop: escapes become detections.
Every escape is a specification for the rule that would have caught it. DOWNRANGE turns that into a workflow - and points at real-time threat mitigation at the edge.
01
Escape detected
a round runs the bus to egress - logged with its exact signature
→
02
Auto-draft rule
the harness proposes a Python detection script targeting that signature
→
03
Validate in harness
eval-before-merge: the new rule must lift the score without new false alarms
→
04
Push to SIL
the adapted ruleset ships to the systems-integration lab, near-real-time
→
05
SDR + AI edge ROADMAP
an SDR front-end and edge compute close the loop to real-time threat mitigation
The problem
Avionics cyber requirements stopped being a paperwork exercise. The evidence a test director asks for isn't a scan report.
Cyber survivability language now sits in platform RFPs, and government test organizations expect bus-level evidence - what happens on the MIL-STD-1553 bus under attack, not what the enterprise scanner found - before a systems-integration-lab slot gets scheduled. Most companies pursuing that work show up with policy binders and network scan reports. Neither answers the question the test director is going to ask.
The evidence that moves a program forward looks different: named attack classes executed against the actual data bus, a detector whose scoring is independent of the product being scored, and an audit trail somebody else can verify. That is instrumentation, and it has to be engineered.
The bearing: Downrange is that instrumentation, end to end - attack cases, clean-room detection, control-overlay scoring, a hardware-arm interlock, a tamper-evident audit chain. It sits here so a company pursuing DoD platform work can see the standard of evidence before a program office asks for it.
What it is
Five capabilities. One console, honest by construction.
i.
The firing lane
Nineteen attack classes across the MIL-STD-1553 threat surface - bus injection, spoofed remote terminals, timing manipulation, PNT interference - executed as live rounds against the detection stack. Intercepts flare green. Escapes stay red, because a range that hides its misses isn't a range.
ii.
An honest detection engine
Eight clean-room analyzers - bus conformance, timing, command policy, content, PNT integrity, terminal fingerprinting among them - read the monitor stream and decide caught or missed from the traffic itself. Attacks that emit no on-bus signal score as “missed, undetectable on-bus,” never as a fake catch. That honesty is the product.
iii.
Control-overlay readiness
Bus-level test cases crossed with security-control overlays and recomputed into a per-overlay readiness score. Stack an overlay, watch the detection rate move - the readiness argument becomes arithmetic instead of adjectives.
iv.
Alerts in the receiver's dialect
One canonical event model with thin serializers outward: Elastic Common Schema for the SIEM, Cursor-on-Target for TAK operational pictures, program alert formats for the command side. Detection is computed once; the paperwork is a serializer.
v.
An armed-and-audited command path
No case fires at real hardware without a named, authenticated operator, a software arm scoped to the hazard tier, and a physical transmit-inhibit interlock that reads fail-safe to unarmed. Every execute, arm, disarm, and refusal lands in a hash-chained, append-only audit journal a test director can verify offline.
How it works
Five layers. Clean-room detection, sealed evidence.
The console is self-contained: inline assets, embedded data, no external requests, CSP-safe. The bench runs mock-first, so the full attack suite executes with zero hardware. Detection is standards-only - no vendor code, no signatures - and the audit journal is verifiable with no network and no vendor tooling.
Layer 1
The console
A self-contained single page: inline CSS and JS, embedded data, no build step, no external requests, CSP-safe. Tabbed views for summary, operator, readiness, threat intel, PNT/EW, and provenance, in a dark cockpit-MFD idiom. It renders with no server running - the model view is a working artifact, not a demo shell.
Layer 2
The bench
A Python 3.12 + FastAPI backend executes attack cases against a real or simulated MIL-STD-1553 / ARINC 429 bench. Built mock-first: the full suite runs with zero hardware, and COTS 1553 interface cards drop in behind a driver seam without touching case or UI code.
Layer 3
The scoring authority
Bus monitor words normalize into an ordered, seekable message stream; the analyzers fuse to a verdict; windowed scoring grades captured, escaped-unexpected, and escaped-by-design against a ground-truth inject ledger. A golden-corpus replay gate - baseline, verify, diff - blocks any engine change that moves the numbers unexplained.
Layer 4
The command path
An authenticated gateway checks the operator before a driver even resolves; real hardware additionally requires the physical transmit-inhibit arm signal. The audit journal behind it is standard-library only - hash-chained, crash-tolerant, verifiable with no network and no vendor tooling.
Layer 5
The outputs
One canonical detection event serialized to Elastic Common Schema, CoT/TAK, and downstream alert formats; readiness rolls up per control overlay. The audit journal stays a separate, sealed stream from the detection feed - evidence and telemetry never share a channel.
What this is not
Three clarifications.
Not a vendor IDS. The detection engine is clean-room and standards-only - published MIL-STD-1553B analysis techniques, no vendor code, rules, or signatures - so the scoring authority stays independent of any product being scored. A range that grades its own homework proves nothing.
Not an accreditation. A range scorecard is the evidence you bring to a government test organization, not a replacement for its process. Today's numbers run against a simulated golden corpus; hardware-in-the-loop rates arrive when the physical bench and its interlock are wired.
Not anyone's program data. Every program name, bench tag, operator, flight, and score on these screens is fictional. The engineering underneath - the analyzers, the interlock, the audit chain - is real and running.
Next step
If you're pursuing platform work with a cyber-survivability requirement, the first move is seeing what the evidence looks like.
One conversation, one written summary, no commitment. The bearing comes first.