HyperMesh CISO Solution Brief

Endpoint Behavioural Anomaly Detection With Temporal Hypergraphs and Liquid State Machines

Audience: CISO, SOC leadership, security architecture, detection engineering
Use case: Zero-shot behavioural anomaly detection from Microsoft Defender for Endpoint telemetry
Core stack: HyperMeshDB + temporal hypergraph features + Liquid State Machine reservoir + One-Class SVM
Primary result: 90.2% precision on the NANXCV validation host while training only on clean baseline activity

---

Executive Summary

Modern endpoint attacks often do not announce themselves as one obvious bad event. They emerge as a gradual shift in how machines, processes, accounts, and network artefacts co-occur over time. Traditional SIEM and EDR rules are excellent for known signatures, but they struggle when each individual action looks legitimate in isolation.

HyperMesh addresses this gap by modelling endpoint telemetry as a temporal hypergraph. Each event becomes a first-class n-way behavioural fact linking the machine, process, account, and IP involved at that moment. A Liquid State Machine then gives the system a short fading memory of recent behaviour, and a One-Class SVM learns the boundary of normal activity from clean baseline data only.

The key operational claim is simple:

HyperMesh can learn what normal endpoint behaviour looks like from Defender telemetry and flag anomalous behaviour windows without training on attack labels.

On the NANXCV validation host, the zero-shot detector achieved:

Metric	Result
Precision	0.902
Recall	0.537
F1	0.673
ROC-AUC	0.744
PR-AUC	0.831
Accuracy	0.720

This means that when the detector fires on this validation run, it is right about 9 times out of 10. That is the most important number for a SOC, because analyst attention is the scarce resource.

This is not positioned as an EDR replacement. It is an additive analyst-priority signal that surfaces behaviourally unusual windows for investigation.

---

The CISO Message

The Problem

Security teams already collect rich endpoint telemetry, but most pipelines still treat it as flat rows. A row may contain a machine, process, account, IP address, timestamp, and action type, yet the detection system often loses the fact that these identities acted together.

Attackers exploit this gap. Living-off-the-land behaviour, lateral movement, staging, command-and-control, and dwell time often appear as changes in patterns of co-occurrence, not as single events that cross a static threshold.

The HyperMesh Approach

HyperMesh turns endpoint telemetry into a temporal hypergraph:

machine + process + account + IP + behaviour category + timestamp

Each event is stored as a hyperedge, preserving the n-way relationship directly. Temporal analytics then summarize behaviour in five-minute windows, and the reservoir model tracks how those windows evolve.

Why It Matters

The model is trained on normal activity only. It does not need examples of every attack technique. This makes it suitable for a zero-shot detection setting where future attacker behaviour may not match yesterday’s signatures.

---

End-to-End Architecture

┌────────────────────┐
│ Microsoft Defender │
│ Endpoint telemetry │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ HyperMesh ingest   │
│ MDE rows → entities│
│ and hyperedges     │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ Temporal hypergraph│
│ machine + process  │
│ account + IP       │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ 5-minute features  │
│ 16-dim vector per  │
│ time window        │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ LSM reservoir      │
│ 500 recurrent      │
│ memory neurons     │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ One-Class SVM      │
│ learns normal only │
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│ Anomaly timeline   │
│ score + evidence   │
│ for SOC triage     │
└────────────────────┘

Repository artefacts:

Layer	Implementation
MDE ingestion	scripts/ingest_mde_baseline.py, scripts/ingest_mde_fleet.py, hypermeshdb/ingest/strategies/mde_baseline.py, hypermeshdb/connectors/mde.py
Temporal features	scripts/temporal_common.py, scripts/temporal_analysis_nanxcv.py, scripts/temporal_analysis_fleet.py
Reservoir and readouts	scripts/snn_train_nanxcv.py
Results	data/snn_results_nanxcv.json, data/snn_results_ciso_fleet.json, data/temporal_nanxcv.json, data/temporal_ciso_fleet.json
Presentation assets	data/HyperMesh_CISO_LSM_Deck.pptx, client/src/pages/SnnDashboard.tsx, design/snn-hypergraph-*deck.html
Methodology	design/methodology_temporal_hypergraph_snn.tex

---

Data Used

The study uses Microsoft Defender for Endpoint timeline exports provided by the LTIMindTree CISO team for February 2026.

Host	Role	Baseline Window	Notes
NANXCV (nanxcv00f89340g)	Primary victim host	Feb 9-13, 2026	Cleanest baseline; 0% simulation traffic; validation host
AZRPREPW (AZRCIPREPWCYMLT)	Windows VM	Feb 7-12, 2026	Cymulate simulation traffic excluded
AZRPREPL (AZRCIPREPLCYMLT)	Linux VM	Feb 6-12, 2026	Cymulate simulation traffic excluded

The attack/exercise slice is NANXCV, Feb 14-20, 2026, stored as SYS_NANXCV.

Two study modes were run:

Phase	Scope	Purpose
Phase 1	Single host, NANXCV	Method validation with the cleanest baseline and clearest behavioural contrast
Phase 2	Three-host fleet	Scale-realism test using a global entity map across machines

Important caveat: the attack window is labelled by the CISO team’s operational calendar, not by per-event kill-chain ground truth. That is sufficient for prototype validation, but a production evaluation needs analyst-confirmed labels.

---

Hypergraph Ingestion

The MDE ingestion strategy converts raw endpoint rows into typed entities and hyperedges.

For each event, HyperMesh resolves:

Entity Type	Source Field
Machine	Computer Name or Machine Id
Process	Initiating Process SHA1, with filename used for display
Account	Initiating Process Account Domain + Initiating Process Account Name
IP	Remote IP, when present
Formation	Mapped from Action Type

Each row becomes one behavioural hyperedge:

e = (event_ts, members, formation, weight)

Where:

Field	Meaning
event_ts	Unix timestamp for the endpoint event
members	Integer entity IDs for machine, process, account, and optional IP
formation	Compact behavioural category
weight	Event count or aggregated event volume

The formation vocabulary is:

PROCESS_EXEC
NETWORK_CONN
FILE_OPS
REGISTRY_OPS
DNS_LOOKUP
HTTP_TRAFFIC
IPC_PIPE
MODULE_LOAD
LOGON
SCRIPT_EXEC
GENERIC

Why this matters: a normal graph would split one 4-way behaviour into multiple pairwise edges. A hypergraph preserves the complete behavioural fact as one object.

---

Ingestion Magnitudes

Measure	NANXCV Phase 1	Fleet Phase 2
Baseline hyperedges	14,034	-
Attack hyperedges	13,341	-
Total hyperedges	-	39,016
Approx. raw rows after Cymulate exclusion	-	374,000
Unique baseline entities	1,775	2,993
Novel entities in attack	53	815

The fleet run uses a global, deduplicated entity map so shared IPs, accounts, and file hashes resolve to the same node across hosts.

---

Temporal Features

HyperMesh partitions the telemetry into contiguous five-minute windows. Each window becomes a 16-dimensional feature vector.

Aggregate Features

Feature	Description
hedge_count	Number of hyperedges in the window
entity_count	Number of distinct active entities
novelty_rate	Fraction of entities not seen in baseline
mean_members	Average hyperedge cardinality
formation_entropy	Behavioural diversity across formation types

Formation Histogram

The remaining 11 channels are raw counts for each formation category.

Measure	NANXCV Phase 1	Fleet Phase 2
Total windows	952	1,614
Baseline windows	457	1,119
Attack windows	495	495
Windows scored after washout	922	1,584

An important interpretability signal came from formation_entropy: volumetric features generated many noisy changepoints, but entropy produced only a small number of statistically meaningful shifts. The sharpest was Feb 17, 09:15 UTC, where entropy collapsed to 0.65 from a running mean near 2.34, indicating concentration into a narrower behavioural mix dominated by network and process execution activity.

---

Baseline-Only Normalisation

The model is deliberately normalised using baseline windows only.

u_tj = (X_tj - mean_j_baseline) / std_j_baseline

This mimics production deployment. In a real environment, the model would learn from an assumed-normal historical period and then score future activity. No future attack distribution is used to scale the features.

---

Liquid State Machine Reservoir

The reservoir is a fixed recurrent neural system that gives each five-minute window a fading memory of recent activity.

x(t) = (1 - α) x(t-1) + α tanh(W x(t-1) + W_in u(t) + ε_t)

Parameter	Value	Meaning
n_reservoir	500	Number of reservoir neurons
spectral_radius	0.95	Keeps the reservoir stable and fading
leak_rate	0.30	Controls memory decay
sparsity	0.10	Sparse recurrent connectivity
input_scaling	0.30	Input projection scale
washout	30	Initial windows discarded before scoring
seed	7	Reproducibility

The recurrent weights are fixed. There is no deep backpropagation. Only the readout is trained. This is important for security telemetry because the number of labelled attack windows is usually small and overfitting risk is high.

---

Detection Models

Production Mode: One-Class SVM

The deployable detector is a One-Class SVM trained only on baseline reservoir states.

OneClassSVM(kernel="rbf", gamma="scale", nu=0.05)
anomaly_score = -decision_function(state)

nu = 0.05 sets an approximate baseline false-alarm budget of 5%. In the NANXCV run, the observed baseline alarm rate was 29 / 427 = 6.8%, close to the intended operating point.

Diagnostic Mode: Logistic Regression

A logistic readout was also tested on the same reservoir states. It uses labels and is therefore not a production simulation. It is included only to assess whether separability exists in the reservoir representation.

The key message: operational claims should use the One-Class SVM results, not the supervised diagnostic readout.

---

Results

Phase 1: NANXCV Validation Host

One-Class SVM, trained only on clean baseline windows:

Metric	Value
Precision	0.902
Recall	0.537
F1	0.673
ROC-AUC	0.744
PR-AUC	0.831
Accuracy	0.720

Confusion matrix:

	Predicted Normal	Predicted Anomalous
Actual Baseline	398	29
Actual Attack	229	266

Interpretation:

• The detector is highly precise: when it fires, it is usually meaningful.
• Recall is moderate: some attack windows, especially dwell-like behaviour, remain inside the normal boundary.
• Attack windows sit 13.6% farther from the baseline reservoir centroid than baseline windows, confirming a measurable state-space drift.

Headline:

When HyperMesh fires on the NANXCV validation host, it is right 90% of the time, without training on attack labels.

Phase 2: Three-Host Fleet

Metric	One-Class SVM	Logistic Diagnostic
Precision	0.731	0.561
Recall	0.329	0.980
F1	0.454	0.713
ROC-AUC	0.713	0.908
PR-AUC	0.613	0.809

Interpretation:

• The zero-shot fleet model remains precision-oriented but recall drops.
• Pooling heterogeneous hosts widens the normal envelope.
• The supervised diagnostic AUC of 0.908 shows the signal exists, but the zero-shot boundary needs per-host or per-segment baselines to recover recall.

This is a roadmap item, not a hidden flaw.

---

What Analysts Would See

Each anomaly window can be surfaced with:

Evidence	Why It Helps
Timestamp	Places the alert on the incident timeline
Anomaly score	Prioritises the analyst queue
Dominant formations	Shows whether the window is network-heavy, process-heavy, etc.
Novel entity count	Highlights new accounts, processes, hashes, or IPs
Contributing hyperedges	Links back to raw Defender evidence
Reservoir drift	Quantifies departure from baseline behaviour

This makes the model investigable rather than a black-box score.

---

Honest Limitations

These should be stated explicitly in any CISO presentation.

1. Recall is not yet high enough to replace existing controls. The NANXCV result is precision-first and should be used as an analyst-priority signal layered on top of EDR.
2. The attack label is calendar-based. The Feb 14-20 window was designated by the CISO team, but per-event kill-chain labels are not yet available.
3. No MITRE technique attribution is claimed. The system flags behaviourally anomalous windows; analysts determine root cause.
4. No commercial EDR or UEBA head-to-head benchmark has been run yet.
5. Fleet modelling needs per-host or per-segment boundaries. Pooled baselines are too broad for best zero-shot recall.
6. The logistic model is diagnostic only. It uses labels and should not be presented as deployable performance.
7. Validation is single-tenant. Broader generalisation requires additional environments.

---

Roadmap

Priority	Workstream	Outcome
1	Per-host and per-segment baselines	Higher recall without sacrificing precision
2	Adaptive operating point	Tune alert budget to SOC capacity
3	Richer temporal features	Capture dwell, inter-arrival timing, and formation sequences
4	Explainability UI	Per-alert “why” view in SnnDashboard
5	EDR / UEBA benchmark	Credible side-by-side comparison on the same telemetry
6	Shadow-mode pilot	Analyst-validated precision, recall, and time-to-detect

---

Recommended Pilot Ask

To move from prototype to operational validation, ask the CISO team for:

1. Ground truth for Feb 14-20. Analyst-confirmed true positives, timestamps, and known activity phases.
2. A four-to-six-week shadow-mode pilot. HyperMesh runs alongside the existing stack; analysts validate alarms.
3. A same-data benchmark against the current EDR or UEBA. Agree the scoreboard before the pilot begins.
4. A longer clean baseline. Weeks or months of normal Defender telemetry across a representative host mix.
5. A live telemetry path. Defender API, Sentinel, Event Hub, or batch export cadence.
6. A target alert destination. SIEM, SOAR, ticketing, or dashboard.

The pilot success criteria should be agreed up front:

Criterion	Example Target
Precision	Analyst-validated precision above agreed SOC threshold
Alert volume	Within analyst capacity per day
Time-to-detect	Earlier or complementary detection versus current stack
Explainability	Analyst can trace each alert back to contributing events
Deployment fit	Runs within the customer’s governance and data residency constraints

---

Anticipated CISO Questions

Question	Answer
How is this different from our EDR?	EDR detects known signatures and rule conditions. HyperMesh detects deviations from a host’s own behavioural baseline. It is additive, not a replacement.
Did the model train on the attack?	No. The production One-Class SVM trains only on baseline windows. The supervised logistic readout is diagnostic only.
Why should we care if recall is around 54%?	Because the signal is highly precise. It gives analysts a high-quality priority queue on top of existing controls. Recall improvement is the next engineering target.
What about false positives?	The operating point is tunable. In the NANXCV run, the baseline alarm rate was 6.8%, close to the intended 5% budget.
Does it scale to the fleet?	Yes, but pooled baselines reduce zero-shot recall. The next step is per-host or per-segment baselines.
Can analysts act on it?	Yes. Each alert can carry score, timestamp, dominant formations, novel entities, and contributing hyperedges.
What is needed for production confidence?	Ground truth, a shadow-mode pilot, and a head-to-head benchmark against the current stack.

---

Reproducibility

# 1. Ingest baseline and attack hyperedge tables
.venv/bin/python scripts/ingest_mde_baseline.py
.venv/bin/python scripts/ingest_mde_fleet.py

# 2. Build five-minute temporal features
.venv/bin/python scripts/temporal_analysis_nanxcv.py
.venv/bin/python scripts/temporal_analysis_fleet.py

# 3. Train LSM reservoir and readouts
.venv/bin/python scripts/snn_train_nanxcv.py \
  --input data/temporal_nanxcv.json \
  --output data/snn_results_nanxcv.json

.venv/bin/python scripts/snn_train_nanxcv.py \
  --input data/temporal_ciso_fleet.json \
  --output data/snn_results_ciso_fleet.json

Default model settings:

n_reservoir=500
sparsity=0.10
spectral_radius=0.95
input_scaling=0.30
leak_rate=0.30
washout=30
seed=7

---

Glossary

Term	Meaning
Hyperedge	A relationship linking more than two entities at once, such as machine + process + account + IP
Formation	Behaviour category such as NETWORK_CONN or PROCESS_EXEC
Temporal hypergraph	A hypergraph where each hyperedge has a timestamp
Liquid State Machine	A recurrent reservoir that gives the model fading memory of recent behaviour
Echo-state property	Stability condition ensuring the reservoir memory fades instead of exploding
One-Class SVM	A model that learns normal behaviour only and flags points outside that normal boundary
Zero-shot detection	Detecting attacks without training on examples of those attacks
Washout	Initial windows discarded while the reservoir state stabilises

---

Source Artefacts

All quantitative claims are reproduced from repository artefacts:

• data/snn_results_nanxcv.json
• data/snn_results_ciso_fleet.json
• data/temporal_nanxcv.json
• data/temporal_ciso_fleet.json
• scripts/snn_train_nanxcv.py