SI-3 is the antimalware control. It asks you to put malicious code protection at system entry and exit points, keep it updated automatically, run periodic and real time scans, alert defined people when something is found, and deal with false positives and their effect on availability. NIST 800-53 binds US federal systems and, by contract, some others. For a small or mid size company it is a reference you can borrow when a customer or auditor asks how you stop malware.
What it asks
The statement breaks into these requirements:
- Deploy protection mechanisms at entry and exit points to detect and eradicate malicious code.
- Update the mechanisms automatically as new releases appear, following your configuration management procedures.
- Configure periodic scans of the system and real time scans of files from external sources as they are downloaded, opened or executed.
- Block or quarantine malicious code, and send alerts to defined recipients.
- Address false positives and their possible impact on availability.
Several values are organization defined: the scan frequency, the action taken, and who is alerted. You choose them and then have to meet them.
What it means in practice
NIST's guidance lists the entry and exit points: firewalls, remote access servers, workstations, email servers, web servers, proxy servers, notebooks and mobile devices. Malicious code includes viruses, worms, Trojan horses and spyware, and it can hide in compressed files or be concealed with techniques like steganography. It arrives by email, web and portable storage, and through the exploitation of system vulnerabilities.
That last point links SI-3 to flaw remediation. Patching reduces the ways malicious code gets in.
The guidance separates signature based and nonsignature based protection. Nonsignature approaches use heuristics, behavior and reputation to catch code with no signature yet, including polymorphic code that changes its signature when it replicates. A modern endpoint tool usually covers both, but you should know which of your tools does what.
For software teams there is a supply chain angle. Malicious code can arrive inside a dependency or a build tool, not only on a laptop. Scanning packages before adoption belongs in the same conversation.
Evidence to collect
- A list of entry and exit points and the protection deployed on each.
- Configuration exports showing automatic updates, scan schedules and real time scanning enabled.
- Console reports of coverage, showing which endpoints are protected and current.
- Alert routing configuration and examples of alerts that were triaged.
- The procedure for false positives, with a record of one being handled.
- Evidence for servers and cloud workloads, not only laptops.
Common gaps
- Coverage that stops at laptops, leaving servers, containers and mobile devices out.
- Definitions that update, but on endpoints that have not checked in for weeks.
- Alerts landing in a mailbox nobody reads.
- No false positive procedure, so staff disable protection to get work done.
- Email and web filtering counted as protection, but with no scanning of downloads or removable media.
- Nothing covering malicious packages in the software supply chain.
How to implement it
Take an inventory of the places files enter and leave: mail, web, endpoints, servers, build systems and removable media. Assign a tool to each, and write the gaps down honestly.
Turn on automatic updates and real time scanning, then verify coverage with a report. A monthly check for devices that have not reported in is a cheap and effective control.
Route alerts to a monitored queue with an owner. Write a short false positive procedure: who can allow a file, how it is recorded, and when it is reviewed.
If you have a lot of unmanaged devices, SI-3 pairs well with policies on device ownership and removable media. If you are ready for more, the enhancements add central management (SI-3.1), automatic updates (SI-3.2), non-privileged users (SI-3.3), updates only by privileged users (SI-3.4), portable storage devices (SI-3.5), testing and verification (SI-3.6), nonsignature based detection (SI-3.7) and detecting unauthorized commands (SI-3.8). Testing and verification is useful because it proves the tool actually fires.
Quick check
Is signature based antivirus enough for SI-3?
The base control does not demand a technology. The guidance describes both signature and nonsignature approaches, and enhancement SI-3.7 addresses nonsignature detection specifically.
Why does the control mention false positives?
Because a false positive can take down a legitimate file or service. The control wants a defined way to handle that so availability is not harmed and protection is not switched off.
