SC-35: External Malicious Code Identification

Quick-reference card

What this control requires

SC-35 requires organizations to deploy system components that proactively search external networks, including the internet, for malicious code hosted on websites and other external sources. Unlike passive defenses that wait for threats to reach the perimeter, this control demands an outward-facing capability that hunts for malicious content before it can target your environment.

In practice, this control means operating specialized components, often called honeyclients, that actively browse and interact with suspicious websites to identify malicious payloads. These components simulate user behavior to trigger drive-by downloads, exploit kits, and other attack vectors that rely on a target visiting a compromised page. The goal isn’t just detection after the fact; it’s intercepting threats at the source.

The control also carries a critical isolation requirement. Because these probing components deliberately seek out and may execute malicious code during analysis, they must run within sandboxed or virtualized environments that prevent any discovered threats from reaching production systems. Without that isolation boundary, the very tool designed to protect your network becomes a conduit for infection.

Why it matters

Organizations that lack proactive external threat identification operate in a reactive posture, discovering malicious code only after it has already reached their perimeter or compromised a system. That delay gives attackers a significant window to establish persistence, exfiltrate data, or stage follow-on attacks.

Failure to implement SC-35 creates a measurable gap in your security architecture that auditors will flag. Federal and regulated environments expect documented evidence that your systems don’t just defend against known threats but actively hunt for emerging ones outside the network boundary.

The risk compounds when you consider your external attack surface. Employees browse the web, partners share links, and third-party integrations connect to external services. Each of those interactions is a potential delivery mechanism for malicious code that passive controls won’t catch until it’s already inside.

Without proactive identification, your threat detection and response capabilities start a step behind. You’re relying entirely on signature-based defenses and endpoint tools to catch what your network perimeter missed, rather than preventing exposure in the first place.

What attackers exploit

• Watering hole attacks that compromise legitimate websites frequented by your workforce, embedding malicious code that targets specific visitor profiles
• Drive-by download campaigns that weaponize ad networks or third-party scripts on otherwise trusted sites, delivering exploits without user interaction
• Malicious redirect chains that funnel traffic through multiple compromised domains before landing on an exploit kit page
• Typosquatting and lookalike domains that host malicious payloads disguised as legitimate software downloads or business tools
• Supply chain compromise of external code repositories where attackers inject malicious packages into public libraries your development teams may pull from

How to implement

Most organizations struggle with SC-35 because it requires building and maintaining proactive threat-hunting infrastructure that deliberately interacts with potentially hostile content. The implementation challenge isn’t just technical; it requires operational discipline to keep probing components isolated while still feeding actionable intelligence back to your security operations team.

For your organization

Step 1: Establish isolated probing infrastructure

Deploy honeyclient components or automated web-crawling systems within a fully isolated environment. Virtualization platforms and containerized sandboxes are the most common approach. These systems should have no direct network path to production assets, using dedicated network segments with strict egress controls.

Step 2: Define external probing scope

Determine which external sources your probing components will monitor. Start with domains and URLs that appear in your threat intelligence feeds, industry-specific indicators of compromise (IOCs), and sites commonly visited by your workforce. Expand coverage to include newly registered domains and known malicious infrastructure.

Step 3: Automate analysis and reporting

Configure your probing systems to automatically capture, analyze, and categorize any malicious code they encounter. Integrate findings with your security information and event management (SIEM) platform and threat detection workflows. Automated alerting should trigger when a probed site returns malicious content that matches assets in your environment.

Step 4: Maintain isolation integrity

Regularly verify that your sandboxed environments remain fully segmented from production systems. Common mistakes include allowing shared storage volumes, reusing credentials across sandbox and production environments, and failing to reimage probing systems after exposure to confirmed malware. Schedule quarterly isolation validation tests.

Step 5: Document and review

Maintain logs of all probing activities, discovered threats, and containment actions. Review these records monthly to refine your probing scope and update your system and communications protection policy. Auditors will expect to see both the technical configuration and a documented review cadence.

For your vendors

Step 1: Assess vendor probing capabilities

Ask vendors whether they deploy components that proactively scan external networks for malicious code. Request documentation describing their honeyclient infrastructure, automated web-crawling tools, or equivalent external threat identification mechanisms.

Step 2: Verify isolation controls

Request evidence that any probing components operate in isolated environments. Review network architecture diagrams showing the segmentation between probing infrastructure and production systems. Red flags include shared network segments, lack of virtualization, or no documented reimage process for compromised probing systems.

Step 3: Review threat intelligence integration

Evaluate how your vendor feeds external malicious code findings into their broader security monitoring operations. Vendors should demonstrate that discoveries from proactive probing result in updated threat signatures, blocked domains, or adjusted firewall rules within a defined timeframe.

Step 4: Evaluate ongoing operations

Request audit logs showing the frequency and scope of external probing activities over the past 12 months. Vendors that claim SC-35 compliance but can’t produce evidence of active probing may have deployed the capability without operationalizing it. Look for regular activity patterns, not a one-time deployment.

**Step 5: Assess **supply chain risk

Determine whether your vendor’s probing capabilities extend to monitoring external code repositories and third-party libraries they depend on. Supply chain attacks increasingly target upstream dependencies, and vendors should demonstrate awareness of this vector within their malicious code identification program.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for SC-35.

Related controls

• SC-07 — Boundary Protection: Defines the network perimeter controls that complement SC-35 by constraining the paths through which externally discovered malicious code could enter the environment.
• SC-26 — Decoys: Uses passive decoy components (honeypots) to attract attackers, whereas SC-35 actively probes external networks to identify malicious code at its source.
• SC-44 — Detonation Chambers: Provides controlled execution environments where suspicious code can be safely analyzed, supporting the isolation requirement that SC-35 mandates for probing components.
• SI-03 — Malicious Code Protection: Covers traditional antivirus and anti-malware defenses that detect known threats on internal systems, complementing the proactive external search that SC-35 requires.
• SI-04 — System Monitoring: Establishes the broader monitoring infrastructure that ingests and acts on the threat intelligence produced by SC-35 probing activities.

Frequently asked questions

What is NIST SP 800-53 SC-35?

SC-35 is the NIST SP 800-53 control that requires organizations to deploy system components capable of proactively identifying malicious code on external networks and websites. These components, commonly implemented as honeyclient systems, actively browse and interact with suspicious sites to trigger and capture malicious payloads before they reach the organization’s perimeter. The control also mandates isolation measures, typically virtualization, to prevent any discovered malware from infecting production systems during the identification process.

What happens if SC-35 is not implemented?

Without SC-35, your organization loses the ability to detect malicious code at its external source before it targets your systems. Auditors reviewing your System and Communications Protection family controls will identify a gap in proactive threat identification, which weakens your overall compliance posture. The practical consequence is that your defenses become entirely reactive, relying on perimeter and endpoint tools to catch threats that proactive network probing could have identified and blocked earlier.

How do you audit SC-35?

Auditors verify SC-35 by examining whether honeyclient components or equivalent probing tools are deployed, operational, and producing documented results. They review system design documentation for proper isolation architecture, inspect audit logs for evidence of regular external probing activity, and confirm that discovered threats feed into the organization’s broader malicious code protection and monitoring processes. The audit also checks that procedures addressing external malicious code identification are current and that probing components are reimaged or restored after exposure to confirmed threats.

How does SC-35 differ from SC-26?

SC-35 actively sends probing components outward to search external networks for malicious websites and code, while SC-26 deploys passive decoy systems (honeypots) within or near the network to attract and observe attacker behavior. The key distinction is directionality: SC-35 hunts for threats on the internet before they reach your environment, whereas SC-26 waits for threats to come to it. Both controls support threat intelligence gathering, but they serve fundamentally different detection strategies.