Lab 12 Network Segmentation & Access Control Assessment

Mission Overview

Welcome to Lab 12 — Network Segmentation & Access Control Assessment.

In Lab 11, you analyzed how systems communicate and built a traffic map. Now you will use that knowledge to answer a more architectural question:

Are network trust boundaries actually enforcing least-privilege communication?

Network segmentation separates systems based on:

• business function

• sensitivity

• trust level

• administrative role

• workload tier

• user type

Typical enterprise zones may include:

• user network

• server network

• management network

• guest network

• database tier

• DMZ

• infrastructure zone

A network can appear segmented on a diagram while still permitting unnecessary traffic between zones.

Your objective is to validate whether only the required paths are allowed.

Mission Goal: Assess authorized network trust boundaries, compare expected and observed communication paths, identify unnecessary cross-zone access, validate management-plane isolation, and produce evidence-based segmentation findings.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Network Segmentation Assessment
Secondary Skill	Access Control Validation
Environment	GoHackersCloud Network Pentesting Lab
Input	Service inventories and communication maps from Labs 03–11
Primary Outcome	Network Segmentation Validation Matrix
Safety Level	Authorized Lab Systems Only

Learning Objectives

By completing this lab, you will be able to:

• understand network trust boundaries

• identify security zones

• map allowed and denied communication paths

• validate user-to-server access

• validate server-to-database access

• assess management-plane isolation

• assess guest-network isolation

• analyze east-west communication

• assess least-privilege network access

• distinguish service exposure from segmentation failure

• understand firewall and ACL enforcement

• compare architecture intent with observed behavior

• identify unnecessary network trust

• document positive segmentation controls

• create evidence-based segmentation findings

• define remediation and retest criteria

Assessment Methodology

Use:

Source Zone → Destination Zone → Required Service → Expected Policy → Observed Reachability → Evidence → Finding

Conceptually:

Source Zone
    │
    ▼
Destination Zone
    │
    ▼
Required Business Flow?
    │
    ├── Yes
    │     ↓
    │   Expected Service
    │
    └── No
          ↓
       Should Be Denied
    │
    ▼
Validate Reachability
    │
    ▼
Compare Expected vs Observed
    │
    ├── Allowed as Expected
    ├── Denied as Expected
    ├── Unexpectedly Allowed
    └── Unexpectedly Blocked
    │
    ▼
Evidence
    │
    ▼
Finding

The central principle is:

Network access should exist because a business function requires it—not simply because routing allows it.

Part 1 — Revalidate Scope

Confirm the zones included in your lab.

Example:

User Network:
192.168.10.0/24

Server Network:
192.168.20.0/24

Database Network:
192.168.30.0/24

Management Network:
192.168.40.0/24

Guest Network:
192.168.50.0/24

Your actual lab may use different subnets or virtual interfaces.

Record:

Authorized Source Zones:

Authorized Destination Zones:

Authorized Services:

Firewall Testing:
Connectivity Validation Only

Denial-of-Service:
No

Firewall Modification:
No

Bypass Testing:
No

Assessment Date:

Investigator:

Part 2 — Create the Workspace

Create:

Network-Pentesting-Labs/
└── Lab-12/
    ├── Scope/
    ├── Architecture/
    ├── Notes/
    ├── Zones/
    ├── Flow-Tests/
    │   ├── User-to-Server/
    │   ├── User-to-Database/
    │   ├── User-to-Management/
    │   ├── Guest-Isolation/
    │   ├── Server-to-Database/
    │   └── Management/
    ├── Evidence/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-12-Network-Segmentation-Assessment.md

Suggested structure:

# Lab 12 — Network Segmentation & Access Control Assessment

## Mission Objective

## Authorization

## Network Architecture

## Security Zones

## Expected Communication Matrix

## User Network Assessment

## Server Network Assessment

## Database Tier Assessment

## Management Network Assessment

## Guest Network Assessment

## East-West Communication

## Firewall / ACL Validation

## Positive Controls

## Segmentation Gaps

## Findings

## Recommendations

## Retest Criteria

## Limitations

## Conclusion

Part 3 — Build the Zone Inventory

Create:

Zone	Subnet	Purpose	Trust Level
User		End-user workstations	Standard
Server		Application/services	Elevated
Database		Data tier	High
Management		Administration	High
Guest		Untrusted devices	Low

The purpose of segmentation is to keep these trust levels from becoming one flat network.

Part 4 — Build the Architecture Diagram

Example:

                    Internet
                       │
                       ▼
                     DMZ
                       │
                       ▼
                Application Tier
                       │
                       ▼
                  Database Tier


User Network ───────► Application Tier

Management Network ─► Servers
                  ├─► Database
                  └─► Infrastructure

Guest Network ─────X─► Internal Networks

The X represents an expected denied path.

Part 5 — Understand North-South vs East-West Traffic

North-South

Traffic moving between external and internal environments.

Example:

Internet → Web Server

East-West

Traffic between internal systems or zones.

Example:

User → Server
Server → Database
Server → Server

Internal east-west traffic is a major segmentation concern.

Part 6 — Build the Expected Flow Matrix

Before testing, document the intended policy.

Example:

Source	Destination	Service	Expected
User	Web Server	HTTPS 443	Allow
User	Linux Admin SSH	22	Deny
User	Database	3306	Deny
Server	Database	3306	Allow
Management	Linux	SSH 22	Allow
Management	Windows	RDP 3389	Allow
Guest	Internal Server	Any	Deny

This is your test plan.

Part 7 — Why Expected Policy Comes First

If you test first and ask questions later, every open path may look suspicious.

Professional segmentation assessment starts with:

What should be allowed?

Then tests:

What is actually allowed?

Part 8 — Build the Segmentation Test Register

Use:

ID	Source Zone	Destination	Port	Expected	Observed
SEG-01	User	Web	443	Allow
SEG-02	User	DB	3306	Deny
SEG-03	User	Admin SSH	22	Deny

Part 9 — Validate the Source Zone

Before every test, verify where you are testing from.

Record:

Source Host:

Source IP:

Source Zone:

Interface:

Default Gateway:

Assessment Role:

Do not assume a workstation is in the intended zone.

Part 10 — Validate the Destination

For each target record:

Destination Host:

Destination IP:

Destination Zone:

Target Service:

Expected Port:

This prevents incorrect conclusions caused by testing the wrong address.

Part 11 — Test Required User-to-Web Access

Suppose users require access to an application over HTTPS.

From the authorized user-segment test host:

nc -vz <web-server> 443

or use the normal application connection method.

Record:

Flow:
User → Web

Service:
HTTPS

Expected:
Allow

Observed:
Allowed / Denied

Result:
Pass / Review

Part 12 — Unexpected Blocking Is Also Important

If a legitimate business flow should work but is blocked:

Expected:
Allow

Observed:
Denied

this may be:

• configuration problem

• firewall rule issue

• routing problem

• test setup issue

A pentest is not only about finding excessive access.

Part 13 — Validate User-to-SSH Restrictions

If users should not administer Linux servers directly:

nc -vz <linux-server> 22

Expected:

User Network
      │
      X
      │
      ▼
SSH / Linux Server

Record:

Expected:
Deny

Observed:
Denied

This is a positive control.

Part 14 — Unexpected SSH Reachability

If SSH responds from the user network:

Expected:
Deny

Observed:
Allowed

do not attempt authentication attacks.

The segmentation weakness is already established:

The user segment can reach the administrative SSH surface.

Part 15 — Validate User-to-RDP Restrictions

For Windows administration:

nc -vz <windows-server> 3389

If the architecture says management network only:

User → Windows RDP
Expected: Deny

Record the result.

Part 16 — Assess User-to-Database Access

A common multi-tier architecture is:

User
  │
  │ HTTPS
  ▼
Application
  │
  │ Database Protocol
  ▼
Database

Users generally do not need:

User → Database

directly.

Part 17 — Test Database Reachability

Against the known database listener:

nc -vz <database-server> 3306

or the appropriate known database port.

This only validates reachability.

Do not authenticate to the database unless separately authorized.

Part 18 — Record Database Segmentation

Source:
User Network

Destination:
Database Network

Service:
3306/TCP

Expected:
Deny

Observed:

Security Assessment:

Part 19 — Why Database Segmentation Matters

Database services often contain:

• sensitive data

• business records

• authentication material

• application state

Even strong database authentication benefits from reduced network exposure.

Use defense in depth:

Network Restriction
       +
Authentication
       +
Database Authorization

Part 20 — Validate Application-to-Database Access

Move to the authorized application/server test host where available.

Validate:

Application → Database

on the required database port.

Expected:

Allow

This establishes that segmentation can be restrictive without breaking legitimate flows.

Part 21 — Build the Database Tier Matrix

Source	Database Port	Expected	Observed
User	3306	Deny
Application	3306	Allow
Management	3306	Policy dependent
Guest	3306	Deny

Part 22 — Assess Management Network Isolation

Administrative services may include:

• SSH

• RDP

• WinRM

• SNMP

• management HTTPS

• database administration

• network device administration

These should often be reachable from a dedicated management zone.

Part 23 — Build the Management Flow Matrix

Source	Destination	Service	Expected
Management	Linux	SSH	Allow
Management	Windows	RDP	Allow
Management	Network Device	SNMP	Allow
User	Linux	SSH	Deny
User	Windows	RDP	Deny
Guest	Any Admin	Any	Deny

Part 24 — Validate Management-to-SSH

From the management test host:

nc -vz <linux-server> 22

Record:

Expected:
Allow

Observed:

Assessment:

No credential test is required to validate the network path.

Part 25 — Validate Management-to-RDP

From the management zone:

nc -vz <windows-server> 3389

Record:

Expected:
Allow

Observed:

Compare this with the same test from the user zone.

Part 26 — Compare Source-Dependent Access

A strong segmentation control might produce:

User → RDP
Denied

Management → RDP
Allowed

This is strong evidence that access control is source-aware.

Part 27 — Build the Source Comparison Register

Service	User Zone	Management Zone	Expected
SSH	Denied	Allowed	Yes
RDP	Denied	Allowed	Yes
SNMP	Denied	Allowed	Yes

Part 28 — Assess Guest Network Isolation

The guest zone should normally have minimal or no direct access to internal resources.

Conceptually:

Guest
  │
  ├────► Internet
  │
  X
  └────► Internal Systems

Do not test public systems.

Focus only on authorized internal lab targets.

Part 29 — Test Guest-to-Internal Paths

Use a small set of known internal services rather than broad scanning.

Example validation:

Guest → Internal HTTPS
Guest → Internal SSH
Guest → SMB
Guest → Database

Expected:

Deny

Part 30 — Build the Guest Isolation Matrix

Destination	Port	Expected	Observed
Internal Web	443	Deny/Policy
Linux SSH	22	Deny
Windows SMB	445	Deny
Database	3306	Deny
Management UI	443	Deny

Part 31 — Do Not Turn Segmentation Testing into Broad Scanning

The objective is:

Validate specific network-policy statements.

Not:

“Scan everything from every zone.”

Use known services discovered in prior labs.

Part 32 — Assess Server-to-Server Communication

Server networks may have overly broad east-west access.

Example:

Web01
  │
  ├──► DB01      Required
  │
  ├──► DNS       Required
  │
  └──► FILE01    Not Required

The unnecessary third path may deserve review.

Part 33 — Build the East-West Flow Matrix

Source Server	Destination	Service	Required	Observed
Web	DB	DB Port	Yes
Web	DNS	53	Yes
Web	File Server	SMB	No
DB	User Workstation	SMB	No

Part 34 — Understand Lateral Movement Exposure

Broad east-west access can increase the impact of one compromised system.

Conceptually:

Compromised Host
      │
      ├────► Server A
      ├────► Server B
      ├────► Database
      └────► Management

Good segmentation aims to reduce unnecessary paths.

This lab identifies paths; it does not perform lateral movement.

Part 35 — Assess Infrastructure Access

Use results from Lab 10.

Examples:

User → DNS
Expected Allow

Guest → Internal DNS
Expected Deny / Policy dependent

User → SNMP
Expected Deny

Management → SNMP
Expected Allow

Build these into your segmentation matrix.

Part 36 — Validate SNMP Management Segmentation

From a non-management zone, test only whether the known SNMP service is reachable.

No credential guessing is required.

Then compare against the management host.

The ideal pattern may be:

User → SNMP
Denied

Management → SNMP
Allowed

Part 37 — Assess SMB Segmentation

Use Lab 08’s SMB target.

Questions:

Should user systems access SMB?
Should guest systems access SMB?
Should server systems access SMB?
Should management systems access SMB?

There is no universal answer.

Use architecture requirements.

Part 38 — Build the SMB Zone Matrix

Source	SMB	Expected
User
Server
Management
Guest

Do not perform share enumeration again unless needed to validate an explicitly authorized scenario.

Part 39 — Assess DNS Segmentation

DNS can have different access rules:

Internal DNS
   ├── User: Allow
   ├── Server: Allow
   ├── Management: Allow
   └── Guest: Deny

Your lab policy may differ.

Validate the intended model rather than assuming one.

Part 40 — Assess Administrative Web Interfaces

Examples:

• hypervisor UI

• firewall UI

• router UI

• application administration

• server management console

Test only basic reachability.

If it is supposed to be management-only:

User → Admin Web
Expected Deny

Management → Admin Web
Expected Allow

Part 41 — Build the Management Interface Matrix

Interface	Port	User	Management	Guest
Linux SSH	22	Deny	Allow	Deny
Windows RDP	3389	Deny	Allow	Deny
Device HTTPS	443	Deny	Allow	Deny
SNMP	161	Deny	Allow	Deny

Part 42 — Understand Firewall and ACL Enforcement

Segmentation may be enforced using:

• firewall rules

• router ACLs

• VLAN ACLs

• cloud security groups

• network security groups

• host firewalls

• security appliances

• microsegmentation policies

You do not need administrator access to prove whether a network path works.

Part 43 — Evidence from Connectivity vs Configuration

Two evidence sources may exist.

Observed Network Evidence

Connection succeeded.

Configuration Evidence

Firewall rule explicitly allows the source.

Observed network behavior is especially important because configuration alone may be wrong or overridden.

Part 44 — Compare Intended Rule vs Actual Behavior

Example:

Firewall Documentation:
Deny User → Database

Observed:
TCP 3306 reachable

This discrepancy is a strong finding.

Part 45 — Do Not Modify Firewall Rules

This is an assessment lab.

Do not:

• add allow rules

• disable firewalls

• change ACLs

• create temporary bypasses

• modify routing

Document what exists.

Part 46 — Identify Overly Broad Rules Conceptually

Examples:

Any → Database : 3306

User Network → Server Network : Any

Guest → Internal : Any

These may be overly permissive depending on environment requirements.

But the assessment should focus on the actual resulting access.

Part 47 — Understand Default-Allow vs Default-Deny

Default Allow

Traffic is allowed unless specifically blocked.

Default Deny

Traffic is blocked unless specifically permitted.

Security-sensitive zones often benefit from a least-privilege model:

Deny by default
     +
Explicitly allow required services

Part 48 — Assess Least-Privilege Network Access

For each allowed path ask:

Does the source actually need this destination and service?

Example:

User → Web:443
Required

versus:

User → Web:22
Not Required

Part 49 — Build the Least-Privilege Flow Register

Source	Destination	Service	Business Need	Access
User	Web	443	Required	Allow
User	Web	22	None	Deny
Web	DB	3306	Required	Allow

Part 50 — Identify Any-to-Any Trust

A flat network effectively behaves like:

Zone A
  │
  ├──► Zone B
  ├──► Zone C
  ├──► Zone D
  └──► Zone E

with minimal restriction.

This increases attack-path opportunities.

Do not call a network flat solely because one path is open.

Evaluate the broader policy.

Part 51 — Build the Trust Relationship Map

Example:

User
 │
 ├──443──► Web
 │
 X──3306─► Database
 │
 X──22───► Linux Admin


Web
 │
 └──3306─► Database


Management
 │
 ├──22────► Linux
 ├──3389──► Windows
 └──161───► Network Device

Use:

• arrows for allowed

• X for denied

• dashed lines for unknown

Part 52 — Identify Unexpected Allowed Paths

Create:

ID	Source	Destination	Service	Expected	Observed
GAP-01	User	DB	3306	Deny	Allow
GAP-02	Guest	SMB	445	Deny	Allow

These become your segmentation-gap candidates.

Part 53 — Identify Unexpected Denied Paths

Create:

ID	Source	Destination	Service	Expected	Observed
BLOCK-01	Web	DB	3306	Allow	Deny

Unexpected blocking can indicate operational misconfiguration.

Part 54 — Build the Segmentation Validation Matrix

This is the lab’s core deliverable.

Source	Destination	Port	Expected	Observed	Status
User	Web	443	Allow	Allow	Pass
User	DB	3306	Deny	Allow	Fail
User	SSH	22	Deny	Deny	Pass
Mgmt	SSH	22	Allow	Allow	Pass
Guest	SMB	445	Deny	Deny	Pass

Part 55 — Classify Segmentation Results

Use:

Pass

Observed behavior matches policy.

Segmentation Gap

Traffic is allowed when policy says deny.

Unexpected Restriction

Traffic is denied when policy says allow.

Inconclusive

Unable to determine network behavior confidently.

Policy Unknown

Technical behavior is known, but expected architecture is not.

Part 56 — Separate Reachability from Authentication

Suppose:

User → RDP
Reachable

but authentication blocks access.

The segmentation result remains:

Network Path:
Allowed

Authentication is a separate security control.

Remember:

Authentication Denied
       ≠
Network Segmentation Enforced

Part 57 — Separate Host Firewall from Network Firewall

A failed connection could be caused by:

• network firewall

• host firewall

• service binding

• application behavior

Therefore report:

The service was not reachable from the tested source.

Only attribute enforcement to a specific control if validated.

Part 58 — Assess Defense in Depth

A sensitive service may have:

Network Segmentation
       +
Host Firewall
       +
Authentication
       +
MFA

This is stronger than relying on one mechanism.

Document effective layered controls.

Part 59 — Build the Defense-in-Depth Register

Service	Network Restriction	Host Restriction	Auth	MFA
SSH	Yes	Yes	Yes
RDP	Yes	Yes	Yes
Database	Yes	Yes	Yes	N/A

Part 60 — Identify Positive Controls

Examples:

Guest network cannot reach internal SMB.

User network cannot reach database services.

SSH is reachable only from management network.

RDP is reachable only from administration systems.

SNMP is isolated to the management zone.

Application server can reach the database on only the required port.

Database tier cannot initiate unnecessary user-network communication.

These are important assessment outcomes.

Part 61 — Build the Positive Control Register

Control	Test	Result
User→DB blocked	TCP 3306	Pass
Guest→SMB blocked	TCP 445	Pass
Mgmt→SSH allowed	TCP 22	Pass

Part 62 — Example Finding — User-to-Database Access

Finding ID:
SEG-01

Title:
User Network Can Access Database Service Directly

Source:
User Network

Destination:
Database Server

Service:
3306/tcp

Expected Policy:
Application tier only

Observed:
TCP 3306 reachable from user segment

Severity:
High

Confidence:
High

Description:
The database service is directly reachable from the user network,
despite the documented architecture requiring database access only
from the application and approved administration tiers.

Impact:
Compromise of a user workstation could provide direct access to
the database authentication surface, bypassing the intended
application-tier network boundary.

Recommendation:
Restrict database network access to explicitly approved
application and management systems.

Retest:
Confirm the database service is no longer reachable from the user
segment while required application connectivity remains available.

Part 63 — Example Finding — Guest-to-SMB Access

Finding ID:
SEG-02

Title:
Guest Network Can Reach Internal SMB Service

Source:
Guest Network

Destination:
Internal Windows Server

Service:
445/tcp SMB

Severity:
High

Confidence:
High

Description:
The internal SMB service is reachable from the simulated guest
network.

The intended guest-network design requires isolation from internal
corporate resources.

Impact:
Untrusted guest devices can interact directly with an internal
Windows authentication and file-sharing surface.

Recommendation:
Block guest-to-internal SMB traffic and review the guest network's
internal routing and firewall policies.

Retest:
Confirm TCP 445 is denied from the guest zone to internal hosts.

Part 64 — Example Finding — Management Interface Exposure

Finding ID:
SEG-03

Title:
Linux Administrative SSH Service Reachable from User Segment

Source:
User Network

Destination:
Linux Server

Port:
22/tcp

Expected:
Management network only

Observed:
Reachable

Severity:
Medium

Confidence:
High

Impact:
A compromised user workstation could directly interact with the
server's administrative authentication service.

Recommendation:
Restrict SSH to approved management networks and jump hosts.

Part 65 — Example Positive Control — Management Isolation

Control:
Administrative Network Segmentation

Observation:
SSH and RDP were inaccessible from the user and guest segments but
available from the designated management network.

Assessment:
Administrative network segmentation is operating as intended.

Part 66 — Example Positive Control — Database Tier

Control:
Database Tier Isolation

Observation:
The database listener was inaccessible from the user network but
available from the application server on the required database
port.

Assessment:
Application-tier segmentation is operating as expected.

Part 67 — Assess Severity

Consider:

Source Trust Level

Destination Sensitivity

Service Sensitivity

Authentication Surface

Potential Data Exposure

Potential Administrative Access

Breadth of Allowed Source Range

For example:

Guest → Database

generally deserves more attention than:

Server → Approved Monitoring Service

Part 68 — Build the Segmentation Risk Matrix

Gap	Source Trust	Destination Sensitivity	Service	Priority
Guest → SMB	Low	High	File/Auth	High
User → SSH	Medium	High	Admin	Medium/High
User → NTP	Medium	Low	Infra	Low

Part 69 — Assess Confidence

High Confidence

Repeated connectivity tests produce consistent results.

Medium Confidence

Behavior is consistent but policy intent is partly inferred.

Low Confidence

Network behavior or architecture is unclear.

Keep:

Severity

and:

Confidence

separate.

Part 70 — Build the Final Segmentation Findings Register

ID	Source	Destination	Service	Severity	Confidence
SEG-01	User	DB	3306	High	High
SEG-02	Guest	Windows	SMB	High	High
SEG-03	User	Linux	SSH	Medium	High

Populate only findings supported by your lab.

Part 71 — Build the Network Trust Map

Example:

                         Management
                        /    |     \
                      SSH   RDP    SNMP
                      /      |       \
                   Linux   Windows   Network


User
 │
 ├── HTTPS ──────► Web
 │                   │
 X                   │ DB
 └── Database        ▼
                  Database


Guest
 │
 └──── X ─────► Internal Networks

Mark each relationship:

ALLOW
DENY
UNEXPECTED ALLOW
UNKNOWN

Part 72 — Build the Final Access Control Profile

NETWORK SEGMENTATION PROFILE

Security Zones:

User Network:

Server Network:

Database Network:

Management Network:

Guest Network:

Required Flows:

Denied Flows:

Unexpected Allowed Flows:

Unexpected Denied Flows:

Management Exposure:

Database Exposure:

Guest Isolation:

East-West Restrictions:

Infrastructure Access:

Positive Controls:

Validated Segmentation Gaps:

Highest-Priority Issue:

Part 73 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Network Segmentation & Access Control Assessment

Assessment Date:

Investigator:

Authorized Zones:


NETWORK ZONES

User Network:

Server Network:

Database Network:

Management Network:

Guest Network:

Infrastructure Network:


USER NETWORK

User → Web 443:
Expected:
Observed:

User → SSH 22:
Expected:
Observed:

User → RDP 3389:
Expected:
Observed:

User → SMB 445:
Expected:
Observed:

User → Database:
Expected:
Observed:

User → SNMP:
Expected:
Observed:


SERVER NETWORK

Web → Database:
Expected:
Observed:

Web → DNS:
Expected:
Observed:

Web → SMB:
Expected:
Observed:

Unexpected East-West Paths:


MANAGEMENT NETWORK

Management → SSH:
Expected:
Observed:

Management → RDP:
Expected:
Observed:

Management → SNMP:
Expected:
Observed:

Management → Admin Web:
Expected:
Observed:


GUEST NETWORK

Guest → Web:
Expected:
Observed:

Guest → SSH:
Expected:
Observed:

Guest → SMB:
Expected:
Observed:

Guest → Database:
Expected:
Observed:

Guest → Management:
Expected:
Observed:


DATABASE TIER

User Access:

Application Access:

Management Access:

Guest Access:

Unexpected Source Access:


SEGMENTATION SUMMARY

Required Flows Allowed:

Expected Denials Working:

Unexpected Allowed Paths:

Unexpected Denied Paths:

Management Plane Restricted:

Guest Isolation Working:

Database Isolation Working:

East-West Controls Effective:


POSITIVE CONTROLS

Control 01:

Control 02:

Control 03:


FINAL ANALYSIS

Highest-Risk Segmentation Gap:

Most Significant Management Exposure:

Most Significant Guest Exposure:

Most Significant Database Exposure:

Best Positive Control:

Validated Findings:

Inconclusive Paths:

Ready for Network Attack-Path Analysis:
Yes / No

Part 74 — What Not to Do

Do not:

Scan outside the authorized lab

Perform broad unrestricted scans from every zone

Modify firewall rules

Modify ACLs

Disable host firewalls

Change routing

Create unauthorized tunnels

Bypass network controls

Use VPNs to evade segmentation

Perform source-IP spoofing

Perform ARP spoofing

Perform VLAN hopping

Attempt firewall evasion

Use covert channels

Perform port knocking tests unless explicitly designed

Exploit reachable services

Guess credentials

Attempt lateral movement

Install remote access tools

Create persistence

Perform denial-of-service testing

Flood firewall state tables

Expose vulnerable lab systems publicly

The professional rule is:

Validate whether the boundary works without attempting to defeat the boundary.

Troubleshooting

Connection Is Denied

Do not automatically conclude:

Network firewall blocked it.

Possible causes include:

• host firewall

• service not listening

• route missing

• service binding

• network firewall

Report the observed behavior first.

User-to-Database Test Fails but Should Succeed

Verify the expected architecture.

Direct user-to-database access may not actually be required.

Management Access Fails

Check:

• correct management source

• routing

• service status

• intended port

• firewall policy

Do not change controls during the assessment.

Guest Can Reach One Internal Host

Validate the path again.

Do not immediately scan the whole internal network.

A single confirmed inappropriate path may already justify investigation.

Ping Fails but TCP Works

Remember:

ICMP Denied
    ≠
Network Segmentation Enforced

Test the specific authorized service.

Ping Works but Sensitive Ports Are Blocked

That may be a valid segmentation design.

Reachability at one protocol does not imply full access.

Evidence Requirements

Capture:

Evidence 01

Authorization and scope.

Evidence 02

Security Zone Inventory.

Evidence 03

Architecture diagram.

Evidence 04

Expected Flow Matrix.

Evidence 05

Segmentation Test Register.

Evidence 06

User-to-Web test.

Evidence 07

User-to-SSH test.

Evidence 08

User-to-RDP test.

Evidence 09

User-to-Database test.

Evidence 10

Application-to-Database test.

Evidence 11

Management-to-SSH test.

Evidence 12

Management-to-RDP test.

Evidence 13

Source Comparison Register.

Evidence 14

Guest Isolation Matrix.

Evidence 15

East-West Flow Matrix.

Evidence 16

Infrastructure segmentation tests.

Evidence 17

SMB Zone Matrix.

Evidence 18

Management Interface Matrix.

Evidence 19

Least-Privilege Flow Register.

Evidence 20

Unexpected Allowed Paths Register.

Evidence 21

Unexpected Denied Paths Register.

Evidence 22

Segmentation Validation Matrix.

Evidence 23

Defense-in-Depth Register.

Evidence 24

Positive Control Register.

Evidence 25

Segmentation Risk Matrix.

Evidence 26

Final Findings Register.

Evidence 27

Network Trust Map.

Evidence 28

Mission Challenge worksheet.

Mission Deliverables

Complete:

• scope revalidated

• security zones documented

• network architecture mapped

• expected communication flows defined before testing

• user-to-web access validated

• user-to-SSH restriction validated

• user-to-RDP restriction validated

• user-to-database restriction validated

• application-to-database flow validated

• management-to-SSH flow validated

• management-to-RDP flow validated

• management-plane restrictions assessed

• guest isolation tested

• SMB segmentation assessed

• DNS/SNMP infrastructure access assessed

• east-west communication reviewed

• firewall/ACL behavior validated through observed connectivity

• least-privilege network access assessed

• unexpected allowed paths documented

• unexpected blocked paths documented

• positive controls documented

• Segmentation Validation Matrix completed

• risk and confidence assigned

• findings written

• remediation prepared

• retest criteria defined

• Network Trust Map completed

• final report completed

Lab Report Template

# Lab 12 — Network Segmentation & Access Control Assessment

## Executive Summary

## Mission Objective

## Authorization and Scope

## Network Architecture

## Security Zone Inventory

## Segmentation Methodology

## Expected Communication Matrix

## User Network Assessment

### User to Web
### User to SSH
### User to RDP
### User to SMB
### User to Database
### User to Infrastructure

## Server Network Assessment

## Application-to-Database Assessment

## East-West Communication

## Management Network Assessment

### SSH
### RDP
### SNMP
### Administrative Web Interfaces

## Guest Network Isolation

## Database Tier Isolation

## Infrastructure Segmentation

## Firewall / ACL Enforcement

## Least-Privilege Network Access

## Segmentation Validation Matrix

## Positive Security Controls

## Segmentation Gaps

## Unexpected Restrictions

## Risk Assessment

## Validated Findings

### SEG-01
### SEG-02
### SEG-03

## Recommendations

## Retest Criteria

## Limitations

## Conclusion

Knowledge Check

Question 1 — What is network segmentation?

The separation of systems into controlled security zones with defined communication paths between them.

Question 2 — Why define expected flows before testing?

Because you need to know what should be allowed before deciding whether observed connectivity is secure or insecure.

Question 3 — Does failed ping prove a zone is segmented?

No.

ICMP may be blocked while other protocols remain accessible.

Question 4 — Does successful authentication prove a segmentation failure?

Not necessarily. Segmentation concerns whether the network path is available; authentication is a separate control.

Question 5 — Why should user systems generally not connect directly to databases?

Because users normally interact with data through application services, while direct database exposure increases the network attack surface.

Question 6 — What is management-plane isolation?

Restricting administrative services to approved management systems, networks, or paths.

Question 7 — What is east-west traffic?

Traffic between internal systems or internal security zones.

Question 8 — Why is guest-network isolation important?

Guest systems are generally less trusted and should not have unnecessary access to internal enterprise resources.

Question 9 — Is every denied connection a positive security control?

No.

A legitimate required business flow may have been incorrectly blocked.

Question 10 — What is the central question of this lab?

Can systems communicate only across network paths required for legitimate business functions, or do unnecessary trust relationships expose sensitive services across security boundaries?

Skills Achieved

After completing this lab, you should understand:

• network segmentation concepts

• security-zone identification

• expected-flow modeling

• user-network restrictions

• database-tier isolation

• management-plane isolation

• guest-network isolation

• east-west communication

• firewall and ACL validation

• least-privilege network access

• allowed-vs-denied path analysis

• management-service exposure

• infrastructure segmentation

• defense in depth

• positive-control validation

• segmentation-gap identification

• risk prioritization

• evidence-based segmentation findings

• remediation and retesting

Professional Takeaway

A weak segmentation assessment looks like:

Ping Network
    ↓
Host Responds
    ↓
Network Is Flat

A professional assessment looks like:

Understand Zones
      ↓
Define Required Flows
      ↓
Define Expected Denials
      ↓
Test Specific Services
      ↓
Compare Source Networks
      ↓
Validate Allowed Paths
      ↓
Validate Denied Paths
      ↓
Identify Trust Gaps
      ↓
Assess Business Impact
      ↓
Evidence-Based Finding

Always distinguish:

Ping Works
    ≠
All Services Reachable

Ping Blocked
    ≠
Segmentation Proven

Authentication Blocks Access
    ≠
Network Access Blocked

Service Reachable
    ≠
Service Exploitable

Firewall Rule Exists
    ≠
Firewall Rule Works

One Unexpected Flow
    ≠
Entire Network Is Flat

Connection Denied
    ≠
Specific Firewall Identified

By the end of this lab, you should be able to answer:

“Do the network’s actual trust relationships match the intended architecture, and can every permitted cross-zone path be justified by a legitimate business requirement?”

What’s Next?

➡️ Lab 13 — Network Attack-Path Analysis

In the next lab, you will combine everything discovered so far—hosts, services, vulnerabilities, authentication surfaces, Windows and Linux exposure, infrastructure services, traffic relationships, and segmentation gaps—to model realistic attack paths through the network.

You will work with:

• entry points

• exposed services

• trust boundaries

• authentication surfaces

• validated vulnerabilities

• excessive permissions

• management exposure

• segmentation gaps

• high-value assets

• dependency chains

• attack-path diagrams

• control-break analysis

• remediation prioritization

The methodology becomes:

Entry Point → Exposure → Weakness → Trust Relationship → Reachable Asset → Security Impact → Control Break → Remediation Priority

The central question will be:

“If one authorized lab system were compromised, which validated network relationships and weaknesses could increase the attacker’s reach, and which security controls should be strengthened first to break those paths?”