10 Considerations for Implementing an XDR Strategy

Executive Summary:

There is no “one size fits all” XDR strategy that will work for every organization, and many security teams may decide that XDR is not yet advantageous or worth the cost. This article provides 10 things that security leaders and their teams should consider when evaluating XDR, deciding what type of XDR strategy to invest in, and assessing which solutions will support their XDR design pattern while integrating into their existing security stack.
An XDR strategy can be measured in many ways, including tangible KPIs such as improved mean time to detect (MTTD) and mean time to respond (MTTR).
The ultimate goal of XDR is to help security teams better detect and defend against even the most sophisticated of threats faster so they can pivot to tasks and analyses that strengthen their organization’s overall defenses. In turn, these teams are able to give their leaders more complete and timely guidance that enables them to manage cyber risk better and protect their organization’s reputation and bottom line.

What is XDR?

Extended detection and response — or XDR — is a threat detection tool that augments the monitoring and alert capabilities of other cybersecurity systems, such as network detection and response (NDR), endpoint detection and response (EDR), and security information and event management (SIEM). As the name suggests, XDR is meant to extend visibility across the expanding attack surface of the enterprise, and improve mean time to detect (MTTD) and mean time to respond (MTTR) to malicious cyber events.

What problems is XDR meant to solve?

Organizations have added many point solutions to solve specific problems as the information security landscape has evolved. As a result, products and product categories have developed independently, without the benefit of an all-encompassing platform that delivers synthesis and seamless integration of product capabilities, alerts, and data storage. XDR is often discussed as a solution that provides that platform.

Enterprise security began with antivirus software, which was augmented by host-based firewalls and host-based intrusion detection systems (HIDS). These defense categories (among others) merged into single products and agents under the umbrella of endpoint protection (EPP). EPP evolved into EDR when developers built in additional detection methods and response capabilities. NDR is the product of a similar evolutionary process, though its origins are in point solutions that stood apart from what we now call EDR.

The driving process behind the XDR concept is a further evolution that blends together “detection and response” categories such as EDR, NDR, and SIEM. XDR generalizes these capabilities so that they can be applied to all assets (tangible or otherwise), including managed endpoints, unmanaged endpoints, networks, cloud workloads, SaaS software, etc.

An ever-increasing number of assets and digital businesses’ flexible perimeters have left security operations centers (SOC) overworked, and often toggling between disparate security tools and the alerts they generate. Whether an adversary gains access to a workload or database in public cloud infrastructure, gets a user to open a malicious attachment, or obtains credentials to a SaaS email inbox, the SOC must detect and remediate the situation as quickly as possible. XDR’s design can help present a more complete, integrated picture of the company’s attack surface, which can facilitate SOC management and help the team pivot to more proactive threat hunting and defense.

Currently, XDR’s broad scope is its greatest strength and its greatest drawback: The more things XDR is used to protect, the more things it needs to interact with to achieve its goal.

There is no “one size fits all” XDR strategy that applies to every business environment. Each security team should carefully assess what potential solutions would be needed to support an XDR strategy and how they would integrate into their organization’s current security stack. They should also evaluate other considerations like the potential for introducing automation into the fold to potential costs for shifting to XDR.

Here are the top 10 considerations to make when choosing a solution(s) that support your XDR strategy. We will explore each in more detail in later sections:

Data collection and visibility
Detection and response capabilities
Integration capabilities
Automation and orchestration
Scalability and performance
User experience and workflows
Threat intelligence integration
Compliance and reporting
Vendor support and reputation
Total cost of ownership (TCO)

1. Data collection and visibility

Visibility is the first objective of XDR: The optimal strategy will enhance the security team’s view of as much—if not all—of the infrastructure and assets the organization uses. Obtaining this visibility will require a multimodal approach, as different assets have different characteristics, and the telemetry available for different types of assets is often unique.

The first two foundational sources of telemetry for XDR visibility are EDR and NDR, because they are both broad and deep, and provide substantial visibility for the amount of time and effort invested.

EDR coverage is generally broad because organizations typically elect to deploy EDR agents to as many managed endpoints as possible, and managed endpoints often make up most of an organization's compute assets. It is deep because EDR agents can provide lots of granular visibility into the actions taking place on any given endpoint.

NDR coverage is broad because visibility into the network actions of almost all endpoints on the network can be obtained by deploying out-of-band network taps at a few strategic locations in an organizational network, without having to deploy any agents.

After architecting and deploying EDR and NDR within the security stack, the security operations team can fill in the remaining gaps by collecting logs or telemetry from a handful of other high-value areas—such as SaaS email providers, mail filters, public cloud logs, SASE logs, etc.—to complete the XDR design pattern for their organization’s unique requirements.

2. Detection and response capabilities

As stated, the core functions of an XDR strategy should help a security team achieve faster MTTD and MTTR. When evaluating different solutions to support your XDR strategy, these questions can help an organization determine which XDR design pattern will meet this goal while meshing with the unique characteristics and complexity of the organization’s environment.

Questions to ask about detection:

What types of detection techniques are involved: e.g., signatures, supervised machine learning, unsupervised machine learning, etc.?
How are those detection techniques applied to the various data domains being ingested? Is the right technique applied to the right task?
How do detections map to the MITRE ATT&CK Framework, and how much coverage is provided?
How much net new coverage is added with the addition of an XDR platform?

Questions to ask about response:

What sort of response activities does the SOC routinely use (e.g., deactivating user accounts, forcing password resets, quarantining hosts via an on-board agent, disabling switch ports, modifying ACLs on network equipment, adding/modifying firewall rules, adding IOCs to threat intelligence platform, etc.)?
Are there mechanisms to facilitate those actions from inside the XDR platform?
Can custom response actions such as external PowerShell or Python scripts be run, and from where?

These questions will help uncover the organization’s unique requirements, which can then inform an analysis of their existing capabilities, and whether they are sufficient to achieve ‘extended’ detection and response, or if adding another solution or a separate XDR product would be a more effective means of improving overall security.

3. Integration capabilities

An effective XDR strategy is built on a design pattern that integrates all potential data sources to consume the desired security data and provide detections and context. A viable XDR design pattern also integrates other systems such as user directories, SASE platforms, EDR agents, firewall platforms, network access control, and a SIEM or ticket management system to facilitate the existing team workflows.

As an example, consider the lifecycle of an “impossible travel” alert, which is generated when there are two logins for a user within a brief time frame from widely separated locations. A solution that supports an XDR design pattern could compare a successful VPN authentication from Europe against a webmail authentication to a SaaS email provider from America and generate an alert. An analyst would then need to determine whether this alert is a false positive or true positive, which of the logons was legitimate, and how to follow up. The analyst would require access to contextual information, such as a list of all authentication attempts and their status (success/failure) across all platforms that use authentication. The solution would also require an integration function that compiles the alert’s contextual information in a format that is easy for a security analyst to reference.

Once the analyst reviews the collected evidence, they might force a password reset for the user on one or more authentication platforms, which would require an integration to each of those authentication platforms. In addition, the workflow would likely require contacting the user in some way, via email, SMS, or a voice call. Those interactions could also be conducted via the click of a button with the proper integrations.

Ultimately, the alert, analyst notes, final status, and case attributes would need to be communicated back to the primary ticketing system for calculating metrics such as MTTD, MTTR, top incident categories, case/incident open and closure rates, and any other metrics that the security team uses to track their progress and value add to the business.

4. Automation and orchestration

Once an architected solution to support the chosen XDR strategy is in place and analysts can begin reviewing detections, SOCs can accelerate MTTR and case closure rates by leveraging automation and orchestration inside of the newly architected solution.

The first way to do this non-disruptively is to take repetitive tasks that analysts do regularly and script them so that analysts can select actions from a menu rather than manually construct them. One example is setting up a query to gather commonly used data and summarize it in a table for an analyst based on a piece of information the analyst supplies, such as an IP address or username.

The next step to make this faster and easier for an analyst is to start to build a workbook that automatically takes these actions for the analyst when the case is opened, so that by the time the analyst looks at the case, some or all of the data they will need is already waiting for them and they can skip straight to analysis. If there are tickets which are commonly being acted upon in the same way, the security team can then consider whether a playbook should be allowed to automatically take those actions without human intervention (fully automated).

While the architected XDR solution should be flexible enough to deal with all possible scenarios a security team may face, the team should still carefully consider the risk and cost associated with a false positive. For example, if an alert triggers in the middle of the night because an executive was up late working on something against a deadline, and a false positive alert then causes their account to be locked out, this could harm the business.

5. Scalability and performance

The best XDR strategy will be able to scale to match the organization’s needs. Security teams need to consider each of the components of the XDR solution, as well as the limitations of those components as disclosed by vendors, and then map out an architecture to determine how many of each component must be deployed and where. This will help the team determine whether the solution can meet scalability requirements, and also how complex the solution will be.

If the organization chooses a standalone XDR solution, it will need to consider its ancillary performance effects on all of the surrounding components and systems it integrates with. For example, if an XDR solution integrates with an EDR platform by polling an API to gather information from the EDR, will that place an extra load on the EDR platform, and will that load adversely affect EDR performance?

6. User experience and workflows

When considering how to best architect a solution for your XDR strategy, a security operations team will need to consider what changes they will make to their workflow. An XDR solution could attempt to provide a single pane of glass for a security team, or it could consist of several separate UI portals for analysts to pivot into when needed.

Security teams will need to consider in advance what end-user experience best supports their approach, and evaluate the solution’s capacity to support that experience, as well as whether additional components are needed to achieve this experience.

7. Threat intelligence integration

Most mature security organizations manage threat intelligence in at least one threat intelligence platform (TIP). The TIP can include threat intelligence that generally applies to all users of the Internet, threat intelligence that applies to specific industries or verticals, and threat intelligence that an organization has compiled based on artifacts extracted during investigations on their own network.

For an XDR solution to meet the needs of mature security organizations, it will need to be able to integrate with all of these TIPs to consume new indicators of compromise (IOCs) that are fed from other intelligence sources, and to publish IOCs discovered during investigations within the TIPs for storage and lifecycle management.

A security organization may want to architect an XDR strategy that supports the following tasks using IOCs ingested from various sources:

Generate sightings/alerts based on real-time data and the current set of IOCs
Retro-hunting to take new IOCs and generate sightings from historical data in case of attackers being active in networks for long periods

8. Compliance and reporting

Data lakes of security data can help security teams achieve, and just as importantly demonstrate, compliance with mandates and frameworks such as PCI DSS, SOX, NERC CIP, NIST CSF, and others.

An XDR strategy should be based on solutions that help companies evaluate and demonstrate their level of compliance. There are solutions that can help teams achieve this through pre-built reports to help companies make this process of evaluation and demonstration easier. Teams often need the option of creating customer reports, so it’s worth considering solutions that can deliver longer-term value by being flexible enough to help teams build their own specific report, since each team’s goals and metrics may be slightly different.

Additionally, it may be helpful to build your XDR strategy with solutions that can generate point-in-time reports at regular intervals and send them to one or more destinations (e.g., email, file share, object storage).This enables teams to quickly review compliance levels over a continuous timeline, and have readily available artifacts to demonstrate compliance if that ever comes into question.

9. Vendor support and reputation for standalone XDR products

If the security team at an organization decides that buying a standalone XDR product is the best option to support its XDR strategy and design pattern, the team should consider potential vendors’ support history, company history, and reputation carefully. This may be challenging since many vendors have entered this space in just the last few years. Newer vendors may lack a track record of performance, so it may be more difficult to gauge their claims, projections, and support capabilities. In these cases, it can be helpful to ask to speak with the vendors’ existing customers.

In some cases, a vendor may be new to the XDR market, but they may also possess a quantifiable track record supporting other established products, as well as a reputation for delivering on their vision and marketing. A strong history of working with security teams may warrant additional confidence that the XDR solution is viable.

Bear in mind that vetting XDR products may lead teams to reassess their existing capabilities and determine that the requirements of extended detection and response are already within reach. Keeping the organization’s unique needs in focus can help avoid a lock-in with a vendor whose product and support are not a good match.

10. Potential costs of shifting to an XDR strategy

When tabulating the TCO of architecting an XDR strategy and corresponding solution, it’s important to include associated and often-forgotten soft costs, most notably how much team member time is estimated to be dedicated to maintenance every week. Other considerations and estimates may include:

What is the capital expense now?
What is the operational expense annually?
How much team member time will be needed for ongoing maintenance?
How much training will be required for team members?

Additionally, potential buyers should break out the onboarding costs from the ongoing expenses. One solution framework may require more up-front capital or staffing and less ongoing maintenance once in place. Another may require less up-front effort but have a higher ongoing maintenance burden or a higher subscription cost throughout the lifecycle.

An XDR Strategy Starts with Network and Endpoint Telemetry

The right approach to extended detection and response can help propel an organization toward a robust and coordinated defense against complex cyber threats. Whether you are considering the integration of a standalone XDR product or find that existing NDR and EDR capabilities are sufficient, the end result should be end-to-end visibility across your entire infrastructure, with the potential to keep improving threat detection and remediation in terms of speed and thoroughness.

Designing and implementing an XDR strategy doesn't have to be a daunting task. With a strategic approach based on these considerations, it's possible to find a solution that aligns with your unique security objectives and budget parameters.

To ensure that your security team is architecting an XDR strategy that meets all of your organization’s security, compliance, and budgetary needs, it’s important to start with the basics. The foundation for extending detection and response begins by pairing EDR with NDR. Learn how integrating our Open NDR Platform into your existing security architecture consolidates your security stack and bolsters your overall security posture.