I spend my working hours telling teams how to do security well. Segment the network. Write the change down. Model the threat before you build the control. Verify the thing actually works instead of assuming the config took. Own your mistakes fast. Then I go home, and if I am honest with myself, the temptation is to cut every one of those corners because it is "just the lab."
That gap is a problem. If I am going to teach, write, and lead in a business environment, the home lab cannot be the place where I stop doing the work the right way. I cannot expect people to buy my book and follow what I say, if I am not doing it.
It has to be the place where I do it the right way when nobody is watching, because that is the only way the habits stay real. This week I spent a day reworking the segmentation on my home network, and it turned into a clean example of why.
While I technically had segmentation, it has grown organically, with a lot of things in the "to-do" or the "bucket-list" land of forgotten projects. From a high level, the following image is an uncomfortable truth that my network was in.
Here is what I did, and here is the professional practice each piece maps to.
Move the front door out of the living room
My internet-facing reverse proxy (SOCFortress WAF) was sitting inside my trusted internal VLAN. Every published service behind it terminated on the same flat segment as my workstations and infrastructure. If that proxy ever got popped, the attacker would already be standing in the trusted zone. That is exactly the architecture I would flag in a client review, and there it was in my own house.
So I moved it into the DMZ. New VLAN, new address, repointed the WAN port forward, and then the part that actually matters: I wrote the firewall policy that lets the proxy reach only the backends it needs, and nothing else. In a zone-based firewall, DMZ to internal is deny by default. If I had just moved the box and walked away, every site would have returned 502, because the proxy could no longer reach the services it fronts. The move is easy. Making it keep working while staying least-privilege is the real work.
The professional parallel is obvious. We do not put internet-facing services on the trusted LAN at work. We put them in a DMZ with tightly scoped paths back to the application tier. The reason I could do this cleanly at home in an afternoon is that I have done it enough times in the enterprise to know where the 502 is going to come from before it happens.
Cameras are not trusted devices, so stop trusting them
My cameras were on their own VLAN, which felt like segmentation, but that VLAN was inside the trusted zone. IoT cameras are among the most likely things on any network to get compromised: internet-sourced firmware, questionable patch cadence, and a habit of phoning home. A compromised camera in a trusted zone has lateral reach across everything before it ever touches the recorder.
I built a dedicated surveillance zone and moved the camera VLAN into it. Cameras can now reach the recorder, DNS, and time. That is the entire list. Everything else is denied. The recorder stayed where it needed to be for the platform to manage it, so the camera-to-recorder path became the one sanctioned bridge, scoped to the specific ports and hosts, and I left it logging so I can tighten it later on evidence rather than on a guess.
This is SC-7(21) in the NIST catalog, isolate by component type, and it is the same thing I would recommend for a corporate camera fleet or any OT-adjacent gear. The device class is untrusted. The zone should reflect that.
Build the security zone before you fill it
I also stood up a dedicated SOC zone, the eventual home for the detection stack: the SIEM, the vulnerability scanner, the SOAR, the DFIR tooling. The point of isolating your detection plane is simple and it is written into the audit standards for a reason: the logs and the tooling that would catch an intruder must not be reachable and tamperable from a compromised general-purpose host. Detection an attacker can reach is detection an attacker can blind.
If you want to learn more about the pipeline I am creating and establishing, that these changes support, go to my GitHub Project.
I did not migrate the production tooling yet, because that is a re-IP of an interdependent cluster and it deserves its own careful, dependency-mapped change. What I did was build the zone, prove the ingest ruleset works, and leave the migration as the next tracked piece of work. Standing up the destination before you move production into it is not procrastination. It is how you avoid taking your own detection offline during a rushed cutover.
The part I would rather not write about
Here is where I embarrassed myself, and here is why I am including it.
There were three unnamed VMs sitting on that security VLAN. My network controller showed them only as anonymous DHCP clients. I assumed they were empty test boxes and moved the VLAN into the new default-deny zone. They were not empty. They were an old three-node cluster, and the move cut connectivity to it. I caught it within minutes because the firewall was logging the drops and I was watching the counters, and I rolled it back cleanly. No lasting harm, and the system turned out to be retired anyway.
But the process failure was real, and it was mine. I had spent the entire day preaching "verify before you cut" on every other change, and then I moved a production segment on an assumption instead of checking the hypervisor first, where those VMs had perfectly clear names. The lesson is not "be careful." The lesson is specific and reusable: your network controller will happily hide a production server behind an anonymous DHCP entry, so identify every occupant of a segment from the source of truth before you change its policy. I wrote that lesson into my own runbook so the next me does not repeat it.
I am telling you about it because this is the difference between someone who teaches security and someone who actually does it. The doers break things, notice fast because they instrumented the change, and fix it honestly. If your home lab never breaks, you are probably not changing anything real in it, and you are certainly not learning at the edge where the good lessons live.
Change control is not a corporate tax
Every change I made followed the same loop I would demand at work. Snapshot the current state first so rollback is a known-good file and not a memory. Make the change. Verify by evidence, not by the API returning success. A firewall rule that returns "201 created" is not a working rule; a published site returning 200 through the new path is. Cameras still streaming after the cutover is. Then write it down while it is fresh.
That last step is where home labs die. I updated the standing zone-model reference, the knowledge-base landing page, and the threat model to reflect the new zone count and the corrected facts, and I cross-linked the change records so a future reader can trace what happened and why. I even caught that one of my own reference pages still described an eight-zone world that no longer existed and was not linking to the changes that superseded it. Stale documentation is worse than none, because it lies with confidence.
Refresh the threat model, do not bolt a note onto it
After the changes, I re-ran the threat model against the new topology. Yes, I do threat models within my home and lab network. Not a "we made some changes" footnote, an actual re-assessment: updated the topology diagram, re-scored the risks, marked the camera exposure closed, and re-anchored the top remaining risk to where it actually lives. A threat model that does not move when the architecture moves is a compliance artifact, not a security tool. The whole value is watching the risk posture shift as you make decisions.
Why this matters if you teach, write, or lead
If you are going to stand in front of a room, publish an article, or sit at the architecture table and tell people how this should be done, your own environment is your proof of work. You have to eat your own $#!?, if you are expecting other to as well. Not because anyone audits your house, but because the habits do not switch on and off by context. The person who cuts corners at home cuts them at work under pressure, because that is the muscle they trained. You have to remember, slow is smooth, smooth is fast. The person who snapshots, verifies, documents, and owns the mistake at home does the same thing when the stakes are real, because it is simply how they operate.
Segment your network. Put untrusted things in untrusted zones. Isolate your detection plane. Write the change down and verify it actually took. And when you move a segment on a bad assumption and break something, say so, fix it, and record the lesson.
Do it at home the way you would do it at work. Especially at home, where the only person holding you to the standard is you.
