FC-04 · Malware Protection
Confluence page header block
Page title: FC-04 · Malware Protection
Parent page: 02 · Fundamental Controls
SCM variants: Default (all-staff) | isms-it-staff | isms-security
Page owner: IT Manager
Last reviewed: [DATE]
Next review: [DATE + 12 months]
Framework mapping panel
Visible to all users. Placed immediately below the page title as a metadata callout.
| Field | Value |
|---|---|
| CMMC Level 1 practices | SI.L1-3.14.2 · SI.L1-3.14.4 · SI.L1-3.14.5 |
| Cyber Essentials domain | Malware Protection — all requirements for endpoints, servers, and mobile devices |
| DEFSTAN 05-138 | Profile 0 (Baseline) — §Malware (AV on all capable systems, current signatures, real-time scanning) |
| ISO 27001 Annex A | 8.7 (Protection against malware) · 6.3 (Awareness — phishing and social engineering) |
| Related advanced pages | AT-SI · System and Information Integrity |
| All-staff guidance | 02 · Fundamental Controls → FC-04 (this page) · 04 · User Guidance Hub → Phishing and Suspicious Emails |
| Evidence items (IT/Security) | EV-D32 · EV-D19 · EV-D20 · EV-F01 · EV-F04 |
Why malware protection is the control that bridges human and technical risk
All-staff layer — visible to everyone.
Every other Fundamental Control in this section protects against attackers who are trying to break through barriers — a firewall at the network boundary, a password as the account gate, a configuration baseline as the floor below which settings cannot fall. Malware protection is different. It is the control that operates once something has already arrived. By the time the AV agent on your laptop is making a decision, a file is already there. The question is what happens next.
This makes malware protection the control that sits at the intersection of technical defence and human behaviour. The technical layer — the antivirus software, the email gateway scanning, the web proxy inspection — operates without your involvement and catches the majority of threats automatically. But it does not catch everything. Sophisticated phishing emails, zero-day exploits, and malware specifically crafted to evade signature-based detection all depend on a human decision somewhere in the chain. Someone clicked a link. Someone opened an attachment. Someone ignored a warning and approved a download.
The three CMMC Level 1 practices on this page — deploy malware protection, keep its definitions current, and run both scheduled and real-time scans — are the technical baseline. Cyber Essentials adds the requirement that this protection covers every device in scope, not just some of them, and that it is centrally managed. DEFSTAN Profile 0 requires that systems handling OFFICIAL information run malware protection with current signatures at all times, with no exceptions for servers or devices that are "rarely used" or "only on the internal network."
Understanding why the controls exist, and what role your behaviour plays alongside them, is what this page is for.
All-staff layer
No SCM variant wrapper — visible to isms-all-staff, isms-it-staff, and isms-security.
What the three CMMC Level 1 practices require
These three practices are among the four SI (System and Information Integrity) controls that the US Department of Defense considers baseline requirements for any organisation handling Federal Contract Information. They address the most universal threat to system integrity: malicious software.
SI.L1-3.14.2 — Provide protection from malicious code at appropriate locations.
Malware protection must exist at every location where malicious code could enter or execute. This means not just your laptop — it means the email gateway that receives messages before they reach your inbox, the web proxy that inspects outbound web traffic, the DNS resolver that can block resolution of known malicious domains, and the servers in the CUI environment. The control explicitly uses the phrase "appropriate locations" rather than "all endpoints" because the assessment is about coverage, not just about ticking a checkbox on one device type. An organisation with antivirus on workstations but none on servers, or on Windows devices but not on macOS, fails this control.
SI.L1-3.14.4 — Update malicious code protection mechanisms when new releases are available.
Protection that was current six months ago is materially less effective today. The threat landscape changes continuously — new malware variants are released constantly, and the AV vendor's response is to update the detection definitions. The control requires that those updates are applied when they are available, which in practice means automatic updates enabled rather than manual update processes that depend on an engineer remembering to run them. Signatures that are more than 24 hours old on an internet-connected device are treated as non-compliant with this control.
SI.L1-3.14.5 — Perform periodic scans and real-time scans of files from external sources.
This control has two distinct components that must both be implemented. Periodic scans are scheduled full-system scans that run even when the device is idle — they catch malware that may have arrived in a state that evaded real-time detection, malware that was dormant before activating, and threats introduced via paths the real-time scanner did not monitor at the time of arrival. Real-time scans happen at the moment a file from an external source is written to disk, opened, or executed — every file downloaded from the internet, every email attachment saved, every USB drive file accessed. Both are required. A device with only real-time scanning misses the periodic verification. A device with only scheduled scans creates a window between scans during which active malware can operate undetected.
Cyber Essentials — the malware protection requirements
Cyber Essentials defines malware protection as one of its five mandatory technical controls and is notably more prescriptive than NIST on what counts as adequate protection. The Cyber Essentials position is that malware protection must be demonstrably present and current on every in-scope device — there are no carve-outs for server operating systems, for devices that are "only on the internal network," or for devices where the operating system vendor considers built-in protections adequate.
Requirement 1: Malware protection is installed on all computers and servers.
Every device in scope — every Windows workstation, every macOS laptop, every Windows server, every Linux server capable of hosting malware protection software — must have malware protection software installed and active. The Cyber Essentials guidance specifically calls out that servers are included. A server running without AV because it is "only accessed by IT staff" or "on a protected network segment" does not satisfy this requirement.
For Linux systems, the historical argument that Linux does not need AV is not accepted by Cyber Essentials assessors. Linux servers are in scope, and while the threat landscape for Linux differs from Windows, the control requirement is explicit. The EDR platform deployed in this organisation covers Linux servers in addition to Windows and macOS endpoints.
Requirement 2: Malware protection software is kept up to date.
Anti-malware signatures — the detection database that allows the software to recognise known malware — must be updated automatically and within defined time limits. Cyber Essentials requires that signature updates happen within one month of release as an absolute minimum, but in practice daily or more frequent updates are the expectation for internet-connected devices. The organisation's requirement is that signatures are current within 24 hours. A device more than 24 hours behind on signatures is treated as non-compliant and is flagged in the monthly coverage report.
Engine updates — updates to the malware protection software itself rather than just its detection database — must also be applied promptly. An outdated engine may be unable to process the latest signature formats or may have its own vulnerabilities.
Requirement 3: Malware protection is configured to scan files automatically upon access.
This is the real-time scanning requirement from SI.L1-3.14.5. Every file that is accessed — opened, executed, saved — must be scanned before being permitted to run or be read. Malware protection software that only scans on demand, or that only scans files in specific locations rather than all file access, does not satisfy this requirement. Real-time scanning must be active and enforced — a user should not be able to disable it.
Requirement 4: Malware protection prevents connections to malicious websites.
Web-based malware delivery is the most common infection vector. The Cyber Essentials malware control extends beyond file-based scanning to include web filtering — blocking access to websites that are known to deliver malware, host phishing pages, or are used as command-and-control infrastructure. This is implemented via the web proxy and DNS filtering layer, which operates independently of the endpoint AV agent.
Requirement 5: Malware protection is centrally managed.
For organisations with more than one device, Cyber Essentials requires centralised management of malware protection. This means a management console that shows the protection status — coverage, signature currency, detected threats — for every enrolled device. It means policy enforcement that prevents individual users from disabling protection. And it means alerting when a device goes offline from the management platform or its signatures fall out of date, because an unmanaged device is an unmonitored device.
DEFSTAN Profile 0 — baseline malware requirements for defence work
DEFSTAN 05-138 Profile 0 §Malware sets the minimum malware protection requirement for all systems handling OFFICIAL-tier information. For defence contract work, the OFFICIAL classification covers most of what we handle, and Profile 0 is the floor from which all our DEFSTAN obligations begin.
Profile 0 requires anti-malware software on all systems capable of supporting it.
The phrase "capable of supporting it" is the DEFSTAN qualifier. In practice, this means every Windows system, every macOS system, and every Linux system running a general-purpose operating system. Purpose-built embedded systems, industrial control systems, and some network appliances may fall outside this requirement — but every general-purpose computing device that handles OFFICIAL information is in scope. DEFSTAN assessors will ask about any system that does not have AV and require a documented justification for its absence.
Profile 0 requires that anti-malware signatures are current at all times.
Current is not defined as a specific number of days in Profile 0, but the expectation is consistent with Cyber Essentials — daily or more frequent automatic updates for internet-connected systems. For isolated or air-gapped systems that cannot receive automatic updates, DEFSTAN requires a documented offline update procedure with a defined update interval. The organisation's 24-hour signature currency standard exceeds what DEFSTAN Profile 0 explicitly mandates and is therefore fully compliant.
Profile 0 requires that real-time scanning is active.
On-access scanning — the AV agent checking every file as it is opened or executed — must be active on all OFFICIAL-scope systems. Disabling real-time scanning, even temporarily for performance reasons or to allow a specific installation, is not permitted without explicit CISO approval and an entry in the exception register. A device with real-time scanning disabled is not in a Profile 0 compliant state for that period.
Profile 0 requires that malware protection cannot be disabled by the user.
The tamper protection requirement: end users must not be able to disable, uninstall, or circumvent the malware protection software. This is technically enforced via MDM tamper protection on Windows (Microsoft Defender Tamper Protection) and MDM configuration profiles on macOS, and via the EDR agent's own anti-tamper mechanism. A user who attempts to disable the AV agent receives an error indicating that the action is blocked by policy, and the attempt is logged to the SIEM.
Profile 0 and removable media:
DEFSTAN Profile 0 makes a specific reference to removable media in the malware context. Any removable media — USB drives, external hard drives, optical discs — that is connected to an OFFICIAL-scope system must be scanned before files from it are accessed. The real-time scanning requirement satisfies this in most cases, but the DEFSTAN requirement is also interpreted to mean that the system should not auto-execute files from removable media (AutoRun/AutoPlay disabled) and that the security team should be informed when removable media is connected to CUI-scope systems. The USB monitoring alerts in the SIEM satisfy this visibility requirement.
How malware actually arrives — what you need to understand
The technical controls described on this page are effective. The email gateway blocks the majority of malicious attachments before they reach your inbox. The web proxy blocks access to most malicious websites. The EDR agent detects and quarantines most malware that reaches your device. But none of these controls are perfect, and understanding the gaps helps you fill them.
Email is the primary delivery mechanism. The majority of malware infections in organisations begin with an email. Phishing emails — messages designed to look legitimate that contain malicious attachments or links to malicious websites — are the single most common entry point. The email gateway scans attachments and inspects links, but targeted phishing emails crafted specifically for our organisation, using information gathered from public sources, may use techniques that evade automated scanning. Your judgment is the last line of defence.
The signals that an email is a phishing attempt are documented in detail in the User Guidance Hub → Phishing and Suspicious Emails. The most important signals to know are: unexpected urgency, a sender address that does not quite match who it claims to be, links that go somewhere different from what the text suggests, and attachments you were not expecting. None of these signals is definitive on its own, but together they should trigger a pause before you act.
Malicious websites deliver malware without any obvious download. Browser-based malware delivery — sometimes called drive-by download — can install malware simply by visiting a page, without any action on your part. The web proxy and DNS filtering block access to known malicious sites, but new malicious infrastructure appears constantly and may not be blocked immediately. Being cautious about which websites you visit on a company device, and avoiding sites that seem unusual or that you navigated to via an unexpected link, reduces your exposure.
USB drives and removable media are a physical attack vector. A USB drive found in a car park, left on a desk by a visitor, or handed over by a supplier for "convenience" is one of the oldest and most reliable attack methods. The AV agent will scan files from any USB drive before they execute, and USB storage is restricted on CUI-scope systems, but physical media carries risks that justify a blanket rule: do not plug any USB drive you did not personally receive from IT Operations into a company device.
Malware that evades detection may be present for a period before it is identified. The scheduled periodic scan exists specifically to catch malware that arrived in a state that evaded real-time detection. If your device is behaving unusually — running slowly for no apparent reason, generating unexplained network activity, displaying strange pop-ups, or behaving in ways it did not previously — report it to IT Operations even if no antivirus alert has fired. You may be observing the behavioural indicators of malware that has not yet been detected by signatures.
What this means for you — all-staff obligations
Your obligations under this control are largely behavioural rather than technical. The software does the technical work. Your role is to not undermine it and to support it when something goes wrong.
Never disable or attempt to disable the antivirus or EDR agent on your device. The agent runs continuously and may occasionally cause a small performance impact on your device. If the impact is significant enough to affect your work, report it to IT Operations — do not disable the agent. A disabled AV agent is not just a compliance violation; it is an open door.
Do not attempt to add exclusions to the AV agent without IT Operations approval. If the AV agent is blocking a file or application that you believe is legitimate, contact IT Operations. They will assess whether the detection is a false positive and, if so, add a properly scoped and documented exclusion. Self-service exclusions are not permitted — they can silently exempt entire directories from scanning.
When you receive an AV alert, treat it as real until IT Operations confirms otherwise. An alert that says a file has been quarantined or that malicious activity has been detected is not something to dismiss or work around. Note the details — what was detected, what file or activity was involved, what time it appeared — and contact IT Operations immediately. The security team needs to know about every detection, even the ones that appear to resolve themselves.
Apply updates when prompted. The signature update requirement (SI.L1-3.14.4) depends on devices being able to update automatically, but some updates require a restart to complete the installation. When your device prompts you to restart to apply security updates, treat this as a priority rather than something to defer. The update includes the latest detection capabilities.
Report anything suspicious about your device's behaviour. Slow performance without explanation, pop-ups that are unfamiliar, files that have been renamed or moved, applications that launch unexpectedly — these are behavioural indicators that something may be wrong. Do not wait for an AV alert. If something feels unusual, report it.
Do not connect USB drives from unknown sources to company devices. This includes drives provided by visitors, found drives, and drives from any external party that have not been confirmed clean by IT Operations.
If you receive an unexpected download prompt, security warning, or pop-up asking you to install something: do not click through it. Close the browser tab or window and report the URL you were visiting to IT Operations. Drive-by download attempts often present as fake security warnings or software update prompts.
What to do if something goes wrong
Your device displays an antivirus alert or quarantine notice. Note the details and contact IT Operations immediately. Do not delete the quarantine notification, do not try to restore the quarantined file, and do not continue using the device for sensitive work while waiting for IT Operations to respond. IT Operations will tell you whether the detection is a true positive or a false positive, and what steps to take.
You click a link or open an attachment and something unexpected happens — the file does not open normally, a program launches, your device becomes slow, or an unusual window appears. Stop immediately. Do not close windows, restart the device, or delete files. Call IT Operations. Preserving the current state of the device allows the security team to investigate what happened and contain any infection before it spreads.
Your device shows a ransomware notice — a screen or message saying files have been encrypted and payment is required. Disconnect from the network immediately: unplug the ethernet cable or turn off Wi-Fi. Then call IT Operations and the security team. Do not pay. Do not turn the device off unless IT Operations instructs you to. The network disconnect is the critical step — ransomware typically attempts to spread to network shares and other connected devices, and disconnecting limits that spread.
You notice a colleague's device behaving strangely — unusual pop-ups, unexplained slowness, the AV agent showing as disabled. Tell them to contact IT Operations immediately and do not access any shared drives from that device while the investigation is underway. A device that is infected with malware and connected to the network is a potential source of infection for shared resources.
You realise you may have introduced malware from a USB drive or external source. Report it immediately and do not use the device until IT Operations has cleared it. The AV agent may not have detected anything, but that does not mean nothing arrived — report the event so the security team can investigate.
IT-staff layer
SCM variant: isms-it-staff — visible to isms-it-staff and isms-security.
{scroll-content:variant=isms-it-staff}
Technical implementation — IT Operations
This section provides the full implementation specification for SI.L1-3.14.2, SI.L1-3.14.4, and SI.L1-3.14.5 across all platform types, the Cyber Essentials malware protection requirements, and the DEFSTAN Profile 0 §Malware baseline. Full integration with the SI family advanced controls (monitoring, alerts, threat intelligence) is documented in AT-SI. This page covers the fundamental tier obligations, platform-by-platform deployment specifications, and the coverage verification procedure.
SI.L1-3.14.2 — Technical implementation: deployment specification by platform
What assessors test: Assessors will request the EDR management console coverage report. They will look for any in-scope device not shown as enrolled. They will check whether the server fleet is covered, not just workstations. They will verify the email gateway and web proxy configurations include malware scanning. They may select a device at random and verify the agent is running and tamper-protected.
EDR platform: [product name — e.g. Microsoft Defender for Endpoint /
CrowdStrike Falcon / SentinelOne / Sophos Intercept X — specify]
Management console URL: [internal console URL]
Management authentication: PAM-mediated — privileged account checkout required
CISO + IT Manager = console admin access (maximum 2)
IT Operations = analyst/read access via named individual accounts
Coverage requirement:
100% of CUI-scope endpoints: Windows workstations, macOS workstations, mobile
100% of CUI-scope servers: Windows Server, Ubuntu Linux, any additional Linux distros
0 exceptions permitted for CUI-scope systems without: CISO approval + compensating
control documentation + exception entry in EV-D08
Windows (workstations and servers):
Primary platform: Microsoft Defender for Endpoint (integrated with Intune)
OR [third-party EDR product]
Deployment method: Intune → Endpoint Security → Antivirus policy
OR SCCM package deployment
OR third-party EDR onboarding script via Intune PowerShell
Required policy settings (Intune → Endpoint Security → Antivirus):
Microsoft Defender Antivirus:
Turn off Microsoft Defender Antivirus: Not configured (Defender stays ON)
Turn off real-time protection: Not configured (real-time stays ON)
Turn on behaviour monitoring: Enabled
Enable network protection: Enabled — Block mode
Enable potentially unwanted application (PUA) protection: Block
Cloud-delivered protection:
Cloud-delivered protection level: High
Automatic sample submission: Enabled
Tamper protection (critical — prevents user disabling):
Tamper protection: Enabled
Enforcement: via Intune/MDE integration — cannot be overridden from local settings
Real-time scanning:
Scan all downloaded files and attachments: Enabled
Monitor file and program activity on your computer: Enabled
Enable raw volume write notifications: Enabled
Scheduled scan:
Scheduled scan type: Full scan
Day to run scheduled scan: Sunday (or Saturday — weekend off-peak)
Time of day: 02:00 local time
Reduce scan priority: Enabled (limits CPU impact during business hours
if the scheduled scan runs over into working hours)
Verify deployment:
MDE portal: Devices → Device inventory → filter by OS
Expected: every CUI-scope Windows device shows:
Onboarding status: Onboarded
Sensor health state: Active
Antivirus status: No issues
PowerShell verification on sample device:
Get-MpComputerStatus | Select-Object -Property `
AMRunningMode, AntivirusEnabled, BehaviorMonitorEnabled, `
IoavProtectionEnabled, RealTimeProtectionEnabled, `
AMTamperProtectionEnabled, AntispywareSignatureLastUpdated
Expected values:
AMRunningMode: Normal
AntivirusEnabled: True
BehaviorMonitorEnabled: True
IoavProtectionEnabled: True (on-access file scanning)
RealTimeProtectionEnabled: True
AMTamperProtectionEnabled: True
AntispywareSignatureLastUpdated: within past 24 hours
Windows Server-specific considerations:
Windows Server Core (no GUI): Defender managed via PowerShell or
third-party EDR agent deployed via package manager
Server roles: same Intune policy applies; scheduled scan during
maintenance window (aligned with AT-CM BL-WINSRV baseline)
Performance impact: use ExclusionExtension and ExclusionProcess sparingly
for documented legitimate performance exceptions only — never ExclusionPath
on broad paths like C:\Users or the entire data volume
Server 2022 with Defender: runs in Passive mode when a third-party AV
is also installed — if using third-party EDR on servers, confirm Defender
is not creating a conflict (check: Get-MpComputerStatus → AMRunningMode)
macOS (workstations):
Primary platform: [Microsoft Defender for Endpoint macOS / CrowdStrike Falcon macOS /
Sophos for Mac — specify deployed product]
Deployment method: Jamf Pro configuration profile + package deployment
OR Microsoft Intune macOS policy
Configuration profile payload requirements:
System extension: approved for the EDR vendor's kernel extension
Full disk access: granted to the EDR agent process
(Required for on-access scanning of all file system paths including
the user home directory and application containers)
Privacy preferences: accessibility permissions granted
Without Full Disk Access granted via MDM: the agent cannot scan files
in protected locations (Mail attachments, Safari downloads, iCloud Drive) —
this is one of the most common macOS EDR coverage gaps
Verify deployment:
Jamf: Computers → Smart Group "CUI-Scope-macOS-AV-NonCompliant"
Criteria: [EDR agent process] is not running
Expected: zero members in this smart group
Command line verification on sample device:
ps aux | grep [EDR agent process name]
Expected: agent process running
[EDR vendor CLI command for status — specify for deployed product]
Expected: Protection: Enabled, Signatures: Current, Engine: Current
Scheduled scan:
macOS EDR platforms: typically implement scheduled scan via MDM policy
Schedule: Sunday 02:00 (configured via Jamf policy or MDM profile)
Full system scan: enabled (scans all mounted volumes including Time Machine
if connected — Time Machine drives are a known malware reservoir)
Verify: [EDR vendor command to show scheduled scan status]
Tamper protection (macOS equivalent):
macOS MDM profile: managed configuration prevents uninstallation
MDM restriction profile → restrictUsersFromInstallingProfiles: true
System extension protection: kernel extension cannot be removed without
entering Recovery Mode — not accessible to standard users
Additionally: Gatekeeper and SIP (System Integrity Protection) provide
OS-level tamper resistance for the EDR kernel extension
Verify SIP is enabled (prerequisite for tamper resistance):
csrutil status → "System Integrity Protection status: enabled."
If disabled: this is a BL-MAC baseline violation — remediate immediately
Linux servers (Ubuntu 22.04 LTS):
Primary platform: [Microsoft Defender for Endpoint Linux / CrowdStrike Falcon Linux /
Sophos Antivirus for Linux / ClamAV (open source — minimum standard) —
specify deployed product]
Deployment method: Ansible role — av_agent
Package manager repository configuration → install → configure → service enable
Example Ansible tasks:
# Add vendor repository
- name: Add [EDR vendor] repository
apt_repository:
repo: [vendor apt source]
state: present
# Install agent
- name: Install [EDR agent package]
apt:
name: [package-name]
state: present
update_cache: yes
# Enable and start service
- name: Enable and start [EDR service]
systemd:
name: [service-name]
state: started
enabled: yes
# Verify agent is running
- name: Verify agent status
command: [vendor CLI status command]
register: agent_status
failed_when: "'enabled' not in agent_status.stdout"
On-access scanning configuration (Linux):
On-access scanning requires a kernel-level hook — this is provided by
the commercial EDR agents and by ClamAV's clamonacc daemon
ClamAV on-access configuration (/etc/clamav/clamd.conf):
OnAccessIncludePath /home
OnAccessIncludePath /var/www
OnAccessIncludePath /opt/[application-paths]
OnAccessExcludeUname clamav (prevent scanning of ClamAV's own files)
OnAccessPrevention yes
OnAccessExtraScanning yes
Commercial EDR: on-access is typically enabled by default; verify in console
Scheduled scan (Linux):
ClamAV: cron job or systemd timer
# /etc/cron.d/clamav-weekly:
0 2 * * 0 root /usr/bin/clamscan -r --quiet --infected \
--log=/var/log/clamav/weekly-scan.log \
--exclude-dir=/proc --exclude-dir=/sys --exclude-dir=/dev \
/home /opt /var /srv
Commercial EDR: scheduled scan configured via management console
Verify deployment (Ansible check playbook):
- name: Check AV agent service status
systemd:
name: [service-name]
register: service_status
failed_when: service_status.status.ActiveState != "active"
Include in weekly Ansible drift detection run (FC-02 OP-03 procedure)
Any server where AV agent is not active: SIEM alert + IT Operations ticket
Email gateway (SI.L1-3.14.2 — network layer malware protection):
Platform: [Microsoft Defender for Office 365 / Proofpoint / Mimecast /
Sophos Email Security — specify]
Integration: MX record points to gateway; gateway delivers to Exchange Online/on-prem
Required capabilities:
Attachment scanning: all attachment types; detonation in sandbox for:
Executable types: .exe, .com, .bat, .cmd, .ps1, .vbs, .js, .wsf, .hta
Office types with macros: .xlsm, .xlsb, .docm, .pptm
Compressed archives: .zip, .7z, .rar, .gz (scan contents recursively)
PDF: scan for JavaScript, embedded executables, embedded URLs
Zero-day attachments (sandbox detonation):
Files that do not match any known malicious signature are detonated
in an isolated cloud sandbox before delivery
Delivery delay: [vendor-specific — typically 1–5 minutes]
If detonation identifies malicious behaviour: block + quarantine
If inconclusive after [N] minutes: deliver with warning header
Link rewriting and time-of-click scanning:
All URLs in email body: rewritten to pass through gateway's URL scanner
Time-of-click scan: when the user clicks the link, the URL is checked
again at click time (not just at delivery time) — catches URLs that
were safe at delivery but became malicious after the email arrived
Anti-spoofing:
DMARC: reject or quarantine on DMARC fail
DKIM: verify signatures; treat failure as spam indicator
SPF: verify; treat fail as spam indicator
Sender intelligence: block known phishing infrastructure
Verify email gateway configuration:
Send test messages with EICAR test string in various containers
Send test messages with known-malicious URL (AMTSO test URLs)
Confirm: test messages are quarantined, not delivered
Monthly: review quarantine queue for false positives (legitimate mail quarantined)
Review frequency: weekly during initial deployment; monthly once stable
Web proxy and DNS filtering (SI.L1-3.14.2 — network layer):
Web proxy platform: [Zscaler / Cisco Umbrella / Squid + blocklist /
FortiProxy / Palo Alto URL filtering — specify]
Required categories blocked:
Malware: block (sites hosting malware for download)
C2/Botnets: block (known command-and-control infrastructure)
Phishing: block (confirmed phishing pages)
Dynamic DNS: block (commonly used by malware for C2 evasion)
Newly registered domains: block or warn (domains <30 days old — high malware association)
Anonymous proxy/VPN: block (attempts to circumvent the proxy itself)
Note on TLS inspection:
Most malware delivery is now over HTTPS
TLS inspection (break-and-inspect) is required for effective web malware scanning
TLS inspection requires: a trusted internal CA cert deployed to all managed devices
(via MDM/GPO) so that the proxy's re-signed certificates are trusted by browsers
Configure TLS inspection exclusions for: banking sites, medical sites,
authenticated government portals (where local data protection law restricts)
All TLS inspection configuration: change managed via RFC
DNS filtering layer:
Platform: [Cisco Umbrella DNS / Cloudflare Gateway / NextDNS — specify]
Configuration: all CUI-scope systems use internal DNS resolver
which forwards to the DNS filtering service
DNS filtering blocks resolution of known-malicious domains at the
DNS layer — before a TCP connection is established
This provides protection even for traffic that bypasses the HTTP proxy
(e.g. non-browser applications, malware that connects directly)
DNS filter categories: same as web proxy categories (malware, C2, phishing)
SIEM integration:
DNS query logs forwarded to SIEM
Alert rule: DNS query to domain on threat intelligence blocklist → Medium alert
Alert rule: High volume NXDOMAIN responses from single host → Medium alert
(DGA/malware C2 detection indicator)
Mobile devices:
Platform: [MDM-enforced mobile security app — Lookout / Zimperium /
Microsoft Defender for Mobile — specify]
Deployment: MDM compliance policy — app must be installed and reporting clean
for device to be granted CUI resource access via Conditional Access
Capabilities: app scanning; web browsing protection; network protection;
jailbreak/root detection
Jailbroken/rooted device: Conditional Access blocks all company resource access
until the device is remediated or unenrolled
SI.L1-3.14.4 — Technical implementation: signature and engine update management
What assessors test: Assessors will check signature ages in the EDR console for a sample of devices. They expect to see all devices current within 24 hours. They will also check whether an update failure generates an alert — the management visibility question.
Signature update architecture:
Windows (Defender for Endpoint / Intune):
Source: Microsoft Update → Windows Update for Business → Device
Frequency: Multiple times per day (Microsoft releases definitions
multiple times daily — Defender pulls on each check-in)
Fallback: MMPC (Microsoft Malware Protection Center) cloud lookups
Policy verification:
Get-MpPreference | Select-Object SignatureUpdateInterval
Expected: 1 (check every hour) or 2 (check every 2 hours — acceptable)
Get-MpComputerStatus | Select-Object `
AntispywareSignatureLastUpdated, `
AntispywareSignatureVersion, `
AntivirusSignatureLastUpdated, `
AntivirusSignatureVersion
Expected: LastUpdated = within past 24 hours
macOS ([EDR product]):
Update mechanism: vendor cloud — agent polls on defined interval
Interval: [vendor default — confirm ≤4 hours in policy]
Verify:
[Vendor CLI command] --version (shows signature version and date)
Or: management console → Devices → [device] → Signatures → Last updated
Linux ([EDR product] or ClamAV):
ClamAV freshclam service:
/etc/clamav/freshclam.conf:
DatabaseMirror database.clamav.net
Checks 24 (check for updates 24 times per day = hourly)
Service: freshclam — verify running and enabled
Verify: freshclam --version / freshclam --list-mirrors
Log: /var/log/clamav/freshclam.log — check for "Database updated" entries
Commercial EDR: vendor-managed; verify in management console
Email gateway:
Update mechanism: continuous cloud-delivered updates (vendor managed)
No manual intervention required
Verify: vendor management console → Health → Signature definitions → Last updated
Alert if: definitions not updated within [vendor-defined SLA — typically 1 hour]
Update failure detection and alerting:
SIEM alert rule: "AV signatures not updated within 24 hours"
Source: EDR management console API → SIEM (via custom connector or export)
OR Windows: Event 1116 (malware detected) / Event 1006 (scan failed due to
signature issue) forwarded to SIEM
More reliable: MDM compliance policy
Intune compliance policy:
Antivirus: Required
Microsoft Defender Antimalware security intelligence up to date: Required
If policy fails: device marked Non-Compliant
Conditional Access: Non-Compliant device loses access to CUI resources
SIEM: compliance state change event from Intune → alert
Alert threshold:
Device with signatures >24h old: IT Operations ticket (P3 — resolve within 1 business day)
Device with signatures >72h old: escalate to IT Manager; consider network isolation
Device with signatures >7 days old: CISO notification; mandatory network isolation
from CUI segment until remediated
Engine/product version updates:
Windows: engine updates delivered via Windows Update on the same channel as definitions
macOS: [EDR vendor] releases engine updates as full package updates via Jamf/Intune
Linux: package manager update (apt upgrade [package-name])
Engine update procedure:
Treat as a Normal change (RFC required — AT-CM change process)
Exception: if the vendor marks the engine update as a Critical security fix,
treat as Standard change (pre-approved) and apply within 7 days
Staging: deploy to 10% of devices in ring 1 → verify no issues for 48 hours
→ deploy to 50% → 100%
Rollback: Intune policy or Jamf policy allows rollback to previous version
if ring 1 reveals a compatibility issue
SI.L1-3.14.5 — Technical implementation: periodic and real-time scan configuration
What assessors test: Assessors will use the EICAR test file to verify real-time scanning catches a known test pattern on a sample device. They will check the scheduled scan configuration in the EDR console. They will ask how you verify that all devices have completed their periodic scans.
EICAR test file — assessor demonstration preparation:
The EICAR test file is the industry-standard method for verifying real-time
scanning without using real malware:
Standard EICAR string:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Save as: eicar.com (or eicar.txt — real-time scanning catches both)
Expected result: AV agent detects and quarantines immediately
(within seconds of the file being written to disk)
AV alert: "Threat found: EICAR-Test-File" or equivalent
Evidence: AV console shows detection event with timestamp, device, file path
IMPORTANT: only run EICAR on a dedicated test device or with IT Manager
confirmation that the alert will not trigger an incident response activation
Real-time scan scope and coverage:
Windows — what "on-access" covers:
File system writes (files saved from any application)
File execution (any process launch)
Email attachment saves (Outlook → file system scan on save)
Browser downloads (file written to downloads folder — scanned on write)
USB drive content (file access on removable media — scanned on access)
Verify scope (PowerShell):
Get-MpPreference | Select-Object -Property `
DisableIOAVProtection, (should be False — IOAV = Internet-based scan)
DisableRealtimeMonitoring, (should be False)
DisableRemovableDriveScanning (should be False)
All values should be False (i.e. the protection is NOT disabled)
macOS — on-access scan scope:
All file system paths where Full Disk Access is granted
Requires: Full Disk Access granted to EDR agent via MDM profile
Without FDA: files in ~/Library/Mail, ~/Downloads, iCloud Drive sync folders
are NOT scanned — critical gap for email attachment delivery
Verify FDA is granted:
Jamf: check configuration profile includes FDA entry for EDR process
System Settings → Privacy & Security → Full Disk Access →
[EDR agent process]: ✓ (green tick)
If not present: MDM profile not applied or requires re-enrolment
Linux — on-access scan coverage:
Commercial EDR: covers most filesystem access via kernel module
ClamAV clamonacc: covers specified OnAccessIncludePath directories
Critical paths to include:
/home (all user home directories — file downloads and personal files)
/var/www (web server content — uploaded file injection via web app)
/opt /srv (application directories — software drop and execute attacks)
/tmp /var/tmp (common malware staging locations)
Do NOT include (causes performance issues without security benefit):
/proc /sys /dev (virtual filesystems — no files to scan)
/var/lib/docker (container layers — scan via container security instead)
Scheduled (periodic) scan configuration:
Windows (via Intune/GPO):
Schedule day: Sunday
Schedule time: 02:00 local (after midnight; before business hours)
Scan type: Quick scan weekly; Full scan monthly
Quick scan: checks running processes, startup items, registry, common
malware locations — fast (5–15 minutes)
Full scan: every file on every connected drive — slow (1–6 hours depending
on drive size; runs in reduced-priority mode)
Monthly full scan schedule via Intune:
ScheduleMonthlyQuickScanDay: set to run on first Sunday of month at 01:00
Verify scan completion:
Get-MpComputerStatus | Select-Object LastFullScanTime, LastQuickScanTime
QuickScanTime: within past 7 days
FullScanTime: within past 30 days
If not: device not completing scheduled scans — investigate (hibernation?
device powered off during scan window? scan aborted due to low battery?)
EDR console: Health → Scan health → filter for devices not completing scans
This view shows devices that have not had a successful scan within the SLA
macOS:
Scheduled scan configured via MDM or [EDR vendor] management console
[Vendor-specific scheduling command or MDM payload]
Verify: management console → [device] → Last scanned: within past 7 days
Linux:
ClamAV scheduled scan via cron (see deployment section above)
Verify: /var/log/clamav/weekly-scan.log → contains "scan completed" entry
from within the past 7 days
If using commercial EDR: management console shows last scan completion
Cyber Essentials — technical verification checklist
Cyber Essentials malware protection is assessed during CE+ via direct
device inspection. Prepare a demonstration device of each OS type.
CE-MAL-1: AV software installed and active on all in-scope devices
Verification query (for CE scope definition):
"All devices in the CE scope" = all company-managed devices that
connect to your network OR access internet services
Prepare:
- Complete device inventory (EV-D22) showing all CE-scope devices
- EDR management console showing all devices with status "Active/Healthy"
- Reconcile: every device in EV-D22 should appear in the EDR console
- Any device in EV-D22 not in EDR console: finding — investigate immediately
Personal devices used for work (BYOD):
If any personal devices access company email, SharePoint, or other
company services: they are CE scope
Options:
Option 1: require company-approved AV on personal devices (verify via
Conditional Access device compliance — non-compliant → no access)
Option 2: prohibit personal devices from accessing CE-scope services
(and actually enforce this with Conditional Access)
If personal devices are in use without verified AV: CE finding
CE-MAL-2: Signatures updated automatically
For each OS type in scope, demonstrate:
Windows: Get-MpComputerStatus → AntispywareSignatureLastUpdated
macOS: [vendor CLI command] → signature version and date
Linux: cat /var/log/clamav/freshclam.log | tail -20 (shows recent updates)
Show automatic update mechanism is configured (not manual)
Acceptable: any signature update within past 24 hours from an automated source
If signatures are older than 24 hours on any device:
This is a CE finding regardless of the reason
Remediate before CE assessment: force signature update on all devices
Windows: Update-MpSignature
macOS: [vendor CLI update command]
Linux: freshclam
CE-MAL-3: Real-time scanning is enabled and cannot be disabled by the user
EICAR test: on a sample Windows device, attempt to save the EICAR test file
Open Notepad → paste EICAR string → Save As eicar.com to Desktop
Expected: AV alert immediately; file quarantined before it can be accessed
If the file saves without alert: real-time scanning is NOT active — finding
Tamper protection test: on a sample Windows device, attempt to disable Defender
Settings → Windows Security → Virus & threat protection →
Virus & threat protection settings → Real-time protection → toggle off
Expected: toggle is greyed out / returns to On immediately / error message
If the toggle can be turned off by the user: tamper protection is NOT enabled — finding
PowerShell disable attempt: attempt from a standard user account
Set-MpPreference -DisableRealtimeMonitoring $true
Expected: "Operation failed with the following error: 0x800704EC"
or "Access Denied" — the command is blocked
If the command succeeds: running as admin account; re-test from standard user account
CE-MAL-4: Web filtering / malware site blocking
Test: browse to AMTSO threat test sites from a managed device
URL: https://www.amtso.org/security-features-check/
Use: "Malware Download Protection" and "Potentially Unwanted Applications" tests
Expected: browser shows a blocked page warning (from proxy or EDR browser extension)
If the test file downloads: web malware filtering is not functioning — finding
Verify web proxy is configured for all in-scope devices:
All browsers use the proxy: confirmed via GPO/MDM proxy settings
Bypass list: review — any bypass should be documented; broadly bypassed
devices are not covered by web filtering
CE-MAL-5: Central management
Prepare for assessor review of EDR management console:
Coverage percentage: show overall device coverage (target: 100%)
Signature currency: show percentage of devices with signatures <24h old (target: 100%)
Recent detections: show last 30 days of detections and their disposition
Policy compliance: show any devices marked as non-compliant and the reason
The assessor may ask: "What happens if a device goes offline for a week
and comes back with outdated signatures?"
Answer: MDM compliance policy marks the device non-compliant; Conditional
Access denies access to company resources until the device checks in and
signatures are updated; device is prompted to update on next connection
to a network with internet access
DEFSTAN Profile 0 — specific verification procedures
Profile 0 §Malware examination by contracting authority:
DEFSTAN-MAL-1: AV on all OFFICIAL-scope systems
Prepare: list of all systems handling OFFICIAL information (from SSP system boundary)
Show: each system on the list appears in the EDR management console with
status "Protected" or equivalent
For Linux servers: show the Ansible playbook confirming AV is installed and
running as a managed service; show systemctl status for the agent
Any system on the OFFICIAL-scope list not showing in EDR console:
Investigate: is it a false absence (enrolled but showing differently)?
Or a real gap: deploy immediately; create EV-D08 exception record for
the period the gap existed; CISO risk assessment
DEFSTAN-MAL-2: Signatures current at all times
Show: EDR console → all OFFICIAL-scope devices → signature age
Expected: all within 24 hours
For systems that are not always internet-connected (servers in isolated segments):
Verify: WSUS/SCCM or equivalent distribution point delivers signature
updates to isolated systems
If truly air-gapped: document offline update procedure and evidence of
execution (freshclam logs or equivalent)
DEFSTAN-MAL-3: Real-time scanning active and tamper-protected
Show: Get-MpComputerStatus on OFFICIAL-scope servers and workstations
Expected: RealTimeProtectionEnabled = True; AMTamperProtectionEnabled = True
For Linux: show that the AV service is protected against user termination
Standard user cannot stop the service:
sudo systemctl stop [av-service] (requires sudo — standard user cannot)
Or: service file has ProtectSystem = strict or ProtectKernelTunables = true
Or: commercial EDR has its own anti-tamper mechanism
DEFSTAN-MAL-4: Removable media is scanned
Show: GPO/MDM setting confirming USB storage scan is enabled
Windows: Get-MpPreference | Select DisableRemovableDriveScanning
Expected: False (removable drive scanning is NOT disabled)
Show: USB insertion generates a SIEM log event (demonstrates monitoring)
Insert a clean USB drive on a CUI-scope device
Confirm: SIEM receives an event within 60 seconds showing the connection
DEFSTAN context: the contracting authority may be concerned about
exfiltration via USB from OFFICIAL systems as much as malware introduction
USB monitoring alerts demonstrate that this vector is monitored
even if the USB block (AT-AC 3.1.21) is the primary control on CUI servers
DEFSTAN exception handling:
If a system type cannot run AV software (embedded device, network appliance):
Document in EV-D08 with justification
Identify compensating controls:
Network isolation: the device is on a separate VLAN not reachable
from general network traffic
Minimal function: the device runs only firmware, no file execution
Monitoring: the device forwards all network traffic to SIEM via flow monitoring
CISO sign-off required for any OFFICIAL-scope system without AV
Contracting authority notification may be required — check contract schedule
Monthly AV/EDR coverage report procedure (generates EV-D32)
Produced by: Security Analyst / IT Operations
Frequency: Monthly (by the 7th of each month, covering the previous calendar month)
Source: EDR management console export + email gateway and proxy statistics
STEP 1 — EDR console data export
Navigate to: EDR console → Reports → [Coverage / Device Health / Endpoint Summary]
Export the following metrics:
A. Deployment coverage:
Total in-scope devices: [N]
Devices with agent active: [N] — Coverage: [%]
Devices with agent inactive/offline: [N] — list by device name
Devices not enrolled (in asset register but not in console): [N] — list
B. Signature currency:
Devices with signatures <24h old: [N] — [%] of total
Devices with signatures 24h–48h old: [N] — [flag for investigation]
Devices with signatures >48h old: [N] — [immediate remediation required]
C. Scan completion:
Devices with quick scan completed in past 7 days: [N] — [%]
Devices with full scan completed in past 30 days: [N] — [%]
Devices not completing scheduled scans: [N] — list by device name
D. Detection statistics:
Total detections in period: [N]
By severity: Critical [N], High [N], Medium [N], Low [N]
Detections quarantined automatically: [N]
Detections requiring manual action: [N]
Detections escalated to security team: [N]
Open detections (not yet resolved): [N]
E. Update failures:
Devices that generated a signature update failure alert in period: [N]
Resolution: [all resolved / N still outstanding]
STEP 2 — Email gateway statistics
Navigate to: Email gateway management console → Reports → Threat statistics
A. Malicious attachments blocked: [N]
B. Malicious URLs blocked at delivery: [N]
C. Malicious URLs blocked at click-time: [N]
D. Emails quarantined for sandbox review: [N]
E. Sandbox verdicts — malicious: [N], clean: [N], timeout/inconclusive: [N]
F. Phishing simulation detection (if platform supports): click rate [%], report rate [%]
STEP 3 — Web proxy and DNS filter statistics
A. Malware category blocks: [N]
B. C2/Botnet DNS blocks: [N]
C. Phishing page blocks: [N]
D. Newly registered domain blocks: [N]
E. TLS inspection coverage: [% of HTTPS traffic inspected] (target: >80%)
Exceptions to TLS inspection: [N categories/domains excluded]
STEP 4 — Action items from this report
For each device with coverage gap (not enrolled): create ITSM ticket
For each device with signature age >24h: create ITSM ticket
For each device not completing scheduled scans: investigate cause
For each open detection: confirm resolution in EDR console
All action items: entered in ITSM within 24 hours of report generation
EV-D32 Record — Monthly AV/EDR Coverage Report [YYYY-MM]
Period covered: [first date] to [last date of month]
Produced by: [name]
Date produced: [date]
SECTION A — Deployment coverage
In-scope devices (from EV-D22 asset register): [N]
Devices with agent active: [N] — Coverage: [%]
Devices with agent inactive: [N]
Device names: [list or "None"]
Devices not enrolled: [N]
Device names: [list or "None"]
SECTION B — Signature currency
Signatures <24h (current): [%] of enrolled devices
Signatures 24h–48h (degraded): [N devices] — [list]
Signatures >48h (non-compliant): [N devices] — [list]
SECTION C — Scan completion
Quick scan <7 days: [%]
Full scan <30 days: [%]
Devices not completing scheduled scan: [N] — [list with investigation note]
SECTION D — Detection statistics
Total detections: [N]
Automatically resolved: [N]
Escalated to security team: [N] — incident references: [list or "None"]
Open detections: [N] — [list with current status]
SECTION E — Network layer (email + proxy + DNS)
Email: malicious attachments blocked [N] / phishing URLs blocked [N]
Proxy: malware category blocks [N]
DNS: C2/botnet blocks [N]
SECTION F — Action items
ITSM tickets created: [list ticket numbers]
Escalations to CISO: [list or "None"]
AV coverage target: 100% — Current: [%]
Signature currency target: 100% <24h — Current: [%]
Security Analyst sign-off: _________________ Date: _________
IT Manager review: _________________ Date: _________
File at: EV-D → Malware Protection → Coverage Reports → [YYYY-MM]
AV exception management (documents in EV-D19 supplementary)
AV exceptions are performance or compatibility exclusions from scanning.
Every exception reduces coverage and must be documented.
Types of exceptions:
Path exclusion: a directory not scanned (most dangerous — widest scope)
Process exclusion: a specific process whose file access is not scanned
Extension exclusion: files with a specific extension not scanned
Hash exclusion: a specific file (by hash) not flagged even if signature matches
Creating an exception:
1. Request via ITSM: engineer documents the application creating the
conflict; the specific error or performance impact; the proposed
exclusion scope
2. IT Manager approval: minimum approval for all exceptions
3. CISO approval: required for path exclusions (highest risk)
4. Scope minimisation: the exclusion must be as narrow as possible
Path exclusion: only if process exclusion is not feasible
If path exclusion required: only the specific subdirectory, not parent
5. Add exclusion with minimum scope in EDR console
6. Document in AV exception register:
Exclusion type | Scope (path/process/hash) | Reason | Approver |
Date added | Review date (90 days) | Risk: [Low/Moderate/High]
Quarterly exception review:
Review all entries in AV exception register older than 90 days
For each: is the business justification still valid?
If the application has been updated: re-test without the exclusion
If justification is no longer valid: remove exclusion via RFC
Blanket exceptions that are never acceptable:
Exclusion on C:\Users\ or /home/ (user home directories) — path too broad
Exclusion on C:\Windows\Temp or /tmp/ — common malware staging locations
Exclusion based on "the application is from a trusted vendor"
(supply chain compromise means trusted vendors can deliver malware)
Evidence generation — this control family
| Evidence ID | What to produce | When | How | Filed at |
|---|---|---|---|---|
| EV-D32 | Monthly AV/EDR coverage report — coverage %, signature currency %, scan completion %, detection statistics, email/proxy/DNS stats | Monthly (by 7th of each month) | EDR console export + email gateway + proxy stats — compiled per procedure above | EV-D → Malware Protection → Coverage Reports → [YYYY-MM] |
| EV-D19 | AV exception register — all active scanning exclusions with scope, reason, approval, and review date | Continuous; quarterly review | EDR console export of exceptions + IT Manager sign-off | EV-D → Config Management → AV Exceptions (supplementary to BL-[PLATFORM] docs) |
| EV-D20 | Quarterly configuration audit — AV settings verified per BL-[PLATFORM] baseline (real-time enabled, tamper protection active, scheduled scan configured) | Quarterly | CIS-CAT Pro + manual PowerShell checks (Get-MpComputerStatus) on sample devices | EV-D → Config Management → Config Audits → [YYYY-QQ] |
| EV-F01 | Monthly SIEM log review — includes AV alert volume, detection escalations, USB connection events | Monthly | SIEM log review procedure (OP-03) — AV-specific alert categories reviewed in Step 2 | EV-F → Continuous Monitoring → Log Reviews → [YYYY-MM] |
| EV-F04 | Monthly IDS/IPS and proxy alert review — web malware blocks, DNS C2 detections | Monthly | Proxy and DNS filter console review; IDS alert review | EV-F → Continuous Monitoring → IDS Reviews → [YYYY-MM] |
Evidence production calendar:
Daily:
[ ] EDR alert queue review — Critical alerts (response within 1 hour)
[ ] Email gateway quarantine review — confirm no legitimate mail quarantined >24h
Weekly:
[ ] SIEM alert queue — AV-related Medium and Low alerts
[ ] EDR scan completion report — devices not completing scheduled scans
[ ] Signature currency check — devices >24h outdated
Monthly:
[ ] EV-D32 — full coverage report (by 7th of each month)
[ ] AV exception register review — any entries approaching 90-day review date
Quarterly:
[ ] EV-D20 — configuration audit includes AV settings verification
[ ] AV exception register full review — remove expired or unjustified exceptions
[ ] EICAR test — verify real-time scanning on sample devices of each OS type
Annually:
[ ] Engine/platform version review — are we on a supported EDR engine version?
[ ] Email gateway and proxy platform review — current version, supported, vendor roadmap
[ ] Coverage architecture review — does the deployment still match the system boundary?
{scroll-content}
Security-staff layer
SCM variant: isms-security — visible to isms-security only.
{scroll-content:variant=isms-security}
Evidence currency dashboard
Review and update at the beginning of each month. Any red status requires action before the next assessment.
| Evidence ID | Item | Required frequency | Last produced | Status | Owner |
|---|---|---|---|---|---|
| EV-D32 | Monthly AV/EDR coverage report — coverage, signature currency, detection stats | Monthly (by 7th) | [date] | [Current / Overdue] | Security Analyst |
| EV-D19 | AV exception register — all active exclusions reviewed within 90 days | Quarterly review | [date of last review] | [Current / Overdue] | IT Manager |
| EV-D20 | Quarterly configuration audit — AV settings in BL-[PLATFORM] verification | Quarterly | [date] | [Current / Overdue] | IT Manager |
| EV-F01 | Monthly SIEM log review — AV alert categories reviewed | Monthly | [date] | [Current / Overdue] | Security Analyst |
| EV-F04 | Monthly IDS/IPS and proxy alert review — web malware blocks | Monthly | [date] | [Current / Overdue] | Security Analyst |
Critical dependency:
EV-D32 (coverage report) is only meaningful if EV-D22 (asset register) is current. If new devices have been added to the CUI-scope asset register but not yet deployed with the EDR agent, the coverage gap will not be visible in the EDR console — it only appears when you compare the console to the asset register. Before any assessment, reconcile EV-D22 against the EDR console to identify any devices that are in scope but not enrolled.
EV-F01 (SIEM log review) depends on EV-F06 (SIEM health) confirming that the EDR console is forwarding events to the SIEM. If the EDR-to-SIEM integration has a gap, the monthly log review for AV-related events is incomplete regardless of how thoroughly the analyst reviewed the SIEM queue.
MITRE ATT&CK context — what this control family detects and prevents
The malware protection controls are the primary technical prevention for initial access and execution phases of the ATT&CK kill chain. The following maps the three CMMC Level 1 practices and their implementation components to specific technique categories.
T1566 — Phishing (all sub-techniques): The email gateway's attachment scanning (sandbox detonation), link rewriting, and anti-spoofing controls directly target phishing delivery. Endpoint real-time scanning catches malicious attachments that reach the device even if the email gateway did not flag them. SIEM detection: email gateway quarantine events (high volume of quarantined emails from the same sender domain); EDR events for malicious file detected in the Outlook attachment cache path (%AppData%\Local\Microsoft\Windows\INetCache).
T1059 — Command and Scripting Interpreter (PowerShell, VBScript, WScript): Endpoint EDR with behavioural detection catches script execution patterns that signature-based AV misses. PowerShell Script Block Logging (BL-WIN11 baseline setting) records all PowerShell script content for SIEM analysis. Tamper protection prevents malware from disabling the AV before executing. SIEM detection: Windows Event 4104 (PowerShell Script Block Logging) showing encoded commands, download cradles (IEX/Invoke-Expression + DownloadString pattern), or known offensive tool signatures in script content; EDR alert for suspicious script execution.
T1486 — Data Encrypted for Impact (ransomware): The most operationally severe malware threat for our sector. EDR platforms include specific ransomware protection modules: file system activity monitoring for mass file extension changes, shadow copy deletion commands, and encryption behavioural patterns. These detect and terminate ransomware before it encrypts the majority of files. SIEM detection: mass file rename/modification events from a single process (volume anomaly rule); Windows Event for vssadmin or wmic process deleting shadow copies (ransomware preparation step); network share file access volume anomaly (ransomware spreading to mapped drives).
T1071.004 — Application Layer Protocol: DNS: Command-and-control via DNS tunnelling is detected at the DNS filtering layer. High-entropy subdomain queries (DGA domains used for C2), unusually high NXDOMAIN response rates from a single host, and DNS query volumes significantly above baseline are all indicators of DNS-based C2. DNS filtering blocks resolution of known C2 domains before a connection is established. SIEM detection: DNS query entropy score above threshold; DNS query volume from single host >200% of 7-day baseline; NXDOMAIN rate from single host >50% of total DNS queries.
T1055 — Process Injection: Malware injecting code into legitimate processes to execute under the cover of a trusted application. Behavioural EDR detects unusual memory operations, unexpected process hollowing, and code execution in contexts that do not match the parent process's legitimate function. Scheduled periodic scans catch injected code that may persist in memory between real-time scan events via different detection mechanisms. SIEM detection: EDR alert for process injection; unexpected child processes from legitimate parent processes (Word spawning PowerShell, Explorer spawning cmd.exe); memory anomaly alerts from EDR behavioural engine.
T1562.001 — Impair Defenses: Disable or Modify Tools: Tamper protection (AMTamperProtectionEnabled = True) is the direct prevention for this technique. Attackers who gain code execution will commonly attempt to disable AV as one of their first actions. The tamper protection prevents this even if the attacker is running in an elevated context. SIEM detection: Windows Event for Defender tamper protection trigger; EDR alert for anti-tampering event; SIEM rule for AV service stop command that was blocked; SIEM alert for EDR console showing device protection status changed to "At Risk."
Control effectiveness assessment — quarterly
Complete each quarter as part of the internal assessment programme (AT-CA 3.12.1).
| Control | Test | Last tested | Result | Trend | Notes |
|---|---|---|---|---|---|
| AV coverage: 100% of CUI-scope devices | EDR console coverage % vs EV-D22 asset register reconciliation | [date] | [coverage %] | ↑↓→ | Target: 100% |
| Signature currency: 100% <24h | EV-D32 Section B — devices with signatures >24h | [date] | [% current] | ↑↓→ | Target: 100% <24h |
| Real-time scanning active — Windows | EICAR test on 3 sample Windows devices | [date] | Pass / Fail | ↑↓→ | |
| Real-time scanning active — macOS | EICAR test or [vendor test] on 3 sample macOS devices | [date] | Pass / Fail | ↑↓→ | |
| Tamper protection — Windows | Attempt disable from standard user (Settings UI + PowerShell) | [date] | Pass / Fail | ↑↓→ | |
| Tamper protection — macOS | Attempt to stop EDR service from standard user account | [date] | Pass / Fail | ↑↓→ | |
| Scheduled scan completing — Windows | EDR console: devices with scan >7 days | [date] | [N behind schedule] | ↑↓→ | Target: 0 |
| Scheduled scan completing — Linux | Clamav log review: weekly scan entries <7 days old on all servers | [date] | Pass / Fail | ↑↓→ | |
| Email gateway blocking malicious attachments | Send AMTSO test file to internal address via external mail | [date] | Pass / Fail | ↑↓→ | |
| Web proxy blocking malware download | AMTSO web-based malware test from managed device | [date] | Pass / Fail | ↑↓→ | |
| DNS filtering blocking C2 domains | Attempt resolution of domain on CISA KEV-associated list | [date] | Pass / Fail | ↑↓→ | |
| AV exception register — all within 90-day review | Exception register audit — count of expired entries | [date] | [N expired] | ↑↓→ | Target: 0 expired |
| Linux AV agent service active on all CUI servers | Ansible check-mode run: av_agent role status | [date] | Pass / Fail | ↑↓→ |
Assessor preparation — C3PAO, Cyber Essentials+, and DEFSTAN
C3PAO examination (CMMC Level 1)
The three CMMC Level 1 practices in this family are assessed using
Examine, Interview, and Test methods. All three methods are used —
this is one of the few Level 1 families where the assessor will
actually perform a technical test (EICAR) rather than only reviewing documents.
Documents to prepare (2 weeks before):
[ ] EV-D32 — last 3 months of monthly coverage reports
Confirm: coverage ≥95% each month (100% target; <95% is a finding)
Confirm: signature currency ≥95% each month for <24h threshold
[ ] EV-D19 — AV exception register
Confirm: all entries reviewed within past 90 days
Confirm: no exceptions on broad paths (C:\Users, /home, C:\)
[ ] EV-D20 — most recent quarterly configuration audit
Confirm: AV settings section shows compliant results for all OS types
[ ] EDR management console access ready for live demonstration
Technical demonstration preparation:
[ ] Identify a test device (can be a CUI-scope device — EICAR is harmless)
[ ] Confirm EICAR test will generate an alert visible in EDR console
[ ] Confirm alert response time is <30 seconds (real-time scanning is instant)
[ ] Prepare to show EDR console during EICAR demonstration
Interview talking points:
IT Operations: "Walk me through how you ensure every new device
that joins the environment has AV deployed before it accesses CUI."
→ New device onboarding: MDM enrolment is a prerequisite for Conditional Access;
MDM enrolment triggers automatic EDR agent deployment via Intune policy;
device must show as compliant (AV active, signatures current) before
Conditional Access grants access to CUI resources
IT Operations: "If an endpoint's AV agent goes offline — the device
loses connection to the management console — what happens?"
→ MDM compliance policy marks the device non-compliant after [N] hours
without check-in; Conditional Access blocks access to company resources;
SIEM alert generated when a device disappears from EDR console;
IT Operations investigates and remediates before access is restored
CISO: "How do you know your email gateway is actually catching malicious
attachments and not just claiming to?"
→ Monthly EV-D32 shows detection statistics; AMTSO test is run quarterly;
phishing simulation results (EV-B07) show the correlation between
technical blocking and successful human detection;
any incident where malware reached an endpoint is post-incident reviewed
to determine whether the gateway should have caught it
Common pre-assessment finding for this family:
Coverage gap on a specific device category — most often:
(a) Linux servers — not enrolled in EDR (assessors look specifically here)
(b) Mobile devices — BYOD in use without verified AV
(c) Recently added devices not yet enrolled (asset register vs EDR console gap)
Prevention: run the EV-D22 vs EDR console reconciliation before assessment
Cyber Essentials+ technical verification preparation
CE+ assessors will connect to sample devices of each OS type and
run verification commands or demonstrate controls directly.
Prepare one device of each type for demonstration:
This is a production CUI-scope device that has been pre-verified
Run all the verification commands below yourself first to confirm results
Windows device demonstration sequence:
Step 1: Show that AV is running
Get-MpComputerStatus | Select-Object AMRunningMode, AntivirusEnabled,
RealTimeProtectionEnabled, AMTamperProtectionEnabled,
AntispywareSignatureLastUpdated
Expected values: Normal / True / True / True / [date within 24h]
Step 2: Show scheduled scan is configured
Get-ScheduledTask -TaskPath "\\Microsoft\\Windows\\Windows Defender\\" |
Select-Object TaskName, State
Expected: "Windows Defender Scheduled Scan" — State: Ready
Get-MpComputerStatus | Select-Object LastQuickScanTime, LastFullScanTime
Expected: QuickScan within past 7 days
Step 3: EICAR test (real-time scanning demonstration)
[Assessor or IT Operations performs] — save EICAR string as eicar.com
Expected: alert fires within 5 seconds; file quarantined
Show EDR console alert generated by this test
Step 4: Tamper protection test
Settings → Windows Security → Real-time protection → attempt to toggle off
Expected: toggle is greyed out or immediately returns to On
Step 5: User cannot disable via PowerShell
Open PowerShell as standard user account (not admin)
Set-MpPreference -DisableRealtimeMonitoring $true
Expected: Access Denied or 0x800704EC error
macOS device demonstration sequence:
Step 1: AV agent running
ps aux | grep [EDR agent process]
Expected: process listed as running
[EDR vendor CLI] status
Expected: Protection Enabled, Signatures Current
Step 2: Full Disk Access granted (prerequisite for complete coverage)
System Settings → Privacy & Security → Full Disk Access →
show [EDR agent] with green tick
If not present: this is the most common macOS EDR CE finding
Step 3: EICAR test (if vendor supports it on macOS)
[Vendor-specific test method]
Step 4: User cannot stop service
Attempt: sudo systemctl stop [service] (macOS uses launchd, not systemd)
Or: pkill [EDR process name] from standard user account
Expected: permission denied
CE specific: devices connecting from home networks
Assessor may ask: "When a user connects from home with no VPN,
is their AV still centrally managed?"
Answer: Conditional Access requires the device to be marked compliant
(AV active and current) before granting access to any company resource;
the MDM connection is separate from the VPN — the device checks into
Intune/Jamf via the internet directly; signatures update via Windows Update
or vendor cloud directly — not requiring VPN;
a device that goes offline entirely and stops updating signatures will be
marked non-compliant within 24 hours and lose access to company resources
on next connection attempt
DEFSTAN assessment preparation
DEFSTAN Profile 0 §Malware examination typically occurs as part of
a desk-based review (documents and evidence) or a site visit.
1. AV on all OFFICIAL-scope systems — the comprehensive list question
Assessor question: "Show me every system that handles OFFICIAL information
and confirm that each one has anti-malware software installed."
Preparation:
Produce: OFFICIAL-scope system list from SSP boundary (AT-CA Section 3)
Produce: EDR management console filtered to same system list
Reconcile: every system on the SSP list is visible in EDR console as Protected
If a system on the OFFICIAL list is not in the EDR console:
Either: it was recently added and agent is deploying (acceptable if <48h gap)
Or: there is a coverage gap — remediate before the assessment
2. Signatures current — the spot check
Assessor may ask for a live demonstration
Prepare: show EDR console real-time → all devices → sort by signature date
Show: all OFFICIAL-scope devices show signature update within past 24h
If any device shows >24h:
The assessor will ask why
Acceptable answer: device was powered off; it will update on next connection
Unacceptable answer: we don't know; the update mechanism is broken
3. Real-time scanning — the tamper question
DEFSTAN-specific emphasis: Profile 0 requires that protection cannot
be disabled by the user
Prepare: be ready to demonstrate the tamper protection test on a sample device
Also prepare: show the policy in Intune/Jamf that enforces tamper protection
The assessor may ask: "If an administrator account was compromised,
could an attacker disable AV?"
Answer: Defender Tamper Protection in Intune-managed mode requires
disabling Tamper Protection via Intune before it can be changed locally —
local admin rights alone cannot override it; any change to Tamper Protection
via Intune generates an audit log event and SIEM alert
4. Removable media scanning
Assessor question: "What happens when a USB drive is plugged into
a system handling OFFICIAL information?"
Answer sequence:
1. USB connection event is logged to SIEM (SIEM alert if USB storage class)
2. USB mass storage is blocked by GPO/MDM policy on CUI-scope systems
(AT-AC 3.1.21 control)
3. For approved exceptions: the drive is connected; AV agent scans all
files on access (DisableRemovableDriveScanning = False confirmed in BL-WIN11)
4. Any malware detected on the USB: quarantined before file opens
Show: Get-MpPreference → DisableRemovableDriveScanning = False
Show: SIEM event from USB connection test (from quarterly control test)
5. Evidence of ongoing management
DEFSTAN assessors want to see that malware protection is actively managed,
not just deployed and forgotten
Prepare: last 3 months of EV-D32 (monthly coverage reports)
Show: the trend lines — coverage stable at 100%; signatures consistently current;
detections are being reviewed and resolved; the management console is
being actively used
An EV-D32 that shows the same numbers for three consecutive months with
no action items is suspicious — it suggests the report is being produced
as a formality without genuine review
POA&M templates — most likely deficiencies for this control family
Template: AV agent not deployed on one or more CUI-scope systems
POA&M item: PM-[YYYY]-[NNN]
Controls: SI.L1-3.14.2 · CE Malware Req 1 · DEFSTAN Profile 0 §Malware
Weakness: [N] CUI-scope system(s) identified in the [month/quarter] coverage
review as not enrolled in the EDR management console.
Affected systems: [list hostnames/device names]
Gap duration: [estimated — from last confirmed enrolled state or asset register date]
Discovery source: EV-D32 monthly coverage report / EV-D22 vs EDR console reconciliation
Risk during deficiency: High — unprotected CUI-scope system has no endpoint
malware detection or tamper evidence capability
for the gap period
Compensating controls: Network segmentation limits exposure —
affected system is in Zone [N] with firewall rules
restricting inbound connections;
Email gateway and web proxy provide network-layer protection;
SIEM monitoring for anomalous network behaviour
from the affected system's IP
Corrective action: (1) Deploy EDR agent to affected system(s) within
[N] business days via [Intune policy push / Ansible playbook /
manual installation]
(2) Verify agent is active and signatures current after deployment
(3) Confirm system appears in EDR management console as Protected
(4) Add check to onboarding procedure to prevent future gap:
new device may not access CUI resources until EDR console
confirms Protected status
Owner: IT Operations
Target completion: [3 business days — High risk]
CISO approval: required — High risk
Template: Signature update failure — multiple devices
POA&M item: PM-[YYYY]-[NNN]
Controls: SI.L1-3.14.4 · CE Malware Req 2 · DEFSTAN Profile 0 §Malware
Weakness: [N] CUI-scope device(s) identified with antivirus/EDR signatures
older than 24 hours as of [date]. The signature age ranges from
[minimum age] to [maximum age].
Affected devices: [list]
Root cause (if identified): [e.g. WSUS configuration issue /
internet connectivity from isolated VLAN blocked update source /
EDR agent version incompatibility with update format]
Discovery source: EV-D32 monthly coverage report Section B /
SIEM alert "AV signatures >24h on CUI-scope device"
Risk during deficiency: Moderate — devices with outdated signatures may
not detect malware variants released
after the signature date
If root cause is connectivity: the inability to
update may indicate a broader network isolation
issue worth investigating
Compensating controls: Behavioural detection in EDR (not solely signature-based)
continues to function regardless of signature currency;
Email gateway and web proxy blocking operate independently;
Network monitoring active for anomalous behaviour
Corrective action: (1) Force signature update on affected devices immediately:
Windows: Update-MpSignature (or device restart to trigger)
macOS: [vendor CLI update command]
Linux: freshclam / [vendor CLI update command]
(2) Investigate root cause of update failure
(3) If root cause is WSUS/distribution point: resolve
configuration and verify all devices can update
(4) Verify SIEM alert rule is active for signature age >24h
to prevent similar gaps going undetected in future
Owner: IT Operations
Target completion: signature update: immediate (within 24 hours);
root cause resolution: [5 business days]
CISO approval: IT Manager sufficient for Moderate risk
Template: Tamper protection disabled or bypassable
POA&M item: PM-[YYYY]-[NNN]
Controls: SI.L1-3.14.2 · CE Malware Req 3 (cannot be disabled) · DEFSTAN Profile 0 §Malware
Weakness: Tamper protection on [N] CUI-scope [Windows / macOS] device(s)
was found to be disabled or bypassable by a standard user account
during the [quarter] control effectiveness assessment.
Affected devices: [list]
Test result: [describe specifically — settings toggle was not greyed out /
PowerShell Set-MpPreference command succeeded from standard user account / etc.]
Discovery source: Quarterly control effectiveness assessment / EV-D20 configuration audit
Risk during deficiency: High — malware with user-level privileges can disable
antivirus protection before executing payload;
ransomware commonly disables AV as first action;
the value of the AV investment is significantly
reduced if it can be disabled post-compromise
Compensating controls: MDM compliance policy marks device non-compliant
if AV reports as disabled; Conditional Access then
restricts access;
SIEM alert for "AV protection disabled on CUI device"
is active and tested
Corrective action: (1) Investigate why tamper protection is not active:
Is the device Intune-managed? (check: dsregcmd /status)
Is the Intune AV policy applying? (check: gpresult + Intune
device configuration status)
Is the device licensed for MDE? (tamper protection
requires Defender for Endpoint P1 or P2 licensing)
(2) Re-enrol or re-push the Intune AV policy with
tamper protection explicitly enabled
(3) Verify: attempt the tamper bypass again — confirm it fails
(4) Run across all CUI-scope devices:
Get-MpComputerStatus |
Where-Object {$_.AMTamperProtectionEnabled -eq $false}
Any additional results: add to this POA&M
Owner: IT Operations
Target completion: [7 days — High risk]
CISO approval: required — High risk
Cross-family evidence dependencies — this control family
AT-SI (System and Information Integrity — advanced tier): EV-D32 (AV coverage report) is cited in both this fundamental tier page and AT-SI. The fundamental tier page documents the deployment and coverage obligation. AT-SI documents the advanced controls (alert monitoring, IDS/IPS, threat intelligence). The same EV-D32 satisfies both the fundamental compliance obligation and the advanced tier evidence requirement. If EV-D32 is overdue, both FC-04 and AT-SI are simultaneously lacking evidence.
AT-RA (Risk Assessment): The phishing simulation results (EV-B07 from AT-AT) and the email gateway detection statistics (EV-D32 Section E) feed into the annual risk assessment (EV-C02). The risk assessment's threat landscape section should reference the organisation's actual phishing encounter rate as measured by the gateway, providing concrete evidence for the likelihood scoring in the 5×5 risk matrix. If EV-D32 shows high phishing volumes but the risk assessment rates phishing likelihood as Low, there is an inconsistency an assessor will notice.
AT-AC (Access Control): Conditional Access policy (CA-002 from AT-IA/FC-03) requires device compliance as a condition of access. Device compliance includes AV active and signatures current (MDM compliance policy). The AV coverage obligation is therefore both a standalone SI control and a dependency of the access control framework. A device that fails AV compliance loses CUI resource access automatically — this is both a malware protection control and an access control enforcement mechanism. EV-D32 (AV compliance) and EV-D05 (MFA coverage) are both inputs to the device compliance posture that CA-002 enforces.
AT-CM (Configuration Management): The BL-WIN11, BL-MAC, and BL-UBUNTU baselines in AT-CM include the AV configuration settings (real-time protection, tamper protection, scheduled scan) as baseline items. The quarterly configuration audit (EV-D20) verifies these settings. EV-D20 and EV-D32 are complementary — EV-D32 shows whether the deployed agent is active and current; EV-D20 shows whether the agent is correctly configured per the baseline. Both must be current and consistent for a complete evidence picture on SI.L1-3.14.2 through 3.14.5.
{scroll-content}
Page footer
All-staff visible — outside all SCM variant wrappers.
Where to go next
| If you are... | Go to... |
|---|---|
| An all-staff user who clicked a suspicious link or opened a suspicious file | Contact IT Operations immediately — do not wait — [phone number] |
| An all-staff user who received a suspicious email | 04 · User Guidance Hub → Phishing and Suspicious Emails |
| An all-staff user whose device is showing antivirus alerts | Contact IT Operations — [helpdesk URL] — note the alert details before calling |
| An all-staff user whose device shows ransomware demand | Disconnect from network immediately — then call IT Operations — [phone number] |
| An IT Operations engineer deploying the EDR agent to a new platform | FC-04 IT Staff Technical Procedures (this section above) |
| An IT Operations engineer investigating a missed scheduled scan | EDR console → Health → Scan health → filter by device — then ITSM ticket |
| An IT Operations engineer producing the monthly EV-D32 | IT Staff Technical Procedures → Monthly AV/EDR coverage report procedure |
| A security team member investigating a malware detection alert | AT-SI → Playbook PB-02 (ransomware) or PB-04 (phishing campaign) |
| A security team member preparing for CMMC, CE+, or DEFSTAN assessment | This page security layer above + AT-SI Section 5 (assessor preparation) |
Version and review
| Version | Date | Change summary | Author | Approver |
|---|---|---|---|---|
| 1.0 | [DATE] | Initial publication | [NAME] | [CISO NAME] |
Page owner: IT Manager · Review: Annual · Questions: [helpdesk URL] or [ciso@organisation.com]