Week two: fewer alerts, one incident view
What did the Mini SOC do in its second week on a real network?
In its second week the Mini SOC polled the network 4,878 times and raised 13 alerts, down from 36 the week before. Qwen 3.8-27B assessed 11 of them at a median of 37.2 seconds and escalated four. One change shipped: threat alerts now group into one incident per device on my network, and closing an issue closes only what was on screen. Per-device baselines finish learning on 12 October.
- Measured on
- Mac Studio · Apple M2 Max · 96 GB
- Model
- Qwen 3.8-27B · MLX 8-bit
- Published
13 alerts this week, down from 36 the week before. Same rules, same network, same two-minute poll: 4,878 polls since 3 October, and one failure, on the evening of 4 October, when the network controller’s reply came back as broken JSON. The next poll picked up where it stopped.
Fewer alerts doesn’t prove anything yet. The first week carried the noise of a new monitor meeting an old network: every name change, every look-alike, every login it had never seen before. Most of that is known now. What’s left is closer to the real rate, and that’s the number I’ll watch.
What the week looked like
| Alert kind | Alerts | Severity |
|---|---|---|
| Two devices sharing a name | 4 | medium |
| New device | 4 | medium |
| A device’s name changed | 3 | two low, one medium |
| Admin login from a new address | 1 | medium |
| Security event from the network controller | 1 | high |
Qwen assessed 11, with a median of 37.2 seconds and a slowest of 107.8. That median is slower than last week’s 32.8 seconds, on a third as many alerts, and I don’t know why yet. It called seven likely benign and was unsure about three. It called the one high-severity security event likely malicious, with high confidence, and sent it to me. Four escalations in all. I looked at the security event and closed it.
11 new issues opened. I closed 16, and eight are still open. I saved 16 classifications, every one of them mine, and every one says the alert was right to fire. That makes 35 towards the roughly 300 a first LoRA fine-tuning run needs.
What shipped
One commit, on the afternoon of 3 October, just after last week’s entry went out. Threat alerts from the network controller now group the way an analyst reads an incident. Everything aimed at one of my devices is one issue, and when my device is the source, everything it did is one issue. Threats between two outside addresses aren’t grouped, and neither are rogue access points.
The grouping is loose. Paging stays strict. Inside an incident, a repeat stays quiet only when it has the same source and target, the same IPS category, protocol and ports (random high ports aside), at no higher severity. A new attacker, a new rule, or a rule I haven’t confirmed still notifies on its own.
The second half closes a gap I’d been living with. Closing an issue in the web UI now closes only the occurrences that were on screen when I clicked. Anything that arrived while I was reading stays open as a new issue. The alert that lands while you’re closing the others is the one you most need to see.
What the reviews caught
One commit meant one security review this week. The commit record lists no fixes from it, so there’s nothing to report.
Next
Learning ends on Monday, 12 October. 71 devices have a baseline profile, re-learned every day from the previous 14, and there are zero deviations so far, because nothing gets checked while learning runs. From Monday, deviations get recorded and shown. They never page me and never reach the model, and I mark each one expected or suspicious. That gives me the first false-alarm rate per kind of deviation, and that rate decides whether any of it ever pages me. After that comes the credential that can only read, still waiting from last week.