Step 1: Read the segmentation design template
Open materials/segmentation-design-template.md. This provides the framework for zone-based network segmentation.
The core concept: divide the flat network into zones based on trust level and function. Each zone gets its own Docker network. Traffic between zones is denied by default -- only connections with a documented business justification are allowed.
The template defines five zones for building infrastructure:
- Tenant zone -- Wi-Fi access points, guest devices. Untrusted. Assume any device here could be compromised.
- Building systems zone -- BMS (HVAC, fire suppression, elevators). High trust. Access restricted to authorized management only.
- Surveillance zone -- CCTV cameras, NVRs, management interfaces. Medium trust.
- Access control zone -- Electronic locks, readers, controllers. High trust.
- Management zone -- Monitoring, administration. Needs access to all zones for legitimate operations.
Defense-in-depth means controls at different layers. Network segmentation prevents lateral movement between zones. Application-level authentication prevents unauthorized access within a zone. Monitoring detects what prevention misses. Each layer addresses a different failure scenario -- not "more controls" but "controls at different points where different attacks succeed."
Step 2: Design the zone architecture
Using the connectivity matrix from Unit 2 and the threat model, design which containers belong in which Docker networks.
Map each container to a zone:
- tenant-wifi-1 and tenant-wifi-2 go in the tenant zone
- bms-doha and bms-alwakra go in the building systems zone
- cctv-manager goes in the surveillance zone
- access-control goes in the access control zone
- grafana, loki, and alloy go in the management zone
Then define the traffic policy. Start with default-deny -- nothing flows between zones unless you explicitly allow it. Every "allow" entry needs a business justification. Why does this connection need to exist?
The management zone needs to reach all other zones for monitoring. The building systems zone needs outbound internet for firmware updates. The surveillance zone needs outbound connectivity for the third-party CCTV company's remote management. Document every allowed flow.
Step 3: Implement the segmentation
Direct AI to create the Docker networks and reassign containers. This is where AI shortcomings surface.
AI commonly makes architectural mistakes with Docker networking -- generating configurations that look correct but bypass the segmentation in practice. Watch for configurations that leave containers on the default bridge network alongside the new zone networks, or that use identical settings for every container regardless of its role.
Create the separate Docker networks:
docker network create tenant-zone
docker network create building-systems-zone
docker network create surveillance-zone
docker network create access-control-zone
docker network create management-zone
Then disconnect containers from the default network and connect them to their zone networks. The order matters: disconnect from default first, then connect to the zone. If you connect first and then forget to disconnect, the container is on both networks and the segmentation is bypassed.
Step 4: Verify from the attacker's position
Run the same Nmap scan from Unit 2 -- from inside the tenant Wi-Fi container, target the BMS.
docker exec tenant-wifi-1 nmap -sT bms-doha
The result should be different from Unit 2. The BMS ports that were "open" should now be "filtered" or unreachable. If they are still open, the segmentation has a gap -- check whether the container is still connected to the default bridge network.
Test from each zone. Tenant to BMS: blocked. Tenant to access control: blocked. CCTV to BMS: blocked. Management to all: allowed (on monitoring ports). Each test verifies one relationship in the traffic policy.
Step 5: Fix health check failures
Segmentation breaks things. Health checks that previously probed across the flat network now fail because they cannot reach containers in other zones. The orchestrator's health checks may trigger container restarts.
Identify which health checks are failing and redesign them to work within the segmented topology. A health check for the BMS container should probe from within the building systems zone or from the management zone -- not from a container in the tenant zone.
This is the operational cost of segmentation. The network is more secure but also more complex. Debugging connectivity issues becomes harder because "it can't connect" might be a bug or might be the segmentation working correctly. The security benefit must be weighed against this operational cost.
Check: Nmap scan from tenant Wi-Fi container returns no reachable BMS ports. Health checks passing after reconfiguration. Docker network listing shows at least five separate networks (tenant, building-systems, surveillance, access-control, management).