Foundational Elements to Get Right When

Selecting an MSSP
Published: 11 October 2017 ID: G00341387

Analyst(s): Pete Shoard

Managed security service providers define their own service descriptions,

making it difficult to directly compare them. Security and risk management
leaders can use this research to recognize which service deliverables are
most fundamental, helping buyers align their requirements to MSSP
offerings.

Key Challenges
■ MSSPs baffle their buyers with complex or vague service descriptions. This problem is
compounded where a buyer's internal business requirements lack definition or are incomplete.
■ Often MSSPs will not volunteer report templates or samples, not outline which reports are
generated and what data they contain. Such documents are key to measuring the success of
the services provided as well as tracking and managing remediation activity.
■ Organizations that fail to understand which metrics they need to inform the security posture of
their business struggle to communicate the value of security services back to their business.
■ Demand for MSSPs is frequently driven by staffing issues. This may lead businesses to believe
the MSSP will do the heavy lifting without the need to invest internal time and effort to develop
adequate processes internally to manage outputs of such services.

Recommendations
Security and risk management leaders improving their security monitoring and operations should:

■ Establish and document requirements and use cases before engaging providers, and match
service elements and outputs to those use cases.
■ Align service performance metrics of the MSSP with internal KPIs to monitor and react to
performance and service deficiencies and inefficiencies.
■ Ensure successful two-way interaction with the provider by integrating internal processes with
those of the provider and allotting sufficient internal resources.
 ■ Choose providers that commit to regular, fixed-format reporting and alerting with SLAs, and be
cautious of those that cannot or will not.
■ Identify service customization requirements early on to ensure additional service charges are
well-understood and accounted for during purchasing.

Table of Contents

Introduction............................................................................................................................................ 3
Analysis.................................................................................................................................................. 3
Establish Service Requirements Before Engaging Providers..............................................................3
Threat Detection......................................................................................................................... 4
Security Device Management..................................................................................................... 4
Vulnerability Management........................................................................................................... 5
Align Service Reporting Effectively to Identify Service Deficiencies and Inefficiencies......................... 5
Common Overlay........................................................................................................................5
Reporting................................................................................................................................... 6
Alerting....................................................................................................................................... 7
Ready Your Internal Processes......................................................................................................... 7
Choose Only Providers That Commit to Regular, Fixed-Format Reporting and Alerting With SLAs.... 9
Identify Service Customization Requirements From the Outset....................................................... 10
Key Data Points to Request......................................................................................................10
Measuring Service Performance............................................................................................... 11
Gartner Recommended Reading.......................................................................................................... 11

List of Tables

Table 1. Typical Security Incident Summary Fields.................................................................................. 8

Table 2. Typical Security Incident Body................................................................................................... 9

List of Figures

Figure 1. Service Types and Common Overlay........................................................................................6

Page 2 of 13 Gartner, Inc. | G00341387

 Introduction
When selecting a managed security service provider (MSSP), security and risk management leaders
often miss the opportunity to plan the details for the bidirectional communication between the
provider and themselves, assuming such services are self-managing.

Early identification of the value of a security service can come from simple mapping to internal
functions such as compliance reporting or incident response processes. Identify who in the
business is responsible for managing compliance and process items, and involve them early in
defining a range of service requirements.

Focusing on your key requirements for procuring any such service will help to remove the noise
created by the marketing language scattered throughout provider's service description documents.
Understand the snippets of information your business requires and at what frequency they can
sensibly be consumed. This will aid understanding of the share of work that the MSSP should be
expected to take on and how much will still need to be staffed internally.

Too often, buyers do not have a developed concept of what they need from a security service when
engaging a provider. Do not allow providers to set security requirements for your business without
direct input from internal stakeholders. Doing so will likely lead to a service that serves the capability
and desires of the provider, rather than the risk mitigation needs of the business.

Buyers need to establish what outputs from a service relationship are important to them before they
engage in the evaluation process. Having a good understanding of how reporting and alerting from
providers will be consumed is essential in meeting use cases or requirements effectively, and will
inform which specific services they should purchase and from which providers.

Use this document to help identify the commonly required elements and outputs of security
services as well as simplify terminology and language used by providers to make comparison
simpler.

Analysis
Establish Service Requirements Before Engaging Providers
Three main types of managed security service are available to the market: threat detection, security
device management and vulnerability management. These service types encompass the central
elements of managing and monitoring security appliances, the enterprise network and the
intelligence that they produce. The outputs of security devices are often combined with log data
from appliances and applications that are not typically related to security functions. All of the
outputs of these toolsets are combined by MSSPs to produce security incidents, which should be
delivered in a standard format that makes them simple to process when they arrive with the buyer.

Gartner, Inc. | G00341387 Page 3 of 13

 Threat Detection
Threat detection services are available in many forms, usually with some element of log processing,
either internally to the security toolset itself or via a third-party correlation platform. Such toolsets
and platforms can be identified as security information and event management (SIEM; both fully and
co-managed, remote and on-premises), or a managed security appliance, such as an endpoint
protection platform (EPP) manager or user entity and behavior analytics (UEBA) toolset (both fully
and co-managed, remote and on-premises).

Outputs are usually provided in the form of email notifications of security incidents. These should be
detailed and actionable, explaining the activity detected and the assets involved. This information
should have been interpreted by the provider's analyst teams and provide first-step remedial
guidance if the service is fully managed.

Defining use cases before engaging a threat detection service provider is important. These can be in
human-readable language and don't have to solve the issue or include complex definitions of
exactly what to detect. Simple statements such as "I want to know when malicious attachments or
links are clicked and lead to infections" are enough to allow a provider to understand what log
sources are required and whether the MSSP has a predefined mechanism to answer that
requirement. Expect service description materials to use words such as "correlation" or "analytics"
to describe methods used to detect threats, rather than direct descriptions of techniques. Use
examples of use cases you have defined to allow the provider to demonstrate an understanding of
your problem and offer solutions to address it.

Security Device Management

Security device management (SDM) services report on the health factors of security devices such
as uptime and capacity. Although called "security device management," the services often don't
monitor the security of the network directly. SDM services will generally provide patch and change
management for those devices that are under a complete outsource agreement.

SDM services depend heavily on effective device metric reporting to maintain a good understanding
of the level of ROI that is being achieved. Incidents may occur out of working hours or be
remediated automatically by failover infrastructure. Therefore, the issues are not always business-
impacting, but should still be fully investigated and well-understood. Risk to the business is
heightened during failure scenarios, and therefore, any response plan should be aligned with the
capability and responsiveness of the service provider. Being able to identify if a provider is
responding effectively to non-business-impacting events provides a baseline with which to
understand the potential effect of a more serious event. Use this to identify if the required internal
business reaction and processes are sufficient to mitigate risks such as data loss or nonavailability
impacts on earnings.

SDM services complement threat detection services by providing a route to remediation of security
issues through effective network security policy management. In all instances, a business will
require effective threat detection and SDM as part of a complete security function, although
elements of this may be managed internally.

Page 4 of 13 Gartner, Inc. | G00341387

 For more information on the network security policy management market profile, please refer to
"Hype Cycle for Threat-Facing Technologies, 2017."

Vulnerability Management
Vulnerability management and patch management services (for security devices) address the
identification of key areas of vulnerability risk across an estate. There is frequently a requirement to
install network-based devices for internal scanning. Work with the provider to agree to windows of
activity to ensure that the activity does not cause unexpected impacts to the running of normal
business functions.

Vulnerability management services are regularly defined as a "reporting only" service. Remediation
of detected vulnerabilities is unlikely unless the devices are managed by the same provider. The
need to ensure effective two-way communication for services of this type is imperative for effective
tracking of any remediation and virtual patching actions by both parties. Without an effective
communications channel — one that is directional enough to align to organizational boundaries and
take asset responsibility across technology silos into account — effort will likely be spent retesting
and highlighting already remediated issues, which will remove focus from important issues and
reduce ROI, thus increasing risk.

Incident context is not always available with services of this type, and long, unwieldy reports are
often an output. When aligned with services that manage security devices or threat detection, data
should be cross-correlated to give a more representative view of risk. This should lead to an
element of rationalization (duplicate vulnerability and false positive reduction) with prioritization
being carried out by the provider.

It should be expected that when purchasing multiple services from the same provider those services
will be enhanced by cross-service correlation. Outputs from multiple services managed by the same
provider should be structured to be complementary, enabling them to be more effectively delivered
and managed together. Buyers should be cautious of providers that do not offer cross-service
correlation and deliver multiple services as individual entities.

Align Service Reporting Effectively to Identify Service Deficiencies and Inefficiencies

Common Overlay
Creating the expectation for a common reporting and alerting overlay, as shown in Figure 1, is
invaluable to the internal processes of the buyer's business:

■ Be prepared to align content within reporting and alerting service outputs, even when selecting
separate providers for different service types.
■ Expect entities that are able to be correlated to appear in every communication (for example,
hostnames on vulnerability reports should be shown alongside outstanding security incidents
for the same hostname).

Gartner, Inc. | G00341387 Page 5 of 13

 ■ Alerts should include actionable information for the customer.
■ Reports should be valuable and informative to the customer (for example, if a report is for
regulatory compliance purposes, it should fully address the requirements for that regulation).
Figure 1. Service Types and Common Overlay

Source: Gartner (October 2017)

Insist that providers are explicit about the levels of detail they will deliver in any reporting, and about
what features will be cross-correlated where multiple services exist. Ask for templates and samples
to allow your business to prepare integration for processes and systems internally. Buyers must be
able to effectively consume the service outputs for the security services to have value. MSSPs will
often not volunteer such templates or samples, so it is imperative that buyers specifically ask for
examples early in the procurement process. It is essential to gain a clear understanding of the cost
of integrating internal processes with a provider.

Reporting
Reporting is frequently driven by the toolsets the service provider uses with minor levels of
customization. Ensure that the value of such reporting is quantified and that outputs will be
actionable where possible. Some of the more agile providers offer real-time dashboards for access

Page 6 of 13 Gartner, Inc. | G00341387

 to the same information that historically would have been featured in a report. This is preferable, as
it provides flexibility for historical comparison, and is more convenient and accessible than email of
a file.

Beware of long and unwieldy reports, as these have little internal value. Instead, request specific
information at a specific frequency that aligns with your use cases and requirements. This will
ensure the usefulness of the information to internal functions as well as to other managed services.

Alerting
Alerting can come in the form of a short automated email or a more defined incident report. A key
indicator of value is that the more human-driven the notification feels, the greater the level of
analysis can be assumed. Commonly, providers are not expected by buyers to outline the format,
detail levels and effort that are put into an alert or incident notification at procurement stages.
Understanding the levels of detail that will be provided, and the extra work that is required to get the
content to a standard where it can be consumed and the incident remediated, is extremely
important. Make sure that you evaluate examples of the output of the alerting that the MSSP will
provide, that your business is sufficiently equipped to respond to such notifications and that they
contain adequate detail. Examples of alerting and reporting output can be found in Table 1 and
Table 2 of this document.

To understand exactly what information is required, define the underlying processes for the
business to deal with any alert that is incoming from a provider. This will highlight potentially missing
information and identify efficiencies that could be achieved through provider-customer ticketing
system integration at an early stage, increasing service effectiveness and ROI. Alerting should
always be a two-way process that allows your business to enhance an incident alongside the
provider, allowing continuation of any investigation for both parties. A single communication
outbound from the provider allows for mistakes and repetition, but an integrated process and two-
way flow will allow for a more accurate and speedier response.

Ready Your Internal Processes

Internal systems and processes should be ready to receive fixed format data from providers as well
as enable fast entry into internal ticket management platforms using well-defined internal
processes. Such simple processes can be carried out by non-security-specialist staff, such as help
desk operators, but are critically important for effective reporting and reaction to threats.

Processes should include a data entry phase that is able to receive and automatically consume
electronic communications such as email, and have a complementary manual process for verbal
communications such as telephone calls. Storing vital information at the earliest possible point can
be key when responding to multiple issues that require prioritization. Other phases should include a
regular review phase, ensuring that issues don't remain open and unattended for long periods. The
reporting phase should demonstrate value back to the business and should be measurable against
items on a risk register.

Gartner, Inc. | G00341387 Page 7 of 13

 Some key information is required at the early stages of being notified of an incident. As a minimum,
the data received from the provider should include information in Table 1. This data should not be
exhaustive, as it is simply used to complete an initial triage and prioritization of the incoming data.
Incident notifications should include enough information, context and detail so that the enterprise
can make the alert actionable.

Table 1. Typical Security Incident Summary Fields

Field Description

Subject An outline of the issue containing a reference to the priority of the incident

Notification Time A date and time stamp indicating the send time of the incident

References Reference number generated by the provider and internal customer references, if applicable

Priority A numerical representation of the priority/intended severity of the issue (usually on a scale of
1-4, where 1 is the highest)

Classification/ Single-word classification of type of issue, such as misconfiguration, malware or phishing

Category

Source: Gartner (October 2017)

Ensuring quality at the outset is highly important when selecting an MSSP. This quality needs to
extend to the levels of detail to be received regarding incidents. The below table outlines what
should be expected from a verbose and high-quality service provider It should be noted that, in
some instances, less-expensive and less-engaging services will only provide high-level details, like
those found in Table 1. Although this is not ideal, it is imperative that a buyer be aware and react to
any expected lack of information flow, as this will drive the requirement to build further internal
capability and processes.

Page 8 of 13 Gartner, Inc. | G00341387

 Table 2. Typical Security Incident Body

Field Description

Date and Time of A date and time stamp indicating the time the activity took place and may include specific
Activity enrichment detail, such as hostnames, to separate events across a common incident (could
be a window of time or single event).

Source Entities If applicable, the details of hostnames, email addresses, IP addresses, vulnerability details or
other identifying factors that pinpoint the source(s) of the issue.

Destination Entities The details of hostnames, email addresses, IP addresses or other identifying factors that
pinpoint the affected asset(s).

Activity Details A descriptive set of sentences or bullet points that outline the series of events, specific issues
or any other detail relevant to the issue that explains the problem discovered.

Risks A descriptive set of sentences or bullet points that outline the risks to the business as a result
of this activity that may have already occurred or may occur in the future.

Recommended Simple-to-follow, intelligence-led instructions that outline remedial actions already taken by
Actions the provider and actions that the business needs to take following discovery. This is often
opinion-driven and is nonmandatory advice.

Discovery Sources Details of the log sources or security equipment that aided the discovery of the issue (helpful
for cause and directional analysis/remediation).

Source: Gartner (October 2017)

Choose Only Providers That Commit to Regular, Fixed-Format Reporting and

Alerting With SLAs
Reporting is only valuable if it is consumable by security operations or being collected to fulfill a
compliance requirement. Providers that enable analysis-based access to dashboards rather than
fixed-format, paper-based reporting provide greater ROI, as they allow for investigatory work to be
carried out with no need for further toolsets or data storage.

Fixed-format, paper-based reporting that is valuable in a security operations environment tends to

be in the form of fixed lists. Some examples of valuable information are:

■ Authentication information (such as the top 10 failed logins for the day)
■ Out-of-hours activity (such as administration accounts logging on after 10 p.m.)
■ Large volume requests (such as http requests to a website first seen this week)
■ High-risk incoming files (such as executable attachments sent to 15% or more of the workforce)

It is critical to differentiate how the business will manage triage and response for different types of
incidents. Where timed and regular reporting on suspicious or high-risk activity is the most effective
solution for notification of an incident type, businesses should have sufficient processes internally to

Gartner, Inc. | G00341387 Page 9 of 13

 action these reports in a timely way. Pinpoint time windows that suit staff availability or where the
workload is lighter. Reporting of this type typically should focus on suspicious and high-risk activity
that requires manual verification, or requires response at more infrequent levels and does not pose
an immediate risk to the business. For more detailed guidance on how to create response
processes, see "Toolkit: Security Incident Response Preparation."

Use cases that underpin higher levels of risk and immediately place the business at direct risk of
severe loss of earnings or reputational damage should be captured by the alerting process. For
more information on the building data security processes, see "The Security Processes You Must
Get Right."

Maintaining an internal record of security incidents as notified by an MSSP is common practice, and
is often simple to integrate with existing ticket management systems designed for standard IT fault
management. Using email inputs into such a system is a trusted way of generating tickets and
internally tracking the businesses' responsiveness to incidents from a provider. Depending solely on
the provider's ticketing system should be avoided, if feasible, as this makes it hard to move away
from that provider in the event of contractual disagreements. Depending on third parties to maintain
ticketing may prove inflexible for applications such as internal SLA measurements, and lead to a
disjointed set of processes, utilizing an interface simply for managing the service being provided.
There are many benefits to a centralized "single pane of glass," including efficiencies in investigation
of an incident and for internal reporting across multiple functions.

Identify Service Customization Requirements From the Outset

Key Data Points to Request

Enrichment data that can be used to increase the correlation of multiple events is valuable, reducing
effort through consolidation. Event consolidation provides time-saving benefits in initial triage by the
provider and postincident investigation. Examples of valuable data:

■ Dynamic Host Configuration Protocol (DHCP) data allows internal hostnames to be aligned with
IP addresses during specific time windows.
■ DNS logs provide resolution for website addresses that may change over time.
■ Authentication information provides user attribution and allows incidents to be tracked to user
profiles as they move around the organization's IT infrastructure.

Data to aid in tracking SLAs is essential in successful management of providers. Time data, which
includes detail of the time the event occurred as well as the time it was discovered, allows for
measurement of service performance.

Alerts that remain open for long periods should be updated at least daily by providers to monitor
spread and severity/priority of events to ensure risks are managed. Additionally, request daily
summaries of open tickets, last update timings and policies on maximum open periods.

Any report received should contain some actionable remediation advice, and such advice should be
treated as optional.

Page 10 of 13 Gartner, Inc. | G00341387

 Expecting the inclusion of known vulnerabilities is normal where a combination of security device
management and vulnerability management is provided by the same MSSP, even if the vulnerability
is not the focus of the alert or notification. For more information on how to formulate requirements
for service providers, please refer to "Toolkit: RFP for Managed Security Services."

Measuring Service Performance

Measuring service performance is the responsibility of both you and your MSSP, and should be
carried out regularly throughout the lifetime of the contract. Prepare systems and processes to
receive and understand this data, defining how you need to receive it at the early stages of contract
negotiation.

Consistency is important. It is difficult to measure similar security events where there is ineffective
classification. If an MSSP does not present event classifications, then be prepared to present your
own. Suggested event classifications include:

■ Misconfiguration of a device
■ Malware or malicious code on a device
■ Failure of a device
■ Account or credential compromise
■ Vulnerability or patch requirement identified

Measurement of downtime is required to ensure that provider SLAs are met, and also that risk that
has been quantified and registered is accurate. Be familiar with the uptime and availability scales
associated with the provision of IT services, which are known as "the nines" (for example, 99.99%
availability).

Service performance measuring metrics, such as downtime and events per second (EPS), are
valuable and should be provided regularly, allowing your business to measure and guarantee the
current and future affordability for any service provided. Such metrics are also important in
maintaining internal business cases for future security investments, as well as ensuring that
additional service charges are well-understood and accounted for — or avoided, if at all possible.

Managed security services, especially those that monitor logging output of security devices, can
often be used to measure the performance of such devices and their ability to prevent or provide
visibility to reduce exposure. Utilizing information such as this can allow for better understanding of
where inefficiencies in security toolsets or processes are, and how they may be resolved, which may
provide validation for wider security expenditure in outsourcing or technology.

Gartner Recommended Reading

Some documents may not be available as part of your current Gartner subscription.

Gartner, Inc. | G00341387 Page 11 of 13

 "The Security Processes You Must Get Right"

"Toolkit: RFP for Managed Security Services"

"Toolkit: Security Incident Response Preparation"

"Hype Cycle for Threat-Facing Technologies, 2017"

More on This Topic

This is part of an in-depth collection of research. See the collection:

■ Prepare an Effective Security Event Monitoring Project

Page 12 of 13 Gartner, Inc. | G00341387

 GARTNER HEADQUARTERS

Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
USA
+1 203 964 0096

Regional Headquarters
AUSTRALIA
BRAZIL
JAPAN
UNITED KINGDOM

For a complete list of worldwide locations,

visit http://www.gartner.com/technology/about.jsp

© 2017 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 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."

Gartner, Inc. | G00341387 Page 13 of 13