Safeguard 13.4 traffic filtering: requirements and evidence

What Safeguard 13.4 traffic filtering asks for and why it is hard

Safeguard 13.4 asks for traffic filtering between network segments where appropriate. It is the enforcement side of the segmentation design that Safeguard 12.2 calls for. An IG2 enterprise often has a segmentation diagram that shows production, corporate, guest, management and cloud zones, yet the question an assessor asks is whether the firewalls, access control lists and cloud security groups between those zones actually block what the design says they block. In CIS Controls v8.1, 13.4 is assigned to the Network asset class and the Protect security function, and it applies to IG2 and IG3 enterprises but not to IG1. The reason it matters is lateral movement: once an attacker holds one foothold, flat or loosely filtered segments let that access reach databases, domain controllers and backup systems without passing any control point.

The requirement is hard for three reasons. The first is segment count, since every additional zone multiplies the number of paths that need a deliberate allow or deny decision. The second is rule drift, where firewall rules added for a migration or an urgent fix are never removed and quietly widen access over time. The third is undocumented exceptions, where a vendor, a backup job or a legacy application needs a path that nobody records. Your first decision is to inventory every inter-segment path, including cloud routing and VPN tunnels, and to decide which ones are approved and why. Your first check is to compare the live rule sets against that inventory, because the assessment specification scores 13.4 with a Coverage metric, the share of network segments properly configured to filter traffic between segments. Confirm with your assessor exactly how they will sample segments and what counts as properly configured in your environment.

Which segments, rules and teams fall under 13.4

Safeguard 13.4 is only as large as the segment map behind it. The decisions below determine how many boundaries need filtering, who writes and approves the rules, and which outside connections must be governed. The CIS Controls Assessment Specification lists no prerequisite safeguards for measuring 13.4, so the segment inventory and rule ownership are the starting point you must establish yourself.

Inventory every segment first

Start with a list of network segments: production, management, user, guest, OT, cardholder data environment, and cloud VPCs or subnets. Each segment is a unit the Coverage metric counts, so an undocumented subnet is a gap an assessor will find. Ask for the current diagram and confirm it matches live routing and cloud network configuration, since diagrams often lag behind changes.

Choose which boundaries need filtering

Not every adjacency needs a rule set. Boundaries that cross trust levels, such as user to production, guest to internal, or IT to OT, usually need explicit filtering, while traffic inside one trust zone may not. Record the decision and the reason for each boundary, because the 'where appropriate' wording in 13.4 leaves that judgment to you and an assessor will ask for the rationale.

Assign firewall and security group owners

Firewalls, cloud security groups and network access lists are often managed by different teams, and a boundary with no named owner tends to drift. Name one accountable owner per boundary and one owner per platform, and separate who requests a rule change from who approves it. Confirm that cloud security groups in each account are included in the count, not only on-premises appliances.

Bring third-party connections into scope

Vendor VPN tunnels, managed service access, payment processor links and partner APIs cross segment boundaries and carry traffic that your internal rules do not describe. List each connection, the segments it reaches, and the rules that govern it. Ask each provider to confirm the ports and destinations it needs, so rules are narrowed to those and not left open for convenience.

Set the rule review cadence

Rule sets accumulate exceptions, and temporary allowances often outlive their purpose. Decide how often each boundary's rules are reviewed, who signs off, and how expired exceptions are removed. Keep the review record, because it is the evidence that a segment is still properly configured at the time of assessment, not only when it was first built.

How an assessor measures segment filtering coverage

This table walks through how an assessor tests Safeguard 13.4 against the Coverage metric, from building the segment list to checking rule sets and logs. Use it to prepare the segment inventory, rule exports and logging evidence before an assessment starts, and to see where findings usually come from.

Assessment step	What the assessor does	What the organization should have ready
Build the segment list	Derives the set of network segments from the architecture documentation and network diagrams, then compares it with live configuration to find segments that exist but are not documented.	Current diagrams, a segment register with owners and purpose, and a reconciliation of diagrams against device configuration exports.
Define the Coverage denominator	Counts every segment in scope as the denominator of the Coverage metric, so an undocumented segment lowers the score the same way a misconfigured one does.	A written rule for what counts as a segment, such as a VLAN, subnet, VPC, zone or security group, applied consistently across environments.
Sample segment boundaries	Selects boundary points (firewalls, routers, cloud security groups, host-level filters at segment edges) and tests whether each one filters traffic between segments.	A list of boundary devices per segment, with management access to read configuration and the ability to export it for the sampled set.
Review rule sets for default deny	Checks whether the last rule on each boundary drops or rejects unmatched traffic, and whether the boundary has an explicit deny rather than relying on the platform default.	Exported rule sets with the default action visible, and a written statement of the intended default policy for each boundary class.
Review for overly broad allows	Looks for any-to-any rules, wide port ranges, broad source networks and rules that permit whole segments into sensitive zones without a stated business reason.	A rule register linking each allow to a business purpose, owner and review date, plus any compensating controls for broad rules.
Check rule ownership and change control	Confirms that rules trace to approved change records and that the rule set has not drifted from the approved design since the last review.	Change tickets for recent rule changes, version history of firewall or cloud policy, and a periodic rule review record.
Check logging of blocked and allowed traffic	Verifies that boundary devices log denied traffic and significant allows, and that those logs reach a place where someone reviews them.	Sample log exports from each boundary, log forwarding configuration, retention settings and evidence of review or alerting.
Score the Coverage result	Calculates the share of segments with properly configured filtering and records each failed segment with its reason, which becomes the basis for findings.	A segment-by-segment status table kept current, so the organization can see its own score before the assessor does.
Common findings	Typical gaps include undocumented segments, boundaries that default to allow, any-to-any rules left from testing, and logs that are written but never reviewed.	Confirm each of these with the assessor's own methodology and your environment, and remediate before the assessment window opens.

Implementing segment filtering in six steps

This sequence turns the segment architecture from Safeguard 12.2 into enforced, logged and reviewed filtering rules, with a named artifact at each stage so an assessor can trace the design to the live configuration.

Confirm the segment inventory from 12.2
Start from the network architecture documented under Safeguard 12.2 and confirm every segment, its purpose, the assets it holds and the boundaries between segments. The network team and the asset owners review the list together, because a segment that exists on paper but has no owner usually ends up with no rules. The output is a segment inventory with each boundary identified. You know this step is done when every boundary has a named owner and no asset sits outside a documented segment.
Define allowed flows per boundary
For each boundary, record which sources, destinations, ports and protocols are required for business or operational reasons, and who approved each flow. Flows that cannot be justified are excluded. The output is a flow matrix that lists every permitted path between segments, with the business reason and approver for each entry. Security and application owners sign off on the matrix before any rule is written, so the rule set reflects documented need rather than whatever was already configured.
Write default-deny rules
Build the filtering policy so that traffic crossing a boundary is blocked unless a rule from the flow matrix permits it. Express the rules by source, destination, port and protocol, and use address aliases for groups of hosts where that keeps the rule set readable. Place the final block rule at the bottom of each boundary policy. The output is a rule-set export per firewall or filtering device, kept under version control with a change record for each rule. The step is done when every rule traces back to a matrix entry.
Deploy and validate enforcement
Apply the rule sets through a controlled change, then test from each side of each boundary. Confirm that permitted flows work, that unlisted flows are blocked, and that the device is the component enforcing the decision rather than a host-level setting that could be bypassed. Record the test results against the flow matrix. The output is a validation record showing expected and observed behavior for each boundary. Any mismatch returns to the matrix or the rule set before the change is closed.
Log and review rule matches
Enable logging for denied traffic and for the permitted flows that cross sensitive boundaries, and forward those logs to the central alerting or log analysis platform used for Safeguards 8.2 and 13.1. Review denied events for patterns that suggest misconfiguration, unauthorized movement or an attack. The output is a log review record that shows who reviewed which boundaries, when, and what action followed. Confirm with the team that owns the central platform how log retention and access are set, since those settings affect what an assessor can later inspect.
Set a recurring review of coverage
Schedule periodic checks that every segment boundary still has a filtering policy, that the flow matrix matches the live rule sets, and that stale or overly broad rules are removed. Each change to the architecture, such as a new segment or a retired application, triggers an update to the matrix and rules. The output is a coverage report that counts segments with properly configured filtering against the total segments, which is the measure the CIS assessment specification uses for this Safeguard. The review cadence should be set by the organization and documented in its own policy.

Open-source tools that enforce and evidence segment filtering

Safeguard 13.4 is enforced by filtering devices at the boundaries between network segments, and assessed by showing that each segment's filtering is configured and logged. The tools below cover two different layers: a packet filter for segment boundaries and a web application firewall for application traffic. Choosing between them depends on where the boundary sits and what traffic crosses it.

OPNsense as a segment packet filter

OPNsense is a stateful packet filter under the BSD-2-Clause license. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases let you group addresses so one rule covers a whole segment. For 13.4, the assessor will look for a rule set that denies traffic between segments by default and allows only documented flows. Confirm the exact rule behavior and alias options in the version you deploy.

Per-rule logging for segment evidence

OPNsense can log each rule match and show those entries in the live log view. This matters for 13.4 because the Coverage metric depends on showing that filtering is in place, and logged denies provide proof that a boundary is enforcing. Decide which rules log, where the logs are forwarded for retention, and who reviews blocked traffic. Confirm how logs are exported in your version before you rely on them as evidence.

Alias groups for segment inventory

Aliases let a rule refer to a named group of hosts, networks or ports instead of repeating addresses. Keeping one alias per segment makes the segment inventory and the filtering rules match, which is what an assessor checks when counting segments that are properly configured. Review aliases when assets move, because a stale alias can open a path between segments without anyone changing a rule.

Coraza at the application layer

Coraza is an Apache-2.0 web application firewall that is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects HTTP traffic for attacks such as SQL injection and cross-site scripting, and integrates with Caddy, HAProxy, Traefik and Nginx. It fits Safeguard 13.10 better than 13.4, because it filters requests inside an application path rather than deciding which segments may talk to each other. Use it for web tiers that cross a boundary, and keep 13.4 enforcement on the packet filter.

Limits of open-source filtering

A packet filter does not inspect application payloads, and a web application firewall does not control traffic that bypasses it. Neither tool replaces an asset inventory, a documented segment architecture or a review process that catches rules added during changes. Ask your team to name the boundaries each tool covers, and list any path, such as management or east-west traffic, that neither one filters. Gaps in that list are what an assessor will raise first.

Confirm features in your version

Rule options, alias types, logging destinations and integration modules change between releases of both projects. Before you cite a feature as evidence for 13.4, test it in the exact version you run, export a sample rule set and log, and record the results. Keep that test record with the configuration so an assessor can see that the capability was verified, not assumed from documentation.

What meeting 13.4 costs in money and effort

This table lists each cost component of meeting Safeguard 13.4, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, because most of the spend follows from how many segments exist and how often the rules change.

Cost component	One-time or recurring	Who is paid	What drives it and what to ask for
Firewall software licenses	Recurring if commercial, none for OPNsense	Software vendor or none	OPNsense is BSD-2-Clause, so the software carries no license fee. Ask the partner to confirm whether any paid plugins or vendor support are in scope.
Firewall hardware and support	One-time for hardware, recurring for support	Hardware vendor, reseller or cloud provider	Driven by throughput, number of segment boundaries and high availability needs. Ask for hardware sizing tied to the flow map and the support terms.
Flow mapping and rule design	One-time, repeated after major change	Implementation partner or internal network engineers	Scales with the number of segments and undocumented application flows. Ask for a deliverable listing each segment pair, allowed ports and owners.
Rule implementation and testing	One-time per segment boundary	Implementation partner or internal engineers	Rises with the number of segment boundaries and with cloud security groups versus on-premises rulesets. Ask how changes are staged and rolled back.
Change management and rule review	Recurring	Internal network and security teams	Driven by rule churn, the number of requests and how often owners recertify rules. Ask for a documented change process and a review cadence set in the written scope.
Monitoring of blocked and logged traffic	Recurring	Internal SOC or managed service provider	Volume depends on how many deny events are logged and sent to the SIEM under 13.1. Ask how log volume is sized and who triages denies.
External testing or review of segment boundaries	Recurring or periodic	Independent tester or assessor	Scope grows with the number of segments and whether the test covers cloud and on-premises paths. Ask for the test scope in writing before work starts.
Auditor sampling time	Recurring at each assessment	Independent auditor	Auditors sample segment rules and change records, so cost tracks how well the rule inventory is documented. Confirm with the auditor how many segments and changes they will sample.

Who owns segment filtering and what to outsource

Your organization owns Safeguard 13.4. That means deciding which network segments exist, which traffic between them is allowed, who approves each exception and how the filtering is reviewed over time. The assessment specification measures a Coverage metric: the share of network segments properly configured to filter traffic between segments. Your team is accountable for that number being true on every segment in scope, not only for the segments an implementation partner touched.

Segment decisions: Define the segments, their trust levels and the business owner for each one, and keep this aligned with the architecture described under Safeguard 12.2.
Policy approval: Approve the allowed flows and each exception with a named owner, reason and review date.
Operation: Monitor deny logs, handle changes through your change process and confirm that filtering stays in place after upgrades.
Evidence ownership: Keep current rule exports, change records and coverage calculations in a location your auditor can reach.
Ongoing review: Re-check segment coverage whenever a new network, cloud account or subnet appears.

Check that someone on your side can explain every allowed flow in your rule set without referring to the vendor.

Where segment filtering usually falls short and how to close it

Segment filtering in Safeguard 13.4 usually fails in the gaps between documents and running systems rather than in the firewall product itself. The cards below cover the gaps assessors and engineers see most often, and the fix for each. Each one can be checked against the network as it runs today.

Segments missing from the architecture diagram

Cloud accounts, subnets and virtual networks are often created by project teams without updating the network diagram. A segment that appears in no diagram is rarely in the filtering scope, so it passes traffic unchecked. Compare the live routing tables and security groups in each cloud account and data center against the architecture documentation, and record every segment in the Coverage denominator. The Coverage metric counts only segments that are known and configured.

Allow-any rules left from troubleshooting

Temporary rules added to get an application working during an outage often stay in place for months. A broad rule that permits any source to reach any destination on any port makes every segment boundary above it meaningless. Review rules that match on wide address ranges or all ports, and require each one to name a ticket and a reason. Remove the rule once the troubleshooting is done and confirm the application still works.

No default-deny between segments

A filter that lists only the flows someone thought to block still allows everything else. Default-deny reverses this: traffic between segments is blocked unless an approved rule permits it. In OPNsense, the final rule on each interface should block all traffic that no earlier rule has matched, and this behavior should be tested from each segment. Ask the team to show a blocked test flow between two segments with the log entry that records it.

Filtering with no logging

Rules that block traffic without recording it leave no evidence that the filter works and no signal when an attacker probes a boundary. Enable logging on deny rules between segments and on the rules that allow sensitive flows, then forward those logs to the central alerting platform covered by Safeguard 13.1. Check that a sample of blocked connections appears in the log view and in the central system within the time your alerting process requires.

Exceptions with no owner or expiry

A permanent exception for a legacy system or vendor link tends to outlive the people who requested it. Each exception should record a business owner, the flow it permits, the reason and a review or expiry date. Keep the register in the same change system as rule changes so an assessor can match each exception to an approval. Exceptions past their review date should be reported in the monthly governance review.

Rule sets drifting from approved flows

Over time, manual edits, emergency changes and copied rules move the live rule set away from the approved flow matrix. Export the current rule set on a fixed schedule and compare it to the approved matrix in version control. Treat each difference as a finding to resolve, either by approving the flow and updating the matrix or by removing the rule. Store the comparison output as evidence that the filter is still doing what the design says.

Questions buyers ask about Safeguard 13.4 cost, effort and help

Does CIS Safeguard 13.4 apply to IG1 enterprises?

No. Safeguard 13.4 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. IG1 covers essential cyber hygiene and is the minimum baseline for every enterprise, and 13.4 is not part of that baseline. An IG1 organization can still choose to filter traffic between its segments because it is good practice, but it does not need to evidence 13.4 to claim IG1 alignment. If you are unsure which Implementation Group your enterprise falls into, confirm it against the CIS Implementation Group definitions and your own risk profile before scoping this work.

How long does Safeguard 13.4 work take, and what drives it?

No duration figure has been published for this work in the sources we rely on, so we cannot give you a reliable number. The main drivers are the count of network segments in scope, how many of them already filter traffic between each other, the age and complexity of the firewall rule sets, the number of change-control approvals needed, and whether application and cloud security groups must be covered as well. Ask for a fixed-scope estimate that lists the segments, rule sets and environments in scope, the deliverables and the dates agreed in writing before work starts.

What does the work need from our internal team?

You need people who own the network architecture, the firewall change process and the business owners of each segment. Your network engineers must confirm which flows are legitimate, your security team must agree the allowed paths and the deny-by-default posture, and your change board must approve the rule changes. Application owners should validate that their services still work after filtering is enforced. Expect this to be a recurring commitment, because segment rules must be reviewed when systems, vendors or data flows change, not only once at rollout.

Can we implement Safeguard 13.4 in-house with OPNsense?

Often yes, if your team already runs network security and can maintain the rules. OPNsense is a stateful packet filter that passes, blocks or rejects traffic by source, destination, port and protocol, and it supports aliases for address groups and logging of each rule match in the live log view. Those features cover the enforcement side of 13.4 well. Your team still has to design the segment policy, document the allowed flows, test the rules, keep them under change control and produce the coverage evidence. Confirm that OPNsense fits your topology, throughput and high-availability needs before committing to it.

What will an auditor sample for Safeguard 13.4?

The CIS Controls Assessment Specification scores 13.4 with a Coverage metric, the share of network segments properly configured to filter traffic between segments. An assessor will therefore ask for a current list of network segments, the filtering rule set applied at each boundary, evidence that the rules are deployed and not just drafted, and a record showing which segments fall outside coverage and why. Expect requests for change records, rule review history and log samples that show filtering in operation. The independent assessor decides what passes; DeployOpen prepares systems and evidence but does not issue audit reports.

How does Safeguard 13.4 map to SOC 2 and PCI DSS?

The CIS Controls Navigator maps 13.4 to AICPA SOC 2 criteria CC6.6 and CC6.7 and to PCI DSS v4.0 requirements 1.3.1, 1.3.2 and 1.4.2. These mappings tell you where evidence for segment filtering may also satisfy other frameworks, but they do not replace the requirements themselves. PCI DSS assessors and SOC 2 auditors each apply their own scope and testing approach, so confirm with your assessor how they will accept the evidence. The mapping is CIS's published work, and you should verify it against the current version of each framework before relying on it in a contract.

What can a partner take on without taking over control ownership?

A partner can plan the segment architecture with you, configure and document the filtering rules, test them, set up logging and produce the evidence package an assessor will request. Those are preparation tasks. Your organization still owns the control: it approves the segment policy, accepts residual risk, runs the change process and reviews the rules over time. An independent auditor or certification body issues any report or certificate. Ask any partner to put in writing which deliverables they produce and which decisions remain yours.

How DeployOpen scopes, implements and prepares evidence for 13.4

DeployOpen plans, implements and documents the segment filtering that Safeguard 13.4 asks for, inside your own cloud accounts, data centers or air-gapped networks. We prepare the systems and evidence for your assessment, while your organization owns the controls and an independent auditor or certification body issues any report or certificate.

How we scope

The written scope lists which network segments are in scope and which filtering points enforce traffic between them.
Scope names the firewall or filter platforms, rule sets, logging targets and the owners who approve each rule change.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We deploy and configure open-source packet filtering, such as OPNsense rules by source, destination, port and protocol, for each segment boundary.
Rules are built with aliases for address groups and logging enabled so each rule match can be reviewed.
Where web-facing segments need application-layer inspection, we can evaluate Coraza with OWASP Core Rule Set rulesets, subject to testing in your environment.

How we hand over

We document the segment inventory, the filtering policy and a per-segment record showing which segments are properly configured.
We test deny-by-default behavior between segments and record results so the Coverage measure can be verified by your assessor.
Handover includes runbooks for rule changes, review cadence and the evidence files your assessor will request.

How we support

Ongoing support, rule reviews and upgrades are available as a retainer after handover.
Continuous testing of segment boundaries can be added to a retainer so rule drift is caught between assessments.
Confirm with your assessor which evidence format and retention period they require before the handover is accepted.

Safeguard 13.4 Traffic filtering between network segments