SC-35: External Malicious Code Identification

SC-35 requires you to put technical controls in the environment that proactively detect network-delivered malware and access to malicious websites, not just react after an endpoint alert. Operationalize it by deploying web/DNS filtering and network malware detection at key egress and ingress points, defining ownership and escalation, then retaining ongoing evidence that the detection is active and tuned. ¹

Key takeaways:

• SC-35 is about proactive, network-based identification of malicious code and malicious sites, not general “anti-malware” policy. ¹
• Auditors look for coverage at common traffic chokepoints (DNS, web proxy/SWG, email/web gateways, network sensors) plus proof it’s operating. ¹
• The fastest path is a control card + minimum evidence bundle + recurring health checks, mapped to your egress architecture. ¹

SC-35: External Malicious Code Identification is a practical control: can your environment identify malware and malicious websites as users and systems try to reach them over the network? The wording is short, but the expectation is operationally specific. You need at least one system component (often several) positioned where it can observe and block or flag traffic that is likely malicious, before it becomes a host compromise or data loss event. ¹

For a Compliance Officer, CCO, or GRC lead, the work is less about choosing a particular tool and more about making the requirement defensible: define where network traffic exits and enters, pick the control points that cover those paths, set ownership and alert handling, and maintain evidence that shows continuous operation and tuning. If you only have endpoint anti-virus and an incident response plan, you will struggle to argue you “proactively seek to identify network-based malicious code or malicious websites.” ¹

This page gives requirement-level implementation guidance you can hand to Security Operations, Network, and IT, while still meeting what assessors typically ask for: scope, technical placement, exceptions, and proof. ¹

Regulatory text

Requirement (verbatim): “Include system components that proactively seek to identify network-based malicious code or malicious websites.” ¹

Operator interpretation: You must implement technical components that actively detect suspicious/malicious network content or destinations (malicious sites) as traffic flows. “Include system components” implies this is not satisfied by a policy statement alone. “Proactively seek” implies enabled detection capability, current threat intelligence/signatures (as applicable), and monitoring that is actually running in production. ¹

What this means in practice:

• You need coverage for malicious destinations (typically DNS and web URL filtering).
• You need coverage for malicious content over the network (gateway malware scanning, network IDS/IPS, sandboxing/detonation, or similar capabilities).
• You need evidence that these controls are deployed, enabled, monitored, and maintained. ¹

Plain-English requirement

SC-35 asks a simple question: If a user or workload tries to reach a known bad domain, or downloads malware over the network, will your security stack detect it quickly and consistently? This control is about preventing and detecting “drive-by” infections, command-and-control callbacks, credential phishing destinations, and malware downloads that happen before an endpoint tool catches up. ¹

Who it applies to

Entity scope

• Federal information systems and contractor systems that handle federal data commonly implement NIST SP 800-53 controls, including SC-35. ²

Operational scope Apply SC-35 to systems and networks where:

• Users browse the internet or access third-party SaaS
• Workloads have outbound internet egress (including cloud workloads)
• Email or web traffic enters your environment
• Remote access and roaming endpoints operate off-network (you still need web/DNS protection paths) ¹

Common scoping decision If you have multiple environments (corporate IT, production, restricted enclaves), document which egress points exist for each and how SC-35 coverage is provided per egress. Assessors usually accept different implementations per segment if your rationale and evidence are tight. ¹

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

1) Build a “control card” for SC-35 (make it runnable)

Create a one-page runbook that includes:

• Objective: Identify network-based malicious code and malicious websites proactively. ¹
• Owner: Named role (e.g., SecOps Manager) with backup.
• In-scope systems: egress points, DNS resolvers, web proxies/SWG, email security gateways, network sensors, cloud egress/NAT, remote endpoint web protection.
• Cadence: how you review detections, tune policy, and verify sensors are healthy.
• Trigger events: new egress, new acquisition, major network change, new cloud account/VPC/VNet, tool replacement.
• Exceptions: who can approve, time-bounded, compensating controls, logging requirements. ¹

2) Map your real traffic paths (you can’t control what you can’t see)

Inventory and diagram:

• Corporate user internet access path(s)
• DNS resolution path(s) (on-prem, cloud, third-party)
• Email ingress/egress path(s)
• Production egress path(s) for workloads
• Remote endpoint path(s) (agent-based SWG/DNS protection, VPN-based, or split tunnel)
• Third-party connectivity paths (B2B tunnels, APIs, managed services) ¹

Deliverable: a one-page “SC-35 Coverage Map” that shows where external traffic is inspected and where malicious destinations are blocked/detected.

3) Choose control points that meet the intent

You generally satisfy SC-35 by implementing a combination of these components:

• DNS filtering / protective DNS to identify known malicious domains.
• Secure Web Gateway (SWG) / web proxy with URL categorization, phishing/malware blocking, and content scanning.
• Network IDS/IPS or NDR to identify malicious patterns and command-and-control activity.
• Email security gateway (relevant because many malicious websites arrive via links).
• Detonation/sandboxing for suspicious downloads, if your architecture supports it. ¹

A common, defensible minimum is: DNS filtering + SWG for user traffic + network detection in key segments + centralized logging/alerting. Your exact stack depends on architecture, but the coverage map and evidence are what make it auditable. ¹

4) Define detection actions and escalation (don’t stop at “we have the tool”)

For each control point, document:

• What gets blocked vs alerted
• Severity mapping (phishing, malware download, C2 callback)
• Who receives alerts (SOC queue, on-call rotation)
• Expected response steps: isolate host, reset creds, block indicators, open incident ticket
• How long logs are retained and where (SIEM/data lake) ¹

5) Establish your “minimum evidence bundle” (design for audits)

Per execution cycle (for example, a monthly control check), retain:

• Screenshot/export showing the control is enabled (policy/config summary)
• Report of detections/blocks (even if low volume) for the period
• Sample alert/ticket showing routing to SOC and closure notes
• Proof of threat feed/signature update status where applicable
• Exceptions list with approvals and expiration dates
• Coverage map and any change tickets for new egress points ¹

Store evidence in a single system of record. Many teams use Daydream to standardize the control card, define the evidence bundle, and track recurring health checks with owners and due dates, so the audit packet is reproducible. ¹

6) Run recurring control health checks (prove ongoing operation)

Your health check should answer:

• Are all sensors/agents reporting?
• Are DNS/SWG policies still attached to the right users/VLANs/VPCs?
• Did any new egress bypass inspection?
• Are blocklists/allowlists reviewed and justified?
• Are alerts generating tickets and being triaged? ¹

Required evidence and artifacts to retain (audit-ready checklist)

Keep these artifacts current and version-controlled:

1. SC-35 control card (owner, scope, cadence, exceptions). ¹
2. SC-35 Coverage Map (network/data flow diagram focused on egress/ingress inspection points).
3. Tool configuration exports (DNS filtering policy, SWG policy, IDS/NDR policy summary).
4. Logging/SIEM evidence showing data sources onboarded (DNS logs, proxy logs, IDS/NDR alerts).
5. Sample detections + tickets demonstrating alert handling workflow.
6. Exception register with business justification, risk acceptance, compensating monitoring, and expiration.
7. Recurring health check records and remediation tracking to closure. ¹

Common exam/audit questions and hangups

Assessors and customer due diligence teams tend to ask:

• “Show me where you identify malicious websites for roaming endpoints.”
• “What network egress is not inspected, and why?”
• “Do you have split tunneling? If so, how do you enforce DNS/web protection off-VPN?”
• “Show evidence this is proactive: blocks/detections, not just ‘we own a license.’”
• “How do you keep the control effective after network changes?” ¹

Hangup pattern: teams can explain the tools verbally but cannot produce a clean evidence bundle tied to an operating cadence and an accountable owner. This is explicitly called out as a risk factor for implementation failure. ¹

Frequent implementation mistakes (and how to avoid them)

1. Relying on endpoint AV alone. Fix: show network-layer identification (DNS/SWG/IDS) aligned to egress paths. ¹
2. Incomplete egress coverage in cloud. Fix: document each VPC/VNet egress and enforce centralized egress or equivalent controls per segment.
3. No story for remote endpoints. Fix: require agent-based DNS/SWG or enforced DNS resolvers; document exceptions for BYOD.
4. “Set and forget” filtering with growing allowlists. Fix: periodic allowlist review with approvals and expirations.
5. Evidence is scattered. Fix: define the minimum evidence bundle and store it in one place with consistent naming and retention. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t anchor your program on a specific regulator narrative. Treat SC-35 as a foundational detective/preventive control that reduces the likelihood and dwell time of web-borne malware and phishing-driven compromise. The risk is operational: a gap in network-based identification often becomes an audit finding, and it increases the probability that common intrusion paths go undetected until after impact. ¹

Practical execution plan (30/60/90)

Use this as an operator plan. Adjust scope based on system criticality and architecture.

First 30 days: establish scope, ownership, and coverage map

• Name the SC-35 control owner and approvers; publish the control card. ¹
• Produce the SC-35 Coverage Map for corporate, production, and remote access.
• Identify gaps: unfiltered DNS, direct-to-internet egress, unmanaged endpoints, missing telemetry in SIEM.
• Define the minimum evidence bundle and retention location. ¹

By 60 days: implement or close the biggest visibility gaps

• Roll out DNS filtering and/or SWG controls to the largest user and endpoint populations.
• Onboard DNS/proxy/IDS logs to your central logging platform; validate alert routing.
• Write and test the SOC runbook: triage steps, containment actions, and ticket fields for SC-35 detections.

By 90 days: operationalize and prove steady-state operation

• Run at least one full control health check cycle and track remediation to closure with due dates. ¹
• Tighten exceptions: time-bound approvals, compensating controls, and metrics you can show in an audit (counts are fine, but avoid unsupported claims).
• Package your audit-ready evidence: latest configs, sample alerts, sample tickets, coverage map, and health check record.

Frequently Asked Questions

Does SC-35 require a specific tool like a web proxy or IDS?

No specific product is named. You need system components that proactively identify malicious code or malicious websites over the network, and you must be able to show where they sit in your traffic paths. ¹

Can endpoint protection satisfy SC-35 by itself?

Usually no, because SC-35 is explicitly network-based and focused on identifying malicious code or websites via network activity. Endpoint controls can support your story, but you still need network-path coverage such as DNS or web filtering. ¹

How do we handle remote users who are often off-VPN?

Implement DNS/web protections that follow the device (agent-based) or enforce DNS resolution through controlled resolvers. Document the architecture and retain evidence that policy applies to roaming endpoints. ¹

What evidence is most persuasive to an auditor?

A coverage map plus exports showing policies are enabled, then logs/alerts and a corresponding ticket that shows triage and closure. Pair that with a recurring health check record tied to an owner. ¹

What should we do about legitimate business needs to visit risky categories or newly registered domains?

Use a formal exception process with business justification, approver, expiration, and compensating monitoring. Keep the exception register as part of your SC-35 evidence bundle. ¹

How do we operationalize this across multiple cloud accounts and environments?

Start with an egress inventory per environment, then standardize controls at the egress points or document equivalent controls per segment. Your audit defense is the combination of scoped coverage and consistent evidence. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5