FC-01 · Firewalls and Network Security
Confluence page header block
Page title: FC-01 · Firewalls and Network Security
Parent page: 02 · Fundamental Controls
SCM variants: Default (all-staff) | isms-it-staff | isms-security
Page owner: IT Manager
Last reviewed: [DATE]
Next review: [DATE + 12 months]
Framework mapping panel
Visible to all users. Placed immediately below the page title as a metadata callout.
| Field | Value |
|---|---|
| CMMC Level 1 practices | SC.L1-3.13.1 · SC.L1-3.13.5 · AC.L1-3.1.20 |
| Cyber Essentials domain | Firewalls — all boundary and device firewall requirements |
| DEFSTAN 05-138 | Profile 0 (Baseline) — §Boundary Protection and §Network Security |
| ISO 27001 Annex A | 8.20 (Network security) · 8.21 (Security of network services) · 8.22 (Segregation of networks) · 5.14 (Information transfer) |
| Related advanced pages | AT-SC · System and Communications Protection → AT-SC-BDY · Boundary |
| All-staff guidance | 02 · Fundamental Controls → FC-01 (this page) · 04 · User Guidance Hub → Working From Home |
| Evidence items (IT/Security) | EV-D19 · EV-D20 · EV-F03 · EV-F04 · EV-D21 |
Why firewalls are the perimeter every other control depends on
All-staff layer — visible to everyone.
Every security control we operate — the antivirus on your laptop, the MFA on your account, the encrypted VPN tunnel you use when working remotely — assumes that the network boundary between our systems and the outside world has not been compromised. The firewall is what maintains that boundary. It decides which network connections are allowed in, which are allowed out, and which are silently discarded before they reach anything meaningful.
Without a functioning, correctly configured firewall, none of the other controls operate in the environment they were designed for. An antivirus product running on a system that is directly exposed to the internet without boundary protection is fighting a significantly harder battle than one operating behind a properly configured perimeter. The firewall does not replace the other controls — it is the prerequisite for them.
This is reflected in how assessors approach our compliance programme. Cyber Essentials lists firewalls as the first of its five technical controls. CMMC Level 1 includes boundary protection as a baseline practice. DEFSTAN Profile 0 requires documented boundary controls before anything else in the technical domain. Every framework starts here because every other control depends on it.
All-staff layer
No SCM variant wrapper — visible to isms-all-staff, isms-it-staff, and isms-security.
What the three CMMC Level 1 practices require
These three practices are the US Department of Defense's baseline boundary protection requirements. They apply to any organisation handling Federal Contract Information, which includes most of the contract work we do.
SC.L1-3.13.1 — Monitor, control, and protect communications at external boundaries and key internal boundaries. Every connection between our systems and the internet passes through a firewall that monitors, permits, or denies that connection based on documented rules. The same principle applies to boundaries between internal network segments where different levels of sensitivity exist — the network where CUI is processed is separated from the general office network, which is separated from any guest or visitor network.
SC.L1-3.13.5 — Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. Any system that needs to be reachable from the internet — our public-facing web presence, email gateways, or other externally accessible services — sits in a network zone that is separated from the internal network where CUI is processed. A breach of the externally accessible zone does not give the attacker direct access to internal systems. They face another boundary.
AC.L1-3.1.20 — Verify and control all connections to external systems. Every connection we make to a system outside our network boundary is authorised and documented. Staff do not connect to external systems using unauthorised channels. The organisation does not have undocumented connections to third-party systems. Cloud services accessed from our network are approved and controlled.
Cyber Essentials — the firewall requirements
Cyber Essentials defines boundary firewall requirements across two contexts: the network boundary that protects all our connected devices, and the software firewall on each individual device.
Boundary firewall — the perimeter:
The firewall at the boundary of our network must be configured so that only connections that are necessary for the organisation's business are permitted. The default position is block everything; then specifically allow what is needed. The opposite approach — allow everything and block the bad stuff — is not acceptable under Cyber Essentials and is not how our firewalls are configured.
Specifically, the boundary firewall must block all inbound connections from the internet except for services we have explicitly decided to make accessible. If we have no externally accessible services on a given port, all traffic to that port from the internet is denied. This applies even if the service behind that port is otherwise secure — if it does not need to be internet-accessible, it should not be.
Firewall rules must be documented. Each rule must have a stated business purpose. Rules that exist without a documented reason — because a previous engineer created them and nobody knows why — are removed during the regular firewall rule review. An undocumented rule permitting inbound traffic is a Cyber Essentials finding.
The firewall must be configured to block unauthenticated inbound connections by default — meaning that an external system trying to initiate a connection to our internal systems will fail, regardless of whether the connection itself looks legitimate. Connections from us to external systems (outbound) may be controlled less strictly, though outbound filtering is also implemented for known malicious destinations.
Personal firewall — on every device:
In addition to the boundary firewall, every device connected to our network — and every device used to access our systems remotely — must have a software firewall enabled. On Windows, this is Windows Defender Firewall. On macOS, this is the built-in application firewall. The personal firewall is the device's own boundary protection, operating even when the device is on a network we do not control.
The personal firewall must be enabled at all times. You must not disable it. IT Operations configures the personal firewall via Group Policy (Windows) and MDM configuration profile (macOS) and the settings cannot be changed by standard user accounts. If you believe the firewall is causing a problem with an application you need to use, report it to IT Operations — do not disable the firewall.
Cyber Essentials assessors will verify that personal firewalls are enabled on every device in scope. A single device with the firewall disabled is a finding that affects the certification.
What is not permitted under Cyber Essentials:
The following configurations fail the Cyber Essentials firewall requirement and are explicitly prohibited on any device used for work:
Disabling the firewall entirely, even temporarily. Configuring a firewall rule that allows all inbound connections from all sources on any port. Running services that listen on network ports that are not documented and approved. Connecting a device to a network where there is no firewall between it and the internet without the device having its own software firewall active. Using a personal router in the office that bypasses the corporate perimeter firewall.
DEFSTAN Profile 0 — boundary requirements for defence work
DEFSTAN 05-138 Profile 0 §Boundary Protection sets the minimum boundary security requirements for organisations handling OFFICIAL-tier UK government information. For most of our MOD and defence contract work, Profile 0 is the minimum that applies. Some contracts specify Profile 1 or Profile 2, which layer additional requirements on top.
Profile 0 requires:
A documented network boundary exists between systems handling OFFICIAL information and any less-controlled environment — including the internet, shared networks, and guest networks. The boundary must be technically enforced, not just described. A policy saying "only authorised users access OFFICIAL systems" is not a boundary — a firewall enforcing that policy technically is.
All connections crossing the boundary — inbound and outbound — are controlled by a rule-based system. Rules are documented. The documentation includes what is permitted, from where, to where, and why. Rules without documented justification are removed.
The boundary protection is reviewed at defined intervals. For Profile 0, an annual review is the minimum. Our boundary review is conducted quarterly (EV-F03 monthly firewall rule review) and following any significant network change, which exceeds the Profile 0 requirement.
Remote access to systems handling OFFICIAL information is encrypted. VPN access to our network uses certificate-based authentication and encrypts all traffic between the remote device and our network gateway. Unencrypted remote access to OFFICIAL systems is not permitted.
The boundary is not circumvented for convenience. Staff do not use personal mobile hotspots to bypass the corporate network when on site. IT Operations does not create temporary firewall rule exceptions for ease of access. Any permanent or temporary exception requires a documented justification and follows the change management process.
Profile 0 boundary documentation requirement:
DEFSTAN requires that the boundary be documented in the organisation's security management system. The network topology diagram, the firewall rule register (maintained in EV-D19), and this Fundamental Controls page together constitute that documentation. Assessors may request to review the firewall rule register and the network topology to verify the documented boundary matches the actual technical boundary.
What this means for you — all-staff obligations
Most of what is described on this page happens automatically and is invisible to you. The firewalls operate, the rules are reviewed, the VPN encrypts your traffic — none of this requires your active involvement. Your obligations are behavioural rather than technical.
Use the VPN whenever you are working outside the office. The VPN routes your traffic through the corporate network and subjects it to the same firewall protection as if you were sitting at your desk. Without it, your traffic goes directly to the internet from whatever network you are on — a home network, a hotel Wi-Fi, a café connection — without the benefit of the corporate perimeter protection. The VPN is not optional for remote working. It is the mechanism by which the boundary extends to where you are.
Do not connect personal devices to the corporate network. Personal laptops, tablets, and phones that are not enrolled in our MDM and have not had the security baseline applied are not permitted on the CUI-scope network. They are permitted on the guest network where one exists. A personal device on the corporate network is a device that has not been verified against our security baseline, has an unknown security posture, and bypasses the internal boundary controls.
Do not use a personal mobile hotspot as a workaround. If the corporate network or VPN is unavailable, the correct response is to contact IT Operations, not to use your phone's hotspot to get the work done. A mobile hotspot creates a path from your device to the internet that bypasses the corporate perimeter firewall entirely. This is a policy breach and may constitute a reportable incident depending on what information is accessed via that path.
Do not approve firewall exception requests from unknown callers. Social engineering attacks sometimes involve a caller claiming to be a vendor or IT support engineer asking you to allow a connection, approve a firewall prompt, or change a network setting. You are not in a position to approve these requests and you should not attempt to do so. Decline and report the call to IT Operations.
Report unexpected network behaviour. If you notice that a website or service that should be accessible is suddenly blocked, that a connection that normally works has stopped working, or that a security prompt is appearing on your device that you do not understand — report it to IT Operations. Do not attempt to work around it. Unexpected changes in network behaviour are worth investigating.
What to do if something goes wrong
You receive a firewall permission prompt on your device asking you to allow an application to accept incoming connections. Do not click Allow unless IT Operations has specifically told you to expect this prompt. Take a screenshot and report it to IT Operations immediately. This type of prompt may indicate that software on your device is attempting to open a listening service that was not previously present.
You cannot connect to the VPN. Contact IT Operations. Do not access company systems without the VPN. If your work requires access to a system that can only be reached via VPN, wait for IT Operations to resolve the issue rather than finding a workaround.
A website or service you use for work is suddenly blocked. Report it to IT Operations. Do not use a VPN client or proxy service to bypass the block. The firewall may have blocked it deliberately because a threat intelligence source identified it as malicious, or it may be a misconfiguration — either way IT Operations needs to know.
You are advised by anyone — including someone claiming to be from IT support — to disable your firewall. This is a social engineering attack. Decline. Report it to IT Operations and the security team. Provide as much detail as possible: the method of contact, what was said, and any identifiers the caller provided.
You believe a personal device or an unknown device has connected to the corporate network. Report it to IT Operations immediately. This is a potential boundary violation and the security team needs to investigate.
You receive a security alert from your device indicating that the firewall has blocked a connection. This means the firewall is working. Note the details if possible (what application was blocked, what it was trying to connect to) and report it to IT Operations. You do not need to take any other action — the block is the correct behaviour.
IT-staff layer
SCM variant: isms-it-staff — visible to isms-it-staff and isms-security.
{scroll-content:variant=isms-it-staff}
Technical implementation — IT Operations
This section provides the implementation detail for SC.L1-3.13.1, SC.L1-3.13.5, and AC.L1-3.1.20 across the boundary firewall, the host-based firewall on all endpoint types, and the internal network segmentation. Full boundary architecture specification is in AT-SC-BDY. This page covers the fundamental tier obligations and the Cyber Essentials and DEFSTAN-specific configuration requirements.
Network architecture and zone model
Zone model — three-tier architecture:
ZONE 0: Internet (untrusted)
Everything outside our control
All inbound connections from Zone 0 are denied by default
Specific inbound permitted: [document only what applies]
- HTTPS (443) to DMZ web presence only
- SMTP (25) to email gateway only
- VPN (UDP 500/4500 or TCP 443) to VPN endpoint only
- IMAP/POP3: explicitly blocked (legacy auth — zero exceptions)
ZONE 1: DMZ (semi-trusted — SC.L1-3.13.5)
Publicly accessible components sit here
Physically or logically separated from Zone 2 (internal)
What lives in DMZ:
- Reverse proxy / WAF (if public web presence exists)
- Email gateway / MTA
- VPN concentrator / gateway
- Any other externally accessible service
DMZ to internal (Zone 2) rules:
Only specific, documented application traffic permitted
No "any to any" rules between DMZ and internal
DMZ compromise must not give direct access to Zone 2
DMZ to internet (Zone 0) rules:
Outbound: only what the service in DMZ legitimately needs
Email gateway: outbound SMTP (25) to specific destination MX records
Reverse proxy: no outbound (receives only; does not initiate external connections)
ZONE 2: Internal network (trusted — general office)
Domain workstations and general business systems
Staff workstations, printers, IP phones, meeting room devices
Internal to internet:
Outbound via web proxy (not direct to internet from workstations)
Web proxy applies: URL filtering, TLS inspection, malicious destination blocking
Protocol restriction: HTTPS (443) and HTTP (80 — redirect to HTTPS) via proxy
Direct outbound on other ports from workstations: blocked (all traffic via proxy)
ZONE 3: CUI network segment (most trusted — SC.L1-3.13.1)
CUI-scope servers, CUI data stores, CUI-processing applications
Logically separated from Zone 2 via VLAN and firewall rules
Zone 2 to Zone 3 rules:
Specific user accounts only (enforced via identity-aware firewall or CA)
Specific applications/ports only:
File server: SMB (445) from CUI-authorised workstations only
Database: [port] from application server only (not directly from workstations)
Management: SSH/RDP from management VLAN only (not from Zone 2 directly)
Zone 3 to internet (Zone 0):
No direct internet access from CUI servers
Update traffic: via WSUS/MDM proxy only
SIEM log forwarding: via syslog to SIEM (not direct internet)
Any required cloud API access: via proxy or NAT gateway with egress filtering
ZONE 4: Management VLAN (admin plane — AC.L1-3.1.20)
Network device management interfaces, hypervisor management, BMC/IPMI
Accessible only from specific named workstations (admin workstations in Zone 2)
No user access permitted — IT Operations only via PAM
No route to internet from Zone 4
Zone 4 access rules:
Inbound: only from adm-* PAM jump host in Zone 2
Outbound: NTP to internal NTP server; SYSLOG to SIEM; nothing else
ZONE 5: Guest/Visitor (untrusted internal)
Physically separate SSID and VLAN
Internet access via NAT (no RFC1918 routes — cannot reach any internal zone)
No access to Zone 2, 3, or 4 from Zone 5
Captive portal: acceptable use acknowledgement before internet access granted
DHCP scope: separate range outside the internal RFC1918 space
DNS: resolved via public resolver (not internal DNS — prevents internal hostname enumeration)
Perimeter firewall — configuration specification
Platform: [Deployed product — e.g. Palo Alto PA-Series / Fortinet FortiGate /
Cisco Firepower / Azure Firewall / AWS Network Firewall — specify]
HA configuration: Active-passive (preferred) / Active-active
Management: [Panorama / FortiManager / Firepower Management Centre / vendor equivalent]
Management interface: accessible from Zone 4 management VLAN only
Management authentication: PAM-mediated — FIDO2 required for firewall admin accounts
Firewall rule ordering principle:
1. Deny rules (explicit blocks for known-bad sources and specific protocols)
2. Allow rules (specific, documented, least-privilege permits)
3. Default deny (implicit — all traffic not matched by an allow rule is dropped)
Important: never use "allow any any" or "allow any any any" rules.
Every allow rule must specify: source zone/IP, destination zone/IP,
application/service (not just port), and have a documented justification.
Rule documentation requirements (Cyber Essentials and DEFSTAN):
Every firewall rule in the active rule base must have:
Rule name: descriptive (e.g. ALLOW-SMTP-GW-to-Internet, not Rule_47)
Description field: business justification for the rule
Owner field: IT Operations engineer responsible for this rule
Creation date: populated (many platforms support this natively)
Last reviewed date: updated at each quarterly review
Rules without a populated description field:
Add "UNDOCUMENTED-REVIEW-[date]" to the name
Investigate at next CAB: either document or remove
Remove at the subsequent review if still undocumented
An undocumented rule is a Cyber Essentials finding regardless of
whether the traffic it permits is legitimate
Standard rule set — inbound (internet to DMZ):
Name Src Dst App/Port Action Justification
──────────────────────────────────────────────────────────────────────────────────
ALLOW-HTTPS-Internet-WAF any [WAF IP] https/443 permit Public web
ALLOW-SMTP-Internet-MTA any [MTA IP] smtp/25 permit Email receive
ALLOW-VPN-Internet-GW any [VPN IP] udp/500 permit Remote access
udp/4500
tcp/443
DENY-ALL-Internet-Internal any [internal] any deny+log Security boundary
DENY-ALL-Internet-Mgmt any [Zone 4] any deny+log No external mgmt
DEFAULT-DENY any any any deny+log Implicit default
Standard rule set — outbound (internal to internet):
(All workstation outbound via web proxy — not direct)
Name Src Dst App/Port Action Justification
──────────────────────────────────────────────────────────────────────────────────
ALLOW-HTTP-Proxy-Internet [proxy IP] any http/80 permit Web via proxy
ALLOW-HTTPS-Proxy-Internet [proxy IP] any https/443 permit Web via proxy
ALLOW-SMTP-MTA-Internet [MTA IP] any smtp/25 permit Email send
ALLOW-NTP-Internal-Internet [NTP IP] [pool] ntp/123 permit Time sync
ALLOW-DNS-Resolver-Internet [DNS IP] [root] dns/53 permit DNS resolution
DENY-ALL-Workstation-Internet [wkst net] any any deny+log No direct internet
DENY-ALL-CUI-Internet [Zone 3] any any deny+log CUI no direct out
Cyber Essentials specific rule requirements:
All inbound rules from "any" source must target only specific named services
No rule permits inbound "any" to "any" destination
No rule permits inbound to port ranges unless each port in range is justified
Administrative interfaces (web GUI, SSH management) must NOT be accessible
from the internet — they should appear in Zone 4 rules only:
firewall management: accessible from [jump host IP in Zone 4] only
switch management: accessible from [jump host IP in Zone 4] only
hypervisor management (ESXi/Hyper-V): accessible from [jump host IP] only
VPN configuration — remote access (AC.L1-3.1.20)
VPN platform: [deployed product — e.g. GlobalProtect / FortiClient /
Azure VPN Gateway / Cisco AnyConnect — specify]
Protocol: IKEv2/IPsec (preferred) or SSL/TLS
Authentication: certificate-based (device) + Entra ID SAML (user) + MFA
Device certificate: issued by internal CA; installed via MDM
User auth: Entra ID SAML → Conditional Access enforces MFA
Note: username/password-only VPN authentication without MFA fails
IA.L1-3.5.2 and Cyber Essentials Requirement 5.
Certificate + MFA is the required configuration.
Split tunnelling: DISABLED
All traffic routes through corporate VPN when connected
Reason: split tunnelling bypasses web proxy, URL filtering, and
egress firewall controls — defeats boundary protection
Verify: when VPN is connected, internet traffic should route via
corporate IP (test via: curl https://ipinfo.io/ip — should return
corporate egress IP, not personal ISP IP)
Connection policies:
VPN gateway: [IP/FQDN]
Allowed users: members of VPN-Users group (= all staff by default)
Blocked users: accounts in leaver process have VPN group removed
as part of EV-D04 de-provisioning (Step 4)
Session timeout: 8 hours (re-authentication required after 8 hours)
Idle timeout: 60 minutes of inactivity → session terminated
Concurrent session limit: [N] per user (prevents a single compromised
account from establishing many simultaneous sessions)
Traffic forwarded via VPN:
All RFC1918 destinations: via VPN tunnel
All internet traffic: via VPN tunnel (no split tunnelling)
DNS: internal DNS resolver via VPN (prevents DNS leakage)
DEFSTAN Profile 0 remote access requirements:
Encryption: AES-256 minimum for VPN tunnel encryption
Key exchange: IKEv2 with ECDH P-384 or DH group 20 minimum
Authentication: certificate-based device auth + individual user MFA
Verify: openssl or vendor diagnostics showing cipher suite in use
VPN access must be logged:
Connection timestamp (start and end)
User identifier (UPN)
Device identifier (device certificate CN)
Source IP of connection
Bytes transferred (volume anomaly detection)
VPN logs forwarded to SIEM within 60 seconds of event
Retention: 90 days hot (searchable), 12 months archive
External system connections register (AC.L1-3.1.20):
Maintain a register of all external system connections as part of EV-D19:
| Connection | Source | Destination | Protocol/Port | Auth method | Business owner | Last reviewed |
| VPN access | Staff devices | VPN gateway | IKEv2/UDP500,4500 | Cert + MFA | IT Manager | [date] |
| Email send | Internal MTA | External MX | SMTP/25 (TLS) | TLS mutual | IT Manager | [date] |
| Email receive | Internet | MX gateway | SMTP/25 | SPF/DKIM/DMARC | IT Manager | [date] |
| Cloud backup | Backup agent | [cloud endpoint] | HTTPS/443 | Client cert + key | IT Manager | [date] |
| [add all] | | | | | | |
Any connection not in this register that is discovered during network review:
Investigate immediately (undocumented external connection = potential incident)
If legitimate: add to register via change management process
If unknown: escalate to CISO; treat as potential data exfiltration until confirmed
Internal network segmentation (SC.L1-3.13.1 and SC.L1-3.13.5)
VLAN configuration:
VLAN ID Name Zone Subnet Purpose
───────────────────────────────────────────────────────────────────────────────
10 DMZ 1 [e.g. 10.0.10.0/24] DMZ services
20 Internal-General 2 [e.g. 10.0.20.0/23] Staff workstations
30 CUI-Servers 3 [e.g. 10.0.30.0/24] CUI-scope servers
40 Management 4 [e.g. 10.0.40.0/24] Network/system mgmt
50 Guest 5 [e.g. 192.168.100.0/24] Visitor Wi-Fi
VLAN enforcement:
Workstations: assigned to VLAN 20 at switch port level (GPO + 802.1X)
Servers: assigned to VLAN 30 at switch port level (static assignment)
Management ports: assigned to VLAN 40 (access ports on switches;
management interfaces of all managed devices)
Wi-Fi:
Corporate SSID: 802.1X auth → VLAN 20 (domain-joined devices)
802.1X auth → VLAN 30 (CUI-scope devices, where applicable)
Guest SSID: MAC registration optional → VLAN 50 (internet-only)
VLAN hopping prevention:
Native VLAN on trunk ports: set to unused VLAN (not VLAN 1 and not
any production VLAN — an unused VLAN ID serves as a hopping barrier)
DTP (Dynamic Trunking Protocol): disabled on all access ports
VLAN 1 (default): not used for any production traffic;
all ports pruned from VLAN 1 where supported
Inter-VLAN routing:
Handled by layer-3 switch or firewall (not by end devices)
All inter-VLAN traffic is inspected by firewall rules
No direct routing between Zone 2 and Zone 3 without firewall inspection
Verify: attempt to ping a Zone 3 host from a Zone 2 workstation
Expected: blocked (no direct route, or firewall denies the attempt)
Any successful ping from Zone 2 to Zone 3 without specific rule = misconfiguration
CUI server VLAN access (Zone 3) — specific rule requirements:
Only accounts in GRP-CUI-Access group are permitted to route to Zone 3
Enforcement: identity-aware firewall rule (Palo Alto user-ID / Fortinet FSSO)
OR Conditional Access network location policy for cloud resources
OR combination (network firewall + CA for cloud CUI resources)
Workstation-to-CUI-server traffic:
SMB (445): only from CUI-authorised workstations [explicit source IP/MAC or identity]
RPC (135, 49152-65535): only from CUI-authorised management hosts
Direct database access: blocked from workstations; application server only
SSH/RDP to CUI servers: from jump host in Zone 4 via PAM only
Log all Zone 2 → Zone 3 traffic:
All permitted traffic: logged (source, destination, application, user, bytes)
All denied traffic: logged (source, destination, application, denied rule)
Retention: 90 days searchable; forwarded to SIEM within 60 seconds
Host-based firewall configuration — all platforms
WINDOWS (Windows Defender Firewall with Advanced Security)
GPO enforcement path:
Computer Configuration → Windows Settings → Security Settings →
Windows Firewall with Advanced Security
Required profile settings (applied to all three profiles: Domain, Private, Public):
Firewall state: On
Inbound connections: Block (all inbound blocked unless explicitly allowed)
Outbound connections: Allow (with logging of blocked outbound attempts)
Notification: Do not notify users when programs are blocked
(users reporting firewall blocks go to IT Operations, not bypassing the firewall)
Logging (for SIEM forwarding):
Log dropped packets: Yes
Log successful connections: Yes (for CUI-scope systems)
Log file location: %systemroot%\system32\logfiles\firewall\pfirewall.log
Log file size: 32768 KB
Forward Windows Firewall log to SIEM via WEF:
Enable subscription on WEC for:
Log: Security
EventID: 5152 (packet blocked), 5154 (listen success), 5156 (allowed connection)
Inbound rules required for standard workstations:
All inbound rules from the default Windows ruleset should be reviewed
Many default rules are overly permissive for CUI-scope workstations
Disable via GPO (inbound rules that should be off):
File and Printer Sharing (inbound) — disable unless device is a print server
Remote Desktop — disable unless RDP is specifically authorised for this device
Network Discovery (all rules in this group) — disable for CUI workstations
Remote Assistance — disable (use approved remote support tool instead)
WMI inbound — disable unless required for monitoring agent
Enable via GPO (if required for monitoring/management):
[Monitoring agent name] inbound on [port]: from [management VLAN IP range] only
Verify GPO is applied:
gpresult /h gpresult.html /scope computer
Review: confirm Windows Firewall GPO is applying (not superseded by local policy)
PowerShell verification:
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction
Expected output:
Domain — Enabled: True — DefaultInboundAction: Block
Private — Enabled: True — DefaultInboundAction: Block
Public — Enabled: True — DefaultInboundAction: Block
MACOS (Application Firewall via MDM Configuration Profile)
MDM payload: com.apple.security.firewall
EnableFirewall: true
BlockAllIncoming: true
EnableStealthMode: true
(Stealth mode: device does not respond to ping requests or
other probing attempts — no response is better than "ICMP unreachable")
Outgoing connections: applications can make outbound connections by default
(macOS firewall is inbound-focused; outbound filtering at network level)
Application exceptions (document each):
If a specific application requires inbound listening:
Add to AllowedApplications array with code signing requirement
Only signed applications may be added (no ad-hoc signed or unsigned)
Verify via Jamf smart group or terminal:
/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Expected: Firewall is enabled. (State = 1)
/usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode
Expected: Stealth mode enabled
If not enabled on any enrolled device: MDM compliance alert fires (configured
in the smart group CUI-Scope-MacOS-NonCompliant in FC-02)
LINUX SERVERS (nftables / iptables via Ansible)
For CUI-scope Ubuntu servers, host-based firewall is managed via Ansible:
# Ansible role: host_firewall
# Template: /etc/nftables.conf
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# Established and related connections
ct state established,related accept
ct state invalid drop
# Loopback
iif lo accept
# ICMP (limited — allow ping for network diagnostics but rate-limit)
ip protocol icmp icmp type { echo-request } limit rate 10/second accept
# SSH — from management VLAN only (Zone 4 source)
tcp dport 22 ip saddr [Zone-4-subnet] accept
# Application-specific (add only what this specific server requires):
# Example: SMB from CUI workstations only
# tcp dport 445 ip saddr [CUI-workstation-range] accept
# Log everything else before dropping
log prefix "DROPPED-INPUT: " group 0
drop
}
chain forward {
type filter hook forward priority 0; policy drop;
# Servers should not forward traffic — all forwarding is dropped
}
chain output {
type filter hook output priority 0; policy accept;
# Outbound allowed — filtered at network level by Zone 3 egress rules
# Log outbound connections to CUI-scope systems for audit
log prefix "OUTBOUND: " group 0
}
}
Apply: ansible-playbook baseline.yml --tags host_firewall --limit cui_scope_servers
Verify:
nft list ruleset # Shows current active rules
nft list counters # Shows packet/byte counters per rule
ss -tlnp # Shows listening ports — verify only expected services listen
Quarterly firewall rule review procedure (generates EV-F03)
Conducted by: IT Manager (primary) + Network Engineer
Frequency: Monthly (firewall rule summary) + Quarterly (full rule review)
Timing: Monthly review in first week of each month; quarterly full review in Q1/Q2/Q3/Q4
MONTHLY FIREWALL RULE REVIEW (generates monthly EV-F03 entry):
Step 1 — Export current rule base from firewall management platform
Export format: [vendor-specific — CSV or PDF is acceptable; raw config is better]
Palo Alto (Panorama): Policies → Security → Export to CSV
FortiGate: Policy & Objects → IPv4 Policy → right-click → Download
Preserve the export — it is the audit snapshot for this month
Step 2 — Check for new rules added since last review
Compare current export against previous month's export
Any rule added outside of an approved RFC: immediate investigation
Firewall management platforms log all configuration changes
Verify: configuration change log for the past month
Any change without a corresponding RFC number in the description: finding
Step 3 — Check for rules without a description field
Filter: rules where Description = empty or null
For each: add "UNDOCUMENTED-REVIEW-[YYYY-MM]" to rule name
Create ITSM ticket for review at next CAB
Count and record: [N] rules without documentation
Step 4 — Check for overly permissive rules
Filter for rules matching any of these patterns:
Source = "any" AND Destination = internal zone AND Action = permit
Source = external AND Destination = "any" AND Action = permit
Application/Service = "any" in a permit rule (instead of specific app)
Destination = "any" in a permit rule allowing traffic from internet
Each match is a Cyber Essentials finding unless the rule is the default deny
Record count; create ITSM tickets for each instance
Step 5 — Check for rules with no recent traffic (potential stale rules)
Most firewall platforms show hit count per rule
Rules with zero hits in the past 90 days: candidate for removal
Before removing: confirm with rule owner that the service is genuinely unused
Removed rules: log in change management (RFC) and in EV-F03
Step 6 — Verify default deny is last rule and logs
Last rule in each policy base should be:
Action: Deny
Source: any
Destination: any
Application: any
Log: yes (all denied traffic is logged)
If default deny is not logging: this is both a Cyber Essentials and
DEFSTAN finding — all blocked inbound must be logged for the audit trail
Step 7 — Document and file EV-F03
EV-F03 Monthly Firewall Rule Review — [YYYY-MM]
Review date: [date]
Reviewed by: [IT Manager name] + [Network Engineer name]
Firewall platform: [name and firmware version]
Rule base version/export: [reference or attached]
Rules added since last review: [N]
Corresponding RFCs: [list RFC numbers or "all accounted for"]
Rules added outside change process: [N — if N>0, investigation ref]
Rules without documentation: [N]
ITSM tickets raised: [list ticket numbers or "None"]
Overly permissive rules found: [N]
Details: [list or "None"]
Remediation: [list or "None"]
Stale rules (zero hits >90 days): [N]
Candidates for removal: [list or "None"]
Default deny: Confirmed present and logging / Issue found: [description]
Cyber Essentials compliance: Pass / Issues found (see above)
DEFSTAN Profile 0 compliance: Pass / Issues found (see above)
IT Manager sign-off: _________________ Date: _________
CISO notified of findings: Yes (if findings) / N/A
File at: EV-F · Continuous Monitoring → Firewall Reviews → [YYYY-MM]
QUARTERLY FULL RULE REVIEW (additional steps):
In addition to the monthly steps, the quarterly review includes:
Q-Step 1 — Full rule-by-rule justification review
For every rule in the active rule base:
Is the documented business justification still valid?
Is the service the rule supports still in use?
Has the system the rule targets changed in a way that makes the rule wrong?
Rules whose justification is no longer valid: remove via RFC
Q-Step 2 — Zone boundary verification
Confirm the zone model matches the network diagram
Any host in the wrong zone (server in Zone 2 instead of Zone 3,
management interface reachable from Zone 2): document and remediate
Q-Step 3 — VPN access list review
All members of VPN-Users group
Cross-reference against HR active employee list
Remove any departed staff from VPN-Users group (should already be
done via EV-D04 but quarterly check catches any gaps)
Q-Step 4 — External connection register review
Review the register in EV-D19 against actual observed traffic
Any active external connection not in the register: investigate
Any register entry for a connection that no longer exists: remove
File quarterly addendum alongside monthly EV-F03 for the quarter
IDS/IPS configuration (generates EV-F04)
Platform: [deployed product — Palo Alto Threat Prevention / FortiIPS /
Snort/Suricata / AWS GuardDuty / Azure Defender / etc. — specify]
Mode: Prevention mode on CUI-scope ingress/egress (blocks + alerts)
Detection mode on less-sensitive segments (alerts only)
Signature update: automatic (vendor cloud-delivered) — confirm daily updates
Sensor placement:
IPS-01: Inline at perimeter (between Zone 0 and Zone 1 DMZ)
IPS-02: Inline between Zone 2 (internal) and Zone 3 (CUI servers)
IPS-03: [if applicable — additional placement points]
Signature categories enabled for CUI scope (enable all):
Malware — known malware C2 communication patterns
Exploit — known vulnerability exploitation attempts
Spyware — data exfiltration patterns
Vulnerability — protocol-level exploitation
Command and control — known botnet and C2 traffic patterns
Brute force — authentication brute force patterns
Signature categories reviewed and configured by CISO quarterly
New signature categories enabled when released by vendor if relevant to
our threat profile
Alert thresholds:
Critical severity signatures → block + alert → SIEM High alert →
IT Operations on-call notified within 15 minutes
High severity → block + alert → SIEM Medium alert →
Security Analyst review next business day
Medium severity → alert only → SIEM Low alert →
reviewed in monthly EV-F04 log review
False positive management:
Tuning requires CAB RFC (Normal change) to modify signature policy
Do not suppress signatures without CISO approval
All suppressions documented in EV-D19 with:
Signature ID, reason for suppression, approver, date, review date
Review date: 90 days (reassess whether suppression is still justified)
Monthly IDS/IPS alert review (generates EV-F04):
Security Analyst reviews all Critical and High alerts for the past month
For each unresolved Critical or High:
Is this a true positive? If yes → create/update incident in EV-D12
Is this a false positive? If yes → document reason; consider tuning via RFC
Summary metrics to record in EV-F04:
Total alerts by severity: Critical [N], High [N], Medium [N], Low [N]
True positives: [N] — incidents created: [list]
False positives: [N] — suppressions requested: [N]
Trend vs prior month: increasing / stable / decreasing
Anomalous alert spike (>200% of prior month baseline):
Escalate to CISO immediately
May indicate active scanning campaign, targeted attack, or IPS misconfiguration
Network device hardening — firewall and switch baseline
Reference: BL-NET baseline in AT-CM (FC-02 IT Staff Technical Procedures)
This section provides the specific settings relevant to boundary protection.
Firewall platform hardening:
Management access:
Web GUI: HTTPS only (TCP 443); HTTP → redirect to HTTPS (or disable HTTP)
SSH: enabled on management interface only (Zone 4 only);
SSH version 2; no version 1
Telnet: disabled (no exceptions)
SNMP: version 3 with authPriv security level; no SNMP v1 or v2c
API access: certificate-authenticated; restricted to Zone 4 source IPs
Administrator accounts:
Individual named accounts for each IT Operations admin
No shared "admin" account for routine operations
Shared emergency account: in PAM vault, rotated after each use
Authentication: FIDO2 via PAM (no password-only admin access)
Inactive admin accounts: reviewed quarterly in EV-D01
(firewall admins included in privileged account scope)
Logging configuration:
Log all authentication events (success and failure)
Log all configuration changes with admin account identifier
Log all policy rule hits for rules marked for logging
Log all traffic matching default-deny
Syslog: TCP (not UDP) to SIEM listener — [SIEM IP]:514
Syslog severity: informational and above
Switch hardening (relevant to boundary and segmentation):
BPDU Guard: enabled on all access ports
Prevents rogue switches from manipulating spanning tree
Edge ports send BPDU → port shut down automatically
Root Guard: enabled on uplink ports
Prevents rogue switch from becoming root bridge
Different ports from BPDU Guard (uplinks vs access ports)
DHCP Snooping: enabled
Trust: only uplink ports to DHCP server
Untrusted: all access ports (drops DHCP replies from access ports)
This prevents a rogue DHCP server on the network from redirecting traffic
Dynamic ARP Inspection: enabled
Validates ARP packets against DHCP snooping binding table
Drops ARP packets that don't match known IP-to-MAC bindings
Prevents ARP spoofing / man-in-the-middle attacks on the LAN
Port security / 802.1X:
CUI-scope network ports: 802.1X required (EAP-TLS with device certificate)
Guest network ports: MAC authentication bypass + captive portal
Unused ports: administratively shutdown + assigned to unused VLAN
Syslog to SIEM:
Authentication events (802.1X success/failure)
BPDU Guard events (port shutdown)
DHCP Snooping violations
Configuration change events
NTP: authenticated NTP from internal NTP server (see OP-03 NTP section)
Firmware:
Current firmware: [version]
Last updated: [date]
Critical CVE → patch within 7 days (track in EV-D07)
Check vendor security advisories monthly (add to SIEM threat intel feed)
External connection register — content requirements
The external connection register satisfies AC.L1-3.1.20 and DEFSTAN Profile 0
documentation requirements. Maintained as part of EV-D19 in AT-SC-BDY.
For each external connection, document:
Field Content
──────────────────────────────────────────────────────────────────────────────────
Connection name Descriptive (e.g. "Cloud backup to Azure Blob UK South")
Direction Inbound / Outbound / Bidirectional
Source Internal source (IP range or system name)
Destination External destination (FQDN or IP range if static)
Protocol and port e.g. HTTPS/443; SMTP/25; IKEv2/UDP 500,4500
Encryption TLS version; cipher; certificate validation
Authentication How the connection is authenticated at both ends
Business purpose Why this connection exists
Information transmitted What data types cross this connection (is it CUI? PII?)
Approved by Named role and date of approval
Firewall rule reference The specific rule(s) permitting this connection
Last reviewed Date this entry was last verified as still needed
Evidence generation — this control family
| Evidence ID | What to produce | When | How | Filed at |
|---|---|---|---|---|
| EV-D19 | Firewall rule register, network zone diagram, external connection register | Annual review + on significant network change | Export from firewall platform + network diagram; firewall rule register document | AT-SC-BDY / EV-D → Config Management |
| EV-D20 | Quarterly configuration audit — firewall settings against baseline | Quarterly | Automated check where available; manual verification of key settings | EV-D → Config Management → Config Audits → [YYYY-QQ] |
| EV-D21 | Change management records — RFC for every firewall rule change | Per change | ITSM RFC with SIA; CAB review; post-implementation verification | EV-D → Config Management → Change Log |
| EV-F03 | Monthly firewall rule review | Monthly | Rule export comparison; documented findings and remediations | EV-F → Continuous Monitoring → Firewall Reviews → [YYYY-MM] |
| EV-F04 | Monthly IDS/IPS alert review | Monthly | Alert console export; triage notes; incident cross-references | EV-F → Continuous Monitoring → IDS Reviews → [YYYY-MM] |
Evidence production calendar:
Weekly (automated or standing task):
[ ] SIEM alert review — boundary-related alerts (perimeter IPS,
firewall deny spikes, VPN anomalies)
Monthly:
[ ] EV-F03 — firewall rule review and filing
[ ] EV-F04 — IDS/IPS alert summary review and filing
[ ] VPN connection log review — anomalous sessions, departed users
Quarterly:
[ ] EV-D20 — configuration audit including firewall platform settings
[ ] Full firewall rule justification review (quarterly addendum to EV-F03)
[ ] External connection register verification
[ ] VPN user group cross-reference against HR active list
Annually:
[ ] EV-D19 — full firewall rule register, network zone diagram,
and external connection register review and reversion
[ ] Network penetration test (if in scope for the annual pen test programme)
[ ] Firewall platform firmware review against current vendor release
{scroll-content}
Security-staff layer
SCM variant: isms-security — visible to isms-security only.
{scroll-content:variant=isms-security}
Evidence currency dashboard
Review and update at the beginning of each month. A red status on any row requires immediate action before the next assessment.
| Evidence ID | Item | Required frequency | Last produced | Status | Owner |
|---|---|---|---|---|---|
| EV-D19 | Firewall rule register + network zone diagram + external connection register | Annual review + on significant change | [date] | [Current / Overdue] | IT Manager |
| EV-D20 | Quarterly configuration audit — includes firewall settings | Quarterly | [date] | [Current / Overdue] | IT Manager |
| EV-D21 | Change management records — firewall rule changes | Per change | [most recent RFC date] | [Current / Gap if change made without RFC] | IT Manager |
| EV-F03 | Monthly firewall rule review | Monthly | [date] | [Current / Overdue] | IT Manager |
| EV-F04 | Monthly IDS/IPS alert review | Monthly | [date] | [Current / Overdue] | Security Analyst |
Critical dependency note:
EV-F03 (monthly firewall rule review) depends on the rule register in EV-D19 being current. If EV-D19 was not updated after the most recent network change, EV-F03 comparisons against the prior month will be comparing against a stale baseline. Before any assessment, verify that EV-D19 was updated within 30 days of any RFC affecting the firewall rule base.
EV-F04 (IDS/IPS review) depends on the IDS/IPS sensor being correctly positioned and generating events. If the sensor has not generated any events in the past month, this may indicate the sensor is offline or misconfigured rather than the absence of threats. Verify sensor health as the first step of each monthly EV-F04 review.
MITRE ATT&CK context — what this control family detects
Boundary protection and network segmentation controls are primarily detective and preventive for the following ATT&CK technique categories.
T1190 — Exploit Public-Facing Application: The most common initial access vector for organisations with internet-accessible services. An attacker exploits a vulnerability in a web application, API, or service exposed through the DMZ. The boundary firewall limits the attack surface to only the explicitly permitted services. The IDS/IPS in prevention mode at the perimeter detects and blocks known exploitation signatures. The network segmentation (Zone 1 → Zone 2 boundary) limits lateral movement after initial DMZ compromise.
SIEM detection: IDS/IPS Critical alerts on the perimeter sensor; anomalous HTTP response codes from DMZ systems (5xx errors at volume may indicate exploitation attempts); POST requests to non-standard paths on web applications.
T1133 — External Remote Services (VPN, Citrix, etc.): Attackers who have obtained valid credentials may attempt to authenticate to the VPN gateway or other remote access service. The preventive control is MFA enforcement (certificate + Entra ID + MFA cannot be bypassed with credentials alone). The detective control is VPN authentication anomaly monitoring.
SIEM detection: VPN authentication from an IP in a country where the user has never authenticated; VPN authentication at a time inconsistent with the user's 90-day pattern; VPN authentication failure spike on a specific account; simultaneous VPN sessions from geographically impossible locations.
T1071 — Application Layer Protocol (C2 via HTTP/HTTPS/DNS): Malware that has established a foothold communicates with command-and-control infrastructure using common application protocols that appear legitimate to basic firewall rules. The perimeter IDS/IPS uses threat intelligence to identify known C2 infrastructure. Egress filtering via the web proxy prevents direct outbound connections from endpoints to arbitrary internet destinations (all outbound must route via proxy). DNS filtering blocks resolution of known malicious domains.
SIEM detection: DNS queries to domains with high entropy names (DGA); DNS query volume anomalies for a specific endpoint; HTTPS traffic to IP addresses without associated domain names (direct-IP C2); periodic beaconing pattern (regular outbound connections at fixed intervals) from an endpoint.
T1046 — Network Service Discovery: An attacker who has a foothold on one system scans the internal network to discover other hosts and services. Internal segmentation means that lateral movement from a compromised Zone 2 workstation to Zone 3 CUI servers requires crossing a firewall boundary — the attacker cannot freely scan the CUI segment from a general workstation. The SIEM detects port scan patterns within the network.
SIEM detection: a single source IP generating connection attempts to more than 20 distinct destination IPs within 5 minutes (internal network scan signature); SYN packets to closed ports at volume; ARP requests from a non-gateway device at high volume.
T1048 — Exfiltration Over Alternative Protocol: Data exfiltration using protocols other than HTTP/HTTPS — DNS tunnelling, ICMP tunnelling, raw TCP on unusual ports. The boundary firewall denies all protocols not explicitly permitted. Workstations cannot make direct outbound connections on non-HTTP ports (must go via proxy). DNS queries are logged and analysed for tunnelling indicators (high-entropy queries, unusually long hostnames, unusually high query volume from a single host).
SIEM detection: DNS query length anomaly (queries with subdomains longer than 50 characters); DNS query volume from a single endpoint exceeding [threshold]/minute; outbound traffic on non-standard ports from workstations (should be blocked — any successful connection is a firewall misconfiguration finding); large outbound data transfers to destinations not on the approved external connection register.
Control effectiveness assessment — quarterly
Complete each quarter as part of the internal assessment programme (AT-CA 3.12.1).
| Control | Test | Last tested | Result | Trend | Notes |
|---|---|---|---|---|---|
| Boundary firewall default deny rule active and logging | Attempt connection to internal IP from internet (use external test machine or mobile) | [date] | Pass / Fail | ↑↓→ | |
| All inbound rules have documented business justification | EV-F03 — count of undocumented rules | [date] | [N undocumented] | ↑↓→ | Target: 0 |
| No inbound "any to any" permit rules | EV-F03 — filter for overly permissive rules | [date] | Pass / Fail | ↑↓→ | |
| DMZ is logically separated from internal (SC.L1-3.13.5) | Attempt to connect from DMZ test host to Zone 2 IP | [date] | Pass / Fail | ↑↓→ | |
| Zone 3 not directly reachable from Zone 2 | Attempt to ping Zone 3 server from Zone 2 workstation | [date] | Pass / Fail | ↑↓→ | |
| VPN requires MFA to connect | Attempt VPN connection without MFA (e.g. cert only) | [date] | Pass / Fail | ↑↓→ | |
| Split tunnelling disabled on VPN | Connect VPN; run curl ipinfo.io/ip; confirm corporate IP | [date] | Pass / Fail | ↑↓→ | |
| Host firewall active on all CUI-scope Windows devices | GPO query — DefaultInboundAction: Block on all profiles | [date] | [X% compliant] | ↑↓→ | Target: 100% |
| Host firewall active on all CUI-scope macOS devices | MDM smart group — non-compliant count | [date] | [N non-compliant] | ↑↓→ | Target: 0 |
| IDS/IPS in active prevention mode on perimeter | Vendor dashboard — prevention mode confirmed | [date] | Pass / Fail | ↑↓→ | |
| Firewall admin access not possible from internet | Port scan perimeter from external: confirm mgmt ports closed | [date] | Pass / Fail | ↑↓→ | |
| All firewall config changes have RFC reference | EV-F03 change log cross-reference | [date] | Pass / Fail | ↑↓→ |
Assessor preparation — C3PAO, Cyber Essentials+, and DEFSTAN
C3PAO examination (CMMC Level 1)
SC.L1-3.13.1 — what to prepare:
Documents to prepare:
[ ] Network topology diagram showing all zones, firewall positions,
and data flows — current version, within past 12 months
[ ] Firewall rule register (EV-D19) — complete, all rules with documented purpose
[ ] Last 3 months of EV-F03 (monthly firewall rule reviews)
[ ] Last 3 months of EV-F04 (IDS/IPS alert reviews)
[ ] RFC history for any firewall changes in past 12 months (EV-D21)
Demonstration to prepare:
[ ] Show firewall management console — confirm default deny is last rule and logging
[ ] Show a specific deny log entry in SIEM — confirm all boundary deny events
are being captured
[ ] Show VLAN configuration on a core switch — confirm Zone 2 and Zone 3
are in different VLANs with no direct routing
[ ] Demonstrate that a Zone 2 workstation cannot reach Zone 3 servers directly
Interview talking points for IT Manager:
"Walk me through how traffic from the internet reaches your internal systems."
→ Internet → Zone 0 → perimeter firewall → only specific rules to Zone 1 DMZ →
second firewall boundary to Zone 2 → Zone 3 CUI servers require separate auth
"What happens to connection attempts that don't match any permit rule?"
→ Dropped by default deny, logged to SIEM, SIEM alert if volume anomalous
Common pre-assessment finding to resolve:
The most common SC.L1-3.13.1 finding is rules in the firewall rule base
that were created for a temporary purpose and never removed.
Run EV-F03 procedure before assessment day and remove any stale rules via RFC.
SC.L1-3.13.5 — what to prepare:
Documents to prepare:
[ ] Network topology diagram explicitly showing DMZ separation
[ ] Firewall rules between DMZ (Zone 1) and internal network (Zone 2/3)
[ ] Evidence that publicly accessible systems are in the DMZ,
not on the internal network
Demonstration:
[ ] From DMZ server (or simulated external position),
attempt connection to internal Zone 2 host
[ ] Expected: connection blocked by firewall
[ ] Show the deny log entry in SIEM
Common finding to prevent:
If any publicly accessible service is running on a host in Zone 2
(internal network) rather than Zone 1 (DMZ), this is a 3.13.5 finding.
Audit all systems that are accessible from the internet and verify
each is in the DMZ, not behind only one firewall boundary.
AC.L1-3.1.20 — what to prepare:
Documents to prepare:
[ ] External connection register (in EV-D19) — complete, all connections
[ ] VPN configuration documentation — authentication method, encryption
[ ] Cloud service inventory — all cloud services accessed from the network
Demonstration:
[ ] Show external connection register — each entry has auth method documented
[ ] Show VPN authentication log — confirm cert + MFA for recent connections
[ ] For a connection in the register, show the corresponding firewall rule
and confirm the rule matches the documented connection
Most common finding for this practice:
Cloud services or SaaS applications in use that are not on the
external connection register. Audit cloud app usage (e.g. via CASB
or proxy logs) before assessment and add any discovered services to the
register or block them if they should not be used.
Cyber Essentials+ technical verification
The CE+ technical assessor will conduct live technical verification.
Prepare for the following specific tests:
Test 1 — Boundary firewall inbound check:
Assessor will perform an external port scan of your public IP ranges
Preparation: run an external port scan yourself first (from a cloud VM):
nmap -sV -Pn -p 1-65535 [your-public-IP-range]
Expected result: only the specific services you have documented
as intentionally accessible should appear open
Example: 443 (HTTPS), 25 (SMTP MTA), 1194 or 443 (VPN)
Any unexpected open port = finding
Common unexpected open ports:
22 (SSH management interface visible from internet — should be blocked)
3389 (RDP accessible from internet — should never be open)
8080/8443 (alternative HTTP ports — should not be open if not in service)
23 (Telnet — should be closed on all modern devices)
161 (SNMP — management protocol should never be internet-accessible)
Action before assessment: run the nmap scan; resolve all unexpected open ports
via RFC before the assessment date
Test 2 — Personal firewall verification:
Assessor will log into a sample of devices and verify:
Windows: Get-NetFirewallProfile | Select Name, Enabled, DefaultInboundAction
macOS: /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Preparation: run this verification yourself across all CUI-scope device types
Any device with firewall disabled = CE finding for that device scope
Test 3 — Administrative interface not internet-accessible:
Assessor will attempt to access firewall/router/switch management
interface from an external IP
Expected: connection refused or no response (stealth mode)
Preparation: verify from external IP that no management interface responds
curl -k https://[firewall-mgmt-IP]:443 from external vantage point
Expected: connection refused or timeout — not a login page
Test 4 — Default deny verification:
Assessor will attempt a connection to a port that is not in your
permitted inbound service list from an external IP
Expected: connection refused / timeout (not RST which reveals the port
is closed but reachable)
Stealth mode on firewalls: drops the packet silently rather than
responding with RST — this is better than RST because it reveals less
information to the attacker about the network structure
DEFSTAN assessment preparation
DEFSTAN Profile 0 boundary examination focuses on:
1. Documented boundary with OFFICIAL systems
Prepare: network topology diagram showing boundary between OFFICIAL systems
and other network zones
Show: the boundary is technically enforced (firewall rules, VLAN separation)
Assessor question: "Where does OFFICIAL information stop and the
internet begin in your network architecture?"
2. Firewall rule justification (the DEFSTAN documentation requirement)
Prepare: EV-D19 firewall rule register with all rules documented
Show: the assessor will select 3–5 rules at random and ask:
"Why does this rule exist?"
"What would happen if this rule did not exist?"
"When was this rule last reviewed?"
If any rule cannot be answered: it should be removed before assessment
This is both a DEFSTAN requirement and a security best practice
3. Remote access to OFFICIAL systems is encrypted
Prepare: VPN cipher suite documentation (from OP-01 or AT-SC-BDY)
Show: VPN connection log confirming encryption in use
Assessor may ask: "What encryption does your VPN use?"
Answer: IKEv2 with AES-256 encryption; certificate-based device auth + MFA
4. No uncontrolled external connections
Prepare: external connection register (EV-D19)
Show: every external connection is documented, authorised, and controlled
Assessor will ask about any connection to MOD or prime contractor systems:
"Do you have a direct network connection to [contracting authority]?"
If yes: show the connection in the register with its encryption and auth
"How do you control what leaves your network towards the MOD?"
Answer: egress firewall + web proxy + DLP monitoring
5. Boundary review is performed at defined intervals
Prepare: last 3 months of EV-F03 (monthly firewall review)
Show: reviews are being conducted; findings are being resolved
A regular review with zero findings every month is suspicious —
confirm the review is genuine and thorough, not a checkbox exercise
POA&M templates — most likely deficiencies for this control family
Template: Undocumented or stale firewall rules
POA&M item: PM-[YYYY]-[NNN]
Controls: SC.L1-3.13.1 · CE Firewalls · DEFSTAN Profile 0 §Boundary
Weakness: [N] firewall rules identified during the [month] rule review
that have no documented business justification (description field empty
or contains placeholder text). Additionally, [N] rules have had zero
traffic hits for the past 90+ days, indicating they may be stale.
Discovery source: EV-F03 monthly firewall rule review [YYYY-MM]
Risk during deficiency: Moderate — undocumented rules may permit traffic
that is not required for business purposes,
increasing attack surface beyond what is necessary
Compensating controls: All undocumented rules have been tagged
"UNDOCUMENTED-REVIEW-[date]" in the rule name;
rules are under investigation before potential removal
Corrective action: (1) Review each undocumented rule with the IT Manager
and any known rule owners
(2) Document the business justification for any rule
that is still required
(3) Remove via RFC any rule with no valid justification
or no traffic in 90+ days
(4) Implement a rule naming policy that prevents future
rules from being created without a description field
Owner: IT Manager
Target completion: [30 days from identification]
CISO approval: IT Manager sufficient for Moderate risk
Template: Host-based firewall disabled on enrolled device
POA&M item: PM-[YYYY]-[NNN]
Controls: SC.L1-3.13.1 · CE Firewalls Requirement (host firewall)
Weakness: [N] CUI-scope [Windows / macOS] devices identified in the
[quarter] configuration audit (EV-D20) as having the host-based
firewall disabled or not in Block-inbound mode. Affected devices:
[list hostnames].
Discovery source: EV-D20 quarterly configuration audit / MDM non-compliance report
Risk during deficiency: High — devices without a host-based firewall
have no boundary protection when operating
on untrusted networks (remote working, travel)
Compensating controls: Affected devices are restricted to the corporate
network by Conditional Access (compliant device required)
until the firewall is re-enabled
Corrective action: (1) IT Operations to verify the GPO/MDM profile
is being applied to the affected devices
(2) Force policy refresh on affected devices:
gpupdate /force (Windows) / MDM check-in (macOS)
(3) If policy is being applied but firewall is still
disabled, investigate local override mechanism
and remediate
(4) Re-run EV-D20 spot check to confirm resolution
Owner: IT Operations
Target completion: [7 days from identification — High risk]
CISO approval: required — High risk
Template: Split tunnelling enabled on VPN
POA&M item: PM-[YYYY]-[NNN]
Controls: SC.L1-3.13.1 · AC.L1-3.1.20 · DEFSTAN Profile 0 §Boundary
Weakness: VPN client configuration identified as permitting split tunnelling —
internet traffic from VPN-connected devices is routing directly to
the internet rather than through the corporate perimeter firewall.
This bypasses web filtering, egress IDS/IPS, DLP, and URL filtering
for internet-destined traffic from remote workers.
Discovery source: [describe how discovered — VPN configuration review /
traffic analysis / staff report]
Risk during deficiency: High — internet-bound traffic from remote workers
is outside the corporate security boundary.
Malware C2 traffic, data exfiltration, and
access to malicious sites is not inspected
at the corporate boundary for affected sessions.
Compensating controls: Endpoint EDR (at-device) provides some protection
for internet traffic not routed via corporate boundary;
MFA requirement for all cloud services provides
credential protection even without VPN inspection
Corrective action: (1) Modify VPN client configuration to disable split
tunnelling (set all traffic to route via VPN tunnel)
(2) Test with affected client profiles — confirm all
internet traffic now routes via corporate IP
(verify: curl https://ipinfo.io/ip from VPN-connected
device → must return corporate egress IP)
(3) Deploy updated configuration via MDM/VPN management console
(4) Verify by querying VPN gateway route configuration
Owner: IT Manager
Target completion: [14 days from identification — implement in maintenance window]
CISO approval: required — High risk
Note: This change may affect performance for remote workers.
Communicate change to staff before implementation.
Template: Management interface accessible from internet
POA&M item: PM-[YYYY]-[NNN]
Controls: SC.L1-3.13.1 · CE Firewalls · DEFSTAN Profile 0 §Boundary
Weakness: The [firewall / switch / hypervisor / router] management interface
([protocol: HTTPS/SSH/Telnet] on [port]) is accessible from
internet-facing IP addresses. External port scan on [date]
confirmed [protocol/port] responds from external source IPs.
Discovery source: [pre-assessment port scan / Cyber Essentials technical review /
security analyst finding]
Risk during deficiency: Critical — management interface exposed to internet
enables direct brute-force attacks against
administrative credentials; exploitation of
management interface vulnerabilities by
unauthenticated attackers; potential full
compromise of boundary device
Compensating controls: MFA required for management access (mitigates
credential brute-force risk while perimeter rule
is being remediated); recent management interface
firmware is current (reduces CVE exposure)
Corrective action: (1) Immediately add a deny rule ahead of the current
permit rule blocking all external source IPs from
reaching the management port (emergency change —
verbal CISO approval obtained [time/date])
(2) Confirm management interface is only reachable
from Zone 4 management VLAN after remediation
(3) Review all other management ports for similar exposure
(4) File formal RFC within 24 hours per emergency change procedure
Owner: IT Manager
Target completion: Immediate (within 2 hours of identification)
CISO approval: obtained verbally — formal documentation within 24 hours
Cross-family evidence dependencies — this control family
AT-IA (Identification and Authentication): VPN authentication (AC.L1-3.1.20) depends on MFA being correctly configured (IA.L1-3.5.2). The VPN's certificate + Entra ID MFA enforcement is part of the MFA coverage measured in EV-D05. If EV-D05 shows MFA gaps, VPN authentication may be weaker than documented. Ensure MFA coverage reports include VPN authentication events.
AT-AU (Audit and Accountability): Firewall logging is upstream of the SIEM log review (EV-F01). If the firewall is not correctly logging and forwarding to SIEM (as verified in EV-F06 SIEM health), the monthly boundary activity review in EV-F01 is incomplete. The boundary review section of EV-F01 depends on EV-F06 confirming the firewall log source is active and healthy.
AT-SI (System and Information Integrity): IDS/IPS alert review (EV-F04) is shared between this control family (boundary monitoring) and AT-SI (detecting malware and exploitation attempts). EV-F04 must be produced monthly regardless of which assessment is in scope — it satisfies both the SC.L1-3.13.1 monitoring requirement and AT-SI 3.14.6 monitoring for security alerts.
AT-CM (Configuration Management): Firewall rule changes go through the change management process (AT-CM 3.4.3). EV-D21 (change management records) is the evidence that firewall changes were reviewed and approved. If EV-D21 has gaps — changes made without RFCs — the firewall rule register in EV-D19 cannot be trusted because we cannot confirm that all rules in the current register were authorised. EV-D21 completeness is a prerequisite for EV-D19 credibility.
AT-RA (Risk Assessment): The zone model and boundary protection decisions are informed by the risk assessment (AT-RA 3.11.1). The risk register should contain a risk entry for boundary compromise — the boundary controls documented on this page are the treatment for that risk. If the risk register does not reference boundary threats, the risk assessment may not have adequately considered the threat landscape for an organisation handling CUI.
{scroll-content}
Page footer
All-staff visible — outside all SCM variant wrappers.
Where to go next
| If you are... | Go to... |
|---|---|
| An all-staff user with a VPN question | 04 · User Guidance Hub → Working From Home |
| An all-staff user who received a firewall prompt on their device | Contact IT Operations helpdesk — [helpdesk URL] |
| An IT Operations engineer implementing the full SC boundary control set | 03 · Advanced Controls → AT-SC · System and Communications Protection → AT-SC-BDY |
| An IT Operations engineer managing the network baseline document | AT-CM → BL-NET · Network Device Baseline |
| A security team member preparing the monthly boundary monitoring | OP-03 · Logging and SIEM Management (EV-F03 and EV-F04 procedures) |
| A security team member preparing for any CMMC, CE, or DEFSTAN assessment | AT-CA · Security Assessment → Section 8 + this page security layer above |
| A security team member conducting a pre-assessment external port scan | Use a cloud VM in a geographically appropriate region; nmap -sV -Pn |
Version and review
| Version | Date | Change summary | Author | Approver |
|---|---|---|---|---|
| 1.0 | [DATE] | Initial publication | [NAME] | [CISO NAME] |
Page owner: IT Manager · Review: Annual · Questions: [helpdesk URL] or [ciso@organisation.com]