← Mini SOC Mini SOC · Build log

Week one: from alerts to issues

What did the Mini SOC learn in its first full week on a real network?

Short answer

In its first full week the Mini SOC raised 36 alerts and no attacks. Qwen 3.8-27B assessed 29 of them at a median of 32.8 seconds and escalated 18 because it was unsure. Most of the week went into giving each alert more evidence: where a device is connected, what traffic it sends, where an admin login came from, and the blocked flow behind a security event. The security reviews caught a way to silence a fake copy of my Wi-Fi network.

Measured on
Mac Studio · Apple M2 Max · 96 GB
Model
Qwen 3.8-27B · MLX 8-bit
Published
The code on GitHub

5,318 polls since 26 September, and three of them failed. One came back as broken JSON. Two were server errors from the network controller itself, on the nights of 29 and 30 September. The next poll, two minutes later, picked up where the failed one stopped.

The bigger outage was mine. On the afternoon of 27 September the model server was down for 83 polls in a row, close to three hours. The rules kept raising alerts, the alerts waited, and Qwen assessed them once it was back. Nothing was lost. Nothing was assessed on time either.

What the week looked like

Alert kindAlertsSeverity
Admin login from a new address9medium
Security event from the network controller9medium
Two devices sharing a name8medium
A device’s name changed9six low, three medium
New device1medium

36 alerts in all. Qwen assessed 29, with a median of 32.8 seconds and a slowest of 116.6. It called eleven likely benign and was unsure about the other 18, so those came to me. I closed 16 issues and saved 19 classifications, every one of them mine. A first LoRA fine-tuning run needs about 300. That is months away at this rate, and the rate is the honest number.

What shipped

The change I use most: alerts about the same device now group into one issue, with an occurrence count. Two phones that keep trading names are one row with a count. Grouping goes by the exact set of devices, so an alert naming two devices never pulls in either device’s other alerts. A device that copies my laptop’s name can’t hide the laptop’s alerts under an issue I’d close as fine.

The rest of the week went into evidence. Every alert page now shows where the device is connected (switch or access point, port, speed). An inventory lists every device the network has ever reported. The watcher reads the gateway’s flow log every 15 minutes and keeps capped daily totals per device, and from those it recommends a network segment for each device. Admin logins show where the address is, looked up in a local copy of the DB-IP Lite database, so no address leaves the Mac. Since 2 October a blocked security event shows the flow behind it: source, destination, the rule that fired, and anything that doesn’t add up, such as a source address on none of my networks.

On 28 September I wrote down what this is for: “automate as much of home and small-business security and connectivity management as can be shown to be safe.” Each device now learns a baseline for 14 days, then runs in shadow mode, where deviations are listed but never page me and never reach the model. 67 devices have profiles. Zero deviations so far, because learning runs until 12 October.

What the reviews caught

Every commit goes through a security review first. This week the reviews earned their keep.

The worst finding sat in a feature I’d built for convenience. In a crowded building, a foreign Wi-Fi network with an ordinary name gets lowered to low, which keeps neighbours’ networks from paging me. The review found that a nearby attacker could get a look-alike of my own network’s name lowered the same way: a typo plus a suffix, a word-order swap, or symbols glued in. Lowered to low means silenced. Five review rounds later, anything that resembles my network is never lowered, and the fix was checked against the old code on 1.06 million generated look-alikes.

Two more. The segmentation recommender could have placed a device in the trusted infrastructure segment because of a name the device chose for itself; a device’s own name can now only lower its trust. And the rogue access point card no longer says “probably yours.” A radio address is broadcast, and any radio can claim one.

Correction

On 26 September I wrote that the Wi-Fi impersonation warning was “almost certainly my own access point.” It wasn’t one of my access point’s configured radio addresses. What it is, I don’t know yet. It could be the access point’s own mesh or setup radio, or a forgery, and I haven’t had time to look at the code, the model output, or the access point itself. I’ve updated that entry.

Next

Shadow mode starts on 12 October, and with it the first false-alarm rate per kind of deviation. Then the credential that can only read, which replaces the owner-level key the monitor runs on today behind a read-only allowlist. Until that lands, read-only is a promise my code keeps. The controller doesn’t enforce it.