SI.L2-3.14.2Malicious Code Protection [CUI Data]
Provide protection from malicious code at designated locations within organizational systems.
[a]
designated locations for malicious code protection are identified; and[b]
protection from malicious code at designated locations is provided.
Designated locations named on paper: endpoints, mail, portal uploads, and the build tier
Implementation
AO coverage. Addresses both Malicious Code Protection objectives: the designated locations are identified, and protection is provided at each of them.
Designated locations identified [a]. Rather than “we run antivirus,” the standard names five entry points where malicious code realistically enters this environment: (1) managed endpoints, Windows and macOS alike; (2) the mail path, before delivery; (3) the customer file-drop portal, where untrusted files arrive from outside; (4) the Linux CI runners that compile firmware and pull third-party packages; (5) removable media on the two hosts still permitted to mount it. Each location has a named owner and a stated mechanism.
Endpoints. Defender for Endpoint runs on every managed device with real-time protection, cloud-delivered protection, tamper protection, and network protection enabled. macOS runs the same platform's agent rather than being treated as exempt — a common gap in mixed fleets. Policy is deployed by MDM, and a device reporting the agent unhealthy or disabled loses CUI access through the compliance path.
Mail. Attachments and links are filtered before delivery, with unknown attachment types detonated in a sandbox and time-of-click link rewriting so a URL weaponized after delivery is still checked. Executable and script attachment types are blocked outright, with an approved transfer path documented for the rare legitimate case.
Portal uploads. Files arriving in the file-drop bucket are scanned before the enclave pull job retrieves them. A detection quarantines the object and notifies both the security queue and the internal requester; nothing infected reaches the labeled store because the scan is a precondition of the pull, not a follow-up.
Build tier. CI runners use on-access scanning plus dependency provenance checks: builds pull from an internal package mirror rather than directly from public registries, and the mirror is scanned. Runners are ephemeral, rebuilt from image per job, which limits persistence.
Removable media. The two hosts permitted to mount media force a full scan on insertion and block autorun.
Maintenance. Weekly agent-health report — coverage percentage, unhealthy agents, agents not reporting in 48 hours — with anything unresolved past three days becoming a ticket. Quarterly review of the designated-locations list against the current architecture, since a new data entry point is how coverage gaps appear. Detections are triaged under the incident response process.
Accepted gap. The lab CNC controller runs an unsupported OS with no compatible agent. It is air-gapped from the enclave, files reach it only from a scanned staging share via a controlled one-way copy, and the exception is reviewed annually.
What the evidence looks like
- Written list of designated locations with the mechanism and owner for each
- Endpoint protection policy export covering both Windows and macOS
- Mail filtering policy showing detonation, link protection, and blocked attachment types
- Portal upload scanning configuration and a sample quarantine notification
- Weekly agent-health / coverage report with open remediation tickets
Environment
Tools
Was this example useful?
Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.
Discussion(0)
No discussion on this example yet
Verdicts capture a conclusion. Use a thread when the interesting part is the argument.
Sign in to start a thread.