SI-3 Malicious code protection: requirements and evidence

What SI-3 malicious code protection requires in practice

If you are preparing for an audit, a FedRAMP annual assessment or a baseline gap review, the question is what SI-3 expects you to run and prove. SI-3 requires malicious code protection at system entry and exit points, using signature-based or non-signature-based mechanisms that update automatically, run periodic and real-time scans, block or quarantine malicious code, alert defined personnel and address false positives. The control covers both directions of traffic and data: code arriving through email, web downloads, removable media and file transfers, and code leaving through outbound channels that could carry payloads or stolen data. In practice, an assessor will ask where the mechanisms sit, who receives their alerts and whether the records show they ran as configured.

The risk SI-3 addresses is simple to state and hard to close: malware that reaches a system and runs before anyone notices. Several things make the control harder than it looks. Server workloads, containers and agentless cloud instances often lack an endpoint agent, so their coverage is a gap that no one owns. Scan exceptions accumulate when teams exclude paths or processes to fix false positives, and nobody reviews them. Update status is easy to lose when agents or signature feeds fall behind on hosts that are offline or rarely patched. Each of these gaps is visible in configuration exports and scan records, which is why the assessment procedures ask for those records rather than a policy statement alone.

SI-3 sits in the low, moderate and high baselines in SP 800-53B, so the control applies at every impact level. Its Release 5.2.0 form has 6 organization-defined parameters that you must set yourself, and the wording of those parameters (scan frequency, the scope of real-time scanning, who receives alerts and how false positives are handled) determines what an assessor will test. Confirm these values in your own system security plan before the assessment starts, and check that the values you wrote match the settings in your tools. FedRAMP's annual assessment requirement for SI-3 at Classes B, C and D means the same evidence must be refreshed each year, so decide now who owns the exception register and the update records.

Which systems and entry points fall under SI-3

SI-3 applies wherever malicious code can enter or leave the system, so scoping starts with the boundary and the impact level, not the tool. The cards below cover the components to include, the baseline and FedRAMP class that set the obligation, and the third-party services that must be evidenced as well.

Email and web entry points

Mail gateways, web proxies and content filters are the most common SI-3 entry and exit points, because they receive inbound files and send outbound traffic. Confirm which gateways, relays and proxies sit inside the authorization boundary, and whether each one runs signature-based or non-signature-based inspection with updates that the organization can show. Record the scan configuration and the blocking or quarantine action for each path.

Endpoints and servers in scope

Workstations, laptops, servers and virtual machines in the boundary each need malicious code protection that the assessor can trace back to the system inventory. Check that the inventory reflects every host, including short-lived cloud workloads and systems that are offline for long periods. Mismatches between the inventory and the agent console are a frequent finding during assessment.

Removable media and file transfer channels

USB devices, optical media and file transfer hand-offs can carry malicious code past network controls. Decide whether removable media is blocked, scanned on connection, or allowed only on approved hosts, and document that decision in the system security plan. Test the control with a known-benign test file so the record shows the channel was checked, not only assumed to be covered.

Baseline selection by impact level

SP 800-53B assigns SI-3 to the low, moderate and high baselines, so the control applies at every impact level. The impact categorization of the system determines the baseline, and the baseline determines which organization-defined parameters must be filled in. Confirm the categorization first, because it sets how much the parameters and assessment objects must be documented.

FedRAMP classes and the annual assessment

For FedRAMP, SI-3 is required at Classes B, C and D, and it must be included in an independent assessment every year. Cloud service offerings should confirm their class with the sponsoring agency or the FedRAMP documentation before scoping the assessment. Plan the annual evidence pull (update logs, scan results and configuration exports) so it is ready before the assessor begins.

Managed services at the boundary

Managed email security, managed endpoint detection, and outsourced SOC services often run the malicious code protection that the organization is responsible for. Ask each provider for its own assessment evidence, the scope of its agents and its update and alert records, and confirm the contract assigns responsibility for false positive handling. The organization still owns the control, so the evidence must reach the authorization package.

How an assessor tests SI-3

This table maps the examine, interview and test methods in SP 800-53A Release 5.2.0 to what an assessor does for SI-3 and the evidence each step asks for. Read it as a preparation checklist: each row shows where a finding usually comes from, so the evidence can be ready before fieldwork starts.

Test method	Evidence requested	Common finding
Examine protection mechanism configuration	Exported settings for endpoint and gateway malicious code protection, showing signature or behavioral engines enabled at entry and exit points	Protection enabled on workstations but not on mail, web or file transfer gateways
Examine update records	Logs or console reports showing signature or engine update history with dates and the source of each update	Updates run manually and sporadically, with gaps the organization cannot explain
Examine scan results	Scheduled and real-time scan reports, quarantine and block actions, and alert records for a sample period	Scan schedules defined in policy do not match what the tool is configured to run
Examine system design documentation	Diagrams and architecture notes showing where malicious code protection sits relative to system entry and exit points	Design documents omit cloud workloads, containers or remote endpoints
Interview system administrators	Walkthrough of how updates are deployed, how exceptions are approved and how alerts reach the responsible team	Staff describe a process that differs from the written procedure
Interview incident response personnel	Explanation of response actions taken on detected malicious code and how alerts are escalated	Quarantine or block actions are not tied to a documented response step
Test protection against a known test sample	Controlled test result showing detection, blocking or quarantine and the resulting alert, performed in an agreed test environment	Detection works on the test host but alerts never reach the monitoring queue
Test false positive handling	Records of reviewed false positives, the decision made and any exclusion approved by a named owner	Exclusions added without review, or no record of who approved them

Implementing SI-3 in order

This sequence moves SI-3 from an organization-defined design to working malicious code protection at every entry and exit point, with each step producing the record an assessor will examine. Work it in order, because later steps depend on the scope and parameters set earlier.

Define the organization-defined parameters
The organization sets the values SI-3 leaves open: how often periodic scans run, which file types and locations are scanned, which actions apply to malicious code, and who receives alerts. The control owner records these values in the system security plan, and the security lead approves them. The step is complete when each parameter has a written value, an owner and a link to the policy or procedure that sets it. An assessor will compare the running configuration against these values, so vague wording here causes findings later.
Map entry and exit points for the system
Engineers list every point where code or files enter or leave the system boundary. Typical points include email gateways, web proxies, file transfer services, removable media ports, software repositories, build pipelines and endpoint agents on user and server hosts. The architecture team compares this list against the system design documentation so that the boundary diagram and the protection inventory agree. The output is a signed inventory that names each point and the mechanism that covers it. Assessors examine this inventory first, because SI-3 applies at these points.
Deploy signature or non-signature protection
The platform team installs malicious code protection mechanisms on each endpoint and at each gateway identified in the inventory. Signature-based tools match known patterns, while non-signature methods such as behavior analysis or heuristics detect unknown threats. Teams often combine both. Open-source options such as ClamAV and YARA rules can cover parts of this layer, and osquery can report running processes and file hashes across hosts to confirm that agents are present and active. The step closes when an inventory report shows every in-scope host with an active mechanism. Confirm each product's detection capabilities with its vendor before relying on them.
Configure automatic updates and scan schedules
Administrators enable automatic signature or engine updates and set periodic full scans and real-time scanning at each protected point, using the parameter values from the first step. They also configure a fallback for hosts that are offline or disconnected, such as an air-gapped network, where updates arrive through an approved transfer process. The output is a configuration export for each mechanism and a sample of update logs showing successful pulls. Assessors look for records of update activity and scan results, so keep these logs retained according to the audit policy.
Set block, quarantine and alert actions
The security team defines what the mechanism does when it detects malicious code: block the transfer, quarantine the file, terminate the process or isolate the host, and notify defined personnel. Wazuh can forward alerts from endpoint and gateway logs into a ruleset with custom rules, and OpenSearch Security Analytics can route findings to Slack or email channels. The step is complete when test code, placed safely in a lab copy of the environment, triggers each action and the alert reaches the named recipients. Keep the test results as evidence of the response actions.
Define false positive handling
The organization writes a procedure for reviewing detections that turn out to be benign, including who can approve an exception, how the exception is documented, how long it stays in effect and how it is revisited when the software changes. Exceptions should be narrow, such as a hash or path for one application, not a broad exclusion. Changes to exclusions usually pass through the change control process of the configuration management family. The output is the exception register and a sample of approved and rejected requests. Assessors check that false positives are handled consistently and do not become silent gaps.
Collect evidence and schedule the independent assessment
The control owner compiles the artifacts an assessor will request: the entry and exit point inventory, configuration exports, update and scan records, scan results, alert test records and the false positive register. Osquery queries and Velociraptor hunts can help gather host-level evidence across a fleet, and the results should be exported with timestamps. Confirm the assessment scope, timing and fees with the independent assessor, since DeployOpen prepares evidence but does not issue assessment reports. The step is complete when the evidence package maps each determination statement in SP 800-53A to a named artifact.

Evidence that passes an SI-3 assessment

SI-3 assessors work from records, not promises. The cards below cover the artifacts an examiner asks to see for malicious code protection, and how each one stays current between assessments. Your organization owns the control; the evidence must show the mechanisms actually ran and that someone acted on what they found.

Mechanism configuration exports

Export the configuration of every malicious code protection mechanism at endpoints and at network entry and exit points, including signature or detection settings, real-time protection state and exclusions. Assessors compare these exports against the scan and update requirements you defined for SI-3, so each exclusion needs a documented reason. Keep dated exports so you can show configuration history, not only the current state. Confirm with each vendor how its management console exports configuration.

Automatic update logs

SI-3 requires protection that updates automatically, so the update history is primary evidence. Collect logs showing signature or engine updates applied across the fleet, with timestamps and any hosts that failed to update. An update gap for a host that was offline is explainable; an unexplained gap is a finding. Review the logs on the cadence you defined and record the review.

Scan schedules and results

Keep the scan schedule as defined in your procedures and the results it produced, covering both periodic full scans and real-time scanning. Assessors look for evidence that scans ran on time, what they covered, and what they found. Retain results for the period your records policy requires. Missing scan runs are usually easier to explain when the schedule and the job history are kept together.

Alert records to defined personnel

SI-3 expects alerts to reach personnel you defined. Keep the alert records themselves, the recipient list or channel configuration, and proof that alerts were delivered and acknowledged. A recipient list that names people who left the organization is a common gap. Check the list at each evidence review and record the change.

Quarantine and block records

For each detection, show what the mechanism did: blocked, quarantined, or cleaned, and whether the action succeeded. Pair the mechanism record with the response ticket, including containment steps and any follow-up such as reimaging. Assessors test whether blocking and quarantine work as documented, so an occasional test detection with its record is useful evidence.

False positive tickets with approvals

SI-3 requires that false positives be addressed, which means every exclusion or suppression needs its own ticket. Record the detection, the analysis showing it was benign, the approver, and the scope of the change. Review open exceptions periodically so temporary exclusions do not become permanent. Assessors often sample these tickets, so each should stand on its own.

Current system design documentation

Keep the system design documents that show where malicious code protection sits, including entry and exit points, endpoint coverage and how the mechanisms connect to monitoring. Assessors use these diagrams to confirm that the scope of your evidence matches the system boundary. Update them when architecture changes, and tie each revision to a change record.

Keeping evidence current between assessments

Evidence goes stale quickly, so schedule a periodic evidence review that pulls each artifact above for a defined period, checks it against the procedure, and files the result. Record who performed the review, what gaps were found, and how they were closed. FedRAMP's Rev5 baselines require SI-3 in an independent assessment every year at Classes B, C and D, so confirm your own assessment cadence with the authorizing body.

What meeting SI-3 costs in money and effort

This table breaks down the cost components of meeting SI-3 malicious code protection, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to shape a written quote, since no price or duration is supplied for SI-3 and the figures depend on your own fleet and entry points.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Licensed endpoint or gateway protection	Software vendor or reseller for licenses, support and updates	Recurring (subscription or maintenance)	Number of endpoints, count of network entry and exit points, and whether existing tooling already covers them
Engineering time to deploy and tune	Internal platform or security staff, or an implementation partner under a fixed-scope agreement	One-time, with periodic retuning	Number of operating system types, custom scan exclusions, and how many false positive cases need investigation
Self-hosted open-source telemetry (for example osquery, Wazuh, Velociraptor)	No license fee for the open-source components; staff or partner pays for hosting and operations	Recurring operations effort plus one-time build	Fleet size, log volume, data retention needs, and whether staff already run a SIEM or endpoint stack
Evidence upkeep	Internal control owner, with scan and update records kept current	Recurring	Frequency of update checks, number of systems in scope, and how well scan results and update logs are centralized
External testing or review	Independent testers or reviewers, paid per written scope	Recurring or periodic	Scope of entry and exit points tested, whether evasion testing is included, and how often the configuration changes
Assessor sampling time	Independent assessor or auditor, billed under their own engagement terms	Recurring at each assessment cycle	Number of endpoints and entry points sampled, and how quickly records can be produced on request
Response and false positive handling	Internal security operations staff	Recurring	Alert volume, quality of exclusion documentation, and clarity of the response runbook

Open-source tools that produce SI-3 evidence

None of the tools below is a signature-based anti-malware engine, so they cannot satisfy SI-3 on their own. They produce the evidence that a malicious code protection mechanism is deployed, scanned, updated and acted on, which is what an assessor examines. Confirm which protection product covers the mechanism requirement before you plan the evidence set.

osquery for fleet queries

osquery exposes running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables. The osqueryd daemon can schedule these queries across an entire fleet of hosts, so you can show recurring checks for unexpected processes, unknown kernel modules and suspicious outbound connections. Check that scheduled query results are retained and timestamped, because an assessor will ask for records over the assessment period. License: Apache-2.0 OR GPL-2.0-only.

Velociraptor for endpoint hunts

Velociraptor collects forensic artifacts defined in VQL from endpoints. Its hunts run one or more artifacts across a group of systems, schedule offline machines to collect when they reconnect, and create a notebook per hunt for analyzing combined results. This supports SI-3 reviews when you need to show that a malicious code sweep reached every endpoint, including machines that were offline during the first run. License: AGPL-3.0-only, which carries source-availability obligations if you modify and provide the software over a network. Confirm that with counsel.

OpenSearch Security Analytics detectors

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Matches are recorded as findings with rule, log type and severity, alerts go to channels such as Slack or email, and a correlation engine links findings across log types. Use it to show that malware indicators trigger alerts and that alerts reach defined personnel. License: Apache-2.0.

Wazuh rule matching and alert records

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus custom rules. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK, and forwarded to the Wazuh indexer for review in the dashboard. Its alert files give an assessor a durable record of detections and responses. Verify that the ruleset includes malware-relevant rules for your platforms and that the alert retention period meets your policy. License: GPL-2.0-only.

Who owns SI-3 and what to outsource

Your organization owns SI-3. The control is implemented by the organization and the system, and the decisions about what protects which entry and exit points, how aggressively scans run, and who acts on a detection stay with your people. An outside partner can recommend options, but it should not be the approver of its own design. Retain these responsibilities internally:

Protection mechanism decisions: choose the anti-malware approach (signature-based, non-signature-based or both) for endpoints, email, web gateways and other entry and exit points, and document why each was selected.
False positive approvals: define who may suppress or allowlist a detection, what justification is required, and how suppressions are reviewed and expired.
Alert response: name the personnel who receive malicious code alerts, the containment steps they take, and the escalation path into incident response.
Update and scan policy: set the update cadence and the periodic and real-time scan requirements in the procedures your assessor will read.
Risk acceptance: record any exceptions, such as hosts that cannot run an agent, with an owner and a review date.

Before engaging anyone, confirm that a named owner can sign these decisions.

Where SI-3 programs usually fall short

Most SI-3 findings are not missing anti-malware products. They are gaps in coverage, verification and follow-through: systems the console never sees, updates nobody checks, scans nobody reads, and exceptions that never expire. Each card names one gap and the action that closes it.

Servers outside the protection console

Protection is usually deployed to the systems people remember, while build hosts, legacy application servers and systems stood up by project teams stay outside the console. SI-3 applies at system entry and exit points as well as endpoints, so a host the console cannot see is a host without evidence. Reconcile the console's agent list against your asset inventory and the cloud account inventory each cycle, and treat any unmatched system as an open finding until protection or a documented alternative is in place.

Updates configured but never verified

A policy that enables automatic updates does not show that signatures or engines actually reached each system. Check the update timestamps and version reported by each agent against the console's expected values, and keep the records of malicious code protection updates that an assessor will ask to examine. Alert on stale agents rather than waiting for an audit to reveal them.

Scans that run but are never reviewed

Periodic and real-time scans generate results, but SI-3 expects those results to lead to blocking, quarantine and alerting of defined personnel. Assign a named reviewer, define how often scan results are read, and show that detections reached the people responsible. Fleet queries, such as those osquery can schedule across hosts, help confirm that scan activity is happening everywhere it should.

False positive exceptions without owners

Exclusions added to stop noisy detections often outlive the problem that created them, and they quietly remove coverage. Each exception should record an owner, the justification, the affected scope and an expiry date, and it should be reviewed when the software changes. Illustrative example: a folder excluded for a build tool stays excluded after the tool is retired, leaving a path no scanner inspects.

Missing system design documentation

Assessors use system design documentation to confirm where malicious code protection sits at entry and exit points. When diagrams omit proxies, mail gateways, file transfer paths or remote access routes, the assessor cannot tell whether those points are covered. Keep the diagram, the list of protection points and the configuration baseline in one controlled set, and update them with every architecture change.

Response actions not tested end to end

Detection is only half of SI-3. The organization must also show that malicious code is blocked or quarantined and that defined personnel are alerted. Test this with a benign test file that the protection product should flag, then trace the alert to the ticket and the closure record. Confirm the alert path reaches a monitored channel, since a detection that stops at a local log has not alerted anyone.

Questions buyers ask about SI-3

How much effort does SI-3 malicious code protection take to meet?

The effort depends on how many endpoints, entry and exit points and systems fall inside the authorization boundary, and on how much of the malicious code protection is already running. SI-3 asks for mechanisms that update automatically, run periodic and real-time scans, block or quarantine malicious code, alert defined personnel and address false positives. Most of the work is configuration, tuning and producing records that show those settings operate over time. SP 800-53B assigns SI-3 to the low, moderate and high baselines, and SP 800-53A lists eight determination statements that an assessor will test. Ask any partner to size the work from a named inventory of in-scope components, not from a generic estimate. No effort figure is supplied for this control, so confirm the numbers against your own environment.

Can our own team implement SI-3 without outside help?

Often yes, if the team already runs endpoint protection and can show its update history, scan results and alert routing. Internal staff usually own the policy, the malicious code protection mechanisms and the response procedure, because those decisions belong to the organization. Outside help is most useful where the team lacks time or experience with scan configuration, central logging for scan results, or evidence collection across a mixed fleet. The organization must still own the control. An implementation partner can prepare systems and records, but only an independent assessor issues findings on whether SI-3 is met.

What does SI-3 require from our operations and records?

SI-3 needs evidence that protection works continuously, not only that a product is installed. Assessors examine the malicious code protection mechanisms, records of signature or engine updates, scan results and system design documentation. Teams should be able to show:

Where protection runs at endpoints and at network entry and exit points
How updates are pushed and how often they occur
Scan schedules and real-time scanning settings
Who receives alerts and what happens to blocked or quarantined items
How false positives are reviewed and recorded

The records should be retained in a form an assessor can sample.

How long does it take to get SI-3 evidence ready for an assessment?

No duration for this control is supplied, so the timeline must come from your own environment and from a written scope. The main variables are how many systems and boundaries are in scope, whether protection is already centrally managed, and whether scan and update logs are retained long enough to sample. Teams that already keep these records usually need less time to prepare. Ask any partner to state its schedule as milestones tied to the agreed deliverables, and check whether that schedule includes a period for the assessor's sampling and for remediating findings.

Does FedRAMP's annual assessment change the work for SI-3?

Yes, it changes the cadence more than the content. FedRAMP's Rev5 baselines require SI-3 at Classes B, C and D, and its annual assessment rule requires SI-3 to be assessed in a FedRAMP independent assessment every year at those classes. That means the evidence must stay current across the year, and the assessor will expect records from the recent period, not a one-time snapshot. Plan for recurring evidence collection, regular review of update and scan records, and a process for false positive handling that holds up over time. Confirm the current class and assessment requirements with FedRAMP and your authorizing body before you scope the work.

How does SP 800-171 requirement 03.14.02 relate to SI-3?

SP 800-171 Rev. 3 requirement 03.14.02, Malicious Code Protection, is derived from SI-3, so evidence built for SI-3 generally supports it. Organizations working under SP 800-171 for contract purposes should still check the requirement's own wording and their assessment procedures, because the contracting authority decides which evidence is acceptable. Map the same endpoint and entry point records to both controls, and keep a note of any scope difference, such as systems that handle controlled unclassified information but sit outside a FedRAMP boundary.

What should we ask a partner to include in a written SI-3 scope?

A written scope should name the systems, endpoints and entry and exit points in boundary, the malicious code protection products already in use, and the evidence each deliverable will produce. Ask the partner to list:

The configuration baseline for scanning, updates and alert routing
The record types and retention period for update, scan and false positive logs
Who owns each step, including the organization's policy and response decisions
Acceptance criteria tied to the SI-3 determination statements
Recurring tasks for annual assessment support

DeployOpen plans, implements and documents self-hosted platforms in the client's own infrastructure and prepares evidence for assessments, but does not issue audit reports or certifications. Fees follow from the written scope.

How DeployOpen scopes and prepares SI-3 evidence

DeployOpen plans and implements self-hosted open-source tooling that produces malicious code protection evidence inside your own infrastructure. We prepare the mechanisms, configuration and records that an assessor will examine for SI-3, while your organization owns the control and the independent assessor reaches its own conclusions.

How we scope

Agree in writing which systems, endpoints and network entry and exit points fall within the SI-3 boundary.
Confirm which SI-3 parameters your organization must define, such as scan frequency and update cadence, before build work starts.
Document which parts of SI-3 your team retains and which parts the implementation partner prepares, so ownership is unambiguous.

How we build

Deploy self-hosted malware detection and endpoint telemetry components within your cloud accounts, data centers or air-gapped networks.
Configure automatic signature or detection content updates and record update history in a form an assessor can examine.
Set up scan schedules, real-time scanning, alerting to defined personnel and quarantine or blocking actions, then test each path.

How we hand over

Deliver configuration baselines, scan result exports and update records that map to the SI-3 determination statements in SP 800-53A.
Document false positive handling, including who reviews exceptions, how they are approved and how they are closed.
Provide runbooks so your staff can operate the tooling after handover, and confirm which evidence your independent assessor will request.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
Review scan coverage and update records on an agreed schedule so gaps appear before an assessment.
Keep the SI-3 evidence set current when systems change, and reassess scope when new entry points are added.