FC-01 · Firewalls and Network Security — IT Staff Technical Procedures
SCM variant: isms-it-staff · isms-security. This content sits below the all-staff guidance in FC-01 and is not visible to isms-all-staff.
Document scope and architecture
This procedure governs the technical design, configuration, ongoing management, and evidence production for all boundary firewall and network security controls across the CUI-scope environment. It implements NIST SP 800-171 controls SC.L1-3.13.1 (monitor, control, and protect communications at external and internal boundaries), SC.L1-3.13.5 (implement subnetworks for publicly accessible components), and AC.L1-3.1.20 (verify and control connections to external systems), satisfies Cyber Essentials Firewalls domain requirements, and meets DEFSTAN Profile 0 §Boundary and Profile 1 §Boundary obligations.
The full advanced-tier SSP content for all sixteen SC controls is in AT-SC-BDY, AT-SC-ENC, and AT-SC-ARC. This procedure provides the operational implementation detail that IT Operations engineers need to configure, maintain, and evidence the boundary controls on a day-to-day and periodic basis.
Sections:
- Section 1: Network architecture and zone model — technical specification
- Section 2: Perimeter firewall — stateful inspection configuration
- Section 3: DMZ architecture and inter-zone rule sets
- Section 4: Internal boundary enforcement — CUI VLAN and management plane
- Section 5: Outbound filtering — web proxy, egress control, and DNS filtering
- Section 6: IDS/IPS configuration and alert management
- Section 7: Firewall rule review procedure (generates EV-F03)
- Section 8: Logging requirements and SIEM integration
- Section 9: VPN and remote access security
- Section 10: Cloud boundary controls
- Section 11: Evidence generation and maintenance
Deployed platforms:
Perimeter firewall: [product — e.g. Palo Alto PA-Series / Fortinet FortiGate /
Cisco Firepower / Sophos XGS — specify]
Firewall management: [Panorama / FortiManager / Firepower Management Centre / etc.]
Management console URL: [internal URL — Zone 4 access only]
IDS/IPS: [inline IPS on perimeter / NGFW threat prevention engine /
standalone IDS — specify]
Web proxy: [Zscaler / FortiProxy / Squid + blocklists — specify]
DNS filter: [Cisco Umbrella / Cloudflare Gateway / NextDNS — specify]
SIEM: [Microsoft Sentinel / Splunk / Elastic / QRadar — specify]
SIEM syslog collector: [IP address] — port 514 TCP
Network management: [Cisco DNA / Junos Space / manual — specify]
Section 1 — Network architecture and zone model
1.1 Zone definitions and technical implementation
The zone model defines the trust boundaries the firewall enforces.
Every zone is implemented as a distinct VLAN with routing between zones
controlled exclusively by firewall policy — no inter-VLAN routing occurs
at the switch layer without passing through a firewall inspection point.
ZONE 0 — INTERNET (UNTRUSTED)
Definition: Everything outside organisational control
Trust level: Zero — all traffic is assumed hostile until explicitly permitted
IP space: All public IP ranges not allocated to the organisation
Controls: Perimeter firewall with default-deny inbound
IPS inline on the perimeter ingress path
DDoS mitigation (ISP-level or cloud scrubbing — specify if deployed)
ZONE 1 — DMZ (DEMILITARISED ZONE)
Definition: Hosts that must be reachable from Zone 0 (publicly accessible)
VLAN ID: 10
IP subnet: [e.g. 10.0.10.0/24]
Trust level: Semi-trusted — internet-facing, not trusted by internal zones
Hosts: Reverse proxy / WAF, email gateway (MX), VPN concentrator,
public DNS resolver (if separately hosted), externally accessible API GW
Controls: Firewall policy between Zone 0 and Zone 1 (inbound permits)
Firewall policy between Zone 1 and Zone 2 (strict — no general DMZ→LAN)
IPS inline on Zone 0 → Zone 1 path
CUI: NEVER stored in Zone 1. If a Zone 1 service proxies CUI content,
the CUI is stored in Zone 3 and fetched via application-layer call.
ZONE 2 — INTERNAL GENERAL (TRUSTED)
Definition: General office network — staff workstations, printers, meeting room devices
VLAN ID: 20
IP subnet: [e.g. 10.0.20.0/23]
Trust level: Trusted for standard users; not trusted for CUI server access
(CUI server access requires identity-aware policy)
Hosts: Staff Windows/macOS workstations, BYOD-approved devices (MDM enrolled),
IP phones (VoIP), printers, meeting room screens
Controls: Firewall policy between Zone 2 and Zone 3 (identity-aware permit rules)
All outbound internet traffic via web proxy (no direct internet)
802.1X port authentication on switch ports (EAP-TLS)
ZONE 3 — CUI SERVERS (MOST TRUSTED)
Definition: CUI-processing servers and storage systems
VLAN ID: 30
IP subnet: [e.g. 10.0.30.0/24]
Trust level: Highest — restricted to specifically authorised workstations and users
Hosts: CUI file server, CUI database server, domain controllers,
certificate authority, LDAP/AD infrastructure
Controls: Firewall policy between Zone 2 and Zone 3 (application-specific permits only)
No direct internet access from Zone 3 hosts (all outbound via proxy)
All Zone 3 management via Zone 4 jump host only (no direct admin from Zone 2)
SIEM log forwarding from all Zone 3 hosts (all security events)
ZONE 4 — MANAGEMENT VLAN (ADMIN PLANE)
Definition: Network device management interfaces, hypervisor management, BMC/IPMI,
scanner host, PAM jump host
VLAN ID: 40
IP subnet: [e.g. 10.0.40.0/24]
Trust level: Highest — accessible only by named IT Operations admin accounts
Hosts: Firewall management interface, switch management IPs, ACS server,
vulnerability scanner (svc-vulnscan host), PAM jump host,
SIEM log collector, NTP stratum 1
Controls: No route from Zone 0 to Zone 4 (no internet-facing management)
No route from Zone 2 or Zone 3 to Zone 4 without explicit permit
Only specific Zone 2 admin workstations (adm- accounts) can reach Zone 4
Separate SSID or no wireless access to Zone 4
ZONE 5 — GUEST / VISITOR (UNTRUSTED INTERNAL)
Definition: Visitor and contractor internet access; BYOD personal traffic
VLAN ID: 50
IP subnet: [e.g. 192.168.100.0/24] — different RFC1918 range from internal
(Prevents overlap with internal ranges if guest accidentally connects to VPN)
Trust level: Untrusted — treated as if external
Hosts: Visitor devices, personal phones, contractor laptops (non-enrolled)
Controls: No route to Zone 2, 3, or 4 — internet only via NAT
Captive portal: acceptable use acknowledgement before internet granted
Bandwidth cap: [N] Mbps per device (prevents abuse)
DNS: public resolver only (not internal DNS — prevents hostname enumeration)
SIEM: guest DHCP leases and high-volume usage events logged
1.2 VLAN configuration on managed switches
Trunk port configuration (uplinks to firewall and between switches):
All VLANs (10, 20, 30, 40, 50) trunked on uplink ports
Native VLAN: 99 (unused VLAN — no hosts; prevents VLAN hopping)
DTP (Dynamic Trunking Protocol): disabled on all ports
Cisco: switchport nonegotiate
Juniper: no-auto-negotiation
Configuration (Cisco IOS example):
interface GigabitEthernet0/1 ! uplink to firewall
switchport mode trunk
switchport trunk native vlan 99
switchport trunk allowed vlan 10,20,30,40,50
switchport nonegotiate
Access port configuration (host-facing ports):
Zone 2 standard workstation port:
interface GigabitEthernet0/5
switchport mode access
switchport access vlan 20
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable ! prevents rogue switches
storm-control broadcast level 20 ! prevents broadcast storms
ip dhcp snooping limit rate 15 ! DHCP snooping rate limit
Zone 3 server port:
interface GigabitEthernet0/10
switchport mode access
switchport access vlan 30
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
no cdp enable ! disable CDP on server ports
no lldp transmit
no lldp receive
Unused ports (security hardening):
interface range GigabitEthernet0/20-48
switchport mode access
switchport access vlan 99 ! unused VLAN — no DHCP, no routing
shutdown ! administratively disabled
DHCP snooping (prevents rogue DHCP servers):
ip dhcp snooping
ip dhcp snooping vlan 10,20,30,50 ! Zone 40 (management) uses static IPs — not snooped
no ip dhcp snooping information option
Trust only the uplink port (towards DHCP server):
interface GigabitEthernet0/1
ip dhcp snooping trust
All access ports: untrusted by default (no command needed — default is untrusted)
Dynamic ARP Inspection (prevents ARP spoofing/MitM):
ip arp inspection vlan 10,20,30,50
Trust the uplink (towards router/firewall):
interface GigabitEthernet0/1
ip arp inspection trust
802.1X port authentication (Zone 2 and Zone 3 ports):
aaa new-model
aaa authentication dot1x default group radius
dot1x system-auth-control
Per-port:
interface GigabitEthernet0/5
authentication port-control auto
dot1x pae authenticator
authentication event fail action next-method
mab ! MAC Authentication Bypass for non-802.1X devices
authentication order dot1x mab
authentication priority dot1x mab
Section 2 — Perimeter firewall stateful inspection configuration
2.1 Stateful inspection and session handling
Stateful inspection (also called Stateful Packet Inspection — SPI) maintains
a session state table tracking every active connection. A response packet that
matches an established session is permitted automatically; a packet claiming
to be a response to a session that does not exist is dropped.
The perimeter firewall must enforce SPI on all interfaces. Pure packet
filtering (accepting packets based only on header fields without session state)
is explicitly prohibited on boundary devices.
REQUIRED STATEFUL INSPECTION SETTINGS:
Session table configuration:
Maximum concurrent sessions: [product-dependent — set to 80% of hardware maximum]
Session aging:
TCP established: 3600 seconds (1 hour)
TCP half-open: 10 seconds (prevents SYN flood resource exhaustion)
UDP: 30 seconds
ICMP: 10 seconds
Half-open session limit (SYN flood protection):
Maximum half-open sessions: 1000 (tune based on observed legitimate traffic)
SYN cookies: enabled (prevents SYN flood from exhausting session table)
Note: these values are starting points. Review after 30 days of production
traffic and adjust based on legitimate connection patterns observed in logs.
Connection tracking for asymmetric routing (if applicable):
If the environment has asymmetric routing (traffic enters on one firewall,
exits on another), disable strict state checking on the asymmetric path
and document the exception in EV-D19 with CISO approval.
Asymmetric routing = reduced inspection quality; avoid where possible.
Protocol anomaly detection (NGFWs — enable all):
TCP split-handshake detection: block
IP fragmentation reassembly: enabled with fragment limit [N]
Packet size anomaly: block packets claiming invalid lengths
Protocol conformance checking: enforce RFC conformance for HTTP, DNS, SMB, FTP
These catch protocol-level evasion techniques that bypass signature detection.
IP spoofing protection (anti-spoofing):
On the external interface: drop packets with source addresses in RFC1918 space
(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8),
link-local (169.254.0.0/16), or this-network (0.0.0.0/8)
These addresses should never appear as source IPs from the internet.
On internal interfaces: drop packets with source addresses not in the
expected range for that VLAN (prevents internal spoofing)
Palo Alto (zone protection profile):
Zone protection → [External] → Spoofed IP address: Enable
Zone protection → [External] → Reconnaissance protection: Enable
FortiGate:
config system settings
set anti-replay enable
end
(Anti-spoofing via RPF check is enabled on all interfaces)
FIREWALL BASELINE SETTINGS (hardware and software):
Management interface:
Accessible from: Zone 4 only — [specific jump host IP or Zone 4 subnet]
Authentication: PAM-mediated; FIDO2 for firewall admin accounts
Protocols permitted: HTTPS (management GUI); SSH (CLI)
Protocols disabled: Telnet, HTTP, SNMP v1, SNMP v2c
SNMP: v3 only with authPriv (auth + encryption) — no community strings
Palo Alto:
set deviceconfig system permitted-ip [Zone-4-subnet]
set deviceconfig setting management admin-lockout failed-attempts 5 lockout-time 30
FortiGate:
config system interface
edit "mgmt"
set allowaccess https ssh snmp
set management-ip [mgmt-IP]/24
end
Logging (all interfaces):
All permitted traffic: log (required for EV-F01 monthly review)
All denied traffic: log + alert for volume anomalies
Log forwarding: syslog TCP to SIEM within 60 seconds of event
Log retention on firewall: minimum 30 days local (SIEM retains 90 days hot)
Note: logging all permitted traffic generates significant volume. If log
volume is a concern, prioritise: all Zone 0→Zone 1 permitted, all Zone 2→Zone 3
permitted, all Zone 1→Zone 2 attempts, and ALL denied events (mandatory).
General Zone 2 internet traffic via proxy: log at the proxy level, not the firewall.
Firmware version:
Current supported release: verify at vendor PSIRT page (monthly per FC-05 procedure)
Firmware patch SLA: Critical CVE 7 days; High CVE 14 days (per FC-05 EV-D07)
Maintenance window for firmware upgrade: Tuesday/Thursday 22:00–02:00 UTC
Pre-upgrade: export running configuration; take snapshot; confirm rollback path
2.2 Rule base architecture
FIREWALL RULE ORDERING PRINCIPLE:
Rules are evaluated top-to-bottom. The first matching rule wins.
Structure every rule base in this order:
1. Administrative rules (at the top):
Loopback / management self-traffic permits
2. Explicit deny rules for known-bad:
Block lists from threat intelligence (malicious IPs/CIDRs)
Block deprecated protocols (Telnet, SNMP v1/v2, unencrypted management)
3. Explicit permit rules (business-required traffic only):
Each permit rule must have a named source, destination, application/port,
and a description field with the business justification
4. Default deny rule (at the bottom — must be last):
Action: DENY
Source: any
Destination: any
Application: any
Log: YES (always — this is the catch-all evidence of what was blocked)
Description: "Default deny — all unmatched traffic blocked"
RULE NAMING CONVENTION (mandatory — required for EV-F03 compliance):
Format: [ACTION]-[SOURCE-ZONE]-[DEST-ZONE]-[SERVICE]-[BRIEF-PURPOSE]
Examples (compliant):
PERMIT-Internet-DMZ-HTTPS-PublicWebProxy
PERMIT-Internet-DMZ-SMTP-EmailGatewayInbound
PERMIT-Internet-Zone1-VPN-RemoteAccessGateway
PERMIT-Zone2-Zone3-SMB-CUIFileServerAccess
PERMIT-Zone2-Internet-HTTPS-WebProxyOutbound
DENY-Internet-Zone2-Any-NoDirectInternalAccess
DEFAULT-DENY-Any-Any-ImplicitDrop
Examples (non-compliant — fail rule review):
Rule_47
New Rule
Temp rule
[blank description]
Test
RULE DESCRIPTION FIELD (mandatory — every rule):
The description field must answer: "Why does this rule exist?"
Good description:
"Permits inbound HTTPS to WAF/reverse proxy (10.0.10.5) from internet.
WAF inspects and proxies all web traffic to the internal web application.
Requested by: [IT Manager]. Approved by: [CISO]. Date: [YYYY-MM-DD].
Review date: [YYYY-MM-DD + 6 months]."
Bad description (fails rule review):
"Web traffic"
"Required"
"See ticket 1247"
[blank]
Any rule without a compliant description is flagged in EV-F03 as a finding
and must be documented or removed within 30 days.
Section 3 — DMZ architecture and inter-zone rule sets
3.1 DMZ design principles
The DMZ satisfies SC.L1-3.13.5 (subnetworks for publicly accessible components).
The fundamental architectural constraint is:
A successful compromise of any Zone 1 (DMZ) host must NOT give an attacker
direct access to Zone 2 or Zone 3 systems.
This constraint is enforced by:
(a) No permit rule allowing Zone 1 hosts to initiate connections to Zone 2 or Zone 3
except through specific application-layer inspection at specific ports
(b) Internal systems that need to serve Zone 1 (e.g. backend database for a DMZ app):
the internal system initiates the connection from Zone 2/3 to Zone 1,
not the other way
(c) Any Zone 1 → Zone 2 communication that is unavoidable must:
pass through an application-layer firewall inspection point (NGFW app-ID, not port)
be for a specific documented application
be reviewed at every rule review cycle (EV-F03)
PHYSICAL vs LOGICAL DMZ:
Physical DMZ: separate firewall hardware dedicated to the DMZ boundary
Advantage: DMZ firewall compromise does not affect internal firewall
Disadvantage: cost; additional management overhead
Logical DMZ (single NGFW, multiple zones):
Advantage: lower cost; centralised management
Disadvantage: single firewall compromise affects all zones
Mitigation: strong firewall hardening (Section 2.1); separate firewall
software tenants if platform supports (VSYS on Palo Alto; VDOM on FortiGate)
For DEFSTAN Profile 2: physical or logical DMZ is acceptable if the firewall
platform configuration is documented and the zone separation is verified.
Current implementation: [specify Physical or Logical; specify platform]
3.2 Inbound rules — Zone 0 to Zone 1 (internet to DMZ)
STANDARD INBOUND PERMIT RULES:
The following represents the minimum typical ruleset.
Only permit rules for services that are actually deployed and required.
Delete template rules for services not in use.
Rule: PERMIT-Internet-DMZ-HTTPS-PublicWebProxy
Source zone: Zone 0 (Internet) — any source IP
Destination zone: Zone 1 (DMZ)
Destination IP: [WAF/Reverse proxy internal IP, e.g. 10.0.10.5]
Application: HTTPS (TCP 443)
Action: Permit
Logging: All sessions
IPS profile: Internet-inbound-strict (full IPS profile — see Section 6)
Description: Permits public HTTPS to reverse proxy / WAF. WAF inspects
all inbound web traffic before forwarding to backend.
Requested: [name] [date]. Approved: [CISO] [date].
Rule: PERMIT-Internet-DMZ-SMTP-EmailGatewayInbound
Source zone: Zone 0 (Internet) — any source IP
Destination zone: Zone 1 (DMZ)
Destination IP: [Email gateway IP, e.g. 10.0.10.10]
Application: SMTP (TCP 25)
Action: Permit
Logging: All sessions
IPS profile: Internet-inbound-strict
Description: Permits inbound SMTP for email delivery to gateway.
Gateway applies AV, sandbox, DMARC, SPF, DKIM before
forwarding to internal mail server.
Rule: PERMIT-Internet-DMZ-ISAKMP-VPN
Source zone: Zone 0 (Internet) — any source IP
Destination zone: Zone 1 (DMZ)
Destination IP: [VPN gateway IP, e.g. 10.0.10.20]
Application: IKE (UDP 500), IPsec-NAT-T (UDP 4500)
Action: Permit
Logging: All sessions
Description: Permits IKEv2/IPsec for remote access VPN.
User authentication: certificate + Entra ID MFA (no split tunnelling).
Rule: DENY-Internet-Zone1-Management-BlockAdminPorts
Source zone: Zone 0 (Internet) — any source IP
Destination zone: Zone 1 (DMZ) — any destination
Application: SSH (TCP 22), RDP (TCP 3389), HTTPS-MGMT (TCP 8443),
SNMP (UDP 161), Telnet (TCP 23), WinRM (TCP 5985/5986)
Action: Deny + Log
Priority: Above the PERMIT-Internet-DMZ-HTTPS rule
Description: Blocks management protocol access from internet to DMZ.
Management of DMZ hosts occurs from Zone 4 only.
This rule prevents internet-facing management exposure.
Rule: DEFAULT-DENY (bottom of rule base):
See Section 2.2 — applies to all zones
WHAT MUST NEVER APPEAR IN INBOUND RULES:
Source: "any" Destination: "any" Application: "any" Action: Permit
→ This permits all traffic from internet to DMZ — completely unacceptable
Source: "any" Destination: Zone 2 or Zone 3 subnet Action: Permit
→ Direct internet access to internal network — absolute prohibition
A rule permitting inbound traffic to a port range rather than specific ports:
e.g. Destination port: 1–65535 — not acceptable; must specify individual ports
A rule permitting inbound on a port used for administrative access:
e.g. HTTPS/443 to a management interface on the firewall itself from the internet
— management interface must not be internet-accessible
3.3 DMZ to internal rules — Zone 1 to Zone 2 and Zone 3
The default position: Zone 1 (DMZ) cannot initiate connections to Zone 2 or Zone 3.
PERMITTED ZONE 1 → ZONE 3 RULES (only where architecturally required):
For a DMZ web application that needs to authenticate users against Active Directory:
Rule: PERMIT-DMZ-Zone3-LDAPS-AuthQuery
Source zone: Zone 1 (DMZ)
Source IP: [specific DMZ web server IP — not the entire /24 subnet]
Destination zone: Zone 3 (CUI Servers)
Destination IP: [Domain controller IP — not the entire /24 subnet]
Application: LDAPS (TCP 636) — NOT unencrypted LDAP (TCP 389)
Action: Permit
Logging: All sessions
Description: Permits LDAPS auth queries from DMZ web server to DC.
Using LDAPS (encrypted) not LDAP (unencrypted).
LDAP traffic carries credentials — must be encrypted.
Requested: [name] [date]. CISO approved: [date].
Principle: any permitted Zone 1→Zone 3 rule requires CISO approval
Reason: each such rule is a potential lateral movement path post-DMZ-compromise
List all such rules in EV-F03 for specific review at each rule cycle
PREVENTING DMZ → INTERNAL INITIATED CONNECTIONS (architecture enforcement):
Application architecture principle:
The application backend (Zone 2 or Zone 3) polls or calls the DMZ component,
not the other way around. This pattern means:
Web server (Zone 1) → receives HTTP requests
Backend application server (Zone 3) → polls Zone 1 reverse proxy for application data
Database (Zone 3) → never directly reachable from Zone 1
If the current architecture requires Zone 1 to initiate connections to Zone 3:
This is an architectural risk — document in AT-RA risk register
Consider refactoring the architecture (IT Manager + CISO review)
If refactoring is not feasible: CISO risk acceptance + compensating controls
(enhanced monitoring on all Zone 1→Zone 3 connections; least-privilege destination)
ZONE 1 OUTBOUND (DMZ to internet):
Zone 1 hosts require limited outbound internet access for specific functions:
Rule: PERMIT-DMZ-Internet-SMTP-EmailOutbound
Source IP: [Email gateway IP only — not the entire DMZ subnet]
Destination: Any (email relays globally)
Application: SMTP (TCP 25) — with TLS enforcement at gateway
Description: Outbound email relay from email gateway only.
Rule: PERMIT-DMZ-Internet-HTTPS-WAFSignatureUpdates
Source IP: [WAF IP only]
Destination: [WAF vendor update IP ranges — specify from vendor docs]
Application: HTTPS (TCP 443)
Description: WAF/reverse proxy updates its signature database via HTTPS.
Rule: DENY-DMZ-Internet-Any-DefaultDenyOutbound
Source zone: Zone 1
Destination: Internet
Application: Any (not matched by above permits)
Action: Deny + Log
Description: Prevents DMZ hosts from initiating arbitrary outbound connections.
If a DMZ host is compromised, outbound C2 connections are blocked.
3.4 Internal boundary — Zone 2 to Zone 3
The Zone 2 → Zone 3 boundary protects CUI servers from general office traffic.
Not all Zone 2 hosts can access Zone 3 — only specific applications on specific ports.
ZONE 2 → ZONE 3 PERMITTED RULES:
Rule: PERMIT-Zone2-Zone3-SMB-CUIFileShare
Source zone: Zone 2 (Internal General)
Source: Only CUI-authorised workstations
Option A: specific IP range for CUI-authorised workstations
Option B: Identity-based (NGFW user-ID integration with Entra ID)
— permit only members of GRP-CUI-Access group
Destination zone: Zone 3 (CUI Servers)
Destination IP: [CUI file server IP only — not the Zone 3 /24 subnet]
Application: SMB (TCP 445) — not the entire SMB application group
Action: Permit
Logging: All sessions
Description: Permits SMB access from CUI-authorised Zone 2 workstations
to CUI file server. Identity-aware: requires GRP-CUI-Access
membership enforced via NGFW user-ID.
Reviewed: [date]. Reviewed by: [name].
Rule: PERMIT-Zone2-Zone3-LDAP-AuthTraffic
Source zone: Zone 2
Source: All Zone 2 hosts (workstations need to authenticate against DC)
Destination: [Domain controller IPs — specifically named]
Application: Kerberos (TCP/UDP 88), LDAPS (TCP 636), DNS (TCP/UDP 53)
Action: Permit
Logging: Session-level (high volume — may generate large logs)
Rule: PERMIT-Zone4-Zone3-Management-AdminOnly
Source zone: Zone 4 (Management VLAN)
Source: PAM jump host IP only
Destination zone: Zone 3
Destination: [All Zone 3 servers — specific IPs preferred over subnet]
Application: SSH (TCP 22), RDP (TCP 3389)
Action: Permit
Logging: All sessions
Description: Administrative access to Zone 3 servers only from PAM jump host
in Zone 4. Direct SSH/RDP from Zone 2 workstations is NOT permitted.
All sessions are PAM-mediated and recorded (EV-F07).
Rule: DENY-Zone2-Zone3-Management-BlockDirectAdmin
Source zone: Zone 2
Destination zone: Zone 3
Application: SSH (TCP 22), RDP (TCP 3389), WinRM (TCP 5985/5986)
Action: Deny + Log
Priority: ABOVE the PERMIT-Zone4-Zone3-Management rule
Description: Blocks direct administrative access from general office (Zone 2)
to CUI servers. All admin must go through PAM in Zone 4.
A Zone 2 device attempting SSH/RDP to Zone 3 is a potential
indicator of lateral movement — SIEM alert fires.
IDENTITY-AWARE FIREWALL POLICY (NGFW user-ID):
For platforms that support user-ID integration (Palo Alto, FortiGate, etc.):
Integrate with Entra ID (via Azure AD connector or SAML) or Active Directory
Map security groups to firewall policy:
GRP-CUI-Access → permitted to Zone 3 CUI servers (SMB 445, application-specific)
GRP-Standard-Users → not permitted to Zone 3 (denied by implicit deny)
This enforces the identity-based access requirement at the network layer —
even if a workstation is on the Zone 2 network, a non-CUI-authorised user
logging into that workstation cannot reach Zone 3.
User-ID agent configuration (AD-based):
Install user-ID agent on a domain controller or member server in Zone 3
Agent reads Windows Security Event Log (Event 4624 — logon events)
Maps logged-on user → workstation IP → sends to firewall
Firewall applies group-based policy based on the mapped user identity
Verify user-ID is working:
Firewall CLI: show user ip-user-mapping all
Expected: each Zone 2 IP with a logged-in user shows the username
If no mappings: user-ID agent connectivity issue — investigate
Section 4 — Internal boundary and management plane enforcement
4.1 Management VLAN isolation
Zone 4 (management VLAN) is the most sensitive network segment.
Compromise of Zone 4 = compromise of the ability to control network security.
Access to Zone 4 must be the most tightly restricted of any zone.
ZONE 4 PERMITTED INBOUND CONNECTIONS:
Source: Only specific admin workstations in Zone 2 using adm- accounts
These workstations are typically identified by IP (static DHCP reservation)
AND by user-ID (adm- accounts only — standard accounts cannot reach Zone 4)
Protocols:
HTTPS (TCP 443): firewall management GUI access
SSH (TCP 22): firewall CLI and network device management
PAM checkout: PAM jump host in Zone 4 permits RDP/SSH to management targets
No other inbound connections to Zone 4 permitted from any source.
ZONE 4 PERMITTED OUTBOUND CONNECTIONS (Zone 4 → other zones):
NTP: Zone 4 NTP server (chrony) → internet NTP pool (UDP 123)
All other zones use the Zone 4 NTP server as stratum 1 (not internet directly)
Syslog: Zone 4 SIEM collector → receives syslog from all zones
(actually inbound to Zone 4, but sourced from other zones — specify direction)
Vulnerability scanner → Zone 2 and Zone 3 targets (TCP — port scan and authenticated check)
The scanner is in Zone 4 to keep scan traffic identifiable and separate from
production traffic. Zone 4 source IP appearing on Zone 2/3 = expected scanner activity.
VERIFYING ZONE 4 ISOLATION:
Test 1 — Zone 2 standard user cannot reach Zone 4:
From a Zone 2 workstation (non-adm account):
Test: ping [Zone 4 firewall management IP]
Expected: no response (firewall drops ICMP from Zone 2 non-admin source)
Test: open browser to https://[firewall-mgmt-IP]
Expected: connection refused or timeout — not a login page
Test 2 — Zone 4 management interface not internet-accessible:
From an external vantage point (cloud VM or mobile device):
nmap -Pn -p 22,443,8443 [firewall public IP]
Expected: all ports closed or filtered — no open management ports
If any management port responds from internet: Critical finding — immediate remediation
(This is one of the most common CE and DEFSTAN assessment findings)
Test 3 — Zone 3 servers cannot reach Zone 4 management:
From a Zone 3 server:
ssh [admin-workstation-IP-in-Zone4]
Expected: connection refused — Zone 3 to Zone 4 permit rules do not exist
Section 5 — Outbound filtering, web proxy, egress control, and DNS filtering
5.1 Outbound firewall policy
DEFAULT OUTBOUND POSITION: DENY ALL, PERMIT BY EXCEPTION
All outbound internet traffic from internal zones must pass through the
web proxy (not directly to the internet). The firewall enforces this by:
1. Permitting HTTP/HTTPS from the proxy IP only (not from workstation IPs)
2. Denying HTTP/HTTPS from workstation IPs directly (they must use the proxy)
ZONE 2 OUTBOUND PERMIT RULES:
Rule: PERMIT-Zone2-Internet-ViaProxy-HTTPS
Source: Zone 2 workstations (any IP in Zone 2 subnet)
Destination: Web proxy IP [specify]
Application: HTTPS (TCP 443)
Action: Permit
Description: Internal workstations connect to proxy; proxy connects to internet.
Rule: PERMIT-Zone2-Zone4-NTP-TimeSync
Source: All zones
Destination: Zone 4 NTP server IP
Application: NTP (UDP 123)
Action: Permit
Description: All systems use the internal NTP server (Zone 4) — not internet NTP directly.
Rule: PERMIT-Zone2-Zone4-Syslog-Logging
Source: All zones
Destination: Zone 4 SIEM collector IP
Application: Syslog (TCP 514)
Action: Permit
Description: All systems forward logs to SIEM via syslog.
Rule: DENY-Zone2-Internet-Any-NoDirectOutbound
Source: Zone 2 (all workstation IPs)
Destination: Internet (Zone 0)
Application: Any (except the above permits to proxy/NTP/SIEM)
Action: Deny + Log
Description: Prevents direct internet access from workstations.
All internet traffic must route via proxy (enforces URL filtering,
TLS inspection, and egress monitoring).
Important: this rule prevents workstations from bypassing the proxy
by connecting directly to internet IPs on HTTPS. Without this rule,
a workstation could connect directly to an internet IP on port 443
and bypass all proxy-based controls.
ZONE 3 OUTBOUND (CUI SERVERS):
Zone 3 servers must not have direct internet access.
Updates via WSUS/MDM proxy (not direct to Windows Update)
Outbound from Zone 3:
WSUS/MDM update traffic: to internal WSUS server in Zone 2 (TCP 8530/8531) only
Syslog: to Zone 4 SIEM collector only
NTP: to Zone 4 NTP server only
No other outbound from Zone 3 permitted
Rule: DENY-Zone3-Internet-Any-NoDirectOutbound
Source: Zone 3 subnet
Destination: Zone 0
Action: Deny + Log
Description: CUI servers have no direct internet access.
Any attempt from Zone 3 to reach internet = potential indicator
of compromise — SIEM High alert.
SIEM alert for Zone 3 → internet:
Source: firewall deny log
Condition: source IP in Zone 3 subnet, destination in Zone 0
Severity: High (unusual — CUI server should not initiate internet connections)
Alert: CISO and Security Analyst within 1 hour
5.2 Web proxy configuration
The web proxy sits between Zone 2 and the internet. All HTTP/HTTPS traffic
from workstations routes through the proxy for inspection, filtering, and logging.
PROXY ARCHITECTURE:
Mode: Explicit proxy (workstations configured with proxy address via GPO/MDM)
OR Transparent proxy (firewall redirects port 80/443 traffic to proxy)
Explicit proxy (preferred for managed devices):
GPO: Computer Configuration → Policies → Windows Settings → Internet Explorer →
Connection → LAN settings → Use a proxy server: [proxy-IP]:[port]
MDM (macOS): Proxy → Web Proxy (HTTP): [proxy-IP]:[port]
Secure Web Proxy (HTTPS): [proxy-IP]:[port]
Transparent proxy (alternative for zones where explicit proxy is difficult):
Firewall: redirect TCP 80 and TCP 443 from Zone 2 to [proxy-IP]
Works for browser traffic; may miss non-browser HTTPS (e.g. application traffic)
TLS INSPECTION (mandatory for effective HTTPS filtering):
The proxy decrypts HTTPS traffic for inspection, then re-encrypts to the destination.
Internal CA certificate (trust anchor):
The proxy re-signs all HTTPS responses with an internal CA certificate
This internal CA cert must be trusted by all managed devices:
Windows: GPO → Computer Configuration → Policies → Windows Settings →
Security Settings → Public Key Policies → Trusted Root CAs →
Import: [internal-proxy-CA-cert.cer]
macOS: MDM profile → Certificate payload → trust all apps
Linux: /usr/local/share/ca-certificates/[proxy-ca].crt + update-ca-certificates
Without this cert deployed: browsers will show SSL errors for all sites
Verify: open any HTTPS site on a managed device → check certificate chain
Expected: certificate issued by [Internal-Proxy-CA], not the real site CA
TLS inspection exclusions (sites where inspection is inappropriate):
Category: Financial institutions (online banking, payment processors)
Category: Healthcare portals (patient data — local DPA restrictions)
Category: Government authentication portals (HMRC, Government Gateway)
Category: Client legal counsel communications (legal privilege)
All exclusions: documented in EV-D19 proxy configuration baseline
Exclusion list review: annually — remove any that are no longer needed
Note: TLS inspection exclusions create blind spots. Each exclusion is a
potential path for exfiltration or C2 that bypasses inspection.
The list must be kept minimal and reviewed regularly.
URL CATEGORY BLOCKING (minimum required — configure in proxy):
BLOCK (no access, access denied page):
Malware distribution sites
Command and control / botnet infrastructure
Phishing and social engineering sites
Compromised/hacked websites (category updated by threat intelligence feed)
Anonymous proxy / VPN services (prevent proxy bypass)
Dynamic DNS services (common malware C2 evasion)
Newly registered domains (<30 days old) — Block or Warn
Peer-to-peer file sharing
Torrent sites
Hacking tools and exploit code repositories (not including legitimate security research)
WARN (user sees warning; can proceed after acknowledgement — log the bypass):
Personal cloud storage (personal Dropbox, personal Google Drive, personal iCloud)
File sharing sites (WeTransfer, SendSpace, etc.)
Newly registered domains — Warn variant (if Block is creating too many false positives)
ALLOW (with logging):
All other categories — allowed by default; logged for review
ALERT ONLY (allow + SIEM alert):
Executable downloads (.exe, .bat, .ps1, .msi) from uncategorised or new domains
→ IT Operations reviews each alert within 24 hours
→ If unexpected: investigate the source device; contact the user
PROXY LOGGING TO SIEM:
Log every HTTP/HTTPS request (URL, user if proxy-authenticated, response code, bytes)
Log every blocked request (URL, category, user, reason for block)
Log format: W3C Extended Log Format or CEF — specify to match SIEM parser
Forward to SIEM: syslog TCP to Zone 4 SIEM collector
Retention at SIEM: 90 days hot (searchable); full proxy logs may be voluminous
— consider compressed archive for 12-month retention
Key SIEM rules from proxy events:
Malware category block: Medium alert → security analyst review
C2 category block: High alert → immediate investigation (device may be compromised)
5+ blocks from same source in 1 hour: High alert (unusual browsing pattern)
Executable download from uncategorised site: Medium alert → IT Operations review
5.3 DNS filtering
DNS filtering blocks malicious domain resolution before a TCP connection is established.
It is the fastest and most resource-efficient layer of boundary protection.
ARCHITECTURE:
All CUI-scope systems use the internal DNS resolver (Zone 4) — not public DNS directly
Internal DNS resolver forwards to DNS filtering service
DNS filtering service applies blocklists and category filtering before resolution
Ensure: GPO and DHCP push the internal DNS server IP to all Zone 2 and Zone 3 systems
DHCP option 006: [Zone 4 DNS server IP]
GPO: Computer Configuration → Windows Settings → Name Resolution Policy Table
(optional — enforce DNS server for specific suffixes)
Verify: on any Zone 2 workstation:
nslookup google.com [Zone-4-DNS-IP]
Expected: resolves via the internal resolver, which forwards to the filter service
nslookup [known-malicious-domain] [Zone-4-DNS-IP]
Expected: NXDOMAIN or NXREWRITE (DNS sink hole IP) — not the real IP
DNS FILTER CATEGORIES (block):
Malware: known malware distribution domains
Command and control: known C2 and botnet domains
Phishing: confirmed phishing domains
Newly registered domains: high malware association (block or warn)
Dynamic DNS: DynDNS, No-IP, etc. (common C2 evasion technique)
Threat intelligence feeds to integrate:
CISA KEV-associated domains (where KEV advisories list specific domains)
NCSC Active Cyber Defence (ACD) blocklists (requires NCSC ACD subscription)
Vendor threat intelligence feed (specific to deployed DNS filter platform)
DNS LOGGING TO SIEM:
Log every DNS query: source IP, query name, query type, response, timestamp
Log every DNS block: source IP, blocked domain, block reason, timestamp
Forward to SIEM: syslog or API integration
High volume note: DNS logs are very high volume (potentially millions of events per day)
Options: (a) log only blocks (lower volume; misses threat hunting value)
(b) log all and use SIEM sampling or compressed storage
(c) log summary statistics + full logs for specific categories
Recommended minimum: log all blocks (mandatory) + all queries to newly-registered domains
SIEM rules for DNS:
DNS C2 block from internal host: High alert → investigate source device
DGA detection — high-entropy subdomain queries from single host:
SIEM rule: DNS queries from one source IP where hostname entropy > 3.5
in a 30-minute window
Severity: Medium → investigate (potential malware using DGA for C2)
Excessive NXDOMAIN from single host:
SIEM rule: >100 NXDOMAIN responses to one source IP in 30 minutes
Severity: Medium → potential DGA or scanning behaviour
Section 6 — IDS/IPS configuration and alert management
6.1 Deployment and mode configuration
IDS/IPS provides signature-based and anomaly-based detection at the network boundary.
The distinction between IDS (detection only) and IPS (detection + active prevention)
is critical for CUI-scope environments.
DEPLOYMENT POSITION:
Position 1 — Perimeter inline (between Zone 0 and Zone 1):
Mode: IPS (prevention mode — actively blocks matching traffic)
Detects: external attacks against DMZ services; exploit attempts; C2 traffic
Position 2 — Internal boundary (between Zone 2 and Zone 3):
Mode: IPS (prevention mode)
Detects: lateral movement patterns; internal reconnaissance;
CUI data exfiltration attempts; internal exploitation
Position 3 — East-west monitoring (between Zone 2 hosts):
Mode: IDS (detection only — passive tap)
Detects: internal lateral movement; workstation-to-workstation attacks
Note: prevention mode on east-west traffic can cause legitimate traffic drops;
detection mode is usually preferred here
For NGFW platforms (Palo Alto, FortiGate, Cisco Firepower) with integrated IPS:
Apply the IPS security profile to the relevant firewall policy rules:
Palo Alto: Security profile → Vulnerability protection profile → [profile name]
Attach to: all rules where IPS is required
FortiGate: UTM profile → IPS sensor → [sensor name]
Attach to: firewall policy
Cisco Firepower: Intrusion policy → attached to access control rule
SIGNATURE PROFILE CONFIGURATION:
Profile: perimeter-inbound-strict (for Zone 0 → Zone 1 path)
Severity: Critical, High — Action: Block + Log
Severity: Medium — Action: Block + Log
Severity: Low — Action: Alert + Log (do not block — too many false positives)
Severity: Informational — Action: Log only
Profile: internal-boundary-strict (for Zone 2 → Zone 3 path)
Severity: Critical, High, Medium — Action: Block + Log
Severity: Low — Action: Alert + Log
Signature categories to enable (all the following, minimum):
Malware (known malware traffic patterns)
Vulnerability exploits (known CVE exploitation signatures)
Command and control (known C2 traffic)
Brute force (authentication brute force detection)
Spyware (known spyware communication patterns)
Trojan (known trojan communication patterns)
SQL injection (application layer — if inline with web traffic)
Signature updates:
Automatic daily (most platforms — configure in IPS settings)
SIEM alert if signature database not updated within 48 hours
TUNING AND FALSE POSITIVE MANAGEMENT:
Initial deployment (first 30 days): run in alert-only mode
Observe alert volume and identify false positives before enabling blocking
Common false positives:
Internal vulnerability scanner triggering attack signatures
→ Suppress: source = scanner IP (Zone 4 scanner host IP)
Application-layer signatures triggered by business applications
→ Suppress: destination = specific application server IP + specific signature ID
After 30 days: enable blocking on Critical and High signatures
After 60 days: review Medium signatures for blocking
Suppression policy:
Any suppression requires: IT Manager approval (for performance-related)
CISO approval (for Critical/High security signatures)
Document in EV-D19: signature ID, reason for suppression, approver, review date
Review suppressions quarterly: are they still needed?
A suppression on a Critical signature that has been in place for 6+ months
without review is a compliance risk.
6.2 IDS/IPS alert triage procedure
Alert tiers and response SLA:
Critical (known active exploit, confirmed attack): within 1 hour (24/7)
High (suspicious pattern, likely attack): within 4 hours (business hours);
8 hours (out of hours)
Medium: within 1 business day
Low: weekly batch review
MONTHLY IDS/IPS ALERT REVIEW (generates EV-F04):
Produced by: Security Analyst
Deadline: by the 7th of each month (for the prior calendar month)
Source: IPS management console → reporting → alert summary export
STEP 1 — Pull alert statistics:
Total alerts by severity: Critical [N], High [N], Medium [N], Low [N]
Top 10 alerting signatures (by alert count)
Top 10 source IPs (alerts generated from these sources)
Top 10 destination IPs (alerts targeting these destinations)
STEP 2 — Review Critical and High alerts:
For each Critical/High alert in the period:
True positive (actual attack/scan confirmed): create or reference incident in EV-D12
False positive (legitimate traffic triggering alert):
Was it previously known? If yes: existing suppression should have caught it
If not: add to suppression list via RFC
If newly discovered: document reason; add suppression with CISO approval
Inconclusive: investigate further; if no resolution, treat as Medium
A Critical alert that was not reviewed in the same business day as it fired:
Document in EV-F04 as a gap: "Alert [ID] fired [time]; not reviewed until [time]"
This is a process finding — review the on-call notification chain
STEP 3 — Volume trend analysis:
Compare this month vs prior 3 months:
Alert volume increasing significantly: potential new scanner/attacker; investigate
Alert volume decreasing significantly: potential signatures not applying or
traffic not reaching the IPS; verify IPS health
Volume is stable: baseline established; note any anomalous single-day spikes
STEP 4 — IPS health verification:
Confirm IPS is receiving traffic (not just generating zero alerts because traffic bypasses it)
Check: IPS console → traffic statistics → packets processed in the past month
If packets processed = 0 or near-zero: IPS is not inline; investigate immediately
EV-F04 record structure:
Month: [YYYY-MM]
Produced by: [Security Analyst name]
Date produced: [date]
Alert statistics:
Critical: [N] — True positive: [N] | False positive: [N] | Inconclusive: [N]
High: [N] — True positive: [N] | False positive: [N] | Inconclusive: [N]
Medium: [N] (sampled review — full review not required for Medium)
Low: [N] (count only — no individual review)
True positive incidents: [list EV-D12 references or "None"]
New false positives this month: [N] — suppressions added: [N]
Volume trend: [Increasing / Stable / Decreasing] vs prior 3 months
Any anomalous single-day spikes: [describe or "None"]
IPS health: traffic processing confirmed: [Yes / No — if No: describe investigation]
Signature update currency: last updated [date] — within 48h: [Yes/No]
Security Analyst sign-off: _____________ Date: _________
CISO review: _____________ Date: _________
File at: EV-F → Continuous Monitoring → IDS Reviews → [YYYY-MM]
Section 7 — Firewall rule review procedure (generates EV-F03)
7.1 Review cadence and scope
Cyber Essentials requires firewall rules be reviewed regularly.
DEFSTAN Profile 1 requires a formal rule review record at defined intervals.
This procedure satisfies both requirements.
Review cadence: every 6 months (H1 = April; H2 = October)
Plus: immediately following any significant network change
(new service, architecture change, major RFC)
Scope of review:
All rules in the active rule base on all in-scope boundary firewalls
(perimeter firewall + any internal segment firewalls)
Zone 1 → Zone 3 permitted rules: reviewed with particular scrutiny
Any rules added since the last review: confirmed they were added via RFC
Review team:
IT Manager (or designated Network Engineer): technical rule review
Security Analyst: security posture review; SIEM correlation
CISO: sign-off; reviews Zone 3 permit rules specifically
7.2 Full rule review procedure (step by step)
PREPARATION (1 week before review session):
Step P1 — Export current rule base:
Firewall management platform → rule base export
Format: CSV (for analysis) AND PDF/HTML (for archive)
Palo Alto (Panorama): Policies → Security → Export
FortiGate: Policy & Objects → IPv4 Policy → [right-click] → Download
Cisco Firepower: Objects → Access Control → Export
Filename: Ruleset-[firewall-name]-[YYYY-MM-DD].csv
Hash the export file:
sha256sum Ruleset-[firewall-name]-[YYYY-MM-DD].csv
Record the hash in EV-F03 (proves the export was not tampered with after review)
Step P2 — Export prior review's rule base:
Retrieve: Ruleset-[firewall-name]-[YYYY-MM-DD].csv from the previous EV-F03
Diff the two exports:
Windows: Compare-Object (Import-Csv "prior.csv") (Import-Csv "current.csv")
-Property [rule-name-column], [action-column]
Linux: diff <(sort prior.csv) <(sort current.csv)
Output: list of rules that are NEW since last review, MODIFIED, or REMOVED
For each NEW rule:
Cross-reference against RFC change log: was there a corresponding RFC?
If yes: rule is accounted for — note RFC reference in EV-F03
If no: FINDING — rule was added outside change management process
Immediate investigation: who added this rule and why?
IT Manager + CISO notified same day as discovery
Step P3 — Pull hit counts from firewall (rules with zero hits):
Most firewall platforms record a hit count per rule
Query: rules where hit count = 0 since last review
These are candidates for removal — a rule that has never matched traffic
either protects against something that has not been attempted (keep),
or was created for a purpose that no longer exists (remove)
Confirm with rule owner: is this rule still needed?
If yes: keep; note in EV-F03 with justification
If no: remove via RFC; note in EV-F03
THE REVIEW SESSION:
Step R1 — Work through the rule base top-to-bottom:
For each rule, answer all of the following questions.
Document findings in the EV-F03 working spreadsheet before finalising.
CHECK 1: Does this rule have a compliant description?
Compliant: states what is permitted, from where, to where, for what business reason,
when it was created, who approved it, and when it was last reviewed
Non-compliant: blank, "temp", "test", generic ("web traffic"), or just a ticket number
Action: if non-compliant, add to the findings list
SLA: findings from rule review must be remediated within 30 days (calendar)
CHECK 2: Can the source be more specific?
A rule permitting traffic from "any" source (any IP, any zone) where
a specific source IP or subnet could be used is overly broad.
Examples of unnecessarily broad sources:
Source: any — when only specific IP ranges should be permitted
Source: Zone 2 subnet — when only a specific workstation or server should be permitted
If a more specific source is feasible: note as a refinement recommendation
If "any" source is genuinely required (e.g. inbound MX record for email): document justification
CHECK 3: Can the destination be more specific?
Same principle as source — minimise the destination where possible.
A rule permitting traffic to the Zone 3 /24 subnet is broader than necessary
if only one specific server IP needs to receive the traffic.
CHECK 4: Can the application/port be more specific?
A rule permitting "any" application on any port in a permit rule is an immediate finding.
A rule permitting a broad port range where a single port would suffice is a finding.
Particularly examine:
Application: "any" in a permit rule — always a finding (except possibly in outbound
rules where the proxy handles application-level inspection — document this)
Port: 1–65535 in a permit rule — always a finding
ICMP: blanket permit of all ICMP types — should be limited to echo-request (ping)
CHECK 5: Is this rule still necessary?
Has the system this rule was created for been decommissioned?
Has the business process this rule supported ended?
Has the service been moved to a different IP that makes the destination wrong?
Cross-reference: EV-D22 asset register — is the destination host still listed as active?
CHECK 6: Does this rule have any Zone 1 → Zone 3 scope?
Any rule permitting traffic from Zone 1 (DMZ) to Zone 3 (CUI servers):
→ Requires CISO confirmation that this rule is still necessary
→ Requires documentation of the compensating control reducing the risk
→ Should be challenged: is there an architectural alternative?
CHECK 7: Has this rule been active since the last review?
Hit count: has this rule matched at least some traffic since the last review?
Zero hits: add to stale rule list (see Step P3 above)
CHECK 8: For management-related rules: is admin access from the internet blocked?
Confirm: no rules permit SSH/RDP/HTTPS-MGMT from Zone 0 to any host
External port scan (run from a cloud VM or mobile):
nmap -Pn -p 22,23,80,443,3389,8080,8443 [firewall-public-IP]
Expected: all listed ports closed or filtered — especially 22, 23, 3389
If any management port is open from internet: CRITICAL FINDING — immediate action
CHECK 9: Is the default deny rule present and logging?
The last rule in the rule base must be:
Source: any
Destination: any
Application: any
Action: Deny
Logging: Enabled (critical — the default deny log is the catch-all evidence)
If logging is disabled on the default deny: the organisation has no evidence
of what is being blocked. Enable logging immediately.
DOCUMENTATION OF FINDINGS:
For each finding identified during the review:
Finding type:
A — Rule without compliant description
B — Overly broad source or destination (more specific possible)
C — Overly broad application/service
D — Rule added outside change management process (no RFC)
E — Rule for decommissioned service (stale rule)
F — Zone 1 → Zone 3 rule requiring CISO confirmation
G — Management port reachable from internet
H — Default deny missing or not logging
I — Other (describe)
For each finding:
Finding ID: FR-[YYYY]-[NN]
Type: [A through I]
Rule name: [exact rule name]
Description: [what the finding is]
Risk level: Low / Moderate / High / Critical
Remediation: [what needs to be done]
RFC required: Yes / No
Owner: [IT Operations engineer responsible]
Target completion: [date — within 30 days for all non-Critical; immediate for Critical]
POST-REVIEW ACTIONS:
Removals: each stale or unnecessary rule removed via Normal RFC
Modifications: overly broad rules narrowed via Normal RFC
Documentation: descriptions updated (can be done directly without RFC if no functional change)
Escalations: any Critical findings (management port open, undocumented rules) escalated
to CISO same day; IT Manager action plan within 24 hours
REMEDIATION TRACKING:
All findings from EV-F03 are entered in EV-A03 (corrective actions register)
CISO reviews outstanding corrective actions at monthly CISO review
No finding from a firewall rule review should remain open at the next
6-monthly review — if it does, it becomes a repeat finding and requires
escalation to senior management
7.3 EV-F03 record template
EV-F03 Firewall Rule Review — [YYYY] [H1 / H2]
Review period: [start date] to [review date]
Review date: [YYYY-MM-DD]
Conducted by: [IT Manager / Network Engineer name]
CISO review and sign-off: [CISO name]
RULE BASE STATUS:
Firewall platform: [name and firmware version]
Management platform: [Panorama / FortiManager / etc. — version]
Total active rules in rule base: [N]
Rule base export: Ruleset-[name]-[date].csv — SHA256: [hash]
Prior review export: Ruleset-[name]-[prior-date].csv
CHANGE ANALYSIS (since last review):
Rules added since last review: [N]
Accounted for by RFC: [N]
Without RFC (finding): [N]
Finding IDs: [FR-YYYY-NN list]
Rules modified since last review: [N]
All modifications accounted for: Yes / No — [describe any unaccounted modifications]
Rules removed since last review: [N]
RULE QUALITY ANALYSIS:
Rules without compliant description: [N] — Finding IDs: [FR-YYYY-NN list]
Rules with overly broad source: [N] — Finding IDs: [list]
Rules with overly broad destination: [N] — Finding IDs: [list]
Rules with "any" application in permit rule: [N] — Finding IDs: [list]
Rules with zero hits since last review: [N]
Retained with justification: [N]
Removed or scheduled for removal: [N]
ZONE 1 → ZONE 3 PERMIT RULES (special review):
Total Zone 1 → Zone 3 permit rules: [N]
For each (list individually):
[Rule name]: Purpose: [description] — CISO confirmed still required: Yes / No
Alternative architectural approach considered: [describe or "None feasible"]
MANAGEMENT ACCESS VERIFICATION:
External port scan conducted: Yes — date: [date] — conducted by: [name]
External scan tool used: [nmap / Shodan / external vantage point]
Management ports open from internet: None / [list if any — each is a Critical finding]
Admin interface accessible from internet: No / [describe if yes — Critical finding]
DEFAULT DENY RULE:
Present as last rule: Yes / No
Action: Deny
Logging enabled: Yes / No [if No: Critical finding]
FINDINGS SUMMARY:
Total findings: [N]
Critical: [N] — same-day escalation to CISO: [date]
High: [N]
Moderate: [N]
Low: [N]
Detailed findings: [list each FR-YYYY-NN with description and remediation target]
REMEDIATION STATUS (from last review's findings):
All prior findings remediated: Yes / [N outstanding — list with explanation]
OVERALL ASSESSMENT:
Cyber Essentials firewall requirement: COMPLIANT / NON-COMPLIANT (see findings)
DEFSTAN Profile 0/1 boundary requirement: COMPLIANT / NON-COMPLIANT (see findings)
CMMC SC.L1-3.13.1/3.13.6 assessment: COMPLIANT / NON-COMPLIANT (see findings)
IT Manager sign-off: _________________ Date: _________
CISO review and sign-off: ___________ Date: _________
File at: EV-F → Continuous Monitoring → Firewall Reviews → [YYYY-H1 or YYYY-H2]
Section 8 — Logging requirements and SIEM integration
8.1 What the firewall must log
Logging is a compliance requirement, not optional. An assessor who reviews
EV-F01 (monthly SIEM log review) and finds no firewall events is looking
at a control that cannot be evidenced. Logging must be configured before
the system goes into production.
MANDATORY LOG EVENTS:
From the perimeter firewall:
All sessions established (inbound Zone 0 → Zone 1): log
All sessions denied (default deny rule hits): log
All Zone 1 → Zone 2 sessions (any direction, any outcome): log
All Zone 2 → Zone 3 sessions: log
All Zone 4 access events (management access): log
All firewall configuration changes: log (admin audit trail)
All administrator authentication events (login success/failure): log
All policy rule changes: log (rule added, modified, deleted)
IPS alerts: log (all severities)
From managed switches:
802.1X authentication events (success/failure): log
BPDU Guard events (port shutdown): log
DHCP snooping violations: log
ARP inspection violations: log
Configuration changes: log
From IDS/IPS:
All alert events (all severities): log
Health events (sensor up/down, signature update success/failure): log
LOG FORMAT:
Standard syslog (RFC 5424) — common format for all network devices
OR CEF (Common Event Format) — recommended if SIEM supports it (easier parsing)
OR vendor-native JSON — if SIEM has a native connector
Every log event must include:
Timestamp (UTC — NTP-synchronised — see NTP hierarchy in OP-03)
Source IP address
Destination IP address
Protocol and port
Action (permit/deny/alert)
Rule name (the named rule that matched — not just the rule ID number)
Device hostname (which firewall generated the event)
SIEM FORWARDING CONFIGURATION:
Method: syslog TCP (not UDP — TCP provides delivery confirmation)
Destination: Zone 4 SIEM collector IP — port 514 (or 6514 for TLS syslog)
TLS syslog (preferred): encrypts log forwarding (prevents tampering in transit)
Requires: SIEM collector configured with TLS; firewall configured with TLS syslog
Palo Alto configuration:
Device → Server Profiles → Syslog → [add SIEM profile]
Name: SIEM-Collector
Server: [SIEM-IP] Port: 514 Facility: LOG_USER Format: BSD/IETF
Device → Log Forwarding Profiles → [profile] → add syslog server profile
Apply log forwarding profile to each security policy rule
FortiGate configuration:
config log syslogd setting
set status enable
set server [SIEM-IP]
set port 514
set facility local7
set format default (or cef — if SIEM supports CEF)
end
config log syslogd filter
set severity information (log all events — not just warning+)
end
Cisco Firepower:
System → Configuration → Logging → Syslog Servers → [add SIEM server]
Logging level: Informational (6) — captures all events
Apply to: all managed devices
VERIFY SIEM IS RECEIVING FIREWALL LOGS:
Test 1 — Generate a known deny event and verify it appears in SIEM:
From an external vantage point: attempt to connect to an internal IP
Expected: firewall generates a deny log event
Verify in SIEM: search for source = [external IP] within 60 seconds of attempt
If not found: syslog forwarding is broken — investigate
Test 2 — SIEM health check (part of EV-F06):
SIEM console → Data connector health → [firewall source]
Expected: events received within past 60 minutes
If gap: SIEM alert rule should have fired — verify SIEM alert rule is configured:
Alert: "No firewall events received in past 60 minutes" → High severity →
IT Operations notified immediately
Test 3 — Log volume plausibility check (monthly):
Review SIEM event count for firewall source by day
A consistent decrease in event count without a business reason may indicate:
Firewall is dropping events (log buffer full)
SIEM connection to firewall syslog has failed
Traffic volume has genuinely decreased (less likely)
Compare: current month events per day vs 3-month average
8.2 Log retention and the monthly boundary log review
LOG RETENTION:
SIEM hot tier (searchable): 90 days
SIEM warm tier (retrievable <24h): days 91–365
Archive (retrievable <72h): days 366–1095 (36 months)
Firewall local log buffer: 30 days (backup in case SIEM forwarding fails)
Retention rationale for DEFSTAN:
DEFSTAN assessors may request firewall logs for a specific incident period
Logs must be available for the duration of the contract + post-contract period
Confirm retention period with CISO based on current DEFSTAN contracts
MONTHLY BOUNDARY EVENT REVIEW (contributes to EV-F01):
The monthly SIEM log review (EV-F01 — see OP-03) includes a dedicated
boundary monitoring section. The Security Analyst reviews the following
from the boundary SIEM data each month:
Review item 1 — Default deny volume by source:
Query: events where rule = "DEFAULT-DENY", grouped by source IP
Expected: varied sources (internet scanners, misconfigured systems)
Concern: if a specific internal IP appears frequently in deny logs,
that internal system may be misconfigured or compromised
Review item 2 — Zone 2 → Zone 3 denied events:
Query: deny events where source = Zone 2 subnet, destination = Zone 3
Expected: occasional (misconfigured applications, user error)
Concern: repeated denies from the same source IP to the same Zone 3 target
may indicate lateral movement attempts or an attacker probing from
a compromised workstation
Threshold: >10 Zone 2 → Zone 3 denies from same source in 1 hour = Medium SIEM alert
Review item 3 — After-hours Zone 3 access:
Query: permit events where destination = Zone 3, timestamp outside business hours
Expected: IT Operations maintenance; confirmed on-call events
Concern: unexpected Zone 3 access outside hours from an unrecognised source IP
Review item 4 — Large data transfers from Zone 3:
Query: sessions where destination = Zone 3, bytes_out > [threshold — e.g. 100MB]
Concern: large outbound data from CUI servers may indicate exfiltration
Cross-reference: is the transfer to an approved destination?
Is the user's access pattern consistent with their role?
Review item 5 — New permit rule matches (rules with no prior traffic):
Query: permit events where rule_name was not seen in prior month's logs
This catches rules added since the last review that are now being used
Cross-reference against RFC log: was this rule added via the change process?
Review item 6 — IDS/IPS Critical and High alerts:
Covered in EV-F04 (Section 6.2) — summarise any unresolved alerts in EV-F01
Document the boundary section of EV-F01:
This month's Zone 2 → Zone 3 deny events: [N] — patterns noted: [describe or "None"]
After-hours Zone 3 access events: [N] — all verified legitimate: [Yes/No]
Large data transfers from Zone 3: [N] — all verified legitimate: [Yes/No]
New permit rules with traffic: [N] — all have RFC: [Yes/No]
IDS/IPS unresolved High/Critical alerts: [N] — [list refs or "None"]
Default deny volume spike (>200% of prior month): [Yes — investigate / No]
Section 9 — VPN and remote access security
9.1 VPN configuration specification
The VPN satisfies AC.L1-3.1.20 (verify and control connections to external systems)
and DEFSTAN Profile 0 (remote access to OFFICIAL systems must be encrypted).
VPN PLATFORM: [deployed product — e.g. Palo Alto GlobalProtect /
Cisco AnyConnect / Fortinet FortiClient / Azure VPN Gateway — specify]
VPN gateway IP: [public IP of VPN endpoint — in Zone 1 DMZ]
AUTHENTICATION REQUIREMENTS (mandatory — all three factors):
Factor 1: Device certificate
Issued by: internal CA (AT-SC-ENC / OP-02)
Deployed via: MDM to all enrolled corporate devices
Purpose: proves the connecting device is a managed corporate device
Without this: a personal device or attacker device could attempt VPN auth
Factor 2: User credential (Entra ID SAML)
SAML IdP: Azure Entra ID
Authentication: username + password (Entra ID-managed)
Factor 3: MFA (Microsoft Authenticator — number matching)
Required: every VPN session; no exceptions
No re-authentication window (not "remember for 7 days")
Exception only for break-glass accounts (see FC-03)
SPLIT TUNNELLING: DISABLED (mandatory)
All traffic routes through corporate VPN when connected
No split tunnelling = all internet traffic inspected by corporate proxy
Split tunnelling would bypass: URL filtering, egress monitoring, DLP
Verify split tunnelling is disabled:
Connect VPN on a test device
Run: curl https://ipinfo.io/ip
Expected: returns the corporate egress IP (not the personal ISP IP)
If returns personal ISP IP: split tunnelling is enabled — fix immediately
Verify on firewall:
Palo Alto (GlobalProtect): GlobalProtect → Gateways → [gateway] →
Agent → Tunnel Settings → No Split Tunnelling
FortiGate (SSL VPN): VPN → SSL-VPN Settings → Tunnel Mode → Split Tunnelling: Disabled
VPN TIMEOUT AND SESSION MANAGEMENT:
Session timeout (idle): 60 minutes (user must re-authenticate after 60 min idle)
Session timeout (maximum): 8 hours (forced re-authentication after 8 hours connected)
Concurrent sessions per user: 2 maximum (prevents account sharing)
Rationale: an idle VPN session left connected overnight = an unmonitored
connection to the corporate network. Timeouts limit the exposure window.
SPLIT TUNNELLING DEFSTAN NOTE:
DEFSTAN Profile 0 requires remote access to OFFICIAL systems to be encrypted.
The VPN satisfies this if:
(a) Split tunnelling is disabled (all OFFICIAL traffic routes via encrypted VPN)
(b) The VPN encryption meets minimum standards:
Protocol: IKEv2
Encryption: AES-256
Key exchange: ECDH P-384 (DH Group 20) or DH Group 14 minimum
Integrity: SHA-256 minimum; SHA-384 preferred
Document VPN cipher suite in EV-D19 (configuration baseline)
Verify annually as part of AT-SC-ENC encryption audit (EV-D31)
LOGGING VPN EVENTS TO SIEM:
Log: all connection attempts (success and failure)
Log: connection duration; bytes transferred; user; device; source IP
Forward: to SIEM within 60 seconds
SIEM rules for VPN:
Successful VPN from country not in user's 90-day location history:
Alert: Medium → security analyst review within 4 hours
VPN connection from device not in MDM inventory:
Alert: High (unenrolled device should not authenticate —
certificate-based auth should prevent this; alert if it occurs)
Multiple failed VPN auth attempts for same user (>10 in 1 hour):
Alert: Medium → potential credential stuffing
Simultaneous VPN sessions from geographically impossible locations:
Alert: High (user connected from London and Tokyo simultaneously = impossible)
VPN user group review (quarterly — part of EV-D01 review in FC-03):
Export members of VPN-Users group
Cross-reference against HR active employee list
Remove departed employees from VPN-Users (should be handled by EV-D04 leaver process)
Quarterly check catches any leaver process failures
Section 10 — Cloud boundary controls
10.1 Cloud network security group configuration
Cloud resources in scope (specify which cloud providers are used):
AWS: [Yes / No — if Yes, specify accounts and regions]
Azure: [Yes / No — if Yes, specify subscriptions]
GCP: [Yes / No — if Yes, specify projects]
PRINCIPLE: Cloud network security controls must enforce the same default-deny,
explicit-permit standard as the on-premises perimeter firewall. Cloud VMs
are not "behind the corporate firewall" — they are internet-connected by default.
AWS SECURITY GROUP CONFIGURATION:
Principles:
Never use: 0.0.0.0/0 as a source for inbound SSH, RDP, or any admin protocol
Never use: 0.0.0.0/0 as a source for inbound on any port unless it is a
deliberately public service (web, API)
All admin access: from specific IP ranges (corporate egress IP) only
OR via AWS Systems Manager Session Manager (no inbound port at all)
CUI-scope EC2 instances:
No public IP assigned (place in private subnet only)
All inbound: from specific security group or specific IP only
Outbound: to specific destinations only (not 0.0.0.0/0 for all)
Example CUI-scope EC2 security group:
Inbound rules:
Port 443: source = [corporate-egress-IP]/32 (admin access from corporate only)
Port 443: source = [internal-VPC-CIDR] (internal application traffic)
Any other port: no inbound from 0.0.0.0/0
Outbound rules:
Port 443: destination = [specific endpoints, e.g. AWS API endpoints]
Port 514 (TCP): destination = [SIEM collector IP] (log forwarding)
Everything else: deny (or limit to specific known destinations)
Regular audit of security groups:
AWS Config rule: ec2-security-group-attached-to-eni (all SGs are in use)
AWS Config rule: restricted-ssh (SSH not open to 0.0.0.0/0 or ::/0)
AWS Config rule: restricted-common-ports (no common admin ports open to internet)
Review: quarterly as part of EV-D20 configuration audit
AZURE NETWORK SECURITY GROUP (NSG) CONFIGURATION:
CUI-scope Azure VMs:
No public IP (use Azure Bastion or private endpoint for admin access)
Inbound NSG rules: deny all from internet; permit only from specific sources
Outbound NSG rules: deny to internet by default; permit specific destinations
Azure Policy enforcement:
Policy: "Deny public IP on CUI VMs" — deny creation of VMs with public IP
in CUI-tagged resource groups
Policy: "Require Network Watcher" — ensures NSG flow logs are enabled
NSG flow logging:
Enable: for all NSGs on CUI-scope subnets
Destination: Azure Storage Account + Azure Monitor (or SIEM connector)
SIEM integration: Azure Monitor Logs → [SIEM] via API connector
CLOUD SECURITY POSTURE MANAGEMENT (CSPM):
AWS: AWS Security Hub + AWS Config (continuous compliance monitoring)
Enable: NIST 800-53 standard in Security Hub (includes our controls)
Azure: Microsoft Defender for Cloud (continuous assessment)
Enable: NIST 800-53 regulatory compliance standard
CSPM findings review: monthly (part of EV-F01 boundary review section)
Critical CSPM findings: create EV-D07 entry (patch/vulnerability SLA applies)
Key CSPM checks to run monthly:
Any S3 bucket (AWS) / Storage Account (Azure) with public access: Critical finding
Any security group with inbound 0.0.0.0/0 on SSH/RDP: Critical finding
MFA not enabled on cloud console root/global admin account: Critical finding
CloudTrail (AWS) / Activity Log (Azure) disabled: High finding
Document CSPM results in monthly EV-F01 cloud boundary section
CLOUD AUDIT LOGGING (3.3.1 — equivalent to on-premises firewall logging):
AWS: CloudTrail — enable in all regions; send to S3 + CloudWatch Logs → SIEM
Azure: Activity Log — export to SIEM via Diagnostic Settings
GCP: Cloud Audit Logs — export via Pub/Sub to SIEM
SIEM must receive cloud audit logs — verify monthly in EV-F06 (SIEM health)
Section 11 — Evidence generation and maintenance
11.1 Evidence register for FC-01
| Evidence ID | What to produce | Controls satisfied | Frequency | Owner | Filed at |
|---|---|---|---|---|---|
| EV-D19 | Boundary and network configuration baseline — firewall settings, zone model, rule naming policy, VPN cipher suite, proxy configuration, DNS filter configuration, AV exception register | SC.L1-3.13.1, 3.13.5, 3.13.6, 3.13.7, 3.13.9 · CE Firewalls · DEFSTAN P0/P1 §Boundary | Annual review + on significant change | IT Manager | AT-SC-BDY / FC-01 → Config Baseline |
| EV-D20 | Quarterly configuration audit — firewall platform settings against BL-NET baseline; switch hardening; cloud security group review | SC.L1-3.13.1, 3.13.5 · ISO 27001 A.8.20 | Quarterly | IT Manager | EV-D → Config Management → Config Audits → [YYYY-QQ] |
| EV-D21 | Change management records — RFC for every firewall rule change; SIA attached | 3.13.1, 3.13.6 · AT-CM | Per change | IT Manager | EV-D → Config Management → Change Log |
| EV-D19 (supplementary) | External connection register — all authorised external connections; source, destination, protocol, auth method, business justification | AC.L1-3.1.20 · DEFSTAN P0 §Boundary | Annual + on new connection | IT Manager | AT-SC-BDY / EV-D19 → External Connections |
| EV-F01 | Monthly SIEM log review — boundary event section: Zone 2→Zone 3 denies, after-hours Zone 3 access, large transfers, new rule activity | SC.L1-3.13.1 · ISO 27001 A.8.16 | Monthly | Security Analyst | EV-F → Continuous Monitoring → Log Reviews |
| EV-F03 | Six-monthly firewall rule review — full rule base analysis; findings; remediation tracking; CISO sign-off | SC.L1-3.13.1, SC.L1-3.13.5, 3.13.6 · CE Firewalls · DEFSTAN P1 §Boundary | Every 6 months (H1 and H2) | IT Manager + CISO | EV-F → Continuous Monitoring → Firewall Reviews |
| EV-F04 | Monthly IDS/IPS alert review | SC.L1-3.13.1 · ISO 27001 A.8.16 | Monthly | Security Analyst | EV-F → Continuous Monitoring → IDS Reviews |
11.2 Evidence production calendar
DAILY:
[ ] SIEM alert queue: Critical IDS/IPS alerts — respond within 1 hour
[ ] Zone 3 access anomalies: after-hours access alerts; investigate same day
[ ] DNS/web proxy block spike: any large increase in block events vs baseline?
WEEKLY:
[ ] SIEM: Zone 2 → Zone 3 deny events — are there unexplained patterns?
[ ] VPN: any failed auth spikes? Any geographically anomalous connections?
[ ] Cloud CSPM: any new Critical findings in AWS Security Hub / Defender for Cloud?
[ ] Firewall: any configuration changes made this week? All have RFCs?
MONTHLY (by 7th of month):
[ ] EV-F01: boundary section completed as part of full SIEM log review
[ ] EV-F04: IDS/IPS alert review (by 7th)
[ ] Cloud audit logs: SIEM ingesting correctly? (EV-F06 SIEM health check)
[ ] Web proxy: blocked URL category report — any new categories emerging?
[ ] DNS: blocked domain summary — any new malicious domains hitting the filter?
QUARTERLY:
[ ] EV-D20: configuration audit includes firewall platform settings vs BL-NET
specifically: default deny present and logging; management access Zone 4 only;
no management ports open from internet; firmware version current
[ ] VLAN reconciliation: switch VLAN configuration matches zone model
[ ] External connection register (EV-D19): all documented connections still active?
Any new connections made that are not in the register?
[ ] VPN user group: cross-reference against HR active employee list (EV-D01)
[ ] Cloud security groups: quarterly audit (add to EV-D20)
[ ] IDS/IPS signature suppressions: still necessary? Any that can be removed?
EVERY SIX MONTHS (EV-F03 — H1: April; H2: October):
[ ] Export current rule base: SHA256 hash the export
[ ] Diff against prior review export: identify all changes
[ ] Full rule-by-rule review (all checks in Section 7.2)
[ ] External port scan from internet-facing vantage point
[ ] CISO sign-off on EV-F03 before filing
ANNUALLY:
[ ] EV-D19: full network configuration baseline review
Update zone model diagram; verify all settings still current
CISO and IT Manager sign-off
[ ] BL-NET baseline update: any new CIS Benchmark release for deployed platforms?
Update baseline version; schedule remediation if new requirements
[ ] ISP and CDN supplier review: security SLAs still met? (AT-RA supplier assurance)
[ ] Penetration test: external network scope (EV-D09 — covers boundary testing)
Pen test findings create EV-D07 entries (patch SLA applies to pen test findings)
PER EVENT:
[ ] Any firewall rule change: RFC created before change; EV-D21 entry filed
[ ] Any new external system connection: EV-D19 external connection register updated
[ ] Any Critical IDS/IPS alert: CISO notified within 1 hour; EV-D12 opened if incident
[ ] Any management port found open from internet: immediate remediation (Emergency RFC);
EV-D08 if remediation cannot be immediate; CISO notified same day
[ ] Any undocumented rule found in rule base: investigate; CISO notified;
RFC raised for removal or documentation; add to EV-F03 as Type D finding
[ ] Firewall firmware update: RFC; EV-D21; post-upgrade verification; EV-D07 closed
11.3 Pre-assessment quality checks
Run 2 weeks before any C3PAO, Cyber Essentials+, DEFSTAN, or ISO 27001 assessment:
FIREWALL CONFIGURATION:
□ EV-F03 is current (within 6 months) — most recent review signed by CISO
□ No findings from the last EV-F03 remain open without a corrective action plan
□ All firewall rules have compliant descriptions (checked in EV-F03 review)
□ Default deny is last rule in every rule base and is logging
□ No inbound rules permit any source from Zone 0 to Zone 2 or Zone 3
□ No management ports (SSH/RDP/HTTPS-MGMT) accessible from internet:
Run external port scan: nmap -Pn -p 22,23,80,3389,8080,8443 [firewall-public-IP]
Expected: all filtered or closed
DMZ:
□ Zone 1 subnet is distinct from Zone 2 and Zone 3
□ No CUI systems have IP addresses in Zone 1
□ Zone 1 → Zone 3 rules: CISO confirmed each one in most recent EV-F03
LOGGING:
□ Firewall syslog forwarding to SIEM is active (EV-F06 health check confirms)
□ EV-F01 has been produced for each of the past 3 months
□ Boundary section of EV-F01 is populated (not blank)
VPN:
□ Split tunnelling is disabled: verify from test VPN connection
□ VPN requires certificate + Entra ID MFA (no password-only VPN auth)
CHANGE MANAGEMENT:
□ Every firewall rule change in the past 12 months has a corresponding RFC in EV-D21
□ No rules added since last EV-F03 without an RFC (checked by diff)
CE-SPECIFIC:
□ External port scan confirms no unexpected open ports on public IP
□ Personal firewall active on all CUI-scope devices (EV-D20 — FC-02 audit)
□ Guest SSID/VLAN is isolated from corporate network (verify no route Zone 5 → Zone 2)
DEFSTAN-SPECIFIC:
□ EV-F03 is available and shows the rule review was formally conducted
□ VPN encryption: AES-256; IKEv2 — documented in EV-D19
□ Firewall rule documentation: every rule has a business justification
(DEFSTAN assessor may ask "Why does this rule exist?" for any rule they select)
□ Network architecture diagram is current (updated within 12 months)
and reflects the actual deployed topology (not an aspirational diagram)
FC-01 IT Staff Technical Procedures — Owner: IT Manager (boundary policy) + Network Engineer (implementation). Related pages: AT-SC-BDY · Boundary Protection (advanced tier — full SSP detail for all 9 SC boundary controls); AT-SC-ENC · Encryption (VPN cipher suite, TLS, FIPS); AT-CM → BL-NET (network device baseline); OP-03 · Logging and SIEM Management (NTP, syslog, log source management). Evidence produced: EV-D19 (configuration baseline), EV-D20 (quarterly config audit), EV-D21 (change records), EV-F01 (monthly SIEM review — boundary section), EV-F03 (six-monthly rule review), EV-F04 (IDS/IPS alert review). Questions: IT Manager or CISO.