Sentinel · Thierry Bungaroo

Problem

Commercial network detection and response tools cost six figures a year, or send data abroad. SMEs need detection that is affordable, sovereign and GDPR-friendly.

What I built

I was hired to assist the developer on Sentinel and ended up driving the technical decisions and most of the development. In a team of two developers, I built:

the capture pipeline on the sensors (the tap hardware and casing were the other intern’s work);
the continuous-learning loop: retraining on each client’s own traffic and hot-swapping models without restarting the service;
the database design: PostgreSQL with one schema per client, for tenant isolation;
the live client dashboard;
the product positioning.

How it works

Cheap model on everything, expensive models only on what looks suspicious. The red boxes are the detection cascade.

Sensors. Raspberry Pi network taps at client sites mirror traffic one way over a WireGuard tunnel. Zeek and Filebeat produce the network logs; syslog covers host monitoring.

Detection cascade. Events arrive in Redis. A core process parses and routes Zeek and syslog events, and an Isolation Forest sweeps all of them. Only flagged events go on to a per-client Redis queue, where worker processes run XGBoost (multiclass, pre-trained on UNSW-NB15) and then an autoencoder (7→16→8→4→8→16→7, flagging reconstruction error above mean + 2σ). Normal events go straight to PostgreSQL, and the anomalies the autoencoder confirms are written there too. The cheap model sees everything; the expensive models only see what looks suspicious, which means fewer false positives.

Storage. PostgreSQL is where all the data ends up, with one schema per client for tenant isolation. The dashboard and the analyst model both read from it.

Continuous learning. The Isolation Forest and the autoencoder retrain on each client’s own traffic every two weeks (cron), and the new models are hot-swapped without restarting the service.

Analyst. A local Llama 3–based model, fine-tuned on Zeek reports and served with Ollama, writes plain-language reports for non-technical clients. A priority queue serves reports first and chat second; chat is rate-limited. No third-party AI API is involved.

Dashboard. Clients get a live web interface, with the option to isolate a suspicious machine remotely.

Results

Sentinel is in use. Deployment details and results are confidential to Interface Numérique.

Sentinel is proprietary. This architecture write-up and the dashboard screenshots are published with Interface Numérique’s approval. The screenshots use invented demo data; there is no code and no client data here.

Seen running

Sentinel dashboard, in French, for the invented client "Demo SME": four tiles (184,237 packets processed, 41 anomalies detected, 2 alerts in 24 hours, average threat score 3.12), a 7-day chart of traffic and anomalies, and a live feed of connections. — Dashboard, 7 days, with invented demo data (Demo SME).

The same dashboard switched to the 24-hour view: hourly traffic with a spike of anomalies late in the period, above the live connection feed. All data invented (Demo SME). — Dashboard, 24 hours, with invented demo data (Demo SME).

Anomalies page for the invented client "Demo SME - Annexe" (318 anomalies): cards such as periodic HTTP beaconing, port scan, SSH brute force and RDP attempts, each with a severity colour and score, source and destination, protocol, the model that flagged it (XGBoost, Isolation Forest or autoencoder), a status and a "Generate AI advice" button. — Anomaly cards with invented demo data (Demo SME - Annexe).