Why I'm Building a Home Cyber Operations Center

When I started getting serious about cybersecurity, I spent a lot of time learning individual concepts: logs, networking, endpoint security, access control, incident response. That was useful, but I kept running into the same problem. Knowing what a SIEM does isn't the same as operating one. Reading about an alert isn't the same as figuring out why your own alert didn't fire.

So I started building.

At first the goal was pretty simple: get better visibility into my home network and the devices on it. Then one thing kept leading to another. If I was collecting logs, I wanted to know whether the logs were useful. If I could detect something, I wanted a safe way to generate the activity that should trigger it. If I was going to remotely administer the environment, I wanted that access secured properly. And if alerts started piling up, I wanted to learn how automation and incident response could fit into the picture.

Eventually I stopped thinking of these as separate homelab projects. They were becoming parts of one system.

The goal isn't to pretend I run an enterprise SOC

This is still a home environment. I don't have thousands of endpoints, a security team working shifts, enterprise licensing or the operational pressures that come with protecting a real company. I think it's important to be clear about that.

What I can do is build the same kinds of relationships between systems on a smaller scale and understand why they exist. I can generate an event, watch it move through my environment, see whether it gets detected, investigate what happened, and then improve the detection or response.

That's a lot more useful to me than installing a tool, taking a screenshot of its dashboard and calling the project finished.

I'm deliberately letting the project grow with me

I don't know everything required to build the final version yet. That's actually part of the reason I'm doing it.

The environment is being built in phases. Some parts are already operational, some are being improved, and others only exist as designs right now. As my skills improve, I'm going back and changing earlier decisions when I find a better way to do something.

That means this site isn't going to present the lab as if everything worked perfectly the first time. I want to document the failures too: broken configurations, assumptions that turned out to be wrong, security controls that caused unexpected problems, and designs I replaced after learning more.

Where I want this to end up

The long-term goal is an environment where endpoint telemetry, network monitoring, detection, adversary simulation, automation and incident response all work together. Project Ares will give me a controlled way to generate activity and validate detections. Wazuh and the rest of the monitoring stack provide visibility. n8n is being introduced as an orchestration layer so I can experiment with SOAR-style workflows without building another system that duplicates everything else.

There are also infrastructure projects around it: Linux systems, containers, secure remote administration, networking, backups and eventually a small Kubernetes cluster. They're useful projects by themselves, but the interesting part is making them interact.

Why I'm writing about it

GitHub is great for keeping the technical evidence: configuration, code, architecture notes and documentation. It isn't always the best place to explain why I made a decision or spend a page talking about something that went badly.

That's what this journal is for.

I'm going to use it to document the parts of the build that taught me something worth remembering. Sometimes that will be a larger architecture decision. Sometimes it might just be the afternoon I discovered that my DNS filtering had broken a streaming service and had to work backward to figure out why.

If I eventually look back at an early post and realize I would do everything differently, that's probably a good sign. It means the project did what I wanted it to do: forced me to learn.