How I Built an Open-Source SOC for a Network Engineering Lab

Why I Built This

I worked at a Florida state college. I’d saved real money on other projects over the years, but cybersecurity never got a line item. Our IT department didn’t have a cybersecurity team, a SOC, or a single security specialist on staff.

A SOC, a security operations center, pulls logs from every machine on the network and surfaces the events worth investigating. We had nothing doing that job.

Meanwhile, our sister college down the road just landed a $2.9 million federal grant for an integrated AI and cybersecurity lab, on top of an already-running student-powered SOC backed by a commercial security partner. That’s the norm across Florida’s public university system. Real budgets, real partnerships, real infrastructure for students to learn on.

Unfortunately, we had a budget for none of that. So I put it in my own hands and built with what we already had. The network needed to be secured. The students needed something real to learn on. Waiting for a budget line that was not coming was not a plan.

That is how this build started.

The Tooling Problem

Commercial SIEM platforms are expensive in a way that shuts smaller environments out before the first alert ever fires. Splunk, Sentinel, QRadar. They work, but they assume enterprise money, enterprise licensing, and usually an enterprise staff to babysit them.

I needed something different for a network engineering lab. I needed a SOC students could log into, break, fix, and actually understand. So I built one with open-source tooling on Proxmox: Wazuh, TheHive, Cortex, MISP, Suricata, and Zeek.

The point was never to rack up logos on a diagram. The point was to build a working security stack that could detect activity, create cases, enrich observables, and teach the workflow end to end.

What I Actually Built

The stack runs across seven VMs, each with a specific job:

• Wazuh Manager on Ubuntu 24.04 handles log collection, rule evaluation, alerting, and agent coordination.
• Wazuh Indexer on Ubuntu 24.04 stores and searches alert data.
• Wazuh Dashboard on Ubuntu 24.04 gives analysts and students a usable front end.
• TheHive 5 on Ubuntu 22.04 handles alert triage, case management, and investigation workflow.
• Cortex on Ubuntu 22.04 runs analyzers against IPs, domains, hashes, and other observables.
• MISP 2.5 on Ubuntu 24.04 stores indicators, feeds, and intelligence context.
• NIDS on Ubuntu 24.04 runs Suricata and Zeek for network visibility.

That separation matters. It kept the stack understandable, made troubleshooting less miserable, and let me tune storage and memory where it was actually needed instead of shoving everything onto one box and pretending that was architecture.

Why the OS Mix Matters

One of the first lessons was that “latest LTS everywhere” is not a serious deployment strategy.

Wazuh and the network monitoring pieces were fine on Ubuntu 24.04. TheHive and Cortex were not worth fighting there. Those two landed on Ubuntu 22.04 because their dependency chains are pickier, especially once Java, Elasticsearch, Cassandra, Docker analyzers, and older install assumptions get involved.

TheHive is memory-hungry. Cortex analyzers turn into Python hell fast: Ubuntu 24.04 ships Python 3.12, which dropped distutils and enforces PEP 668’s externally-managed-environment, so pip install for the analyzers just refuses. Cassandra and Elasticsearch do not reward optimism. Jammy was the stable choice, so that is what I used.

MISP was its own special case. Early on, I expected to keep it on 22.04 with the older install flow. That stopped making sense once MISP 2.4 was heading out the door. Rebuilding it on Ubuntu 24.04 for MISP 2.5 was the right call, even if it meant more work up front.

Making the Components Talk

Installing each component is the easy part. Getting them to behave like one SOC is where the hours disappear.

Here is the flow I built:

1. Endpoints and servers send logs into Wazuh.
2. Suricata and Zeek monitor mirrored traffic on the NIDS VM.
3. Their logs get normalized and shipped back into Wazuh.
4. High-value alerts get pushed from Wazuh into TheHive.
5. Analysts promote alerts to cases and extract observables.
6. Cortex enriches those observables with analyzers.
7. MISP provides local threat-intel context so the investigation is not happening blind.

That sounds neat in a bullet list. In practice, every line item hides a dozen sharp edges.

Wazuh-to-TheHive required a custom integration script to turn alerts into TheHive objects cleanly. Zeek had to be switched from its default TSV logs to JSON (@load policy/tuning/json-logs.zeek in local.zeek) because Wazuh wants structured input, not detective work. TheHive-to-MISP threw a 400 Bad Request until I narrowed the connector from “all organizations” to a specific org and set the self-signed cert to Loose SSL, on top of the usual “why is this technically configured but still red in the UI?” Cortex analyzers needed cleanup before they were useful instead of just installed.

I spent far more time making systems talk to each other than I did installing them. That is normal for this kind of work.

Network Visibility: Suricata and Zeek

A lab SOC without network telemetry is half a security stack.

Suricata gives me signature-based detection. Zeek gives me metadata, protocol visibility, and the kind of network context that makes an alert easier to investigate. Those tools solve different problems, so I wanted both.

The NIDS VM was configured to watch mirrored traffic and then feed that visibility back into Wazuh. I also had to force Zeek into JSON logging for compatibility, which is one of those tiny details that becomes a brick wall if you miss it.

That mirrored traffic only exists because we already had Cisco Catalyst switches in place, which support port mirroring natively through SPAN (Switched Port Analyzer, Cisco’s name for the feature). Enterprise-class switches like the Catalyst line support it across the lineup, and without that capability this entire layer of the stack would not exist. It is one of the few pieces of real infrastructure I did not have to invent, and the rest of the SOC leans on it.

Once that piece was in place, the stack stopped being just endpoint-centric. It could see host activity and suspicious network behavior in the same environment.

Storage, Memory, and Service Dependencies

A lot of the build work was storage and memory plumbing, the stuff that decides whether the SOC stays up under load.

Ubuntu VMs came up with LVM layouts that only used part of the allocated disk, so I had to resize physical volumes, extend logical volumes, and grow filesystems before some of these boxes had the storage they were supposed to have in the first place. One Wazuh manager filled to 24G 24G 0 100% / and even pip fell over with FileNotFoundError: [Errno 2] No usable temporary directory found, which is a confusing way to learn you are out of disk.

Memory tuning mattered too. TheHive, Elasticsearch, and related services will absolutely eat what you give them. I left Proxmox ballooning on once and Elasticsearch fell over while Cortex quietly dropped its TheHive connection until I restarted it. If you do not tune heap settings and watch ballooning behavior, you end up debugging fake application problems that are really resource-allocation problems.

That is a big part of why I do not describe this as “setting up tools.” It was infrastructure work. Storage, memory, APIs, log formats, certificates, permissions, service dependencies. The normal stuff that decides whether a system is real or just screenshot-ready.

What Students and Analysts Can Learn From It

The educational value here is not theoretical.

Students can see how detection turns into triage, how triage turns into casework, and how intelligence supports decisions instead of living in a separate silo. They can look at a Wazuh alert, move into TheHive, enrich in Cortex, check context in MISP, and understand how each platform contributes to the investigation.

That is much more useful than a lab where every tool is isolated and every exercise is pre-chewed.

It also mirrors the real problem in security operations. The hard part is rarely opening one dashboard. The hard part is connecting signals, deciding what matters, documenting actions, and moving from alert noise to something defensible.

Where the Project Went Next

The stack did not stop at the dashboard layer.

As I kept building, the SOC work turned into a broader agentic security tooling effort. The roadmap that started as “maybe I should build a chatbot for this stack” became a public MCP server suite for Wazuh, TheHive, Cortex, MISP, MITRE ATT&CK, Zeek, and Suricata.

That matters because it changes how analysts and students can work with the environment. Instead of clicking through four or five interfaces to gather context, an agent can pull alert details, map ATT&CK techniques, query threat intel, and summarize next steps in one flow. It is a force multiplier for someone who already knows the platforms, not a substitute for learning them.

Where It Stands Now

The core SOC is deployed and working. Wazuh is collecting alerts. TheHive is handling cases. Cortex is enriching observables. MISP is online. Suricata and Zeek are feeding the detection side. The agentic layer sits on top of that foundation instead of replacing it.

I have since left the college, so the stack is in the team’s hands now. The build only mattered if it kept running without the person who stood it up, which is why I put the work into the agentic layer before I left. The MCP servers and the controls around them let a small team query alerts, map ATT&CK techniques, pull threat-intel context, and triage an incident without memorizing every dashboard. The tooling does the mechanical evidence-gathering so whoever is on call can spend their attention on the decision.

The next work is the less glamorous but necessary part: more endpoint coverage, more rule tuning, better playbooks, tighter documentation, safer approval boundaries for live actions, and clearer guided workflows for students.

These projects become durable by being useful enough that people keep operating them after the builder moves on, not by being declared done.

Open-source security tooling is not free. The bill just shows up as engineering effort instead of licensing. For a lab environment, I think that is a trade worth making. You get real capability, real understanding, and a system you actually own.

View the full SOC architecture →

Read about the 7 security MCP servers that plug into this stack →