How To Build An Effective Malware Protection Architecture

How to Build an Effective Malware Protection
Architecture
Published 18 June 2020 - ID G00726637 - 47 min read
By Analyst(s): Mario de Boer
Initiatives: Security Technology and Infrastructure for Technical Professionals
Malware protection requires a careful balance between multiple

technologies and processes across networks and endpoints.
Security and risk management technical professionals can use
this guidance to assess the maturity of their malware architecture
and to plan for improvements.
Overview
Key Findings
■ Most organizations do not implement a structured anti-malware approach but
engage in isolated product purchases and operational processes across endpoint,
email, web and network. Together with near-default settings, lack of integration and
no overarching processes, this leaves them unnecessarily vulnerable and their
architectures ineffective and more expensive.
■ The lack of understanding regarding common and less common attack methods
and their business impact leaves organizations at the mercy of vendors or
individuals to explain how “big” the problems are and how “good” the solutions are.
■ Good plans require the understanding of the attackers and their methods, and the
effectiveness and impacts of technical and nontechnical mitigations and incident
response. Higher levels of protection cause increased management overhead and
user impact.
Recommendations
To build an effective malware protection architecture, technical professionals focused on
security technology and infrastructure should:
Gartner, Inc. | G00726637 Page 1 of 37
This research note is restricted to the personal use of tanlb@viettel.com.vn.

■ Identify the strengths, scope and imbalances of the current malware protection
capability by using the capability maturity model presented in this research. This
provides an understanding of the level of malware attacks you are protected against.
■ Define a future protection architecture that matches the attacks you need protection
against by designing processes as well as selecting relevant endpoint, email, web
and network controls at the right maturity level. In addition, integrate the multiple
malware protection components. Communicate your protection level goals and
discuss the resulting residual risks with the business.
■ Improve the maturity of malware protection architecture across endpoints, email,

web and the network by defining a roadmap while leveraging the five maturity levels
defined in this guidance.
■ Improve malware protection maturity step by step. With most malware attacks
taking place at threat Levels 1 through 3, all organizations should have an ambition
to reach at least maturity Level 3, and many should strive for maturity Level 4.
Problem Statement
Many organizations approach malware protection in isolated infrastructure components.
They define malware protection requirements, processes and policies in isolation for client
endpoints, server endpoints, email gateways, web gateways, network infrastructure
components and cloud assets.
This approach commonly leads to six potential problems:
■ Unknown effectiveness — Lack of overview makes it hard to assess the overall

strength of the malware protection effectiveness for the organization.
■ Unbalance between technology and processes — In many cases, organizations pay

too much attention to technology and too little attention to processes.
■ Unbalanced technologies — With isolated attention on malware protection in

endpoints, email, web and network (often by different teams), there is a risk of
stacking a lot of security in one control area and much less in another area.
■ Underprotection — A lack of architecture may result in a failure to address attack

types that should be in scope for the organization’s security.

■ Overprotection — A lack of architecture may result in overspending or overdesigning
(leading to unnecessarily high user impact and operations costs) on tools and
people without really mitigating additional relevant risks.
■ Inefficiency — Lack of architecture may lead to higher total cost of ownership, lower
security operations center (SOC) productivity and inefficient security incident
response processes.
To overcome these problems, security architects should view malware protection as an

integrated architecture, with a balance between the various technologies, deployments
thereof and relevant processes.
The Gartner Approach

As organizations are different, they face different threats, have different risk appetites,
capabilities and budgets, and have users who respond differently to restrictive security
measures.
Gartner recommends a structured approach to building a malware protection architecture.

The approach uses a capability maturity model to address the differences in
organizations.
This research presents an approach that security professions in all organizations can use
to:
■ Assess the maturity of their current malware protection capabilities.
■ Uncover gaps in their current capabilities.
■ Maximize the value of their anti-malware purchases and avoid buying products they
don’t need.
■ Plan for improvements in a balanced way among technologies and processes, and
among networks and endpoints.
The Guidance Framework

Technical professionals focused on architecting network and endpoint security in their
organizations should leverage the three steps depicted in Figure 1 to assess and plan for
malware protection architecture.

The three steps are:
1. Assess current malware protection maturity — Use the accompanying Excel (XLSX)
tool, which can be found in the Downloads tab, to assess your current malware
protection architecture.
2. Set objective — Identify what level of malware attacks you need protection against.
This determines the objective maturity level for malware protection architecture.
Setting the objective also determines a high-level architecture.
3. Implement improvements — Use the Excel tool and the high-level architecture of
Step 2 to plan the implementation of improvements to get your architecture to the
required future state.

Figure 1. Guidance Framework for Building an Effective Malware Protection Architecture
1. Assess Your Current Malware Protection Architecture Maturity

Use the accompanying Excel tool to assess your current controls for each of the following
control areas: processes, endpoints, email, web and network. Answer all questions in each
of the five tabs corresponding to each of the control areas. Figure 2 includes an example
of the assessment questions for the endpoint controls area.
Answer “Yes” for all controls that are met by your organization’s malware protection
architecture. Answer “No” in all other cases. The sheets have a fourth column, not shown
in Figure 2, for entering implementation notes. This column can also be used to log the
rationale for not implementing or compensating controls.

Figure 2. Example of the Excel Tool Accompanying the Guidance Document
Source: Gartner
After finishing the five tabs for each of the control areas, analyze the results, which are
summarized in the Scoring tab of the Excel tool. The first result shows the scoring in
tabular form, similar to Figure 3.
Figure 3. Initial Assessment: Tabular Results
Source: Gartner

The assessment in the Excel tool uses a lower threshold of 80% to meet a level. The
average level is computed as an average of the partial results. The average level helps you
see which level the organization is closest to. It is included in the far right column to give
you an easy view of the deltas between the partial results and the average level. This is
further visualized in a radar diagram, an example of which is shown in Figure 4.
Figure 4. Initial Assessment: Visual Representation
In Figure 4, the blue line corresponds to the partial results per control category. The red
dotted line depicts the average level. Figure 4 clearly shows the delta between the
individual control levels and the level the organization is closest to.
2. Set Objective Malware Protection Maturity Level

So far, we have been discussing, and even assessing, maturity levels without saying what
these really are. Figure 5 summarizes the maturity model that plays a critical role in this
guidance document.

Figure 5. Matching Malware Protection Capabilities With Attack Threat Levels
The vertical axis depicts the attacker’s capabilities. The red text summarizes the typical
techniques and/or methods used by malware attackers at the corresponding level. The VT
indicator in the red text gives an indication of the number of engines in VirusTotal that
would detect such malware. Before planning the maturity of the malware protection
capabilities, security professionals must make a conscious decision: Up to what level of
attacks do we need protection? Higher protection comes at a higher cost with respect to
licenses, IT operational overhead and user impact. Failure to decide on the required
protection level — that is, the “height” in Figure 5 — may lead to overprotection,
underprotection or imbalance.
The line in Figure 5 that connects malware attack threat levels with capability maturity
levels is not a straight line; it is wobbly by design. The framework portrayed is by no
means an exact science. Organizations should use the resulting advice as a strong
recommendation but must almost always adapt it to their own best judgment and the
organization’s specific situation.

The horizontal axis in Figure 5 shows the different capability maturity levels for malware
protection. The blue text, at a high level, describes the activities or architectural
components required to move to the next maturity level. In this step, we will only discuss
these at a high level. The actual selection and implementation take place in the last step,
Step 3, of the guidance framework, which contains detailed architecture diagrams and
control descriptions.
Malware Threat Assessments

Security professionals make architectural choices based on the levels of attack they need
to protect against. Every organization draws the line in Figure 5 at a certain height — that
is, a height that fits the risk tolerance. The residual risk is accepted. The implication is that
a balanced malware protection architecture starts with a malware threat assessment to
understand the attack levels that an organization is exposed to. Failure to understand
common and less common attack methods leaves organizations at the mercy of vendors
to explain how “big” the problems are and how “good” the solutions are. For more
information on threat assessments, see “Best Practices for a Successful Security Risk
Assessment.”
For the context of this assessment, the definition for an attack scenario should be
granular enough to make an informed assessment of required malware protection
maturity. Too little granularity does not allow for sufficient differentiation between
different attacks and will lead to too few maturity levels to be usable. The improvement
steps between maturity levels would be too large. Security architects will find benefit from
more granularity when they start planning recommended improvements. The
accompanying Excel tool, or alternatively the tables in the Capability Maturity Model: A
Detailed Definition section, provide guidance for such granularity. When useful for making
architectural decisions, we also provide additional references in the section on Gartner
recommended reading.
Table 1 defines the elements that make up our definition of an attack scenario. Table 2
provides more details on the levels for the infection and payload techniques.

Table 1: Attack Scenarios
Channel Infection Techniques Payload Techniques
■ Internet ■ Level 1: Old malware ■ Level 1: Old

communication: in email, USB or payload,known
Email download hashes
■ Internet ■ Level 2: Common ■ Level 2: Common

communication: Web exploitin client payloads, simple
application variants of old
■ Internal
connectivity:Lateral ■ Level 3: Recent ■ Level 3: New and
spread exploit to recent obfuscated for
vulnerability detection evasion
■ Physical access:
USBor direct physical ■ Level 4: Targeted ■ Level 4: Targeted, no
access (supply chain, through zero day in reuse of attack
evil maid, firmware) application identifiers
■ Level 5: Advanced ■ Level 5: Advanced,

through new evasion across
techniques multiple layers
Source: Gartner
A rationale exists for including channel, infection and payload in the definition in Table 1.
Channel, or rather a combination of channels, defines how the attacker will execute. This
is a critical aspect in our use of the definition of a scenario because this defines the
options for protection. Attacks leveraging email, for example, lend themselves to controls
in the email gateway and the endpoint. The list of channels is purposely incomplete to
avoid complicating the definition. However, it covers the vast majority of attacks. In
summary, channel defines the “where” of an attack.
Other research of ours provides detailed advice for each of the channels in Table 1. For
more on endpoint protection, see “Comparing Endpoint Techniques for Malware
Protection.” For email, see “How to Build an Effective Email Security Architecture,” and for
web, see “Using Secure Web Gateway Technologies to Protect Users and Endpoints.” See
the recommended reading section for more references.

Table 1 combines all attack stages into only two: infection technique and payload
technique. Splitting attacks across more stages of the kill chain is not necessary for the
scope of this research. Other research, such as the endpoint and email security
documents referenced above, goes into more detail. For detailed attack techniques used
by attackers, see MITRE ATT&CK.
The infection and payload techniques define the “how” of an attack. These are split into
five levels in Table 2. Attackers may use infection techniques at levels other than those for
which they can use payload-specific techniques. From a defender’s perspective, the level
of attack must be matched by an equally strong protection measure. To protect against
attacks that cross rows in Table 2, defenders have a choice:
■ Defend at the lowest level of the used techniques: This would suffice to either
disrupt the infection or disrupt the payload, but not both. This is a weak strategy
because it is likely that an attacker has the capacity to change to a slightly more
complex attack, which would succeed.
■ Defend at the highest level of the used techniques: This is the right strategy
because it protects against attackers at both the infection and the payload stages
and can better handle variations in attack techniques.

Table 2: The Five Threat Levels: A High Level Overview
(Enlarged table in Appendix)
Recommended Minimum Maturity Objectives

We estimate that 60% of all malware attacks are at Level 2 or lower (most at Level 2) in
Table 2. An estimated 90% of all malware attacks, including the majority of ransomware
attacks, are Level 3 or lower, and well over 99% are at Level 4 or lower. Note, however, that
while the likelihood of being hit by a high-level attacker is low, the potential impact of such
an attack may be huge.
Not all architectural decisions are based on risk. Some are triggered by auditors or
compliance. External requirements may lead architects to implement controls that may
not be necessary from a pure threat perspective.

Use the attack scenarios in Table 2 to set a goal for your malware protection capability.
Very few organizations will set Level 5 as a target malware protection maturity when they
consider the costs in the form of licenses and IT operations overhead, as well as the
impact on users.
However, with most malware attacks taking place at threat Level 1, 2 or 3, all
organizations should have an ambition to reach at least Level 3. With the increase of
highly evasive attacks on endpoints, most organizations should plan to adopt various
maturity Level 4 controls. Even not-so-risk-averse organizations may find themselves in a
position where some application of Level 5 controls are within reach, for example by
enabling remote browser isolation in an existing secure email gateway. They should take
this opportunity.
Level 3 is a minimum maturity for most environments in most organizations. Implement

all controls at Level 3 to confidently disrupt widespread malware attacks at multiple
attack stages. Most organizations should pick a select set of Level 4 controls to disrupt
more advanced techniques at some attack stages, balancing added security with impact
on operations and users. Choose Level 5 controls if your organization is very risk averse
or if these are available from your existing security solutions with acceptable impact.
This guidance does not distinguish between malware objectives. Technical professionals
can add such nuance when planning controls that are specific to some categories of
malware. For example, some specific endpoint security techniques work against
ransomware but do nothing to stop data exfiltration, and vice versa. This level of detail is
out of scope for this document. For ransomware, see for example “Defend Against and
Respond to Ransomware Attacks.”
3. Implement Improvements to Reach Objective

The capability maturity model for malware protection consists of five levels, such that:
■ Capabilities match the attack levels of Table 2. Of course, some nuance has to be
applied here, but roughly, it holds that “Use Level n and lower to combat malware
threats Level n and lower.”

■ The levels are detailed enough to be usable for:
■ Process planning
■ Product type selection (“Should I use a product that can do X or should I not
care?”)
■ High-level product configuration advice (“Should I enable Feature X or not?”)
This section defines the maturity levels and recommends high-level steps for
improvement. The Capability Maturity Model: A Detailed Definition section provides
security architects with a more detailed definition of the maturity levels. For this purpose,
the Excel tool accompanying this guidance framework as well as the Capability Maturity
Model: A Detailed Definition section splits the maturity model between processes,
endpoints, email, web and network.
Use the Excel tool to analyze all entries that you have answered “no” that form the gap to
reaching the objective maturity level in each of the five controls areas. For each control
where you have answered “no,” choose between the following two options:
■ Implement the control — Optionally, document how you implemented this.
■ Ignore this control — It is critical to document why it is acceptable to not implement

this control. For example, you may document how this control is not applicable to
your organization, or how this is compensated for by the implementation of other
controls. The Excel spreadsheet includes a column to mark the reason.
Level 1: Ad Hoc
The lowest level for capability maturity is called “Ad Hoc.” Organizations that fall into this
category do not invest in centralized security or architecture and processes.
Contradictory to what most security architects may think, many organizations have
endpoints that are at Level 1. Consider this: Do you allow enterprise email processed on
employee-owned endpoints? Do you allow your users to work on corporate documents on
unmanaged endpoints, for example in a work-from-home scenario? If so, those endpoints
effectively are at Level 1.
Characteristics
Figure 6 characterizes the architecture for a “Level 1: Ad Hoc” malware protection
maturity.

Figure 6. Characteristic Architecture for a “Level 1: Ad Hoc” Malware Protection Maturity
The following process and control identifiers are typical for a Level 1 malware protection
capability:
■ Process — Processes related to malware protection are undefined. Activities are ad

hoc, with unrepeatable outcomes. Level 1 malware protection heavily relies on
individual users and IT departments “doing the right thing.” The mitigation of large
malware outbreaks requires huge effort, assuming they are discovered in the first
place.
■ Controls — The organization makes inconsistent use of technology, often with

different solutions in different regions and no oversight and control. There is a lack
of centrally enforced security controls across the network and endpoints. The use of
endpoint AV and host firewall is completely ad hoc. Most users are local admin.
There is a major dependency on OS vendors, individual users and/or service
providers for basic AV.
Please refer to the accompanying Excel tool or the tables in the Capability Maturity Model:
A Detailed Definition section for a complete list of the controls at a Level 1 malware
Attack Scenarios Mitigated

Organizations at maturity Level 1 cannot expect malware protection. By sheer
coincidence, the architecture may provide protection against Level 1 attack scenarios, or
“old” malware. The organization may be lucky and achieve better protection because of
great work by individuals or great performance by the endpoint AV that users happen to
use. Typically, Level 1 provides no guarantee whatsoever to achieve a particular protection
level.
Attackers have many ways to successfully attack this level:
■ Have users download and install malware, typically through social engineering.
■ Exploit missing patches through web, email or network.
■ Reuse existing malware but avoid widespread recent malware.
■ Drop new payloads on endpoints that are already compromised. (It is likely that
some of the Level 1 endpoints have already been compromised.)
In summary, there are many, mostly trivial ways to compromise endpoints at Level 1 at
very low cost.
Recommended Actions for Improvement

From a process perspective, technical professionals improving malware protection to
Level 2 should:
■ Document malware response processes for endpoints, email and web (siloed).
■ Setup centralized management for AV, email security and URL filtering.
■ Implement backup and recovery.
From a controls perspective, technical professionals focusing on malware protection

should:
■ Standardize on technology and configuration for endpoint AV (client and server),

patch management and endpoint backup.
■ Limit the use of privileged accounts, such as Windows local administrator.
■ Standardize hardware and golden images for client endpoints and mobile devices.

■ Implement and centralize email security and URL filtering — either as a secure web
gateway (SWG) or as a firewall (FW) or intrusion prevention system (IPS) capability.
■ Use existing network controls (IPSs or FWs) for basic malware prevention and C&C
communication detection.
See the Capability Maturity Model: A Detailed Definition section and the accompanying
Excel tool for details on these recommended process and control improvements.
Recommended Reading
For more information, see “Building the Foundations for Effective Security Hygiene.”
Level 2: Basic
Gartner refers to Level 2 for capability maturity as “Basic.” Organizations at Level 2 fear
infection by common malware, yet they accept or are unaware of their exposure to a large
category of malware variants. They find low IT operations overhead and low user impact
more important than the protection against malware incidents.
Characteristics
The architecture for a “Level 2: Basic” malware protection maturity is characterized in
Figure 7.

Figure 7. Characteristic Architecture for a “Level 2: Basic” Malware Protection Maturity
The following process and control identifiers are typical for a Level 2 malware protection
capability:
■ Process — A malware response process is defined, documented and performed. The

process is not holistic, but rather applies to endpoints, email and web in silos.
Endpoint antivirus and patch management is somewhat centralized, but instead of
being a security responsibility it typically resides in the desktop management group.
Endpoints are regularly backed up.
■ Controls — This includes centrally managed antivirus and OS patching, use of an

email security solution and URL filtering. Mobile devices require minimum versions
(without known critical vulnerabilities). Firewalls and/or IPS are leveraged for
network AV and C&C detection.
A Detailed Definition section for all the controls that are typical for a Level 2 malware

Organizations at maturity Level 2 achieve protection against Level 1 and 2 attack
scenarios, or “old” and “common” malware. By use of a documented malware response
process and centralized control, the organization can perform some coordinated
responses to outbreaks. Level 2 organizations lack solid prevention against a large and
ever-increasing number of new malware variants.
Attackers have many ways to successfully attack Level 2 malware protection

architectures:
■ Use new or benign URLs for exploit or payload. A weak SWG will not protect against
such malicious URLs.
■ Phish users — lure them into opening attachments or clicking links. Basic secure
email gateways (SEGs) lack strong protection against phishing.
■ Exploit missing security patches in applications, typically through web or email. Even
though Level 2 architectures have some patch management, this process at this
maturity is typically not optimized for achieving the highest security level.
■ Use nontrivial variants of malware. Low-end SEGs, SWGs and AVs have low
detection rates on such variants.
In summary, Level 2 architectures are subject to attacks that can be achieved by

leveraging a good exploit kit and/or spam botnet.

Level 3 should:
■ Document architecture diagrams that include all components for malware

prevention across network and endpoints.
■ Introduce security awareness training focused on common threats. For malware, the
most relevant areas to include are removable media, email (phishing), and web
browsing and downloading.
■ Follow a coordinated malware incident response process across endpoint, email,

web and network.
■ Remove local admin privileges from (almost) all users, or actively manage them.

■ Formalize a vulnerability management process for OS and client applications, and
report centrally.
From a controls perspective, technical professionals improving malware protection to

Level 3 should:
■ Evolve a standard AV solution to a best-of breed endpoint protection platform (EPP)

deployment. Such a solution goes beyond signatures and heuristics, and its
configuration is optimized for detection.
■ Use basic exploit mitigation technologies. If the EPP does not include these
technologies, choose the OS capabilities or a third-party solution.
■ Maintain an inventory of all applications.
■ Control the use of removable media.
■ Use enterprise mobility management (EMM) to manage mobile devices and

corporate mobile applications and data
■ Use secure email gateways and secure web gateways that have sandbox integration
and that are optimally configured for malware detection.
■ In SaaS-heavy environments, use cloud access security broker (CASB) functionality

to detect and protect against malware.
Excel tool for more recommended process and control improvements.
Recommended Reading
For more information, see “Building the Foundations for Effective Security Hygiene,”
“Evaluation Criteria for Endpoint Protection Platforms,” “How to Build and Effective Email
Security Architecture” and “Using Secure Web Gateway Technologies to Protect Users and
Endpoints.”

Level 3: Managed
Level 3 capability maturity for malware protection is referred to as “Managed.” At Level 3,
organizations recognize malware as a significant threat to their business. They treat
malware protection holistically, across different channels, and they afford increased IT
operations overhead and user impact for protection against the majority of malware
attacks. We view Level 3 the minimum malware protection level for most endpoints in
most organizations. Lower levels should only apply to exceptions (such as work-from-
home scenarios or bring your own device). Most of our clients go beyond Level 3 with a
selection of multiple Level 4 and some Level 5 controls.
Characteristics
Figure 8 shows a “Level 3: Managed” architecture for malware protection.
Figure 8. Characteristic Architecture for a “Level 3: Managed” Malware Protection

Maturity

Organizations at maturity Level 3 for malware protection are characterized by:
■ Process — This involves up-to-date and detailed architecture diagrams for all
components involved in malware protection, overreaching all aspects of malware
protection across the network, client endpoints, server endpoints and users. It also
includes rigorous process descriptions for malware detection as part of security
monitoring. Malware recovery processes are well-defined and regularly tested.
Security awareness training is conducted regularly. The vulnerability management
process is formalized. All endpoints are subject to least privilege.
■ Controls — This involves:
■ Centrally managed EPP with audited optimized settings for preventing malware
infection and spread.
■ Inventory of applications.
■ Control of removable media.
■ Centralized vulnerability management.
■ EMM and mobile application management (MAM) to manage the security

configurations of mobile devices and enterprise apps.
■ Multi-AV SEG with sandbox integration, URL inspection and rewrite and
inbound email tagging. SEG should include spoof protection, best-of-breed
phishing protection as well as inbound email tagging.
■ SWG with AV and browser exploit detection as well as sandbox integration. The
SWG should also apply web app control.
■ C&C detection in the SWG and network (FW and IPS).
■ Secure Sockets Layer (SSL) decryption to detect downloads of malicious

content or outbound internet traffic that may indicate a compromised endpoint.
■ In SaaS-heavy environments, CASB functionality is used to detect and protect

against malware.
A Detailed Definition section for more details.

Organizations at maturity Level 3 achieve protection against Level 1, 2 and 3 attack
scenarios: “old,” “common” and “new” malware. An architecture at Level 3 malware
protection suffices to protect against the majority of untargeted malware attacks. Level 3
processes and controls provide a solid prevention against a large and ever-increasing
number of new variants of malware. Organizations at Level 3 may choose to improve
maturity to combat targeted malware attacks — that is, attacks designed to evade
detection by the technology in use. Such improvements require controls at the next level,
Level 4.
Attackers have some ways to successfully attack this level, but attackers must get
targeted to evade detection. Attackers can, for example, use the following techniques:
■ Exploits to very recent vulnerabilities: Exploits must be advanced enough to evade

basic mitigations such as data execution prevention and address space layout
randomization (ASLR).
■ Sandbox evasion techniques or file types not covered by common sandboxes
■ Exploitation of monitoring weaknesses, such as the fact that many network

sandboxes are set up for detection only.
■ Evasive fileless attacks to infect, spread and obtain persistence
■ Evasion of rule-based behavior analysis and signatures
In summary, successful attacks against Level 3 architectures are achievable by leveraging

the strongest exploit kits, but some customization is required to evade the controls.

Level 4 should:
■ Establish a threat intelligence exchange between separate malware protection

components. Threat intelligence derived by one solution should be used in blocking
decisions in other components.
■ Implement 24/7 security monitoring and response across network and endpoints;
employ continuous security testing as well.
■ Security awareness must include targeted attack techniques, such as spear phishing,
removable media use and physical compromise.

Level 4 should:
■ Enhance EPP with additional technologies, such as machine learning, best-of-breed

behavior analysis and endpoint detection and response (EDR). Deploy application
control on exposed client and server endpoints. In case the EPP does not provide
these capabilities, complement it with third-party solutions, or consider switching to
another EPP.
■ Deploy a mobile threat defense (MTD) solution across mobile devices.
■ Use server security suites on all server roles, including servers deployed in
infrastructure as a service (IaaS).
■ Choose a best-of-breed SEG, and enhance protection with strict controls on

attachment file types, URLs and anomaly detection. Apply fine-grained tagging to
emails, which provides continuous security awareness for suspicious messages.
■ Choose a best-of-breed SWG, and enhance protection with strict controls on file
downloads, use of extensions (such as Adobe Flash and Java applets) and exploit
mitigations.
■ Deploy network advanced threat detection that is behavior-based, anomaly-based or

designed to detect lateral spread or exfiltration. Use distributed deception for
improved detection of targeted attacks.
Excel tool for more on recommended process and control improvements.
Recommended Reading
In addition to the recommended research on SEG and SWG provided in the Level 2: Basic
section, see “Market Guide for Endpoint Detection and Response Solutions,” “Solution
Comparison for Endpoint Detection and Response Technologies and Solutions” and “How
to Plan, Implement and Operate a Successful Application Control Deployment.” For server
security, see “Improve Your Cloud Security With Cloud Workload Protection Platforms.” For
details on mobile security, see “Mobile OSs and Device Security: A Comparison of
Platforms” and “Market Guide for Mobile Threat Defense.”

Level 4: Controlled
Capability maturity Level 4 is called “Controlled.” At this level, organizations fully
understand and measure their malware protection capabilities across all best-of-breed
technologies used and processes in place. At Level 4, organizations realize targeted
attacks evade malware prevention controls and invest in robust malware detection and
response capabilities.
Characteristics
Figure 9 illustrates a typical malware protection architecture for a “Level 4: Controlled”
organization.
Figure 9. Characteristic Architecture for a “Level 4: Controlled” Malware Protection

Maturity

Organizations at Level 4 for malware protection share the following characteristics:
■ Process — Malware protection and response follow processes that are entirely
predictable and controlled, and that use quantitative techniques. Quality and
performance are understood and continuously tested across all malware protection
processes. Brand protection services and security awareness focusing on targeted
techniques, such as spear phishing, are in place.
■ Controls — This includes best-of-breed solutions across all potential attack

channels. All solutions are fully optimized for prevention and detection. Mobile
threat defense is used for threat protection across mobile devices. Behavior-based
network threat detection and deception are used for detection.

Organizations at maturity Level 4 achieve protection against Level 1, 2, 3 and 4 attack
scenarios: “old,” “common,” “new” and some “targeted” malware. Level 4 malware
protection includes protection against evasive malware, which is malware purposely
adapted to evade detection by the organization’s controls. Level 4 processes and controls
are integrated and work together for optimized detection of nonstandard attacks. Malware
protection quality is measured and reported, and the organization has a great
understanding of the limitations of its security controls. Organizations at Level 4 carefully
compensate gaps in prevention by using multiple layers of detection controls.
Organizations at Level 4 may choose to improve maturity by leveraging technologies to
avoid exposure to any potential compromise.
Attackers have limited ways to successfully attack this level, typically at very high cost:
■ Deep social engineering. Attackers cannot use any asset (such as IP address, email
address, malware component) of poor reputation, so they must carefully establish
such trust over time or work from compromised assets of good reputation.
■ New exploit techniques applied to zero-day vulnerabilities
■ Best-of-breed evasion across all static and dynamic analysis techniques used by the
target

■ Removing traces of attacks and interfering with network and endpoint detection
technologies
■ Hiding from any detection and prevention processes
In other words, these require manual effort by attackers, with significant cost, effort and
time to develop and prepare.

Level 5 should:
■ Not allow direct, nonisolated internet access and disallow the opening of tainted
content from workstations and servers. They should only grant such access as a
temporary exception on machines that can be discarded or reset after such use.
■ Adopt incremental and innovative technologies and continuous optimization.

Address variations in effectiveness, and change controls continuously.
■ Use threat hunting across endpoints and the network.
■ Embed security awareness as a continuous activity in all end-user workflows.

Level 5 should:
■ Leverage techniques that do not depend on detecting malware or attacks but that
reduce exposure. Examples of such controls include:
■ Content disarm and reconstruction (CDR) for email attachments and file
downloads
■ Blocking any tainted content that cannot be disarmed
■ Application isolation and remote browsing
■ Application control
■ Signing of all email

■ Leverage techniques that are not part of the exposed software stack of the endpoint
under attack and therefore cannot be directly impacted by attackers. Examples of
such controls are:
■ Hardware-assisted containment and OS integrity
■ Trusted Platform Module (TPM) integrity verification
■ Control flow integrity (CFI)
■ Remote attestation of unknown files and device health
Excel tool for more on recommended process and control improvements.
Recommended Reading
See the recommended research on endpoints, SEG and SWG referred to at the previous
levels. Choose the configurations for optimal protection in the referenced research notes.
See “Market Guide for Mobile Threat Defense” for detailed information on MTD solutions
and capabilities. For additional information about deception, see “Solution Comparison
for Six Threat Deception Platforms” and “Applying Deception Technologies and
Techniques to Improve Threat Detection and Response.”
Level 5: Avoiding
Level 5 capability maturity for malware protection is referred to as “Avoiding.” At Level 5,
organizations recognize malware as an unacceptable threat to their business. They
complement the optimized malware protection, detection and response capabilities of
Level 4 by applying techniques to avoid the potential for compromise as much as
possible, and security trumps reduced usability in all circumstances. Level 5 builds on top
of the lower levels. Architects cannot skip controls of lower levels, because no endpoint
can fully avoid exposure to all attacks.
Characteristics
Figure 10 demonstrates a “Level 5: Avoiding” architecture for malware protection, but not
all Level 5 controls can be easily depicted at this high level.

Figure 10. Characteristic Architecture for a “Level 5: Avoiding” Malware Protection
Maturity
Organizations at maturity Level 5 for malware protection are characterized by:
■ Process — Invest in incremental and innovative technologies and continuous

optimization. Address variations in effectiveness and change controls continuously
for improved prevention and detection. Use advanced detection and threat hunting
across endpoints and the network, and embed security awareness in all user
workflows.

■ Controls — In addition to trying to detect malignance, implement a strategy
exclusively allowing known good across all channels. Take an allow list, disarm and
isolate approach. Isolate at the network, endpoints and applications as well as at the
data level, never intermingling trusted and untrusted assets. Externalize controls
from endpoints under attack by leveraging virtualization, remote browsing and the
disarming of all tainted content. Use moving target defense patterns wherever
possible. Use distributed deception for detection.

Organizations at maturity Level 5 achieve protection against known and unknown
malware by minimizing exposure to potential compromise. Perfect implementation of
processes and tools is impossible, so even a 100% score in the accompanying Excel sheet
does not mean that the organization is perfectly protected against all malware.
Recommended Reading
The controls at Level 5 are described in detail in “5 Core Security Patterns to Protect
Against Highly Evasive Attacks.”
Risks and Pitfalls

Defining a malware protection architecture and roadmap can be achieved at relatively low
cost and effort, and it will prevent unnecessary purchases of new products. Assessing
existing maturity and defining a roadmap should not take more than two weeks for an
experienced security professional. Security professionals can use and adapt the approach
taken in this research for this purpose.
Following the guidance presented here comes with several risks and pitfalls to technical
professionals who plan to make their organization’s malware protection capabilities
mature:
■ Improving an architecture across the network and client and server endpoints, with
purchases at different times by different teams, requires strong governance
practices and coordination. These cross-architecture aspects are critical in the
endeavor, but they are hard to achieve from a political point of view in some
organizations.

■ Malware protection is the result of the use and configuration of security network and
endpoint components as well as other OS and network components. This requires
coordination beyond security and must include desktop, server, cloud and network
architects, which is a challenge in many organizations.
■ Taking overzealously large steps in the maturity model leads to long project times
and uncertain outcomes before completion. Prioritizing specific controls from higher
levels is perfectly fine, and even highly recommended if these come as low-hanging
fruit or if required by compliance. But overall, take small steps toward the next
maturity level.
■ Deep integration between products of different vendors is virtually nonexistent,

except at the security information and event management (SIEM) and process
(malware investigation and incident response) levels. Some organizations have built
it on their own, but it takes work.
■ Using more aggressive malware prevention capabilities such as advanced heuristics

or behavior-based blocking, both as capabilities of existing solutions as well as new
solutions, may impact the user and lead to higher operational overhead.
Capability Maturity Model: A Detailed Definition

This section provides details that help security architects improve malware protection
maturity. First, this section splits the maturity model among the most important channels,
which are endpoints, email, web and network, but we start with cross-channel controls.
Table 3 lays out the detailed controls for the processes controls area. These are identical
to the controls in the Excel tool.

Table 3: Capability Maturity Model for Malware Protection Processes
Table 4 details endpoint protection controls for each of the five identified maturity levels.
These are identical to the controls in the Excel tool. For more information on endpoint
security controls, see “Solution Criteria for Endpoint Protection Platforms” and
“Comparing Endpoint Techniques for Malware Protection.”

Table 4: Capability Maturity Model for Endpoint Malware Protection
Table 5 details email protection controls for each of the five identified maturity levels.
These are identical to the controls in the Excel tool. For more information and a tool
dedicated at email security architecture, see “How to Build an Effective Email Security
Architecture.”

Table 5: Capability Maturity Model for Email Malware Protection
Table 6 details web protection controls for each of the five identified maturity levels.
These are identical to the controls in the Excel tool.

Table 6: Capability Maturity Model for Web Malware Protection
Table 7 details network protection controls for each of the five identified maturity levels.
These are identical to the controls in the Excel tool.

Table 7: Capability Maturity Model for Network Malware Protection
Document Revision History

How to Build an Effective Malware Protection Architecture - 13 November 2018
Improving Malware Protection Maturity by Using Attack Scenarios - 21 March 2017
Recommended by the Author

Some documents may not be available as part of your current Gartner subscription.
Comparing Techniques for Endpoint Protection
5 Core Security Patterns to Protect Against Highly Evasive Attacks

Solution Criteria for Endpoint Protection Platforms

Using Secure Web Gateway Technologies to Protect Users and Endpoints
How to Build an Effective Email Security Architecture
Magic Quadrant for Endpoint Protection Platforms

Critical Capabilities for Endpoint Protection Platforms
© 2021 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of
Gartner, Inc. and its affiliates. This publication may not be reproduced or distributed in any form
without Gartner's prior written permission. It consists of the opinions of Gartner's research
organization, which should not be construed as statements of fact. While the information contained in
this publication has been obtained from sources believed to be reliable, Gartner disclaims all warranties
as to the accuracy, completeness or adequacy of such information. Although Gartner research may
address legal and financial issues, Gartner does not provide legal or investment advice and its research
should not be construed or used as such. Your access and use of this publication are governed by
Gartner’s Usage Policy. Gartner prides itself on its reputation for independence and objectivity. Its
research is produced independently by its research organization without input or influence from any
third party. For further information, see "Guiding Principles on Independence and Objectivity."

Table 1: Attack Scenarios
Channel Infection Techniques Payload Techniques
■ Internet communication: Email ■ Level 1: Old malware in email, USB or download ■ Level 1: Old payload,known hashes
■ Internet communication: Web ■ Level 2: Common exploitin client application ■ Level 2: Common payloads, simple variants of
old
■ Internal connectivity:Lateral spread ■ Level 3: Recent exploit to recent vulnerability
■ Level 3: New and obfuscated for detection
■ Physical access: USBor direct physical access ■ Level 4: Targeted through zero day in
evasion
(supply chain, evil maid, firmware) application
■ Level 4: Targeted, no reuse of attack identifiers
■ Level 5: Advanced through new techniques
■ Level 5: Advanced, evasion across multiple
layers
Source: Gartner
Gartner, Inc. | G00726637 Page 1A of 20A

Table 2: The Five Threat Levels: A High Level Overview
Level General Attack General Attacker Infection-Specific Payload-Specific

Characteristics Characteristics Characteristics Characteristics
Level 1: Old Old malware, still floating Achievable by everyone using ■ Email attachment ■ Widespread malware
around on USB, backups and readily available payloads. containing old, executable, payloads
email inboxes payload or droppers
■ Hashes known for at least
■ Old malware files on USB three months
■ Direct download of ■ Use of common command

malware payload from and control (C&C)
internet (e.g., weaponized channels with known
freeware) malicious IP addresses
■ VT detection expected
above 80% (all but the
weakest solutions would
catch it)
Level 2: Common Infection through fully Achievable by everyone using Exploit of a known, and old, ■ Trivial variants of common
opportunistic, ad hoc and basic exploit kits, phishing kits vulnerability (with patch at malware (e.g., padding a
commonly available means and/or spam botnets. least three months old) in a character)
(basic exploit kits and client application commonly
■ Variations in used IP
phishing kits, no used for processing tainted
addresses and file hashes,
customization) content (browser, PDF reader,
but reuse of major
Microsoft Office)

components, behavior and
infection methods
■ VT detection expected
between 40% to 80% (i.e.,
most solutions would
catch it)
Level 3: New Use of polymorphism to reach ■ Achievable by everyone ■ Exploit of a known, but ■ Quickly morphing variants
maximum infection without with access to the best recent, vulnerability (at of common malware, but
becoming targeted exploit and malware kits most three months old) in reuse of behavior
available. a client application
■ Files obfuscated to evade
commonly used for
■ This is the highest attacker detection by the majority
processing tainted content
level before becoming of standard AV and poor
(browser, PDF reader,
targeted. sandboxes
Office)
■ Standard fileless
■ Fully automated lateral techniques
spread
■ VT detection expected 5%
to 40% (i.e., strong
solutions would likely
catch it)
Level 4: Targeted Targeted attack, initiated by Achievable by attackers ■ Zero day in client ■ Obfuscated to evade
person, evading detection by capable of adapting attack application detection by leading
solutions used by target sandboxes; no reuse of

frameworks for a specific ■ Crafty exploit, known common attack identifiers
target. technique adapted for new (filenames, components,
applications or new OS behavior, etc.)
■ Manual lateral spread ■ Advanced fileless

(e.g., after server techniques
compromise)
■ Stealth to defeat detection
■ Targeted entry into (e.g., masquerading as
organization through benign, indicator removal
vulnerability or poor from host and tools)
configuration (e.g., remote
■ VT detection expected <5%
desktop protocol)
(i.e., only the strongest
have a small chance to
detect)
Level 5: Advanced New attack type leveraging Achievable only by the most ■ Zero-day exploit leveraging ■ Known benign, signed or
exploits in privileged code, advanced attackers capable of new techniques in-memory only
with completely new payload using new attack techniques.
■ Exploit in privileged code ■ Hidden in firmware or
types, highly evasive, highly
other components not
targeted (single target) ■ Abuse of benign
visible to OS
applications
■ Advanced evasion within
■ Firmware/BIOS
multiple layers;
persistency
undetectable by common
■ Malware plant through block-listing techniques
physical access

■ No or greatly obfuscated
communication
■ VT detection 0% (i.e., no
file antivirus will detect it)
Source: Gartner

Table 3: Capability Maturity Model for Malware Protection Processes
Level Additional Information
Level 1: Ad Hoc
Organization acknowledges the need for processes. Answer “Yes” even if you have no or purely ad hoc policy management,
reporting and response.
Organization acknowledges the need for integration. Answer “Yes” even if you have no integration between solutions and all
malware solutions are used in isolation.
Organization acknowledges the need for awareness. Answer “Yes” even if you have no security awareness activities.
Level 2: Basic
Incident response activities are defined for malware incidents. Documented response processes exist that are fully reliant on existing
endpoint, email and web malware protection solutions; these processes may
be in isolation.
AV, email security and URL filtering is managed. Processes for managing AV, email security and URL filtering are defined and
executed, but these may be disconnected.
Endpoint backup. Endpoints are being backed up regularly.
Level 3: Managed
Architecture diagrams for malware protection. Up-to-date detailed architecture diagrams for all components involved in
malware protection exist.
Coordinated malware incident response. Malware incident response spans endpoint, email, web and network controls.

No local admin or least-privilege management. No regular user has local admin rights. Optionally, a least-privilege
management solution is used to granularly control local admin rights.
Security awareness training. Security awareness training focusing on common threats; for malware, the
most relevant areas to include are removable media, email (phishing) and
web browsing.
Vulnerability management process. Formalize a vulnerability management process for OS and client applications,
and report centrally.
Level 4: Controlled
Threat intel sharing for malware detection. Exchange, and use, of threat intelligence between malware protection
solutions.
Extended detection and response. Unified security incident detection and response that automatically collects
and correlates data from multiple proprietary security components.
Quantitative indicators. Quantitative indicators are used throughout malware protection processes.
24/7 security monitoring. Fully operational 24/7 security monitoring based on endpoint OS events, EDR,
EPP, SEG, SWG and network — FW, IPS and network traffic analysis (NTA) —
events.
Malware response SLAs (third party). SLA with third party for malware response (investigation and remediation).
Brand protection. Brand protection services (tracking domain registrations, brand abuse, social
media, etc.).
Continuous testing. Continuous testing of malware detection, prevention and remediation

capabilities. For example, breach and attack simulation (BAS) tools can be
used for this.

Focused security awareness. Improve security awareness by focusing attention on more targeted attacks,
such as spear phishing, and physical attacks on networks and endpoints.
Level 5: Avoiding
Continuously improving processes and architecture. Continuously improve and adapt your architecture for malware protection,
and fully integrate it across client and server endpoints and network.
Reverse engineering and malware analysis. Set up internal malware reverse engineering and analysis capabilities to
dissect unknown files and determine their malignance.
Threat hunting. Threat hunting across endpoints and the network.
Embedded security awareness. Security awareness embedded in all end-user workflows; it is a continuous
activity.
Source: Gartner

Table 4: Capability Maturity Model for Endpoint Malware Protection
Level 1: Ad Hoc
Antivirus and host firewall on all client endpoints. Answer “Yes” even if different solutions are used in the organization and if the
configurations are unknown, or default configurations are used.
Organization acknowledges the need for management. Answer “Yes” even if you do not have centralized management and reporting
for endpoint AV.
Organization acknowledges the risk of local admin. Answer “Yes” even if local admin is in use by most or all of your regular users.
Organization acknowledges the need for patching. Answer “Yes” even if your organization has no coordinated patching.
Level 2: Basic
Managed AV across client and server endpoints. AV is usually limited to mainly signatures and heuristics.
Local admin allowed only by exception. A limited set of users or small groups is allowed to have local admin access.
Coordinated patching. Patching is coordinated, typically in the system management group.
Standards for client endpoints. Standardized hardware and golden images for client endpoints.
Require minimum versions for mobile devices. Minimum versions are typically the versions without known critical
vulnerabilities.
Level 3: Managed
Centrally managed EPP with audited optimized settings. The EPP is optimized for preventing malware infection and spread; EPP uses
a combination of basic memory protection and exploit mitigation — data

execution prevention (DEP), address space layout randomization (ASLR) and
heap spray — and extensive use of behavioral detection on all endpoints.
Application inventory. An inventory with all installed applications is kept up-to-date.
Control of removable media. Ports and removable devices are tightly controlled.
Centralized vulnerability management. Management and reporting on vulnerabilities and patches with clear SLA.
Use EMM and MAM to manage mobile devices. EMM and MAM are used to manage the security configurations of all mobile
devices and enterprise apps connecting to corporate resources or processing
corporate data.
Level 4: Controlled
EPP with modern detection methods. The EPP has extensive support for modern detection methods such as
machine learning, heuristics and virtual patching.
Best-of-breed behavior analysis. The EPP is capable of detecting and blocking malware and nonmalware
(fileless or living-off-the-land) attacks on all endpoints.
Extensive memory protection capabilities. Memory protection goes beyond DEP, ASLR and heap spray mitigations.
Extensive use of OS security controls. Central management and reporting across native OS security controls, which
should be optimized for detection/prevention.
Selective use of application control. Application control is used for static client endpoints and the majority of
server roles.
Selective use of EDR for specific categories of endpoints. Endpoints subject to higher risks (laptops, endpoints used by privileged or
VIP users) use EDR.
Monitoring of endpoint, EPP and EDR events. Active management and monitoring of endpoint, EPP and EDR events.

Mobile threat defense. Mobile devices are protected using a mobile threat defense solution.
Attestation of unknown files before execution. Unknown executables and scripts cannot execute until attested to be safe by
a vendor service or a network sandbox.
Comprehensive server security suite or cloud workload protection platform Server security suite or CWPP used across all physical, virtual servers and
(CWPP). IaaS instances, including malware, host-based intrusion prevention system
(HIPS), file integrity monitoring (FIM), virtual patching, application control
and microsegmentation.
Level 5: Avoiding
Isolation of risky exposed processes on endpoints. Processes running on endpoints that use tainted content across servers and
client endpoints must be isolated through containment on the endpoint.
Remote processing for risky processes. Across client endpoints, through browser isolation and remote viewing in the
network.
Use of hardware-supported technologies. Where available, leverage — control flow integrity (CFI) for memory
protection, Intel Virtualization Technology for Directed Input/Output (VT-d)
for containment and application control, TPM for integrity, etc.
Default-deny application control. Application control is deployed across all client and server endpoints.
Endpoint moving target defense. Apply moving target defense to protect against memory attacks on all
endpoints.
Conditional data access. Data access is restricted to authorized users using authorized processes
running on trusted endpoints.
EDR across all endpoints. EDR is deployed and actively monitored across all endpoints.
Endpoint forensics tools and practices. Specialized tools are used for advanced investigation of endpoint behavior.

Source: Gartner

Table 5: Capability Maturity Model for Email Malware Protection
Level 1: Ad Hoc
The organization acknowledges the need for AV in email. Answer “Yes”, even if you have no central AV for email but rather rely on
endpoint and an email provider for malware prevention in email (i.e., relying
on an ISP or cloud email service without good oversight).
Level 2: Basic
Email gateway or email server with standard AV. Email gateway or email server with standard AV scanning of attachments,
typically using a single AV engine.
Detection based on sender and file reputation. Detection mainly based on reputation (e.g., spam block lists and malware
signatures).
Blocking of executables in email attachments. Blocking of executables in email attachments.
Level 3: Managed
Multilayer email protection. Multilayer email protection (SEG, email inbox server and endpoint).
Multi-AV scanning in SEG. Multi-AV scanning in SEG.
Email server hardening and monitoring. Email server hardening and monitoring.
SEG with network sandbox integration. Network sandbox integration (e.g., cloud-based) with SEG.
URL inspection, disarming or rewriting on delivery. URL inspection on delivery (malware, phishing), URL disarming and/or URL
rewriting (redirection).

Basic spoofing protection. Basic spoofing protection (e.g., email address mismatch).
Sender Policy Framework (SPF) and/or DomainKeys Identified Mail (DKIM). SPF and/or DKIM: inbound validation used in SEG, enforced for outbound.
Inbound email tagging. Inbound email tagging.
Level 4: Controlled
Allow-listing file types. Attachment control in the form of allow-listing file types.
Spoofing and impersonation detection. Can be delivered as part of an SEG or as a supplemental solution.
Cousin domain detection. Cousin domain detection.
Anomaly detection. Anomaly detection for business email compromise (BEC) and other low-
prevalent attacks (“outlier detection”).
SPF, DKIM and Domain-Based Message Authentication, Reporting and SPF, DKIM and DMARC for own domain and enforced for inbound.
Conformance (DMARC) in reject or quarantine mode.
Fully customizable advanced threat defense (ATD). Fully customizable ATD/sandbox solution (on-premises).
Integration with secure web gateway. Integration with web for C&C correlation and reuse of categories.
Inbox access control. Inbox access control — two-factor authentication (2FA), conditional access.
Use of DLP for exfiltration detection. Use of DLP for exfiltration detection. This can be content-aware DLP or email
security solutions that focus on limiting outbound mistakes such as
misaddressing email.
Level 5: Avoiding
Content disarming and reconstruction. Content disarming and reconstruction for all attachments.
Strict attachment control. Strict attachment control: file type allow-listing per recipient/sender.

Remote viewing or local isolation of attachments. Remote viewing or local isolation of attachments.
Remote browser isolation for links in email. Links in email open as a remote browsing session.
Anomaly detection for internal email. Anomaly detection for internal email.
Digital signatures on email. Digital signatures on all internal email and select external email.
Source: Gartner

Table 6: Capability Maturity Model for Web Malware Protection
Level 1: Ad Hoc
The organization acknowledges the need for AV in web. Answer “Yes” even if you currently have no malware scan in web channels.
The organization acknowledges the need for URL filtering. Answer “Yes” even if you currently have no, or inconsistent, URL filtering.
Level 2: Basic
URL filtering. URL filtering with policy to prevent visiting known malicious sites in SWG,
firewall, router, IPS or endpoint.
Level 3: Managed
Centralized management and reporting for SWG. Centralized management and reporting for SWG spanning the organization.
SWG with AV scanning. SWG with AV scanning (real-time content inspection).
SWG with protection against uncategorized URLs. SWG with extensive protection against malicious websites not categorized as
malicious (dynamic URL classification).
Known exploit detection and prevention. Known browser exploit detection and prevention (vulnerability shielding) in
SWG/ATD solution.
SWG for off-premises endpoints. SWG for off-premises endpoints (either through endpoint, backhaul or
preferably cloud SWG).
Web application control. Web application control (granular control of web applications beyond
browsers).

Network sandbox integration with SWG. Network sandbox integration with SWG.
C&C detection. C&C detection in the SWG.
SSL decryption. SSL decryption to detect downloads of malicious content or outbound

internet traffic that may indicate a compromised endpoint.
Level 4: Controlled
Download control in the form of allow-listing file types. Download control in the form of allow-listing file types.
Exploit detection and prevention. Exploit detection and prevention for browsers and browser extensions
capable of detecting new exploits.
Granular control over non-HTML content. Granular control over non-HTML content: allow-listing of Java, Flash and
other content on a per-user, per-site basis.
Fully customizable ATD/sandbox solution. Fully customizable ATD/sandbox solution (on-premises).
Integration with email for C&C correlation. Integration with email for C&C correlation to detect whether email threats
have led to actual endpoint compromise.
Use of DLP for exfiltration detection. Use of DLP for exfiltration detection in the SWG.
Level 5: Avoiding
CDR for downloaded content. CDR for downloaded content.
Full web browser isolation. Web browser isolation, either through remote browser isolation, on-endpoint
browser containment or network isolation.
Strict download control. Control the download of files by restricting it to specific file types or even
specific files, sources and downloaders.

Source: Gartner

Table 7: Capability Maturity Model for Network Malware Protection
Level 1: Ad Hoc
The organization acknowledges the role of network AV. Answer “Yes” even if you currently do not use network controls for malware
protection.
Level 2: Basic
AV scanning in firewall and/or network IPS. Enabling gateway AV scanning or malware scanning in network IPS can
prevent the spread of malicious files throughout the network.
C&C communication detection. Firewall or IPS detects communications with known C&C servers.
Level 3: Managed
Bot detection in network. Firewall detects communication with known botnets.
Known exploit detection and prevention. Detection and prevention of known exploits (vulnerability shielding) in
firewalls or IPSs to protect client applications.
Network sandbox integration with firewall or IPS. Network sandbox integration with firewall or IPS.
Network-based outbreak detection. Firewall and IPS events are used to detect malware outbreaks.
SIEM for malware outbreak detection. SIEM with SWG, SEG, FW, IPS and EPP log sources used for monitoring and
malware incident response.
CASB functionality. CASB functionality to detect and protect against malware in SaaS-heavy
environments.

Level 4: Controlled
Advanced threat detection. Advanced threat detection covering behavior-based detection, anomalous
traffic detection (egress) and exfiltration detection.
Distributed deception. Ubiquitous use of deception to detect advanced attackers.
Level 5: Avoiding
Advanced monitoring of user and entity behaviors. Focused on anomalous network behavior.
Software-defined perimeters. To achieve network-based conditional access.
Network moving target defense. To achieve network-based moving target defense.
Microsegmentation in virtual data centers. To prevent lateral movement to and from compromised servers.
Granularly segmented networks. Ubiquitous use of granular segmentation to protect against lateral spread.
Source: Gartner

How To Build An Effective Malware Protection Architecture

Uploaded by

How To Build An Effective Malware Protection Architecture

Uploaded by

How to Build an Effective Malware Protection

Malware protection requires a careful balance between multiple

Gartner, Inc. | G00726637 Page 1 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

■ Improve the maturity of malware protection architecture across endpoints, email,

This approach commonly leads to six potential problems:

■ Unknown effectiveness — Lack of overview makes it hard to assess the overall

■ Unbalance between technology and processes — In many cases, organizations pay

■ Unbalanced technologies — With isolated attention on malware protection in

■ Underprotection — A lack of architecture may result in a failure to address attack

Gartner, Inc. | G00726637 Page 2 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

To overcome these problems, security architects should view malware protection as an

The Gartner Approach

Gartner recommends a structured approach to building a malware protection architecture.

■ Assess the maturity of their current malware protection capabilities.

■ Uncover gaps in their current capabilities.

The Guidance Framework

Gartner, Inc. | G00726637 Page 3 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

Gartner, Inc. | G00726637 Page 4 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

1. Assess Your Current Malware Protection Architecture Maturity

Gartner, Inc. | G00726637 Page 5 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

Figure 3. Initial Assessment: Tabular Results

Gartner, Inc. | G00726637 Page 6 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

Figure 4. Initial Assessment: Visual Representation

2. Set Objective Malware Protection Maturity Level

Gartner, Inc. | G00726637 Page 7 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

Gartner, Inc. | G00726637 Page 8 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

Malware Threat Assessments

Gartner, Inc. | G00726637 Page 9 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

Channel Infection Techniques Payload Techniques

■ Internet ■ Level 1: Old malware ■ Level 1: Old

■ Internet ■ Level 2: Common ■ Level 2: Common

■ Level 5: Advanced ■ Level 5: Advanced,

Gartner, Inc. | G00726637 Page 10 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

Gartner, Inc. | G00726637 Page 11 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

Recommended Minimum Maturity Objectives

Gartner, Inc. | G00726637 Page 12 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

Level 3 is a minimum maturity for most environments in most organizations. Implement

3. Implement Improvements to Reach Objective

Gartner, Inc. | G00726637 Page 13 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

■ High-level product conﬁguration advice (“Should I enable Feature X or not?”)

■ Implement the control — Optionally, document how you implemented this.

■ Ignore this control — It is critical to document why it is acceptable to not implement

Gartner, Inc. | G00726637 Page 14 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

■ Process — Processes related to malware protection are undeﬁned. Activities are ad

■ Controls — The organization makes inconsistent use of technology, often with

Attack Scenarios Mitigated

Gartner, Inc. | G00726637 Page 15 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

Attackers have many ways to successfully attack this level:

■ Exploit missing patches through web, email or network.

■ Reuse existing malware but avoid widespread recent malware.

Recommended Actions for Improvement

■ Implement backup and recovery.

From a controls perspective, technical professionals focusing on malware protection

■ Standardize on technology and conﬁguration for endpoint AV (client and server),

■ Limit the use of privileged accounts, such as Windows local administrator.

Gartner, Inc. | G00726637 Page 16 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

Gartner, Inc. | G00726637 Page 17 of 37

This research note is restricted to the personal use of tanlb@viettel.com.vn.

■ Process — A malware response process is deﬁned, documented and performed. The

■ Controls — This includes centrally managed antivirus and OS patching, use of an