Safeguard 13.10: Perform Application Layer Filtering

Safeguard 13.10 requires you to implement application-layer filtering controls that can detect, allow, block, and log traffic based on Layer 7 attributes (for example, HTTP methods, URLs, headers, DNS queries, and API requests), not just IPs and ports. To operationalize it quickly, define what “application-layer filtering” means in your environment, deploy it at your key ingress/egress points, and retain repeatable evidence that it runs and is reviewed. ¹

Key takeaways:

• Application-layer filtering means policy decisions using Layer 7 context (URLs, methods, domains, protocol commands), not only network-layer rules. ¹
• Scope the control around your real choke points: web apps, APIs, DNS, email/web gateways, and egress paths. ¹
• Audits fail most often on evidence: you need configs, rule baselines, logs, and review records tied to a defined control owner and cadence. ¹

A lot of teams think they meet “application filtering” if they have a firewall with port-based rules. That typically does not satisfy Safeguard 13.10. The operational intent is to filter traffic with application awareness: inspect and enforce policy based on what the traffic is doing at the application/protocol level and record decisions so you can investigate and tune. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate this safeguard into: (1) a clear control statement, (2) a defined scope (which systems and traffic paths are in), (3) technical enforcement points (WAF/API gateway, secure web gateway/proxy, DNS filtering, email security gateway, next-gen firewall app-ID features), and (4) recurring evidence capture that proves the control runs as designed. ¹

This page is written at “requirement implementation” level. It tells you who should own the control, what to deploy or configure, what auditors ask for, which artifacts to retain, and how to execute in a practical phased plan. The goal is a defensible control that reduces web/API malware and command-and-control risk while staying measurable and auditable. ¹

Regulatory text

Framework requirement: “CIS Controls v8 safeguard 13.10 implementation expectation (Perform Application Layer Filtering).” ¹

Operator meaning: You must implement filtering that evaluates traffic at the application layer and enforces allow/deny policy using application-aware attributes, with logging sufficient to support detection, response, and ongoing tuning. Do not treat this as a “nice to have.” Treat it as a control that must be designed, operated, and evidenced. ¹

Plain-English interpretation (what the requirement is really asking)

Safeguard 13.10 expects you to control application traffic using context that lives above Layer 3/4. Examples of Layer 7 decisions include:

• Block known-bad domains and newly registered domains via DNS filtering.
• Restrict outbound web traffic to approved categories using a secure web gateway or proxy with URL inspection.
• Enforce WAF rules for inbound web apps (OWASP-style patterns, bot mitigation, geo/IP reputation, request anomalies).
• Apply API gateway policies (schema validation, method enforcement, rate limits, token checks) and log decisions.

Your “pass” condition is not the specific tool. It’s whether you can show: where application-layer filtering is enforced, what policy it enforces, how exceptions are handled, and what evidence proves it is running and reviewed. ¹

Who it applies to (entity and operational context)

Entities: Enterprises and technology organizations adopting CIS Controls v8. ¹

Operational context:
Apply this safeguard anywhere application traffic crosses trust boundaries, including:

• Internet ingress to web apps and APIs (customer-facing or internal).
• User egress to the internet (corporate devices, VDI, remote users).
• DNS resolution paths (endpoints to resolvers, resolvers to upstream).
• Cloud edge (CDN/WAF), SaaS access, and SASE/secure web gateway paths.
• High-risk segments (admin networks, server subnets, production workloads).

If you have third parties with network connectivity (MPLS, VPN, partner tunnels) or third-party managed apps that terminate traffic on your behalf, include those paths in scope or document compensating controls and shared responsibility boundaries. ¹

What you actually need to do (step-by-step)

Step 1: Write the control requirement in operational terms

Create a one-page control statement that answers:

• Objective: prevent and detect malicious or unauthorized application traffic.
• In-scope traffic: inbound HTTP(S) to apps/APIs, outbound web, DNS, and any other key protocols you can filter at Layer 7.
• Enforcement points: WAF/API gateway, secure web gateway/proxy, DNS filtering service, next-gen firewall app controls (where applicable).
• Minimum outcomes: allow/deny rules, logging, and review. ¹

This is where many programs stall. If you cannot state what “application-layer filtering” means for your architecture, you cannot prove it later.

Step 2: Identify your choke points (the only places you can enforce consistently)

Build a simple scope map (table is fine):

• Internet → CDN/WAF → load balancer → app
• User device → proxy/SWG → internet
• Endpoint → internal resolver → upstream DNS filtering

Record which business services rely on each path and who owns the platform. Your enforcement will be as strong as your routing. If users can bypass proxy/DNS controls, the control is not consistently effective. ¹

Step 3: Implement baseline filtering policies (start narrow, then mature)

Establish a baseline that is defensible and reviewable:

• Inbound web apps: enable WAF protections appropriate to your tech stack, require TLS where applicable, log blocked and allowed requests with sufficient fields to investigate.
• APIs: enforce method and path rules, schema/size limits, authentication expectations, and rate controls where supported by the gateway.
• Outbound web: restrict categories that are clearly non-business and high-risk, and block known malicious destinations (via your SWG/proxy capability).
• DNS: block malicious domains, suspicious TLDs if supported by policy, and log all DNS queries with client identity where feasible.

Avoid writing a policy that you cannot maintain. Start with controls that reduce common abuse paths and produce usable logs. ¹

Step 4: Define exception handling that auditors will accept

You need a lightweight exception process that covers:

• Business justification
• Risk acceptance/approval (security + business owner)
• Compensating controls (for example, allowlist with additional monitoring)
• Expiration date or review trigger
• Ticket/reference ID tying back to the rule/config change

If an auditor sees broad allowlists with no expiry, they will treat the safeguard as only partially implemented.

Step 5: Centralize logs and make them reviewable

Application-layer filtering generates high-volume telemetry. You do not need to read every event. You do need:

• A defined log source list (WAF, SWG/proxy, DNS filter, API gateway).
• A path to your SIEM/log platform or a managed logging destination.
• A documented review workflow: what gets reviewed, by whom, and what constitutes “actionable.” ¹

Step 6: Prove ongoing operation (recurring evidence capture)

Safeguard 13.10 commonly fails on evidence. Set a recurring evidence package that includes:

• Current configuration exports or screenshots of key policies
• Rule baseline and last change date
• Sample logs showing allow/deny decisions
• Review records (meeting notes, tickets, detections)
• Exception register and approvals

Daydream can help here by mapping Safeguard 13.10 to a documented control operation and setting up recurring evidence capture so the control stays audit-ready without heroics. ¹

Required evidence and artifacts to retain

Use this as your audit evidence checklist:

Artifact	What “good” looks like	Owner
Control narrative for Safeguard 13.10	One-page description: scope, enforcement points, logging, review, exceptions	GRC + Security
Architecture/data-flow diagram	Shows where WAF/SWG/DNS filtering sits in traffic paths	Network/SecEng
Policy/rule baseline	Versioned rulesets (WAF policies, URL categories, DNS blocklists, API policies)	Platform owner
Change management records	Tickets/PRs showing approval and testing for policy changes	SecOps/ITSM
Logs + retention proof	Representative events and retention settings	SecOps/SIEM
Review evidence	Documented periodic reviews and follow-up actions	SecOps
Exceptions register	Approved, time-bound, with compensating controls	GRC

Common exam/audit questions and hangups

Expect these questions and pre-answer them in your control narrative:

1. “Show me where application-layer filtering is enforced.” Have the choke point map and platform list ready.
2. “What traffic is not covered and why?” Document exclusions (legacy systems, non-HTTP protocols) and compensating controls.
3. “How do you prevent bypass?” Be ready to show routing enforcement (forced proxy, DNS policies, egress controls).
4. “Who reviews the alerts and how often?” Provide the defined workflow and evidence of completed reviews.
5. “How do you manage allowlists?” Show approvals, expiration, and monitoring.

Hangup to avoid: saying “the firewall does it” without showing Layer 7 rule capability, configured policies, and logs that prove decisions. ¹

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating this as only inbound WAF. Fix: include outbound web and DNS as part of the application-layer filtering story where applicable to your environment. ¹
• Mistake: enabling a tool but not enforcing traffic through it. Fix: confirm routing, endpoint settings, and network controls prevent easy bypass.
• Mistake: drowning in alerts and turning enforcement to “monitor only.” Fix: start with a narrow baseline, tune, and define what gets reviewed.
• Mistake: unmanaged exceptions. Fix: require expirations and periodic review; keep exception volume visible to leadership.
• Mistake: no evidence package. Fix: define recurring evidence capture tied to Safeguard 13.10 and store it in a controlled repository. ¹

Enforcement context and risk implications (practical, not speculative)

No public enforcement cases were provided in the source catalog for this safeguard. ¹

Operationally, gaps in application-layer filtering show up as: malware callbacks over HTTP(S), data exfiltration over common web channels, exploit attempts against web apps/APIs, and limited visibility during incident response because logs lack request context. Your risk statement can be simple: without Layer 7 filtering, you rely on port/protocol controls that attackers routinely evade using allowed web traffic. ¹

Practical 30/60/90-day execution plan

First 30 days (foundation and scoping)

• Name an owner for Safeguard 13.10 and document the control statement and scope. ¹
• Inventory enforcement points already in place (WAF, SWG/proxy, DNS filtering, API gateway) and identify gaps by traffic path.
• Define the minimum logging fields and confirm logs reach your central log platform.
• Create the exception workflow and a register template.

Next 60 days (baseline enforcement and evidence)

• Implement or tighten baseline policies at the most critical ingress/egress points.
• Force routing through the filtering control where feasible (technical enforcement plus documented validations).
• Produce the first evidence bundle: configs, sample logs, review record, and exceptions register snapshot.
• Run a tabletop test: pick a blocked event and confirm your team can trace user/app, destination, and action taken.

By 90 days (operational maturity)

• Tune policies based on false positives and incident learnings; document rule change approvals.
• Establish recurring reviews and evidence capture so the control remains continuously testable. ¹
• Add coverage for additional high-risk paths (admin segments, production egress, third-party connectivity) or document compensating controls.

Daydream fits naturally here if you want the evidence collection and control mapping to be repeatable instead of a last-minute scramble before an assessment. ¹

Frequently Asked Questions

What counts as “application layer filtering” for Safeguard 13.10?

Filtering decisions based on Layer 7 attributes (for example URLs, HTTP methods, DNS queries, API endpoints, protocol commands) plus logs of those decisions. Port-based firewall rules alone rarely demonstrate this safeguard’s intent. ¹

Do we need a WAF to satisfy Safeguard 13.10?

A WAF is a common way to implement inbound HTTP(S) application filtering, but the requirement is about capability and evidence, not a specific product. If you use an API gateway, reverse proxy, or similar Layer 7 control, document how it filters and logs traffic. ¹

How do we scope this in a hybrid environment (on-prem + cloud + SaaS)?

Scope by traffic paths and trust boundaries: internet ingress to apps/APIs, user egress, and DNS. Then list the enforcement point for each path (cloud WAF, SASE/SWG, DNS filtering) and document any excluded paths with compensating controls. ¹

What evidence do auditors usually want first?

They ask for (1) where filtering happens, (2) the rule/policy baseline, (3) sample logs showing allow/deny actions, and (4) proof of periodic review and exception approvals. Build a standard evidence bundle and update it on a recurring schedule. ¹

We allow many third parties and contractors. Does this apply to them?

If third parties access your environment or send traffic to your apps/APIs, include those paths in scope and enforce the same Layer 7 protections at the boundary. Where responsibility is shared, document the boundary, required controls, and what evidence you collect from the third party. ¹

How do we avoid breaking the business with aggressive filtering?

Start with clear, low-regret controls (malicious domain blocking, basic WAF protections, logging) and add stricter rules through change control with testing and an exception process. Track exceptions so “temporary” allowlists do not become permanent. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8