Gartner Security Risk Uae Research Tips For Selecting Security Operations 2021
Gartner Security Risk Uae Research Tips For Selecting Security Operations 2021
Gartner Security Risk Uae Research Tips For Selecting Security Operations 2021
Deciding when to make investments in tools, and selecting the right ones, for the SOC
is challenging for many organizations. Security and risk management leaders
responsible for security operations should use this research to aid in making
pragmatic decisions.
Overview
Key Challenges
■ Security operations center (SOC) owners struggle to make the right technology investments, and
unfortunately chase the latest and greatest technologies that may dilute, rather than enhance, the
efficacy of the SOC.
■ Looking to peers with SOCs or trying to benchmark against others in their vertical is of limited use.
Each SOC is constructed to meet its own organization’s nuances, and current and target maturity level.
■ Artificial intelligence (AI)- and machine learning (ML)-powered technologies, or any that promise to
fully automate your SOC, are not going to magically transform an SOC from low maturity to high
maturity overnight. Your SOC needs trained staff and fine-tuned workflows to use and operate tools
that support its goals and capabilities.
Recommendations
Security and risk management leaders investing in security operations technologies must:
■ Prepare the SOC team and relevant stakeholders for a process-driven evaluation with a “premortem”
analysis to reduce the chance of failed projects.
■ Align the tool selection process according to the target operating model and goals of the SOC,
avoiding premature investments.
■ Make technology investments that will provide the best results against new threat vectors, address the
biggest blind spots and enhance areas of the SOC with operational challenges.
■ Be flexible in case of organizational and business changes. New workflows and tools to support
changes to processes and capabilities might be required.
Introduction
SOCs are like snowflakes, as no two are alike. Many have yet to achieve their desired maturity level and
target operating model. For those that have achieved their ideal maturity level, they still must react to
changes like more hostile threat landscapes, digital business initiatives, and mergers and acquisitions.
These factors will influence the current and future technology investments required for the SOC (see
Note 1).
However, security and risk management leaders may not consider these factors and instead purchase
tools based on short-term needs or as rushed, reactive responses. An example is adding endpoint
detection and response (EDR) to respond to a ransomware event, as opposed to investing in security
awareness and training to reduce the impact from employees launching malicious attachments sent via
phishing emails. Leaders need to consider how new tools contribute to the SOC’s mission, and enhance,
rather than complicate, the work performed by SOC staff (analysts, engineers, threat hunters and
incident responders).
Based on conversations with Gartner clients, a recent driver for implementing tools in the SOC is to take
advantage of “AI” in the form of the application of ML. The promise of new ML techniques is to better
address and prioritize threats (both external and internal) that are getting more sophisticated. They also
pledge to support the growing diversity of environments that need to be monitored — on-premises, SaaS,
IaaS, PaaS, those with operational technology (OT) and the Internet of Things (IoT).
Buying tools that are described as ML or AI for the sake of getting these into
the SOC is the wrong approach.
Before purchasing tools for the SOC, security and risk management leaders should understand why,
where and how the SOC would benefit from the application of AI. Then, they should perform an honest
premortem assessment to determine whether they have the expertise to operate and use these tools over
time (see “Assessing the Impact of Machine Learning on Security”).
Analysis
Tip No. 1: Prepare the SOC Team and Relevant Stakeholders for a Process-Driven
Evaluation With a Premortem Analysis
Security leaders must educate stakeholders that new techniques do not mean that better threat detection
will be achieved. Many of these new techniques will be able to improve only a subset of the threat
detection use cases required. They will not be able to completely replace the tools using more common
or traditional approaches (e.g., correlation-based analytics). It may just add more alert “noise” and
complexity to an already overburdened SOC.
Why do projects fail or not live up to their promises? It may be due to scope, the technology itself (e.g.,
vendor claims were not confirmed during a proof of concept), the implementation of the tool, or the lack
of resources and expertise to run the tool once deployed. For example, a common question from Gartner
clients that have an existing SOC that has reached an adequate maturity level is, “Do I upgrade to a
modern security information and event management (SIEM) tool, or should I build a data lake, create my
own ML analytics capability, and build my own security orchestration and automation on top of those
other two components?” The unhelpful, but always true, answer is, “It depends.” As part of a project to
bring tools into the SOC, a solid understanding of the scope, technologies being considered and affected
processes is required.
Security and risk management leaders can improve the odds of selecting the right tool for the
organization by gaining consensus during a premortem analysis on what could go wrong and which
success metrics should apply to a project. The premortem can also serve as an early-stage vehicle for
collecting initial use cases and requirements. Those can be further refined as part of the formal project
definition and approval cycles.
Figure 1 highlights what attributes need to be considered in order to have a better chance of success,
and to lower the risk of failure.
Tip No. 2: Align the Tool Selection Process According to the Target Operating Model
and Goals of the SOC
Every SOC should have a defined target operating model that describes the mission, responsibilities and
timelines for achieving various goals and levels of maturity (see “Create an SOC Target Operating Model
to Drive Success”). Security and risk management leaders should use the target operating model as the
key reference document as well as the existing technologies, people with expertise, and plays (or
processes) in an SOC playbook. Armed with this, they should ask some key questions to determine
which technologies would advance the mission and capabilities of the SOC, including:
■ What maturity level is our SOC (see Table 5 in “How to Plan, Design, Operate and Evolve a SOC”)?
■ How well will the new technologies integrate with our existing toolset?
An organization building an SOC will prioritize technology purchases to get real-time monitoring
capabilities in order to better understand what is happening when observing the consequences of the
event. This first level of visibility, while potentially limiting the SOC to reactive activities, is necessary.
As the SOC matures and learns, it will build the processes to treat basic incidents, and will start to
differentiate event treatment based on their impact. Additional tools might help at this stage to speed up
initial assessment, with individual alerts being aggregated and augmented with additional context.
More mature organizations may need to strengthen their ability to perform root cause analysis of the
incident and elimination of the threat. They want to ensure that when they close an incident, the risk of
recurrence is properly handled.
Once the end-to-end workflow itself becomes more refined, orchestration and other productivity
improvements will move the SOC forward (see Figure 2).
Figure 2. Example of Tooling a Modern SOC Against Maturity Level and Capabilities
To achieve a modern SOC (see Figure 5 from “How to Plan, Design, Operate and Evolve a SOC”), a set of
technologies is needed that should cover:
■ Management and operations (e.g., an SIEM tool, incident/case management solution or security
orchestration, automation and response [SOAR])
Any technologies on top of this set should be aimed at enhancing the coverage of the SOC, such as
deception technologies, cloud access security broker (CASB) tools, OT security technologies, etc. (See
Note 1.)
SIEM ■ Get an initial starting point for ■ Identifying initial use cases and
visibility into core areas of the IT supporting data sources is necessary
environment. to build requirements.
■ Leverage data collection from existing ■ SOC team size and experience need to
security controls. align with real-time detection and
response requirements.
■ Need for multivector visibility.
■ Time to deploy requires copious
planning and can take a long time.
Smaller or newly-formed SOCs, or those that were previously outsourced where the technology was
provided by the provider, often start with SIEM or log management solutions. This is necessary to start
seeing what is happening in the organization, leveraging logs from network and endpoint security
controls already in place, and possibly from other sources based on criticality to the organization (e.g.,
domain controllers, critical applications, externally exposed assets).
The need to have a common repository of incidents could be addressed within an SIEM tool or within
IT’s case management or service desk tool. Using a security incident response platform (SIRP) tool or the
SIRP capabilities of an SOAR tool should be considered if the incident and case management
capabilities in the SIEM tool are not advanced enough, or there are security and privacy concerns with
using the IT service desk tool. Every “greenfield” SOC will not have the resources (budget, people, time) to
implement SIRP at the beginning, but it should be strongly considered at the start of instrumenting the
SOC, rather than trying to bolt it on later in the SOC building journey.
If security and privacy concerns make the IT service desk tool inappropriate and if the preferred SIEM
tool lacks good enough case management capabilities, security leaders will face an early maturity
bottleneck. They will have to consider an SIEM tool with more advanced case management capabilities,
or leverage an SIRP tool or the SIRP capabilities of an SOAR tool, which would normally be beyond their
current maturity level.
Larger and more mature SOC teams face scalability challenges. Too many events and too much time
spent on investigating complex incidents, combined with strong requirements to provide a definitive
answer to business stakeholders, drive security leaders to seek tools for improving their SOC
productivity. The security orchestration and automation and the threat intelligence platform (TIP)
capabilities in SOAR tools can help automate many of the time-consuming activities of SOC and threat
intelligence analysts, as well as support threat hunting activities.
Tip No. 3: Make Technology Investments That Will Provide the Best Results Against
New Threat Vectors, Address the Biggest Blind Spots and Enhance Areas of the SOC
With Operational Challenges
Most organizations start their SOC journey with an evaluation of existing security controls. When they
feel the need to purchase a specialized tool, they face a paradox of choices and too many possibilities in
the market. Gartner sees many organizations select a tool primarily to solve the most recent security
incident because they get budget right after the event. They have the mandate to “make sure it never
happens again,” and pick the shortest path.
However, even if the preferred tool might provide value, it might not be the right time to add more tools,
given the current maturity of the SOC. One frequent reason is the lack of available resources and
expertise on the team to leverage the tool. It might even affect the budgeting model for the SOC by
spending too much in one area while neglecting others.
There are three categories of improvements where an SOC can invest in tools: visibility, analysis, and
action and management (see “How to Plan, Design, Operate and Evolve a SOC”). Investments can further
be mapped to the several areas of the Adaptive Attack Protection model of the CARTA framework (see
Figure 2 from “Seven Imperatives to Adopt a CARTA Strategic Approach”):
1. Prevent: Capabilities like threat intelligence are one example where to be defensively prepared may
require tool investments. Adding or maturing this capability could drive the adoption of TIP tools or
SOAR solutions with TIP capabilities.
2. Detect: This is where a majority of investments are made, regardless of the size, scope and maturity
of an SOC. Common tools include SIEM solutions, as well as endpoint protection platform (EPP), EDR,
and NTA technologies.
3. Respond: There are two components to response. Both are increasingly being addressed by SOAR
tools, as well as tools like SIEM, EDR, full packet capture (FPC) and NTA.
■ Triage: There is no security monitoring program that can avoid triage challenges when a security
event or incident is identified. The SOC’s objective is to have insight into the priority events to
investigate. They then need the relevant context for those events, to determine the severity of the
potential incident and required response.
■ Incident response: Improvements in incident response overlap with the triage work, but quickly
become a separate field in larger teams. Larger, better-funded SOCs have new requirements and
responsibilities, such as finding the root cause, containing or disrupting a threat, and applicable
remediation and recovery processes.
4. Continuous visibility and verification: While there is no magical tool to predict future attacks,
continuous assessment of prevent and detect capabilities is a way to anticipate and quickly identify
issues. This is typically the realm of analysts, engineers and responders in the SOC. Increasingly, there
are tools on the market that aim to automate the work of “Tier 1” SOC analysts, whether via tools
emphasizing black-box-style security analytics or decision support features.
In the next few years, many SOCs will abandon at least one of the security monitoring tools they
currently use due to a lack of resources and expertise to use the tools effectively. To avoid this
eventuality, SOC leaders should align their investment with the ability of the tool to provide value over the
long term, considering the benefits to the SOC’s mission. They should then evaluate requirements for
resources and expertise. In “How to Respond to the 2019 Threat Landscape,” Gartner highlights a
framework to prioritize threat defense improvement strategies. It starts with an initial assessment of
gaps in defense technologies, and evolves toward a continuous security posture assessment. The
MITRE ATT&CK framework is another tool being leveraged by vendors, but with slower adoption by end-
user organizations, to demonstrate control coverage and threat detection efficacy.
Achieving defense in depth for the most prevalent threat vectors is the
foundational step of maturing the role of the organization’s SOC beyond ad
hoc crisis response.
SOC leaders must find the balance in improving their detection and blocking capabilities. This should
reduce the number of incidents and improve their response capabilities, ultimately to reduce attacker
dwell time.
The key idea is to not treat the SOC as a closed system, but one that is vigilant of the changes to the
environment outside of the SOC (for example, at the organizational level, the external business
environment and sector it operates in). With this understanding, SOC leaders should then embrace
change and new opportunities, when presented, to reengineer, or at least enhance and optimize, the SOC.
This is similar to what other parts of IT might be doing when the business wants to “digitally transform.”
In order to treat the SOC like a living entity, there should be processes established to address change (see
“How to Start Your Threat Detection and Response Practice”). For example, periodic reviews, say on an
annual basis, that baseline and assess the SOC’s capabilities, should be performed. Other opportunities
may include assessing the required capabilities as new business initiatives and strategies are surfaced
to security and risk leaders. These situations provide important opportunities to determine how the SOC
can support these changes, and whether the SOC will need investments to reduce risk to the business
from these changes. Finally, security leaders must seek out the critical inputs into any changes required
in the SOC. These inputs should come from areas such as continuous performance monitoring of the
SOC to uncover trends (both good and bad), postmortems from the completion of projects, strategic
information from stakeholders across the business, and evaluation of the changes in the external threat
landscape.
Note 1
Technologies Available to Buyers With SOCs
There is a plethora of technologies that are being purchased for SOCs. The technologies available to
buyers with SOCs include, among others:
■ EDR (see “Market Guide for Endpoint Detection and Response Solutions”)
■ User and entity behavior analytics (UEBA; see “Market Guide for User and Entity Behavior Analytics”)
■ SOAR (see “Market Guide for Security Orchestration, Automation and Response Solutions”)
■ Deception (see “Applying Deception Technologies and Techniques to Improve Threat Detection and
Response”)
■ Operational technology security (see “Market Guide for Operational Technology Security”)
© 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."
SIEM ■ Get an initial starting point for visibility into core ■ Identifying initial use cases and supporting data
areas of the IT environment. sources is necessary to build requirements.
■ Leverage data collection from existing security ■ SOC team size and experience need to align with
controls. real-time detection and response requirements.
■ Need for multivector visibility. ■ Time to deploy requires copious planning and
can take a long time.
Case/Incident Management and Workflow ■ Processes and procedures are being defined ■ Investment in resources is needed to operate
and need to be documented in a central and manage the tool.
repository.
■ Use cases need to be identified to determine the
■ Case management to aid incident management processes to define.
drives appropriate responses (aka workflows).
EDR ■ Real-time and historical view of activity on ■ Requires deploying another agent on monitored
workstations and servers. devices.
■ Investigate incidents on mobile devices (e.g., ■ Team must have the required investigation skills
laptops). and tool know-how.
NTA ■ Detect abnormal behaviors from network ■ Stakeholder expectations need to align with
traffic, especially where EDR cannot be partial coverage.
deployed (e.g., OT environments).
■ Needs to get access to network traffic for
■ Complementary solution focused on “unknown targeted scope.
unknown” attacks.
■ Team must have the required investigation skills
■ May be easily available (e.g., can be done via or and tool know-how.
added to the SIEM deployment).
■ Encrypted traffic may limit value.
■ No dependency on existing toolsets/visibility in
logging.
SOAR for Orchestration and Automation, Threat ■ Processes and procedures (aka the plays in the ■ Requires a level of readiness and maturity in the
Intelligence Management SOC playbook) have been established and can SOC to take full advantage of the solution (e.g.,
be automated. plays exist to be turned into workflows or
automated).
■ Existing security controls are modern enough
(e.g., there are open APIs) to integrate with an ■ Investment in resources needed to operate and
SOAR tool. tune the tool. Much like SIEM tools, SOAR tools
are not “set and forget” to maximize their
■ A threat intelligence capability exists in the SOC
effectiveness.
and it requires tooling to drive improved use of
threat intel.