Extended Detection and Response (XDR) is a threat detection strategy. You are probably already familiar with EDR – Endpoint Detection and Response; this is the security strategy that XDR extends.
Although “X” seems to stand for “extended,” according to Nir Zuk of Palo Alto Networks, it is intended to represent “anything.”
Here are a few defining characteristics of XDR:
- SaaS-based
- Threat detection and incident response
- Integrated system
- Unified strategies
- Vendor-specific
So, it is a platform, offered from the cloud and it integrates all of the security products that a particular vendor can link together. The last point, that the definition of XDR is vendor-specific throws a variable into the realm of XDR. Some vendors might not have as wide a list of available components as others but could still be able to use the XDR label in their marketing strategy.
Can XDR be all SaaS?
The requirement for an XDR system is that it is “SaaS-based.” That doesn’t mean that it must be exclusively delivered from the cloud. There must be at least an agent program operating on-site and as that agent is responsible for gathering all activity data, it needs to be pretty substantial – more or less, a full SIEM.
A security system that performs all of its detection work offsite would present hackers with a very easy winning strategy to defeat defenses: cut off the system from the internet and then wreak havoc.
The benefits of SaaS-based security systems
Undoubtedly, centralized services that share resources among many customers have many benefits in terms of cost and speed. Centralized services in an organization are cheaper to host, easier to maintain, simpler to defend, and quicker to update. Extending this strategy to the delivery model by the software supplier accelerates these benefits, particularly in the security sector.
All software is vulnerable to reverse engineering by hackers. If a package can be sold to anyone anywhere, then it is very probably that some of those buyers are hacker boiler rooms intent on picking it apart and finding a new exploit. So, all software vendors have to be constantly alert to the possibility of loopholes in their security, and security software producers have to be doubly vigilant.
The need to quickly close off exploits means that new updates for the software will need to be developed and distributed. Until every single customer of the package has installed that update, someone is always going to be vulnerable to an attack that is facilitated by the very software that is supposed to be protecting it.
No matter how quickly a software vendor is at producing and distributing its software, its strength relies on cooperation and vigilance among the technicians working for its customers. Offering software as a service solves that problem. Each customer gets a user account on the vendor’s server. All customers run instances of one central and definitive software package version. As soon as an update is available, the software vendor’s staff apply it on their own host, making the security available to all of the customers to be instantly up-to-date.
The same benefit applies to signature database updates and intelligence feeds. If the security services of all customers are running in one place, the software vendor can gather alerts and log messages from all instances and spot systemic problems immediately. Thus, an attack on one customer gets responded to by system hardening for all clients, stopping the spread of a new exploit in its tracks without the risk of client site technicians dropping the ball.
The benefits of device-based security systems
The most widely implemented device-based security is the traditional antivirus software. These systems have advanced beyond searching for file names and processes to identifiers of suspicious activity. New defense mechanisms are called next-generation antivirus (NGAV) and endpoint detection and response (EDR).
The benefit of onboard systems is that they will continue working even when the device is offline. These services have been adapted to gather usage statistics and use heuristics, a field of Artificial Intelligence to assess what activities should be investigated further. The machine learning techniques make up for the fact that disconnected and isolated devices can end up with out-of-date signature databases. NGAVs don’t rely on a list of names to look out for. This makes up for the fact that they might not always be kept up-to-date.
The main issue with fully autonomous device-based security systems is that they are inefficient in terms of disk space use and processor usage. The same software has to be installed on each endpoint and a very thorough AV system requires a lot of processing power.
The playoff between offsite and onboard
Each XDR producer has its own strategy over how much of the system is centralized and delivered as a SaaS process and how much is distributed to onsite agents and endpoint modules. A site agent, installed on one server on the network can shoulder much of the burden of endpoint processing. Lightening the amount of work that needs to be performed on each device, reduces the size of the software that needs to be held on each device and removes much of the load that security procedures place on device processors.
The minimum requirement for an endpoint module is a data gathering and mitigation agent. This agent collects statistics about the activities on the device and sends those to the onsite manager or the SaaS host. It also receives back instructions on how to shut down any threats that the security engine detects in the received activity data.
Triage
Triage is an important concept in modern distributed security systems that are controlled by a remote server, such as the SaaS-centric XDR model. SIEM systems track network interface activity and gather all system log messages. If the central processor of the security system is based in the cloud, all of those messages and network reports have to be sent across the network and over the network. That generates a lot of traffic and can end up overloading the network with every single endpoint enrolled in the system.
Triage creates selectivity in data gathering. This is a cut-down version of SIEM that only uploads certain data. The local module includes detection rules. Knowing a standard sequence of events and threat identifiers to look for, the agent drastically reduces the amount of event data that needs to be processed and reduces the load on the network. The triage process also speeds up threat detection because part of the detection work is performed right there on the endpoint.
The downside of triage is that it requires programming. That greatly increases the size of the software package that needs to be installed on each endpoint, increasing the amount of disk space needed on each device and duplicating detection processes on every device. Triage is also heavier on processor usage than a dumb data-collecting agent. So, there is also a play-off in the decision over whether to implement triage within an XDR system.
User and Entity Behavior Analytics
User and Entity Behavior Analytics (UEBA) is the anomaly detection sequence that flags a user or process for deeper analysis. This is the way triage is implemented.
UEBA is based on machine learning techniques and its aim is to reduce false-positive reporting. One of the major problems with automated response systems is that they can be over-sensitive or calibrated to suit one type of organization, thus blocking actions that are regarded as normal activity in other businesses.
The definition of normal behavior establishes a baseline. This takes the place of an off-the-shelf standard against which to compare all activity. UEBA is very important because standard security systems can flood operators with alerts that take a lot of time to sort through to identify what activity truly represents a threat. That lost time can be the difference between suffering damage or closing down a threat just in time.
False-positives present an even bigger problem in security systems that include automated response. In these cases, genuine users get locked out of the system and customers can be blocked from accessing accounts.
Security Orchestration, Automation, and Response
Security Orchestration, Automation, and Response (SOAR) is a strategy that can reduce the amount of software that an XDR system needs to include in order to implement threat mitigation. The methodology reason that a typical endpoint already has utilities installed on it that can be used to shut down threats. So, there is no point in programming code to perform threat mitigation when a series of lightweight scripts can provoke existing services to do the job.
An example of a SOAR action is killing a process with a PowerShell script, suspending a user account in Active Directory, or notifying a firewall to blacklist an IP address.
XDR development
XDR is a new term and, as it was invented by Palo Alto Networks, rival security providers might not be willing to use the label even when they provide XDR-style solutions.
Coordinated EDR systems represent a step towards XDR. Under this strategy, EDR software installed on each endpoint reports to a central management unit that operates much of the threat detection analysis. This is a halfway point to offsite processing, letting more powerful onsite servers identify actions that might be spreading across the network. An example of a pattern of activity that this strategy is good at spotting is unexpected user access. For example, if a user who is already logged on at one endpoint also accesses the network from a remote location, then it is likely that the user account has been compromised.
A central SIEM system, running on a server can support the activities of EDR modules. Under this configuration, the EDR elements can be reduced to agents, gathering log data to send to the onsite SIEM. The central SIEM, operating as an intrusion prevention system, can implement SOAR actions with network devices and firewalls to block malicious activity and send an instruction to EDR agents to perform local actions on the device to implement threat mitigation.
A local, coordinated EDR service can then be linked through to a SaaS service to get deeper analysis and a cloud-resident threat intelligence feed. In this stage, the onsite SIEM uses UEBA and tirage to reduce the amount of data that needs to be sent to the threat analysis engine in the cloud. This SaaS system then communicates back to the onsite coordinator with instructions of actions that need to be implemented on the network, possibly including instructions to forward to EDR agents.
The combination of EDR, SIEM, and SaaS threat analysis presents a good balance between fast response times and efficient processing. The use of triage, UEBA, and SOAR lightens processing further, cutting down on networking activity and shortening detection times.
Examples of XDRs
Palo Alto Networks came up with its definition of XDR in 2018. So, the idea has been around for some time and, in fact, part of the inspiration for the concept arose from existing systems that competitors were already marketing. In a sense, the XDR tag was Palo Alto’s attempt to place its own label on the products of rival vendors.
- UnderDefense MAXI MDR (GET DEMO) This platform provides a team of cybersecurity experts to manage your protection software plus tools to protect your endpoints and networks, such as a Dark Web scanner and compliance guides.Start a free demo.
- Palo Alto Cortex XDR The definitive XDR system from the inventors of the term.
- LogRhythm XDR Stack A NextGen SIEM combined with UEBA and SOAR that is a largely cloud-based system.
- CrowdStrike Falcon Combines onsite modules and SaaS systems in a unified security platform.
- Rapid7 Insight Platform A combination of onsite and cloud-based tools that compose an XDR.
As explained earlier, there is no set pattern of how much processing should be performed in the cloud and how much involvement onsite modules should have. In all cases, there needs to be some code executed onsite because XDR requires mitigation actions to be performed.
These four examples all approach the idea of combining SaaS security services and onsite modules in different ways. As you can see by the brief descriptions above, some key XDR systems have evolved out of SIEM services that got shifted to the cloud and then expanded into an entire security platform by the addition of complementary services.
Here is a little more about each of these systems.
1. UnderDefense MAXI MDR (GET DEMO)
The UnderDefense MAXI MDR service takes the XDR concept one step further. While the XDR provides site-wide security by linking together endpoint agents, the MDR is a managed detection and response service that provides the cybersecurity experts to run the cybersecurity software.
The platform lets you choose your own security tools and also supplies Dark Web scanning, compliance guides, and risk assessment templates. You can start off with registering for access to the free demo.
2. CrowdStrike Falcon
CrowdStrike’s system is an expanded EDR service. So, there is a lot of software on each endpoint. The SaaS element of the bundle provides a coordination console to system managers, a threat intelligence feed, and threat hunting through log message searches.
CrowdStrike packages combinations of its Falcon modules as editions. Buyers can choose one element, such as EDR, the entire platform, or a partial platform implementation.
3. Palo Alto Cortex XDR
Cortex XDR is a SaaS system but it doesn’t constitute an entire platform. Rather, it is a security coordinator, interacting with other tools, most of which are also supplied by Palo Alto Networks. The XDR provides a threat intelligence feed and threat hunting processes that are based on the feed and data sent up by onsite services. Those site-based services are a network firewall, called Strata NGFW, Cortex endpoint agents, cloud protection with the VM Series, and third-party data sources, such as Active Directory.
XDR implements processing in the cloud and deploys lightweight agents on endpoints. This system includes UEBA and SOAR.
4. LogRhythm XDR Stack
The core of the LogRhythm XDR is a SaaS SIEM. The company has created a stack out of its SIEM by separating out log management into AnalytiX, threat detection, which is DetectX, and SOAR-based response module, called RespondX. Extra modules are a device-based UEBA tool, called UserXDR and a site-based network monitor, called NetworkXDR. The XDR is split between onsite and cloud locations. Buyers can choose to opt for an entirely onsite version or a mostly SaaS solution instead.
6. Rapid7 Insight Platform
Like the other options in this list, Rapid7 has created a suite of security solutions called Insight that buyers can select from to assemble all, or part of, an XDR platform.
Each component in the Insight stable includes both onsite and cloud-based elements. For example, InsightIDR combines a cloud-based SIEM, device-based EDR units, and a split UEBA. The Rapid7 SOAR system is called Insight Connect. Again, this is managed by a SaaS console but implemented through agents on site. Other modules in the platform include a vulnerability manager, called InsightVM, which is split between the cloud and on-site processing. DivvyCloud protects cloud services and so doesn’t include any on-premises processes. A development support system, called Insight AppSec is implemented entirely on the cloud and is intended to secure Web applications.
Try XDR
XDR isn’t a difficult concept to understand because if you are in a position that would be interested in this product line, you are probably already familiar with all of its contributing elements. Take a look at the emerging field and test some examples of XDR services. You will work out which combination of SaaS and site-based services work best for your infrastructure.
