Chapter 12: Operations & Maintenance

Day-to-day operational procedures, scheduled maintenance tasks, patch management, rule lifecycle management, incident response integration, and long-term architecture evolution planning.

The operational phase of a segmentation deployment is where the majority of the system's lifecycle cost and risk occur. A well-designed architecture that is poorly operated will degrade in security posture over time as rules accumulate, patches are delayed, and documentation falls out of date. This chapter defines the operational procedures, maintenance schedules, and governance processes that must be in place to maintain the security effectiveness of the segmentation architecture over its operational life.

12.1 Daily Operational Procedures

The following daily operational tasks must be performed by the network operations team at the start of each business day. These tasks are designed to detect issues that may have occurred overnight and to ensure the system is in a known-good state before the business day begins. Tasks should be performed in the order listed, as later tasks depend on the results of earlier tasks.

Task	Description	Tool / Method	Expected Result	Escalation if Failed
HA Status Check	Verify all HA pairs are synchronized and both nodes are active	NGFW/ISFW management console	All pairs: Active-Passive synchronized	Network Ops Lead
Log Pipeline Check	Verify all log sources are forwarding to SIEM; check for gaps	SIEM log source dashboard	All sources active; no gaps >15 min	SOC Analyst + SIEM Admin
Interface Status Check	Verify all data plane and management interfaces are up	NMS / SNMP dashboard	All interfaces: Up/Up	Network Ops Lead
Security Alert Review	Review overnight security alerts; triage and assign	SIEM / SOAR dashboard	All Critical/High alerts triaged	SOC Lead
Backup Verification	Verify overnight configuration backups completed successfully	Backup management console	All backups: Success	Network Ops Lead
Certificate Expiry Check	Check for certificates expiring within 30 days	PKI management console / monitoring	No certs expiring within 30 days	Security Engineer

12.2 Scheduled Maintenance Calendar

The following maintenance tasks must be scheduled and performed at the defined intervals. All scheduled maintenance must be performed within a defined maintenance window, communicated to stakeholders in advance, and documented in the change management system. The maintenance calendar should be reviewed and updated annually to incorporate new requirements from vendor advisories and compliance frameworks.

Maintenance Task	Frequency	Duration	Maintenance Window	Owner	Documentation Required
Security patch assessment	Weekly	2 hours	Business hours	Security Engineer	Patch assessment report
Security patch deployment (critical)	Within 72 hours of release	2–4 hours	Off-hours window	Network Engineer	Change ticket + test results
Security patch deployment (high)	Within 30 days of release	2–4 hours	Off-hours window	Network Engineer	Change ticket + test results
Firewall rule review and cleanup	Quarterly	4–8 hours	Business hours	Security Architect	Rule review report; cleanup log
HA failover test	Quarterly	2 hours	Off-hours window	Network Engineer	Failover test report
Penetration test (segmentation focus)	Annual	1–2 weeks	Scheduled with business	External pen tester	Pen test report; remediation plan
Disaster recovery test	Annual	1 day	Scheduled weekend	Network Ops + Security	DR test report
Architecture review	Annual	2–3 days	Business hours	Security Architect	Architecture review report
Documentation review and update	Annual + after major changes	1–2 days	Business hours	Network Engineer	Updated documentation set

12.3 Patch Management Process

Patch management for security appliances requires a balance between security urgency and operational stability. Unlike general-purpose servers, security appliances are in the critical path for all network traffic, and a failed patch deployment can cause a network outage. The patch management process must include a testing phase in a non-production environment before production deployment, except for critical zero-day patches where the risk of delay outweighs the risk of a failed patch.

Patch Severity	CVSS Score Range	Assessment SLA	Deployment SLA	Testing Required	Rollback Plan Required
Critical (Zero-Day)	CVSS 9.0–10.0 (actively exploited)	Immediate	Within 24 hours	Abbreviated (2 hours)	Yes (mandatory)
Critical	CVSS 9.0–10.0	24 hours	Within 72 hours	Full test cycle	Yes (mandatory)
High	CVSS 7.0–8.9	72 hours	Within 30 days	Full test cycle	Yes (mandatory)
Medium	CVSS 4.0–6.9	1 week	Within 90 days	Full test cycle	Yes (recommended)
Low	CVSS 0.1–3.9	1 month	Next scheduled maintenance	Standard regression	Optional
Feature / Non-security	N/A	Quarterly assessment	Annual or as needed	Full test cycle	Yes (mandatory)

12.4 Firewall Rule Lifecycle Management

Every firewall rule has a lifecycle: it is created for a specific business purpose, it serves that purpose for a period of time, and eventually the business purpose changes and the rule should be modified or removed. Without active rule lifecycle management, firewall rule sets grow continuously, become harder to understand and audit, and accumulate rules that no longer serve a valid business purpose — each of which represents an unnecessary attack surface. The rule lifecycle process must be enforced through the change management system and the quarterly rule review process.

Rule Creation: Every new rule must have an associated change ticket with a documented business justification, the name of the requestor and approver, the date of creation, and an expiry date if the rule is for a temporary purpose.
Rule Review: All rules must be reviewed at least quarterly. Rules that have not been reviewed within 180 days are automatically flagged for cleanup. Rules with no associated ticket are flagged as unauthorized and must be investigated.
Rule Cleanup: Rules that are no longer needed must be disabled (not deleted) for a 30-day observation period before permanent deletion. This allows detection of any traffic that was relying on the rule that was not documented.
Rule Expiry: Temporary rules must have an expiry date set at creation. An automated process must disable expired rules and notify the rule owner. The rule owner must either renew the rule with a new justification or confirm deletion.
Shadow Rule Detection: Quarterly rule reviews must include a shadow rule analysis to identify rules that are completely shadowed by earlier rules in the policy and therefore never match any traffic.

12.5 Incident Response Integration

The segmentation architecture must be integrated with the organization's incident response process. During a security incident, the segmentation infrastructure provides both detection capability (through firewall logs and SIEM alerts) and containment capability (through dynamic rule changes and zone isolation). The incident response team must have documented procedures for using the segmentation infrastructure as a containment tool.

Incident Type	Segmentation Response Action	Authorization Required	Rollback Trigger	Documentation Required
Ransomware detected in Office zone	Isolate affected VLAN segment; block lateral movement	SOC Lead	Incident resolved + forensics complete	Incident ticket; firewall rule changes
Compromised server in Production zone	Quarantine server to isolation VLAN; block all outbound	SOC Lead + Network Ops	Server reimaged and verified clean	Incident ticket; quarantine log
Data exfiltration attempt detected	Block destination IPs; increase logging on Data zone	CISO or delegate	Investigation complete	Incident ticket; blocking rules
Unauthorized device on network	NAC quarantine VLAN; block all access	SOC Analyst	Device identified and removed	NAC event log; incident ticket
Brute force attack on VPN/ZTNA	Block source IPs; increase auth logging	SOC Analyst	Attack subsides + source investigated	Incident ticket; blocking rules

12.6 Long-Term Architecture Evolution

Network security architecture is not static. As the organization's business requirements evolve, new technologies emerge, and the threat landscape changes, the segmentation architecture must evolve to remain effective. The annual architecture review process should assess the current architecture against the following evolution drivers and produce a roadmap for the next 12–24 months.

Evolution Driver	Architectural Response	Typical Timeline	Key Dependencies
Cloud adoption (IaaS/PaaS)	Extend zone model to cloud; deploy cloud-native NGFW or virtual appliances; implement CSPM	6–18 months	Cloud strategy; identity federation
Remote workforce growth	Replace VPN with ZTNA; integrate device posture into access policy	12–24 months	MDM/EDR deployment; IdP maturity
Zero Trust adoption	Evolve from zone-based to identity+device+context-based policy; deploy microsegmentation	24–48 months	Full asset inventory; mature IdP; SIEM/SOAR
OT/IoT expansion	Add dedicated OT/IoT zones; deploy OT-aware IPS; implement Purdue model	12–24 months	OT asset inventory; OT security expertise
AI/ML workloads	Add GPU cluster zone with high-bandwidth east-west; implement data governance controls	6–12 months	Data classification; network capacity
Regulatory changes	Update zone design and controls to meet new requirements; re-validate compliance	Per regulation deadline	Legal/compliance team input