⌬
cross-layer correlation
Endpoint, network, and cloud events bind to the same entity graph. A process spawning a curl spawning a cloud API call is one alert, not three.
research
v1.0.19
● release · cross-layer detection live
wardex.
unified XDR · cross-layer detection · federated learning at the edge.
Wardex correlates security telemetry across endpoints, networks, and cloud workloads — and trains its detectors with federated learning so models improve without raw data ever leaving the host. Response orchestration is built in, not bolted on.
A / ABSTRACT
cat README.md/
XDR done from the threat-model out, not the dashboard in.
Abstract · 2026
Most XDR platforms started as endpoint products and bolted on network and cloud telemetry. The seams show up where it hurts most: in detection lag, in over-fitted rules, and in privacy posture. Wardex was built the other direction — a federated detection substrate first, with endpoint, network, and cloud collectors plugged into the same correlation graph.
The architectural commitment is that raw telemetry never leaves the host. Models update via federated gradients with differential privacy; correlations are computed on encrypted feature digests. Response orchestration uses the same execution surface as detection, so playbooks ship with provenance.
XDRfederated learningDP-SGDeBPFONNX runtimecross-layer correlationresponse orchestration
B / ARCHITECTURE
tree -L 2/
Three telemetry layers feeding one correlation graph and one orchestrator.
fig.01 · cross-layer flow
wardex v1.0 · federated
collectors ↘ correlation
decision ↗ orchestrator
collector
endpoint · eBPF
syscalls · proc · file
collector
network · flows
nflog · pcap · dns
collector
cloud · API
audit logs · IAM · k8s
core
correlation graph
entity-bound · streaming
detector
federated ML
DP-SGD · drift-aware
detector
rule engine
sigma · provenance
action
orchestrator
playbooks · receipts
policy
response gate
approval · safety
C / CAPABILITIES
ls capabilities/
Six commitments that distinguish Wardex from a SIEM with marketing.
⊞
federated learning, on-host
Detectors train locally; only gradients leave, clipped & noised for ε-DP. Models improve across the fleet without telemetry pooling.
∂
drift-aware detectors
Each detector ships with a calibrated drift monitor. Quiet degradation surfaces as a separate signal before false negatives accumulate.
⌥
response with receipts
The orchestrator executes playbooks behind a signed policy gate. Every action emits a tamper-evident receipt — auditors can replay, not just read.
⚙
eBPF first on linux
No kernel modules. Endpoint coverage rides on eBPF probes with CO-RE for portability. macOS uses EndpointSecurity; Windows via ETW.
◇
onnx runtime, portable
Detectors ship as ONNX. Same model runs on the edge, the analyst's laptop, and the cloud verifier. No platform-specific re-training.
D / NUMBERS
bench --suite=detect/
Measured on the CIC-IDS2018 + internal pilot blend. Reproducible fixtures in /bench.
detection p50
68ms
event → enriched alert, end-to-end.
vs splunk: −82%
F1 · drift fold
0.94
macro-F1 across 12 attack families, day-7 drift fold.
held-out · drift-aware
privacy budget
ε=2.0
per-round DP budget for federated rounds.
RDP accounting · δ=1e-5
collector overhead
1.8%
avg CPU on a busy app server (eBPF mode).
m1 · m2 · xeon · same band
E / DETECT
cat detector.toml/
A detector is a manifest. The rest is provenance.
detectors as first-class artifacts
Every detector is a versioned manifest: the model (ONNX), the feature spec, the drift monitor, and the response gate. Wardex loads the manifest and binds it to the correlation graph — no glue scripts.
The same manifest format is what gets shared in federated rounds. Hash-stable identity means the analyst, the verifier, and the auditor all reason about the same artifact.
format
TOML + ONNX + sigstore
feature spec
protobuf schema · typed
drift
PSI threshold · KS fallback
response
policy-gated · signed
detectors/c2_beacon.toml1# wardex detector manifest · hash-stable 2[detector] 3name = "c2_beacon" 4version = "1.4.2" 5layer = ["endpoint", "network"] 6 7[model] 8artifact = "./models/c2_beacon.onnx" 9features = "./schemas/c2_beacon.proto" 10 11[drift] 12monitor = "psi" 13threshold = 0.18 14fallback = "ks-test" 15 16[federated] 17aggregator = "secagg.v2" 18dp = { epsilon = 2.0, delta = 1e-5 } 19 20[response] 21policy = "isolate_host_24h" 22gate = "sec_oncall.signed" 23receipt = true 24 25# $ wardex apply detectors/c2_beacon.toml 26# ◆ loaded · hash 7f3a..b201 27# ◆ bound · 2 collectors 28# ◆ drift monitor active
F / MODULES
ls modules//
Nine detector modules in flight. Each is a manifest. Each is benched against held-out attack families.
#namesummarystatus
01
c2.beaconcommand & control
Periodicity + jitter detection on cross-layer flows + endpoint processes.
stable→02
lateral.moveinternal pivots
SMB/SSH/RDP graph walks with entity-bound feature pooling.
stable→03
cred.misuseidentity layer
Token reuse, impossible-travel, role-escalation across cloud + endpoint.
stable→04
exfil.dnscovert channels
Entropy-aware DNS tunneling detector; ε-DP federated retraining.
beta→05
persistence.runasendpoint
Service / scheduled-task / launch-agent anomaly clustering.
stable→06
cloud.iam_driftposture
Role policy drift + over-privileged identity scoring.
beta→07
malware.staticartifact
Static feature ensemble; the topic of the in-flight pre-doctoral work.
beta→08
ransom.shapeendpoint
File-entropy shape + IO burst clustering with playbook gate.
stable→09
insider.accessidentity
Off-hours access scoring with explicit fairness constraints.
draft→G / ROADMAP
git log --quarters/
From eBPF prototype to a pilot-grade XDR.
Q1 · 2025
eBPF collector prototype
correlation graph v0
first rule detectors
Q2 · 2025
cloud + network collectors
onnx detector runtime
TechRxiv submission
Q3 · 2025
federated rounds v1
DP-SGD accounting
drift monitors
Q4 · 2025
orchestrator + policy gate
signed action receipts
first external pilot
Q2 · 2026 — now
malware.static module
cloud.iam_drift v2
analyst workbench beta
Q4 · 2026
multi-tenant fed cohorts
1.0 cut · open-core release
audit replay tooling
H / PAPER
man paper/
Companion preprint.
companion · techrxiv 2025
federated IDS on resource-constrained IoT
Trade-offs and open problems for federated intrusion detection on constrained nodes. The bench in this paper underwrites Wardex's edge profile, and the drift-fold protocol is the one shipped in the federated module.
▸ read on TechRxivCite as — copy the BibTeX block. Indexed on Scholar.
@misc{nguyen2025fedids, title = {Federated Learning-Based Intrusion Detection System for IoT Networks in Resource-Constrained Environments}, author = {Nguyen, Mich\'el}, year = {2025}, doi = {10.36227/techrxiv.176403418.87468767/v1}, url = {https://doi.org/10.36227/techrxiv.176403418}, }
I / FAQ
cat faq.md/
The four questions security teams ask first.
q · 01
how is this different from a SIEM?
A SIEM ingests; Wardex correlates. The detection unit is an entity (process, user, asset) bound across layers — not a stream. SIEMs hand correlation off to humans; Wardex puts it in the graph and ships drift monitors with every detector.
q · 02
does federated learning actually help here?
For rare attack families, yes — sharing gradients across hosts improves recall without pooling sensitive telemetry. For common patterns, signature rules are still better. The paper has the numbers; the module manifest lets you turn either off.
q · 03
can i trust automated response?
Only when the policy gate signs the action. Every response is policy-gated and emits a receipt; nothing destructive runs without a configured signer. Run in advisory mode first — the system is honest about confidence.