DEV Community: Bryant

The Foundation: The Open-Source Stack Behind a Home SOC

Bryant — Sun, 27 Sep 2026 12:50:36 +0000

Part 1 of a series on building an enterprise-grade Security Operations Center at home. Start with Part 0 if you haven't.

In Part 0 I made a claim: you can build a real, operating Security Operations Center on a home network, and the architecture is what matters — not expensive hardware. This post is where we lay the foundation everything else stands on: the sensors, the data layer, and the network design that makes detection possible in the first place.

I'm going to do something most build guides skip. I'll show you what to set up — but I'll spend just as much time on why each piece exists and what job it does. A SOC isn't a pile of tools; it's a division of labor. If you understand the division, you can adapt the whole thing to your own network. If you just copy the steps, you'll get stuck the first time your setup differs from mine.

The stack, and the job each tool does
A common mistake is thinking one tool "is" your SOC. It isn't. Each of these does a specific job, and they overlap on purpose — defense in depth means multiple sensors seeing the same network from different angles.

Suricata — the signature-based IDS. Suricata inspects network traffic and fires alerts when it matches known-bad patterns (a malware signature, an exploit attempt, traffic to a blocklisted IP). Think of it as the sensor that knows what specific threats look like. It's loud, it's fast, and — fair warning — on a normal network it's very noisy. (More on that shortly.)

Zeek — the network's flight recorder. Where Suricata asks "does this match a known threat?", Zeek asks "what actually happened on the network?" It logs every connection, DNS query, TLS handshake, and HTTP request as structured data — not alerts, but a rich record of behavior. This is the single most valuable data source for the interesting detection work later in this series (spotting command-and-control beacons, for example, is only possible because Zeek recorded the timing of every connection). Most home setups skip Zeek. Don't.

Wazuh — the endpoint agent and vulnerability scanner. Suricata and Zeek watch the network. Wazuh watches the hosts. Agents on your machines report file changes, log events, security misconfigurations, and — critically for a later post — the vulnerabilities present on each system. This is your host-based intrusion detection and your patch intelligence in one.

ntopng — traffic visibility and flow analysis. ntopng gives you a live, human-readable view of who is talking to whom and how much — top talkers, protocols, bandwidth, active flows. Where Zeek's logs are for machines to analyze, ntopng is for a human to glance at and understand the shape of their network's traffic at a moment's notice.

Elasticsearch — the SIEM data layer. All of the above produce data. Elasticsearch is where it lands, gets indexed, and becomes queryable. When you search "show me every connection from this IP in the last 24 hours" or "which hosts have critical vulnerabilities," you're querying Elasticsearch. It's the memory and the search engine of the whole SOC. (Alongside it, tools like Kibana give you dashboards over that data.)

(I run a few additional tools beyond these — but this is the core five, and it's more than enough to build a genuinely capable SOC. Start here.)

The one-sentence version: Suricata says "that looks malicious," Zeek says "here's exactly what happened," Wazuh says "here's the state of your hosts," ntopng says "here's your traffic at a glance," and Elasticsearch remembers all of it so you can ask questions later.

The platform: what to run it on
I run this on Proxmox, a free, open-source virtualization platform — it lets me run each component as its own VM or container on dedicated hardware, which is closer to how you'd architect this in a real environment. That's the "enterprise-grade" version.

You don't need Proxmox to start. If you're following along on a laptop or a single desktop, VirtualBox works fine — it's how a lot of people (including me, early on) first stood up a lab. The tools are identical; only the host platform differs. Start with what you have. You can always migrate to Proxmox later when you want the components running 24/7 on their own box.

Whichever you choose, the mental model is the same: each sensor and the data layer runs in its own isolated environment, and they all feed into Elasticsearch.

Network design: why you segment
Here's a why that most guides gloss over, and it's important.

I don't run my devices on one flat network. Traffic is separated into VLANs by role — a segment for main/trusted devices, one for kids' devices, one for gaming, one for IoT (smart plugs, cameras, and the like). This isn't for neatness. It's a security design decision, and it does two things:

It limits blast radius. If a cheap IoT camera gets compromised, segmentation keeps it from
freely reaching your important machines. The compromise stays contained to its segment instead of becoming a foothold into everything.

It makes detection dramatically clearer. When traffic is segmented, "a device on the IoT
network is talking to a device on the main network" becomes a meaningful, suspicious event worth investigating — because it shouldn't normally happen. On a flat network, that signal is invisible; everything talks to everything, so nothing stands out. Segmentation turns network topology itself into a detection tool. (We lean on this heavily in Part 2.)

You don't need enterprise switches for this. A capable home router/firewall — pfSense, OPNsense, or a prosumer platform like UniFi — can create VLANs and route between them with rules. The principle matters more than the brand: separate by role, and make crossing between segments something you can see.

Feeding the sensors: the SPAN/mirror concept
One more foundational piece: your network sensors (Suricata, Zeek) can only analyze traffic they can see. On a switched network, a device normally only sees traffic addressed to it — which is useless for a sensor that needs to watch everything.

The fix is a SPAN port (also called port mirroring): you configure your switch or firewall to copy all traffic to a monitoring port, and you point your sensors at that. Now Suricata and Zeek see the full picture. In a virtualized setup, the equivalent is putting the sensor's interface in promiscuous mode on a bridge that carries the traffic you want to watch.

This is the plumbing that makes network detection possible at all. If your sensors "aren't seeing anything," this is almost always why — check the mirror first.

Putting it together
At the end of this foundation, here's what you have:

A segmented network (VLANs by role) with traffic mirrored to your sensors.
Suricata and Zeek watching the network from a SPAN/mirror.
Wazuh agents on your hosts.
ntopng for at-a-glance traffic visibility.
Everything shipping into Elasticsearch, queryable and dashboarded.
That's a legitimate detection foundation — the same building blocks a commercial SOC uses, running on your own network.

But here's the honest catch, and it's the thread that pulls this whole series forward: a foundation that just generates alerts isn't a SOC — it's a firehose. The first time you look at the raw output, you won't see threats. You'll see tens of thousands of alerts a day, the overwhelming majority of them noise. Learning that the hard way is what led me to build everything in the rest of this series.

In Part 2, we confront that firehose directly: the signal-to-noise problem, and the tiered-triage approach that turns an unusable flood of alerts into a system that tells you only what matters.

Next up: [Drowning in Alerts — The Signal-to-Noise Problem].

I'm Bryant, founder of ByTE X Bit Technologies LLC, a Maryland-based cybersecurity company. This series walks through the detection, triage, and remediation systems I build and operate. If your organization needs help with security monitoring or detection engineering, get in touch.

Drowning in Alerts: The Signal-to-Noise Problem

Bryant — Sun, 27 Sep 2026 12:44:30 +0000

Part 2 of a series on building an enterprise-grade Security Operations Center at home. Start from Part 0.

At the end of Part 1, we had a real detection foundation: Suricata and Zeek watching a segmented network, Wazuh on the hosts, everything flowing into Elasticsearch. By every checklist, that's a SOC.

Then I looked at the output.

131,000 events a day
That's roughly what my sensors generate on a normal day. Not a busy day. Not an under-attack day. A Tuesday.

If you've stood up your own detection stack, you know the feeling. You open the dashboard expecting to hunt threats, and instead you're staring at a wall of alerts scrolling faster than you can read. Suricata is flagging things constantly. Every one has a severity. Every one looks like it might matter. And you slowly realize you have no idea which — if any — actually do.

This is the moment most home SOCs die. Not because the tools failed — they're working perfectly. They die because raw detection output is unusable by a human, and without a way to cut through it, the dashboard becomes noise you eventually stop opening.

Here's the number that reframed the whole problem for me: on a representative sample, roughly 99.8% of my alerts were noise. Not "low priority." Noise. Protocol decoder quirks, benign network housekeeping, retransmitted packets, an IoT device doing exactly what IoT devices do. The actual security signal was a tiny fraction of a percent, buried under a mountain of stuff that fires an alert but means nothing.

A SOC that surfaces 131,000 events and leaves you to find the 20 that matter isn't a SOC. It's a firehose with a search bar.

Why detection tools are so noisy (and why that's not a bug)
It's worth understanding why this happens, because it shapes the fix.

Signature-based tools like Suricata are built to be sensitive. Their job is to fire when they see something that could be bad — and "could be bad" is an enormous category. A malformed packet could be an attack, or it could be a flaky network card. A connection to an unusual port could be C2, or it could be a game launcher. The tool can't know your context, so it errs toward telling you everything and letting you decide.

The problem is that "letting you decide" doesn't scale to 131,000 decisions a day.

Commercial SOCs solve this with two things: layers of tuning (analysts spend months suppressing false positives) and teams of people (someone is always watching). At home, you have neither. You can't hire an overnight shift, and hand-tuning 131,000 events a day is a full-time job you don't have.

So the question that drove the rest of this series became: how do you automatically separate the 0.2% that matters from the 99.8% that doesn't — without a team, and without babysitting a dashboard?

The wrong answer: more filtering rules
The obvious first instinct is to write filters. "Suppress this signature. Ignore that source. Mute those events." And you should do some of that — a baseline of suppression for known-junk signatures is worth it.

But filtering alone hits a wall fast, for a simple reason: whether something matters usually depends on context that a single filter can't see. The same signature can be noise in one situation and a real threat in another. An external IP hitting a random high port is background internet noise. That same external IP hitting your SIEM server on its database port is worth waking up for. A blunt filter either suppresses both (and misses the real one) or alerts on both (and you're back in the firehose).

You don't need more filters. You need judgment — a way to weigh each finding against context.

Tiered triage funnel: 131k events down to the few that matter

The idea: triage in tiers
Human SOC analysts don't treat every alert equally. They triage — they sort findings into buckets by how much attention each deserves. That's the model I built toward, automated:

Auto-dismiss — the overwhelming majority. Known-benign signatures, normal internal chatter,
background internet noise hitting the edge. Logged for the record, never shown. This is where the 99.8% gets handled automatically, so it never reaches you.

Review — the "worth a glance, not an emergency" middle. Filed to a queue you check when you feel
like it. Nothing here pages you.

Elevate — the rare genuine concern. This is the bucket that's allowed to interrupt you — a
real-time alert, because something is actually worth your attention now.

The entire goal: you should be hands-off unless something is genuinely wrong. No dashboard-staring. No scrolling. If the system is quiet, you can trust that quiet — and if it pings you, it's because it earned the interruption.

What decides the tier? Context — starting with topology
If tiering is the what, the harder question is the how: what actually decides which bucket a finding lands in?

The first and most powerful input — and this is where Part 1's network segmentation pays off — is topology. Where is the traffic going, relative to where it came from?

Consider three findings with the exact same signature:

A device on your IoT segment talks to another device on the IoT segment. Internal, expected,
low-stakes. → Auto-dismiss.

An external IP on the internet hits a device on your network from outside. Worth noting — it's the
first stage of a lot of attacks — but the firewall's already dropping most of it. → Review.

An external IP reaches in and touches one of your crown-jewel systems — your SIEM, your domain
controller, your critical infrastructure. → Elevate. Now.

Same signature. Three completely different verdicts — because topology changes what the finding means. This is why we segmented the network in Part 1: it turns the direction of traffic into a first-class detection signal. On a flat network, all three of those look identical. On a segmented one, the difference is obvious — and automatable.

Topology is the foundation of the triage logic, but it's not the whole story. Real judgment also has to account for which asset is involved (traffic toward your domain controller matters more than traffic toward a smart bulb), what the signature actually is (a known-noise decoder event vs. a real malware indicator), and behavioral patterns over time (is this a one-off, or is a device quietly beaconing to the same external address every five minutes?).

Encoding all of that — reliably, automatically, at 131,000-events-a-day scale — is exactly what the rest of this series is about.

Where this goes next
We now have the problem stated plainly: a foundation that generates alerts isn't enough; the value is in automatically deciding which alerts deserve a human. And we have the shape of the solution: tiered triage driven by context — topology, asset value, signature meaning, and behavior.

In Part 3, we build the brain that does it: a custom triage engine that combines deterministic security logic with a locally-run AI model — and, crucially, why I made it deterministic-first rather than just handing every alert to an AI and hoping. That decision is the difference between a system you can trust and one that confidently tells you the wrong thing.

Next up: [Building an AI SOC Analyst From Scratch].

Why I Built a Real SOC in My Basement

Bryant — Sun, 06 Sep 2026 01:38:45 +0000

https://byte-x-bit.com/blog/why-i-built-a-real-soc.html

Part 0 of a series on building an enterprise-grade Security Operations Center at home — from
open-source foundations and custom tooling.

Most "home lab" security projects end the same way: you install Security Onion, watch the dashboard
light up with alerts for a week, feel like you've built something real, and then never look at it
again. The alerts pile up. The noise buries the signal. Nothing gets tuned. Eventually the VM gets
powered off to reclaim the RAM.

I wanted the opposite of that. I wanted a Security Operations Center that actually operates — one
that runs 24/7, triages its own alerts, tells me only when something matters, and keeps working when
I'm not looking at it. In other words, I wanted to build the thing enterprises pay six figures a year
for, on a home network, and understand every layer well enough to have built it myself.

This series is how I did it.

This isn't just a tutorial lab

I want to be precise about the claim, because a home SOC can be a lot of things. What I built is
different from a follow-the-steps install in a few specific ways:

It runs continuously and monitors itself. A SOC that silently dies is worse than no SOC, because it gives you false confidence. Mine has a dead-man's-switch that alerts me if the monitoring itself stops. (More on that later — and yes, it's caught real outages.)
It triages in tiers, not floods. Raw intrusion-detection output on a normal home network is ~99% noise. The system automatically dismisses the noise, files the "worth-a-glance" items for later, and pings me in real time only for the genuinely serious. I'm hands-off unless something is actually wrong.
It has an AI analyst I wrote from scratch — not a wrapper around a cloud API, but a custom triage engine combining deterministic security logic with a locally-run language model. The SOC's data never leaves my network. (This is the part I'm most proud of, and it gets its own posts.)
It closes the loop to remediation — not just "here are 5,000 vulnerabilities," but "here are the three things actively being exploited in the wild that you should patch first."

This isn't just a lab — it's a purpose-built architecture. And the point of this series is to get
security engineers, security architects, and home-SOC builders thinking outside the box: to build
better defenses, contribute to a stronger security community, and raise the bar for what a
self-built system can do. My hardware for this setup is admittedly a bit overkill — but the series
is scaled down so you can do a real version of this at home.

The 30,000-foot view

Here's the whole system in one diagram:

Every arrow in that diagram is a design decision, and over the next several posts I'll walk through
each one: why Zeek and Suricata, why the AI layer is deterministic-first, how beacon detection
actually works, why remediation should be ranked by real-world exploitation instead of raw severity
scores, and how the system watches itself.

"But I don't have a data center in my basement"

Neither do most people, and you don't need one. My setup is robust — multiple virtualization hosts,
dedicated GPUs, a segmented network with a pentest range bolted on — because I also use it for other
work. That's overkill for getting started, and I don't want my hardware to gatekeep the idea.

The architecture scales down. The concepts in this series — tiered triage, topology-aware
detection, risk-based remediation — work on a single mini-PC with 16GB of RAM. Later in the series
I'll lay out three honest tiers: the "single box, start here" floor, the "comfortable home SOC"
sweet spot (a used GPU changes everything for the AI layer), and my full reference build. Hardware
is a dial, not a gate.

If you've followed one of the excellent home-lab build series out there — the kind that walk you
through standing up a virtual network, a firewall, a range, and a SIEM — this series picks up where
those leave off. Those teach you to build the lab. This one is about making it operate: turning a
pile of security tools into a system that triages itself and only bothers you when it matters.

Why bother?

Three reasons, and they're probably yours too if you're reading this:

You learn a field by building its systems, not by reading about them. Standing up detection, watching it fail, tuning it, and operating it taught me more about security operations than any course. When something breaks at 2am — and it will — you learn how it actually works.
It's a portfolio you can't fake. A running system with a custom AI analyst, real detection engineering, and documented war stories says more than any resume bullet. This series is that portfolio, in public.
It's the capability behind the work I do. I run a cybersecurity company, ByTE X Bit Technologies LLC; this is the kind of architecture and tooling that work is built on. Showing it beats claiming it.

What's next

Over the coming posts, we'll build this up layer by layer:

The foundation — the open-source stack (Wazuh, Zeek, Suricata, ntopng, Elastic, and a few others) on a segmented home network, and why each one earns its place.
The signal-to-noise problem — why raw alerts are unusable, and the tiered-triage idea that fixes it.
Building the AI analyst — the custom triage engine, and why running the LLM locally matters.
Hunting C2 — catching malware beacons with statistics and Zeek flow data.
Actionable alerts — LLM enrichment and getting notified only when it counts.
Risk-based remediation — prioritizing what's actually being exploited (CISA KEV).
Who watches the watcher — self-monitoring, and the real failures I found running this thing.

If you've ever wanted to see what "enterprise-grade" actually means under the hood — and build a
real version of it yourself — follow along.

Next up: [The Foundation — Wazuh, Zeek, Suricata & Elastic on a Home Network].

I'm Bryant, founder of ByTE X Bit Technologies LLC, a Maryland-based
cybersecurity company. I build and operate the kind of detection, triage, and remediation systems
this series walks through. If your organization needs help with security monitoring, detection
engineering, or hardening — get in touch.