SAMA Malware Protection Requirements for Layered Endpoint Security

A Saudi financial institution can have antivirus installed on every workstation and still face an uncomfortable question during a security assessment: is the organization actually meeting the intent of SAMA 3.3.8.f?

The distinction matters. Malware defense has changed substantially since endpoint security meant scanning files against a database of known malicious signatures. Modern attacks can abuse legitimate tools, scripts, trusted applications, stolen credentials and previously unseen malware. A malicious file is no longer the only problem, and antivirus alone is no longer the whole defensive architecture.

The Saudi Central Bank Cyber Security Framework addresses this directly. Under control 3.3.8, Infrastructure Security, consideration 3.3.8.f calls for "malicious code/software and virus protection (and applying application whitelisting and APT protection)".

Those few words have significant architectural implications. For CISOs, SOC teams, infrastructure managers and compliance functions, the practical challenge is translating the framework's terminology into endpoint controls that work against today's threats.

That means thinking beyond traditional antivirus toward a layered architecture combining anti-malware, application control, endpoint detection and response (EDR), behavioral analytics, endpoint hardening, threat intelligence, security monitoring and carefully governed exceptions. This article forms part of our complete guide to ISO 27001 and compliance services for GCC SMBs.

What SAMA 3.3.8.f Actually Requires

Control 3.3.8.f sits within the Infrastructure Security subdomain of the SAMA Cyber Security Framework. Its placement is important because malware protection is not presented as an isolated desktop security function. It forms part of broader infrastructure considerations that include approved software and secure protocols, network segmentation, vulnerability and patch management, and other protective measures.

The SAMA Cyber Security Framework specifically identifies malicious-code and virus protection while explicitly mentioning application whitelisting and advanced persistent threat (APT) protection.

The framework's glossary gives additional context. It describes application whitelisting as a list of applications and application components authorized to be present or active on a host according to a defined baseline. It further explains that application-whitelisting technologies are intended to stop malware and other unauthorized software by permitting known activity and blocking other activity, contrasting this approach with traditional antivirus blacklisting.

An APT is broader still. SAMA's glossary, drawing on NIST terminology, describes an APT as an adversary with sophisticated expertise and significant resources that can use multiple attack vectors, pursue objectives over an extended period, adapt to defenders and maintain the interaction needed to achieve its objectives.

So the practical question is not simply "Do we have antivirus?" It is "Can we prevent unauthorized code from executing, identify suspicious behavior that prevention misses, detect persistent attacker activity and respond before it becomes a larger compromise?"

That is a more useful way to approach SAMA malware protection requirements.

Antivirus Still Matters, but It Is Only One Layer

Traditional anti-malware remains valuable. Known malicious files, commodity malware and recognizable malicious behaviors should be stopped as early as possible. The mistake is treating that capability as a complete endpoint security strategy.

Modern endpoint protection platforms increasingly combine signatures with cloud-based analysis, behavioral detection and other techniques. Microsoft, for example, documents Microsoft Defender for Endpoint as providing capabilities that include next-generation protection, endpoint detection and response, and attack surface reduction.

This layered model addresses an important operational reality. An attacker does not necessarily need to drop an obviously malicious executable onto a device. A compromised environment can involve malicious scripts, abuse of existing administrative tooling, unusual process behavior or other activity where recognizing what a program is called is less useful than understanding what it is doing. This is where EDR becomes important.

What EDR Adds to Anti-Malware

Endpoint Detection and Response collects and analyzes endpoint security telemetry to help security teams identify, investigate and respond to suspicious activity.

Conceptually, anti-malware asks whether something should be prevented because it appears malicious. EDR adds the ability to investigate what happened on the endpoint and respond to suspicious activity.

For a Security Operations Center (SOC), that distinction can be significant. An isolated alert saying that a file was blocked gives limited context. Endpoint telemetry can help analysts determine what process executed, what followed it, what devices may be involved and whether investigation or containment is required.

EDR therefore should not be interpreted as a replacement for the antivirus language in SAMA 3.3.8.f. It is better understood as another layer in a modern implementation of malware and advanced-threat protection.

Application Whitelisting Becomes Application Control

SAMA's explicit reference to application whitelisting deserves particular attention because this part of the control is sometimes overshadowed by endpoint security product deployments.

The principle is powerful: instead of trying only to identify everything that is malicious, establish what is authorized to execute. Modern platforms commonly refer to this as application control or application allowlisting.

On supported Windows endpoints and servers, for example, Microsoft documents that Application Control for Windows provides application-control technologies that can be used to control which applications and code are permitted to run.

Application control can significantly change an attacker's options. A user receiving an unknown executable does not necessarily mean that executable should be allowed to run simply because antivirus has not classified it as malicious.

The challenge is that application control is also an operational control. A policy that blocks a critical banking application, finance tool, administration script or approved software update can quickly turn a technically strong security configuration into a business disruption.

Build Application Control Around a Known Baseline

Financial institutions should therefore avoid treating whitelisting as a switch that can simply be turned on across an entire estate.

A safer implementation starts by establishing what is already executing across different endpoint populations. Workstations, privileged administrator devices, application servers and specialized systems rarely require identical policies. Organizations can then classify software and code according to business purpose and trust, define appropriate application-control policies, test them and gradually move toward enforcement.

Microsoft's App Control for Business, for example, provides an audit mode that allows organizations to identify applications, binaries and scripts that would be denied before moving a policy to enforcement. Microsoft's guidance for Attack Surface Reduction (ASR) rules likewise provides audit modes and staged deployment guidance, although Microsoft notes that some standard protection rules can typically be enabled in Block or Warn mode without prior audit testing.

The broader implementation principle applies regardless of security vendor: observe, baseline, test, enforce and monitor.

Exception Management Is Part of the Security Control

Eventually, someone will need an exception. Perhaps a legacy financial application launches an unusual child process. A treasury system depends on a component that does not fit the organization's standard policy. An operations team might rely on an approved script that triggers a behavioral rule.

Simply adding a permanent exclusion every time a business unit reports a problem can gradually dismantle the protection the organization intended to implement. Exceptions should therefore be governed security decisions. A mature exception process should record:

• The affected asset or workload
• Business justification and the requested exception
• An accountable owner and the associated risk
• Compensating controls where required
• Approval, plus an expiration or review date

Broad exclusions deserve particular scrutiny. The question should be whether the exception can be made narrower without disrupting the required business process.

This also creates something important for SAMA-regulated organizations: evidence. Instead of demonstrating only that a security product has been purchased, the organization can demonstrate how protections are configured, where exceptions exist, why they exist, who approved them and how they are reviewed.

APT Protection Requires Looking Beyond the File

The phrase "APT protection" can sound like a product category. In practice, protecting against advanced persistent threats is an architectural objective rather than a single security feature.

Consider how a persistent intrusion can develop. Initial malware might be blocked, but an attacker could instead exploit another path or use legitimate system capabilities. Once access exists, the activity may involve persistence, credential access, internal discovery, communications with external infrastructure and movement toward more valuable systems.

No individual malware signature necessarily tells that entire story. APT protection therefore benefits from correlating multiple security signals.

Behavioral Detection

Behavioral detection focuses on activity rather than relying exclusively on whether a file matches a known malware signature. A process launching suspicious scripts, unusual code execution or unexpected connections can provide useful signals even when the individual executable itself is not known to be malicious.

Microsoft's Attack Surface Reduction rules illustrate this approach by targeting risky software behaviors attackers commonly exploit through malware, such as certain script, executable and code-injection behaviors.

Prevention becomes stronger when defenders can restrict dangerous behavior rather than waiting for every malicious artifact to be identified in advance.

Endpoint Hardening

Endpoint hardening further reduces the paths available to malware and attackers. Depending on the operating environment and risk profile, this can involve application control, attack surface reduction, restricting risky scripting behaviors, network protection, firewall controls, device controls, privilege reduction and secure configuration.

Microsoft's Defender for Endpoint attack surface reduction capabilities include preventive mechanisms such as attack surface reduction rules, controlled folder access and network protection, alongside related Windows security controls.

The objective is straightforward: malware that never obtains a useful foothold is easier to manage than an intrusion that the SOC must detect after compromise.

EDR Becomes More Valuable When the SOC Is Watching

Deploying EDR everywhere solves a visibility problem only if somebody is responsible for what the technology reports. A high-quality endpoint alert at 2:00 a.m. has limited defensive value if it is not reviewed until the next working day. This is why endpoint security architecture and SOC operations need to be designed together.

A SOC should be able to receive relevant endpoint telemetry and alerts, correlate them with other security data, investigate suspicious behavior and execute defined escalation or response processes. Where appropriate, that wider architecture can include Security Information and Event Management (SIEM), network security telemetry, identity events, email security and cloud security data alongside endpoint detections.

Extended Detection and Response (XDR) extends this correlation concept across multiple security domains. Rather than investigating endpoint activity in isolation, an analyst can potentially relate a suspicious endpoint event to identity, email or other security signals supported by the deployed platform.

Cyberactics' managed cybersecurity services include Managed Detection and Response (MDR), SIEM implementation and management, vulnerability management and incident response. For organizations developing a SAMA-aligned endpoint strategy, the operational question is how prevention, detection and response processes work together, rather than how many independent tools have been deployed.

SAMA 3.3.8.f and Threat Management Should Work Together

Malware defense also connects naturally with another part of the SAMA Cyber Security Framework: 3.3.16 Threat Management.

The SAMA Rulebook entry for 3.3.16 says Member Organizations should define, approve and implement a threat intelligence management process that identifies, assesses and understands threats using multiple reliable sources.

Its control considerations identify internal sources such as access-control data, application and infrastructure logs, IDS/IPS, security tooling, SIEM and relevant organizational functions. It also identifies reliable and relevant external sources including SAMA, government agencies, security forums, vendors, security organizations and specialist notification services.

Importantly, the control considerations require consideration of the relevance of derived intelligence and its actionability for follow-up. SAMA's subsequent Cyber Threat Intelligence Principles for the Financial Sector further emphasize actionable threat intelligence, including decisions about necessary actions, responsibility and response timeframes.

This creates a logical connection between 3.3.16 and endpoint protection. Threat intelligence should not live only in a monthly report. Relevant intelligence can inform security monitoring, investigations, hunting, detection engineering, blocking decisions and defensive priorities. When intelligence identifies infrastructure, techniques or behaviors relevant to the institution, the security operation needs a defined method to decide what action follows.

An effective loop looks like this: threat intelligence -> relevant detection or prevention -> endpoint/SIEM telemetry -> SOC analysis -> response -> new internal intelligence. That is stronger than operating antivirus, threat intelligence and SOC functions as separate compliance activities.

What a Modern SAMA 3.3.8.f Architecture Looks Like

There is no single product stack that automatically creates compliance with 3.3.8.f. Architecture should reflect an organization's assets, threats, technology estate and risk decisions. A practical layered model can contain:

• Anti-malware and next-generation endpoint protection to prevent known and detected malicious activity.
• Application control to restrict execution to appropriately trusted software and code.
• EDR to provide endpoint visibility, behavioral detection, investigation and response capabilities.
• Endpoint hardening and attack surface reduction to remove unnecessary opportunities for attackers.
• Threat intelligence to inform detection, prevention, hunting and prioritization.
• SIEM and SOC monitoring to correlate endpoint activity with broader infrastructure and security telemetry.
• Defined incident response processes so high-confidence malicious activity results in appropriate investigation, containment and recovery.
• Formal exception management so security controls are not gradually weakened by undocumented exclusions.

These capabilities should reinforce one another. If antivirus misses something, application control may prevent execution. If prevention does not stop the activity, behavioral analytics or EDR may detect suspicious behavior. SOC analysts can investigate the resulting telemetry, while threat intelligence provides additional context for determining whether the behavior is associated with a relevant campaign or technique.

The result is defense in depth rather than dependence on a single endpoint agent.

Warning Signs That Endpoint Protection Exists but Is Not Mature

The most revealing questions often concern operations rather than licensing. A financial institution should investigate further if large numbers of endpoints are not reporting to central security management, endpoint agents can be disabled without appropriate control, security intelligence or engines are not being updated reliably, or application-control policies exist only on a small subset of systems where the organization intends those policies to apply.

Other warning signs include broad permanent antivirus or EDR exclusions, application-control exceptions with no owners or review dates, security alerts with no defined response workflow, and threat intelligence that is collected but never translated into defensive action.

The same applies when security and asset inventories disagree. If the organization cannot identify which endpoints and servers should be protected, it cannot reliably demonstrate that protection coverage is complete. These are not merely technical housekeeping issues. They affect the organization's ability to demonstrate that a security control operates consistently over time.

Building Evidence for SAMA Assessments

Compliance evidence should show operation, not just intention. A policy saying that relevant endpoints require malware protection establishes governance. It does not by itself demonstrate that the systems within the defined scope are protected.

Organizations should be able to produce evidence from the underlying technologies and processes. Depending on the environment, that may include endpoint coverage reports, security policy configurations, update status, EDR onboarding status, application-control policies, monitoring records, alert and incident workflows, threat-intelligence procedures and approved exception records.

Security teams should also be able to explain how these elements connect. For example, when endpoint protection produces a high-severity detection, who receives it? How quickly is it expected to be reviewed? Under what conditions does containment occur? What happens if threat intelligence identifies an indicator relevant to the environment? Who can approve an application-control exclusion?

Answers that depend on undocumented individual knowledge indicate operational fragility even where good security products are installed.

What This Means for GCC Organizations

SAMA 3.3.8.f applies in the context of Saudi Central Bank Member Organizations, so organizations elsewhere in the Gulf Cooperation Council (GCC) should not treat it as a UAE or Oman regulatory requirement. The security architecture behind it, however, has broader relevance across the GCC and wider MENA region.

Saudi organizations may also need to consider applicable controls issued by the National Cybersecurity Authority (NCA). The NCA's current Essential Cybersecurity Controls (ECC 2-2024) include a requirement for advanced, up-to-date and secure management of malware and virus protection on servers and workstations. The ECC's defined scope covers Saudi government agencies and their affiliated companies and entities, as well as private-sector entities owning, operating or hosting Critical National Infrastructures. NCA encourages other entities in the Kingdom to leverage the controls. The exact regulatory scope and applicable controls should therefore be determined for each organization rather than assuming that one Saudi framework substitutes for another.

Financial and other organizations in the UAE and Oman operate under their own applicable regulatory and sector requirements, but the operational challenge is similar: distributed endpoints, cloud services, remote administration and increasingly integrated infrastructure require prevention and detection capabilities to work together.

For groups operating across Saudi Arabia, the UAE and Oman, this can create an additional architecture challenge. Centralized endpoint and SOC operations can reduce duplication, but control mappings, evidence and regulatory responsibilities still need to remain specific to each applicable jurisdiction. A regional security architecture should therefore aim for technical consistency without assuming regulatory equivalence.

A Practical Implementation Path

The strongest approach usually begins with visibility rather than a new security purchase.

1. Establish an accurate inventory of endpoints and servers and identify which systems fall within the relevant SAMA scope, comparing the asset inventory against endpoint security enrollment so unmanaged or unprotected devices become visible.
2. Review the existing anti-malware and EDR configuration, checking protection status, central policy enforcement, telemetry, alert routing and exclusions rather than relying on agent installation alone.
3. Introduce application control carefully: observe existing software behavior, establish trusted application baselines and pilot policies against representative user and server groups before wider enforcement, giving legacy and specialized systems particular attention.
4. Apply hardening with the same risk-based approach, evaluating attack surface reduction, scripting controls, privilege management and network protections against both security value and operational impact.
5. Connect endpoint detections to SOC monitoring and incident response, defining ownership, severity levels, escalation paths and containment authority before an incident forces those decisions under pressure.
6. Integrate threat intelligence into this operating model so relevant intelligence leads to explicit decisions such as searching historical telemetry, adding detections, adjusting defenses or increasing monitoring around affected assets.

The outcome should be a continuously operated security capability, not a point-in-time compliance project.

From Antivirus Compliance to Endpoint Resilience

SAMA 3.3.8.f uses the terms malware and virus protection, application whitelisting and APT protection. Together, they support a defense-in-depth approach rather than reliance on antivirus alone.

Traditional anti-malware remains part of that architecture, while application control, behavioral detection, EDR or XDR capabilities, endpoint hardening, threat intelligence, SOC monitoring and disciplined exception management can support a broader implementation appropriate to the organization's risks and technology environment.

For Saudi financial institutions, the objective is not simply to demonstrate that antivirus software is deployed. It is to demonstrate that the infrastructure security standard addresses the protections specified by SAMA and that the implemented controls operate effectively across the defined scope.

This is also where SAMA 3.3.8.f and SAMA 3.3.16 can become mutually reinforcing: endpoint telemetry can contribute to threat understanding, while actionable threat intelligence can make endpoint defenses and monitoring more relevant.

Cyberactics supports organizations across Saudi Arabia and the wider GCC with managed cybersecurity, MDR, SIEM, vulnerability management and incident response services, including MDR delivered through EDR platforms. For organizations reviewing SAMA 3.3.8.f, Cyberactics can help assess how existing endpoint protection, monitoring and operational processes fit into a layered security architecture and identify where prevention, visibility or response capabilities need to mature. Get in touch to discuss your environment.