This project grew out of a simple problem: flat networks are easy to build because you do not have to make many decisions. Everything is connected & most things can talk to everything else.
That convenience hides the security model though. You are still making a decision. You are just making the decision that local access equals trust.
I wanted to make that trust visible & test what happens when communication has to be justified instead of assumed.
Reduce accidental trust without creating a network so complicated that the security controls become impossible to maintain.
1. Start with the trust model
Before creating segments, I want to know what kinds of systems exist & how much I actually trust them.
A managed workstation is not the same thing as a guest phone. An IoT device is not the same thing as an administrative system. A public-facing service should not automatically inherit the same access as a trusted internal machine.
The labels themselves are not important. The difference in trust is.
2. Map required communication
I prefer to write the required paths in normal language before creating firewall rules.
For example, "workstations need HTTPS access to this internal application" tells me much more than a rule number & a port with no context.
Once the intent is clear, I can translate it into addresses, protocols & ports. If the implementation changes later, the original reason for the rule is still understandable.
3. Denying traffic is only useful if I know why
A firewall that blocks everything can look secure right up until people disable it because nothing works.
I want denied traffic to be observable. If a legitimate application fails, I need to be able to tell whether the network policy blocked it, DNS failed, the service was down or the client simply used the wrong address.
Security & troubleshooting are not enemies here. Clear policy actually makes troubleshooting easier because there are fewer unexplained paths.
4. Test both sides of the rule
It is not enough to test that expected traffic succeeds. I also want to test that traffic I intended to block actually fails.
If a guest segment is not supposed to reach management interfaces, I should verify that. If a workstation should only reach a selected service on a server, I should not assume the rest of the server is isolated just because the intended service works.
This is the same reason software tests need negative cases. "The correct thing works" & "the incorrect thing is rejected" are different claims.
5. Design around what happens after compromise
I think security discussions sometimes focus too much on preventing the first compromise as if that is the only line that matters.
What happens if prevention fails?
If a low-trust device becomes compromised, can it freely discover servers? Can it reach administrative interfaces? Can it probe developer machines? Does it gain useful information just because it sits on the same local network?
Segmentation gives me a way to reduce those options. It does not make compromise harmless, but it can stop one bad event from automatically receiving access to unrelated systems.
6. Naming & documentation reduce ambiguity
A good network diagram should tell me something useful. Names should tell me what a system is for. Segments should have a purpose. Rules should have a reason.
I do not want to come back months later & find "ALLOW 10.0.30.17 -> 10.0.10.8 TCP 8443" with no idea why that connection exists.
Technical precision is useful, but the human explanation should survive beside it.
7. Monitoring closes the loop
Once the network has intentional boundaries, logs become much more interesting. Unexpected denied traffic may reveal a broken application assumption, bad configuration or behavior I did not know existed.
That is information.
I want to build toward enough monitoring that network policy is not simply a wall. It is also a source of evidence about how the environment behaves.
Security gets stronger when the control also makes the system easier to understand.
8. The main lesson so far
More rules do not automatically mean more security. More segments do not automatically mean more security either.
The useful improvement is reducing ambiguity. I want fewer unnecessary pathways, clearer trust levels & enough documentation that I can explain why communication is allowed.
If the architecture becomes so complicated that I stop understanding it, I have created a different kind of risk.
9. Next steps
The next stage is stronger monitoring, better rule-validation workflows & more documentation around DNS, service exposure & firewall behavior.
I also want to keep the project tied to the home lab so the design is being tested against real services instead of existing only as a clean diagram.
Make the network explain itself
The result I want is a network where a pathway exists because something needs it, not simply because both devices happen to be connected.
If I can explain the trust model in ordinary language, enforce it technically & investigate when reality does not match the model, then the hardening is doing something useful.