CIS Control 13 Network Monitoring and Defense Guide: Safeguards, Implementation Groups and Evidence

Many organisations buy a SIEM, an IDS and an EDR platform and still cannot show which network boundaries are watched, which assets send logs, or when an alert threshold was last tuned. CIS Control 13 (Network Monitoring and Defense) in CIS Controls v8.1 asks organisations to operate processes and tooling that establish and maintain comprehensive network monitoring and defence against security threats across their network infrastructure and user base. This guide explains its eleven Safeguards by Implementation Group, what each requires, how to implement them in a sensible order with testing and rollback, and the evidence an assessor working from the CIS Controls Assessment Specification will expect. It is written for SOC leads, detection engineers, network security teams and GRC staff. For the framework as a whole, see the CIS Controls Guide; for the technology itself, see the NDR Guide and the SIEM Guide.

Key takeaways

• There is no IG1 Safeguard in Control 13. Safeguards 13.1 to 13.6 are IG2 and 13.7 to 13.11 are IG3. Small organisations meet the logging basics through Control 8 instead.
• Coverage is measured per asset and per boundary. The assessment specification counts assets whose logs are centralised, network boundaries covered by intrusion detection, and boundary devices with flow logging enabled. A tool that exists but covers half the estate scores half.
• A SIEM is best practice, not the only option. Safeguard 13.1 is met by a SIEM with vendor-defined correlation alerts or a log analytics platform configured with security-relevant correlation alerts; without either, the Safeguard fails outright.
• Tuning has a 30-day clock. Safeguard 13.11 (IG3) requires alert thresholds to be tuned monthly or more often, and the specification fails it if the last tuning is more than 30 days old.
• Monitoring must see machine identities. Service accounts, VPN bind accounts and API tokens generate most of the traffic on modern networks; detections that only model human behaviour miss the credential abuse that edge device compromises produce.

What it is and who it applies to

Control 13 turns the architecture built under Control 12 into something that is watched and defended. It combines detection (centralised alerting, host and network intrusion detection, flow logs), prevention (host and network intrusion prevention, filtering between segments, application layer filtering, port-level access control) and access decisions for remote devices. It depends on Control 8 for log collection and on Safeguard 12.4 diagrams for knowing where the boundaries are. See the CIS Control 8 Audit Log Management Guide and the CIS Control 12 Network Infrastructure Management Guide.

• IG1: no Control 13 Safeguards. IG1 organisations should still meet Control 8 logging and Control 10 anti-malware.
• IG2: centralised alerting, host and network intrusion detection, filtering between segments, posture-based access for remote assets and flow logs (13.1 to 13.6). This is where an organisation needs either an internal SOC function or a managed detection provider.
• IG3: host and network intrusion prevention, port-level access control, application layer filtering and monthly tuning (13.7 to 13.11).

CIS v8.1 (June 2024) clarified wording, revised asset classes, added a Governance function and realigned to NIST CSF 2.0, but changed no Implementation Group assignments. Titles and IGs below are identical in v8 and v8.1; the asset type and function column shows the v8 values from the CIS Controls Assessment Specification.

Structure and key requirements

Reading the Safeguards carefully

• 13.1 counts log sources, not licences: the specification enumerates assets that produce security event logs and checks whether each one's logs reach the correlation tool. Network devices, cloud control planes, identity providers and VPN gateways are frequently missing. See the Log Management and Retention Guide.
• 13.3 and 13.6 are scoped to boundaries: both are measured against network boundaries or boundary assets taken from the architecture documentation. Internet egress, data centre to cloud links, partner connections and the boundary between user and server segments all count. See the IDS and IPS Guide.
• 13.5 is a posture check: remote access is granted according to anti-malware status, configuration compliance and patch level, which in practice means a device trust or posture policy at the VPN, ZTNA broker or identity provider. It depends on Safeguard 6.6, the inventory of authentication and authorisation systems.
• 13.7 accepts EDR: the Safeguard names an EDR client as an example of host-based prevention, so a well deployed EDR in block mode usually covers 13.2 and 13.7 together. See the EDR Guide.
• 13.9 allows certificates: 802.1X is the usual answer, but CIS accepts similar controls, such as certificates, and device or user authentication. See the Network Access Control (NAC) Guide.

Tooling options by Safeguard

For open source sensors, see the Suricata IDS Guide and the Zeek Network Monitoring Guide.

Identity and NHI requirements

Network monitoring is where identity misuse becomes visible, and much of that misuse involves non-human identities. Build the following into Control 13 detections:

• Service account behaviour baselines (13.1, 13.11): a service account normally connects from a few hosts to a few destinations. Alert on new source hosts, interactive logons, new protocols or connections outside its baseline. Valid account abuse (ATT&CK T1078) is the technique these detections target. See the Service Account Security Guide.
• Edge device credentials (13.1, 13.6): VPN gateways store directory bind accounts, certificates and API keys. Monitor where those credentials are used from; use anywhere other than the appliance is a strong signal of compromise.
• Network device authentication (13.1): forward AAA accounting, local logins, new local accounts and changes to TACACS+ or RADIUS server addresses; attackers modify device authentication to persist (T1556.004 Network Device Authentication).
• Device identity for 13.5 and 13.9: posture and port-level control rely on device certificates and managed device identities, which need their own lifecycle. See the Machine Identity, PKI and Certificate Lifecycle Guide.
• API and workload traffic (13.6, 13.10): east-west traffic between workloads and calls to SaaS APIs carry tokens; flow logs and proxy logs are often the only record of which workload talked to which API.

Implementation steps

1. Define boundaries and log sources (weeks 1 to 3): from the Safeguard 12.4 diagrams, list every network boundary and boundary device; from the Control 1 inventory, list every asset type that produces security event logs. These two lists are the denominators for 13.1, 13.3 and 13.6.
2. Centralise alerting (13.1, weeks 2 to 10): onboard identity provider, VPN, firewall, EDR, cloud control plane, DNS and network device logs first, then servers and applications. Encrypt log transport and keep copies off the source device, because appliances can be compromised along with their local logs. Enable vendor correlation content and confirm each source is parsing correctly before relying on it.
3. Collect flow logs at boundaries (13.6, weeks 4 to 8): enable NetFlow or IPFIX on internet edge, data centre and inter-site devices and VPC or VNet flow logs in cloud. Start with key boundaries to size storage, then expand.
4. Deploy host detection and prevention (13.2, 13.7): roll out EDR in detect mode to a pilot ring, tune exclusions, then switch to block mode ring by ring. Keep a documented rollback (policy back to detect mode) for each ring. See the EDR Tuning and Exclusions Management Guide.
5. Deploy network detection, then prevention (13.3, 13.8): place sensors at each boundary, run in IDS mode for at least two to four weeks, review false positives, then enable IPS blocking for high-confidence rule categories only. Fail-open behaviour and bypass procedures are the rollback.
6. Filter between segments (13.4): apply default-deny rules between segments with logging of denied traffic, using the 12.2 architecture to define permitted flows. Test new rules in log-only mode first. See the Firewall Rule Review Checklist.
7. Posture-based remote access (13.5): require compliant device state at the VPN, ZTNA broker or identity provider. Start in report-only mode, fix non-compliant devices, then enforce with a grace period. See the Secure Remote Access Beyond VPN Guide.
8. Port-level control and application filtering (13.9, 13.10, IG3): deploy 802.1X in monitor mode, then low-impact mode, then closed mode, with MAC authentication bypass only for documented devices that cannot authenticate. Route web traffic through a filtering proxy or secure web gateway.
9. Establish monthly tuning (13.11): a recorded monthly review of noisy rules, suppressed alerts, missed detections from incidents and new threat intelligence, with each change tracked in version control.

Small versus large organisations

• Smaller IG2 organisations: a managed detection and response service often covers 13.1, 13.2, 13.3 and 13.7 more realistically than an internal SOC. Make sure the contract states which log sources and boundaries are in scope, so you can produce the coverage counts.
• Large organisations: the challenge is coverage gaps across business units and clouds, and cost. Use a tiered log strategy (full fidelity for security-relevant sources, summarised flow elsewhere) and measure coverage per boundary, not per tool.

Evidence and assessment

Metrics that show it is working

• Log source coverage: percentage of log-producing assets sending to the SIEM, broken down by asset class.
• Boundary coverage: percentage of network boundaries with both intrusion detection and flow logging.
• Silent source detection: number of log sources that stopped sending for more than 24 hours, and time to restore.
• Alert quality: true positive rate per rule and percentage of alerts closed as benign after tuning.
• Detection coverage: number of prioritised ATT&CK techniques, such as T1021 Remote Services, T1046 Network Service Discovery, T1048 Exfiltration Over Alternative Protocol and T1572 Protocol Tunneling, with a tested detection.

Mapping to other frameworks

Use the official CIS v8.1 mappings for formal crosswalks; this table is a working guide. For capture and forensic use of network data, see the Network Monitoring and Packet Capture Guide.

Common pitfalls

• Trusting the appliance to report on itself: in the Ivanti Connect Secure exploitation, the vendor's integrity checker missed compromised gateways and credentials stored on them had to be treated as stolen. Off-box logging, flow data at the boundary and monitoring of where gateway credentials are used are what 13.1 and 13.6 add.
• No visibility into network devices: in the Salt Typhoon telecom intrusions, attackers changed AAA servers, created local accounts, altered ACLs and stayed for years; none of those changes is hard to alert on once device logs reach the SIEM.
• Sensors at the internet edge only: 13.3 counts every boundary. Lateral movement between user and server segments, or between cloud accounts, goes unseen if only the perimeter is watched.
• IPS left in detect mode indefinitely: 13.8 asks for prevention. A pilot that never moves to blocking does not meet IG3.
• Tuning by deletion: noisy rules get disabled rather than tuned, and nobody records why. 13.11 expects a recorded monthly review, and disabled rules should be listed and justified.
• Dropping sources to save cost: DNS, flow and identity logs are the first cut and the first needed in an investigation. Decide retention by security value. See the DNS Security Guide.

Practitioner checklist

• Confirm your Implementation Group; Control 13 starts at IG2.
• Build the boundary list from current 12.4 diagrams and the log source list from the asset inventory.
• Report the percentage of log-producing assets sending to the SIEM or log analytics platform, with correlation alerts enabled (13.1).
• Cover every boundary with network intrusion detection and flow logging (13.3, 13.6).
• Deploy EDR or HIDS to all capable assets, moving to prevention mode for IG3 (13.2, 13.7).
• Enforce default-deny filtering between segments and log denied traffic (13.4).
• Gate remote access on device posture: anti-malware, configuration compliance and patch level (13.5).
• Baseline and alert on service account, VPN bind account and network device authentication behaviour.
• For IG3, deploy 802.1X or certificate-based port control and application layer filtering (13.9, 13.10).
• Record alert threshold tuning at least monthly (13.11).

Standards and references

• CIS: Control 13 Network Monitoring and Defense
• CIS: Controls Assessment Specification, Control 13
• CIS: CIS Controls Implementation Groups
• CIS: The Ongoing Evolution of the CIS Critical Security Controls
• CISA: Enhanced Visibility and Hardening Guidance for Communications Infrastructure
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Valid Accounts

Related NHI Mgmt Group resources: CIS Controls Guide · CIS Control 12 Network Infrastructure Management Guide · NDR Guide · SIEM Guide · IDS and IPS Guide