Chapter 6: Implementation Guide

Step-by-step deployment methodology, phased rollout strategy, configuration standards, and acceptance testing procedures for production segmentation projects.

Implementing a network segmentation project in a production environment is a high-risk, high-impact activity. Unlike most IT projects, a misconfiguration in a segmentation deployment can simultaneously break legitimate business traffic and create security gaps — both outcomes are unacceptable. The implementation methodology described in this chapter is designed to minimize risk through careful planning, phased rollout, and rigorous testing at each stage before proceeding to the next.

6.1 Pre-Implementation Checklist

Before any physical or logical change is made to the production environment, the following pre-implementation checklist must be completed and signed off by the project sponsor, security team lead, and network operations lead. Items marked as mandatory cannot be waived — if they cannot be completed, the implementation must be postponed.

#	Checklist Item	Owner	Mandatory?	Verification Method
1	Zone design document reviewed and approved	Security Architect	Yes	Signed approval document
2	Inter-zone access matrix reviewed and approved by zone owners	Zone Owners	Yes	Signed approval per zone
3	Change management ticket raised and approved	Change Manager	Yes	CAB approval record
4	Rollback plan documented and tested in lab	Network Engineer	Yes	Lab test report
5	Maintenance window scheduled and communicated	Project Manager	Yes	Communication record
6	Configuration backups taken for all affected devices	Network Engineer	Yes	Backup verification report
7	Lab environment test completed successfully	Network Engineer	Yes	Lab test report
8	Monitoring alerts configured for implementation window	SOC Analyst	Yes	Alert configuration screenshot
9	Business continuity plan activated for critical services	Business Owner	Conditional	BCP activation record
10	Vendor support on standby (if applicable)	Project Manager	Conditional	Vendor support ticket

6.2 Phased Rollout Strategy

The recommended rollout strategy divides the implementation into five phases, each with a defined scope, success criteria, and go/no-go decision point. Phases must be completed in order — proceeding to the next phase before the current phase is fully stable is the most common cause of implementation failures. Each phase should be followed by a stabilization period of at least five business days before the next phase begins.

Phase	Scope	Duration	Success Criteria	Go/No-Go Decision
Phase 1 Infrastructure Prep	Install hardware, configure OOB management, configure HA, verify physical connectivity	1–2 weeks	All devices reachable via OOB; HA failover tested; no production traffic affected	Security Architect + Network Lead
Phase 2 DMZ Segmentation	Implement DMZ zone, configure NGFW DMZ policies, migrate public-facing services	1–2 weeks	All published services accessible; no unintended access to internal zones; WAF operational	Security Architect + App Owner
Phase 3 Management Zone	Deploy bastion host, configure PAM, migrate admin access to bastion-only paths	1–2 weeks	All admin access via bastion; direct SSH/RDP blocked; session recording operational	Security Architect + IT Ops Lead
Phase 4 Production Segmentation	Deploy ISFW, implement Production and Data zone policies, configure DB audit	2–4 weeks	All app-to-DB flows working; unauthorized flows blocked; DB audit capturing all queries	Security Architect + App Owner + DBA
Phase 5 Office and NAC	Deploy NAC, configure 802.1X, implement Office zone policies, enable guest portal	2–4 weeks	All managed devices authenticated; guest devices in isolated VLAN; IoT devices profiled	Security Architect + IT Helpdesk Lead

6.3 Configuration Standards

Consistent configuration standards ensure that the segmentation design is implemented correctly across all devices and that future changes are made in a controlled, predictable manner. The following standards apply to all security appliances in the segmentation architecture. Deviations from these standards require documented approval from the security architect.

Default-Deny Baseline: All firewall policies must start from a default-deny posture. Permitted flows must be explicitly defined with the minimum necessary source, destination, service, and application scope.
Rule Naming Convention: All firewall rules must follow the naming convention: [SOURCE-ZONE]_to_[DEST-ZONE]_[APPLICATION]_[TICKET-ID]. Example: OFFICE_to_PROD_SAP-HTTP_CHG-2024-0042.
Rule Documentation: Every rule must have a description field populated with the business justification, the approving ticket ID, and the review date.
Logging: All permit and deny actions must be logged. Log forwarding to the SIEM must be configured on all devices before the device is placed in production.
Management Access: Management access to all security appliances must be restricted to the Management zone IP range only. No management access from Office, Production, or DMZ zones is permitted.
NTP Synchronization: All devices must synchronize time from the internal NTP hierarchy. Time drift greater than 1 second is unacceptable for log correlation.
Password and Authentication: All local accounts must use passwords of at least 16 characters. Service accounts must use certificate-based authentication where supported. MFA is required for all interactive admin sessions.

6.4 Acceptance Testing Procedures

Acceptance testing verifies that the implemented segmentation matches the approved design. Testing must cover both positive tests (verifying that permitted flows work) and negative tests (verifying that denied flows are blocked). A failed negative test — where a denied flow is not blocked — is a critical finding that must be remediated before the implementation is accepted.

Test Category	Test Description	Expected Result	Test Tool	Severity if Failed
Positive — DMZ	Access published web service from Internet	HTTP 200 response; WAF operational	curl, browser	Critical
Negative — DMZ	Attempt direct connection from Internet to Office IP	Connection refused / timeout	nmap, curl	Critical
Positive — Admin	Admin SSH to production server via bastion	Session established; recorded in PAM	SSH client	Critical
Negative — Admin	Direct SSH from Office to production server	Connection refused / timeout	SSH client	Critical
Positive — App	Application server connects to database on allowed port	Connection established; DB audit log entry created	App test, DB client	Critical
Negative — Data	Office workstation attempts direct DB connection	Connection refused / timeout	DB client	Critical
Positive — NAC	Managed device authenticates via 802.1X and gets correct VLAN	Correct VLAN assigned; network access granted	Managed endpoint	High
Negative — NAC	Unmanaged device attempts to connect to Office VLAN	Redirected to guest VLAN or blocked	Unmanaged device	High
HA Failover	Pull active NGFW power cable; verify traffic continues	Failover within RTO target; no session loss	Traffic generator	High
Logging	Generate test traffic for each zone boundary; verify SIEM receipt	All test events appear in SIEM within 60 seconds	SIEM query	High

Critical Requirement: All negative tests (denied flow tests) must pass with a 100% block rate before the implementation is accepted. A single failed negative test indicates a policy misconfiguration that could allow lateral movement or data exfiltration. Do not accept the implementation until all critical findings are remediated and re-tested.