The control plane is in place.
- Statistical alerts and saved baselines
- Device trust and incident review
- Command acknowledgments and retries
- Reconnect handling and provider fixture tests
Network detection & response
Know the normal.
Notice the unusual.
Every device has a routine. CIPHER learns it, makes unusual activity understandable, and puts the response in your hands.
A student-built prototype for small networks.
A small office. A change worth noticing.Illustration
A pattern breaks.
Monitor
Two signals change. An alert is raised; the device stays connected in monitor mode.
Explore a scenario
A project by The Four Horsemen
Zakaria Alqarra · Belal Hamdan
Raneem Abdullah · Ayham Idais
Contributor: Omar Eid
IEEE BAU Computer Society
01 / THE IDEA
An allowed connection
can still tell an
unusual story.
A laptop starts trying unfamiliar ports. A quiet device suddenly sends more data. What changed—and is it worth investigating?
An existing firewall decides which traffic is allowed. CIPHER adds a device’s behavioral context, brings the evidence together, and helps an operator choose a response.
Unusual is a signal, not a verdict.
A legitimate administrator’s scan can look unusual too.
02 / ARCHITECTUREFrom a packet to a decision
Small observations.
A connected system.
A packet is a small unit of network traffic. Follow its metadata from the Linux router to the person making the decision.
- 01
Observe
Small eBPF programs observe and filter packets at the router’s XDP receive hook.
LINUX · eBPF / XDP - 02
Summarize
The Rust sensor turns collected events into compact summaries of device activity.
RUST · FLATBUFFERS - 03
Understand
Statistics flag changes. An optional AI reviewer explains the evidence and advises.
AXUM · SQLITE · AI REVIEW - 04
Respond
The dashboard brings incidents, device trust, and response controls to the operator.
REVIEW · TRUST · RESTORE
Reports travel over a TLS WebSocket. Commands return to the sensor, which acknowledges their application.
The engineering underneath
eBPF runs small, verified programs in the Linux kernel, the core of the operating system. XDP is the receive hook used here; the current loader uses generic/SKB mode. The kernel emits events through a ring buffer. The Rust daemon aggregates metadata, with HyperLogLog used to estimate distinct addresses.
Reports use FlatBuffers, a compact binary format, over a TLS WebSocket. The control plane uses Rust, Axum and SQLite. Baselines, device trust and local blocks persist. A durable outbox, acknowledgments and retries help the sensor recover after disconnects.
The outbox retains up to 10,000 reports. Successful retries are deduplicated, but a crash between ingestion and receipt storage can still create duplicates. Reports older than 60 seconds are stored without driving current cloud isolation decisions. Telemetry retention is 24 hours.
03 / DETECTION
Normal is different
for every device.
A camera and a laptop should not share the same expectations. CIPHER builds a baseline for each device, then compares new reports with its usual level and variation.
50reports
The starting point for a device’s baseline.
Representative activity matters.
These are sampled observations, not complete connection counts or exact throughput. Traffic direction still needs validation on a real gateway.
THE FOUR SIGNALSPer-device observations
01 Incoming bytes
Incoming payload observed
02 Outgoing bytes
Outgoing payload observed
03 Dropped events
Reported packet events blocked
04 Port entropy
How varied the use of ports is
A deviation score above 3 can raise an alert.Charts are illustrative.
Show the scoring rule and a worked example
The score measures distance from the average, divided by a scale that accounts for normal variation:
score = abs(observed − mean) / scale
scale = max(standard deviation, floor, abs(mean) × 0.1)The minimum scales are 4,096 bytes for each byte signal, 5 for dropped events and 0.25 for port entropy. These floors stop a tiny change after constant traffic from producing an enormous score.
Illustrative example: a baseline of 10 KiB, a new observation of 34 KiB and a scale of 4 KiB produce a score of 24 ÷ 4 = 6. That exceeds the threshold of 3. It does not tell us why the change happened.
The baseline stays fixed until reset; the training reports should represent ordinary activity. The default alert/review cooldown is 120 seconds. Thresholds and detection accuracy still need evaluation against real traffic.
04 / RESPONSEDesigned around operator control
Default: monitor + alertAI can advise.
AI can advise.
Policy decides.
Statistics raise the flag. The model reviews the evidence. For cloud-reviewed automatic isolation, every condition must hold.
You can review incidents, mark false positives, trust devices, and manually isolate or restore them.
- 01
Permission to act
Automatic response is enabled, and the device is not trusted.
- 02
Corroborating evidence
At least two statistical signals are abnormal.
- 03
A valid review
The reviewer recommends blocking with a score of at least 85/100.
- 04
A decision that is still current
The incident remains open, and the policy revision has not changed.
A score is not a certainty.
The model’s score is its own assessment, not measured accuracy. A failed review cannot authorize this cloud response; statistical alerts remain available.
Separate router protections and privacy boundaries
The router also has local heuristics, including flagged-event volume and TCP reset/SYN ratios. Their automatic device isolation respects enforcement mode and trust, but does not require an AI review. Existing protocol, IP and DNS packet filters are separate: monitor mode does not disable them or remove existing blocks.
CIPHER does not decrypt HTTPS or send message bodies to the reviewer. The kernel does parse headers and selected DNS fields for filtering. Report metadata can include device identifiers; it should not be treated as anonymous.
Provider adapters support Anthropic and OpenAI-compatible endpoints. The default offline demo uses a labeled scripted reviewer. A real provider or local model requires separate configuration and connection testing.
05 / THE DEMO01:26 · recorded walkthrough
From “something changed”
to “here’s the evidence.”
Meet the actual software. Follow an incident from its measurements to the operator’s next step.
- 01Notice the change
A simulated scan changes the device’s pattern.
- 02Read the evidence
The incident shows what deviated and why.
- 03Choose a response
Review, trust, or request device isolation.
Read the demonstration walkthrough
Start with normal activity. The dashboard shows a device and its learned baseline. The default response mode is monitoring.
Introduce unusual traffic. A simulated scan changes several measurements. An incident shows the evidence and a plain-language explanation. In monitor mode, the device stays connected.
Enable automatic response. Repeat the scenario. The server requests isolation when the gate passes; the dashboard waits for the simulated sensor’s acknowledgment.
Trust and recovery. Trusting the device preserves alerts and exempts it from automatic isolation. A reviewer failure leaves statistical alerts available without authorizing a cloud block. Reset prepares the next demonstration.
For the full presenter-led sequence, run python3 scripts/booth.py tour after starting the demo. See the demo guide.
06 / PROJECT STATUS
Working software.
Clear next steps.
This is a prototype with a repeatable software demonstration. Its security outcomes still need to be measured.
Prove it on a real gateway.
- Actual XDP packet blocking and traffic attribution
- Missed attacks, false alarms, and model value
- Performance, recovery, and live model setup
- Per-sensor credentials and stronger device identity
A sensor map acknowledgment alone does not prove packet blocking. Detection accuracy and performance have not been established. Read the readiness audit
07 / EXPLORE FURTHER
Take a closer look.
Start with the overview. Trace one report through the code. Or bring the technical sheet to the next conversation.
THE PRESENTATION
The full story, in ten slides.
A student introduction with diagrams and technical speaker notes.
THE TECHNICAL SHEET
THE SOURCE
Presenting CIPHER? Open the presenter notes