Debunking Common Myths about XDR

Good morning, good afternoon. I'm John Tolbert, Lead Analyst here at KuppingerCole, and today our webinar is titled Debunking Common Myths about XDR. And today I'm joined by Marko Kirschner, who's Director of Sales Engineering at SentinelOne.

Welcome, Marko. Thanks, John. Excited to be here. Great. So a little bit of logistical information before we get rolling here. We're in control of the audio, so there's no need to mute or unmute yourself. We will be doing a Q&A session at the end, so there's a questions blank in the GoToWebinar control panel. You can type questions into that at any time, and we'll look at those at the end of our sessions. We're going to do a couple of polls at the end of my section, two questions, and then we'll look at the results right before we start Q&A.

And then we are recording this, so both the recording and the slides will be available shortly. So again, I'm John Tolbert here at KuppingerCole. I'm going to start off by talking about what is XDR, what can it be used for, and kind of look at the marketing versus hype. Then I'll turn it over to Marko. So I thought it'd be good to start with, you know, where has XDR come from? So endpoint protection, endpoint detection and response, network detection and response. You'll see there's a bunch of different tools that can be, you know, fall under the rubric of XDR.

So looking at the history, you know, way back in the 1990s or even late 80s when viruses first appeared, there needed to be a solution for that. So antivirus, which has, you know, morphed in modern day into endpoint protection platforms.

You know, when they started off, they were, you know, doing signatures, you know, the researchers would get, you know, a copy of a bad file, figure out how to, you know, look for that particular virus type and then train their solutions to do the same. You know, things have gotten a lot more sophisticated in the last 20 or 30 years and now we use machine learning and a variety of other techniques like memory analysis and behavioral analysis and, you know, exploit prevention as well as, you know, some signature-based detection models as well.

But EPP also rolled in other kinds of functionality over the last 30 years like application control, endpoint firewalls, URL filtering, and many other features that now commonly come in what is called endpoint protection platforms. Later in the 90s, we saw the rise of IDS, IPS, intrusion detection, intrusion prevention solutions. These were rules-based network attack detection and prevention systems.

They, in order to make it work, you know, network analysts would have to see what was good and bad traffic manually and then write manual rules to look for that and alert on that or block, you know, and that led to a very high positive, high false positive rate. And in general, it's a very high maintenance way of doing intrusion detection. But really, it was the best thing available at the time and very necessary. Moving into the 2000s, we saw the advent of EDR, endpoint detection and response, which has now been rolled together with EPDR, endpoint protection detection response.

And why did this happen? Well, sometimes machines would wind up getting compromised. Maybe they didn't have the latest patches, didn't have the latest endpoint protection. So organizations needed to find out which machines had been compromised.

And APT, advanced persistent threat, was one of the drivers for the development of EDR. These APTs are, you know, when mostly state intelligence agencies are trying to get information, you know, trade secret, other kinds of secret information from different organizations or governments. EDR really requires their detection models to use machine learning algorithms because of the vast amounts of data that have to be poured through in order to automate it.

You know, and in the last decade, we've seen, like I said, the EDR sort of merged with EPP. So now the full platforms, you know, contain both the ability to identify malicious code and try to prevent it from executing and looking for signs of possible compromise and offering the ability to respond to that.

NDR, NDR is sort of the next generation IDS. So rather than being rules-based, it's based on machine learning detection algorithms. And generally that leads to higher accuracy, better ability to classify anomalies correctly. These require sensors for on-premise and cloud deployments and also the ability to look at encrypted traffic, being able to tell what may be malicious simply by looking at the headers. Now that we're into the 2020s, many of these tools are being combined into XDR.

The idea being, you know, having an all-in-one detection and response solution for endpoints of all kinds, network, cloud. Most of these do tend to be single vendor stack solutions.

So drilling down a little bit on EPDR, it includes, like I said, you know, the endpoint firewall, URL filtering, application allow and deny listing, as well as things like system file integrity monitoring, looking for when code may have been trying to change system files to, if it's malicious code, you know, so that it relaunches every time a machine boots, plus the pre-execution detection of potential malicious software.

EDR, drilling down on that a bit, you know, that's looking for indicators of compromise after the fact, the ability to pull in cyber threat intelligence, having a sandbox service is often included. A sandbox would be, if you get a piece of suspicious code, you want to know what it is, it gets, you know, diverted to a sandbox where it executes, and then analysts can look at the results and determine whether or not it was malicious.

There are various alerting and reporting mechanisms, including, you know, pretty modern alternatives for using, you know, messaging solutions that people like to use today. And a query interface, you know, for doing forensic investigations, as well as proactive threat hunting, console for admins, analysts, and then both manual and automatic response functions, and we'll talk about that more in a minute.

So let's contrast that with NDR, network detection and response, whereas EPDR or EDR is based on agents, NDR requires, you know, either an appliance, a virtual appliance, or maybe a code that runs on a machine that can be plugged into, you know, inline on the network or off span ports, you know, doubling the traffic so you can see all the traffic that's going by, or in a few cases, there are solutions that merely pick up, you know, log telemetry from network devices.

These are designed to look for not only north-south, you know, things coming through the perimeter, you know, potentially malicious code or malicious activities, but also the east-west, you know, that's where the threat actors are doing their lateral movement and reconnaissance, looking to, you know, position and data for exfiltration.

Another benefit of many NDR solutions is they understand OT, operational technology, and industrial control systems protocols, and these can be very different from the protocols we work with in our offices every day, you know, things that are designed to interact with specific kinds of machines, you know, for power utilities, manufacturing, warehouse, maintenance, HVAC, so understanding what's going on on those networks can be very advantageous.

NDR also includes threat hunting tools similar to EPDR, which again is sort of going out and looking for things that may not have been defined as an IOC, indicator of compromise, already. Another benefit is, you know, NDR tools might have a chance of finding malicious activity when all the other tools miss it.

You know, in some extreme cases, there have been attacks on companies, government agencies, where the attackers take very strong measures to wipe out all traces that they've been there, so, you know, deleting logs, deleting entries and SIMs, covering their tracks as best they can. It's harder to cover the tracks at the network level, so looking for, you know, evidence where other tools might have missed it is a thing that NDR can do. And then also automated responses, you know, in this case, it's a little bit different.

It's not terminating processes and quarantining files so much as being able to isolate specific nodes or block traffic by, you know, IP or port or domain. So when I say indicators of compromise, here's a couple of high-level examples of what that might be. Malware generally gets in and will try to change things in the registry or the system files, again, so that they can maintain persistence, you know, after a reboot. Unusual use of network ports by applications. Sometimes they try to, you know, disguise themselves as, you know, a common application or run through a common application.

They might use different TCP or UDP ports for that. Simply contact with known bad IPs and URLs. Cyber threat intelligence keeps subscription services keep up to date on what IPs and URLs are being used by various threat actors. Down at the code level, there's unusual process injections. That's one way, you know, malware tries to keep off the radar of security tools as to inject code into a running process that's normally trusted. Same thing with modification and module load points, changing where it points to and adding code that could then be executed and hope to escape detection.

So for responses, what do we mean? Well, these are actions that can be taken either manually or in many cases, you know, in a fully automated way. So running CTI queries, going out looking for that, you know, bad IP, bad URL, you know, hashes, you know, code samples, those are things that, you know, you should be able to get from both EPDR and NDR and XDR. Automatically collecting forensic information is a great benefit.

You know, when an incident happens, there's a number of things that, you know, analysts commonly have to do that can be very repetitive, time-consuming, and maybe even error-prone. So being able to automate the collection of forensic information is a big advantage. Same with running scripts to support threat hunting, incident response, systems management. Case management is another feature most of the XDR, NDR, EPDR solutions have.

Being able to get information about an event or an incident, automatically create a case, assign tickets, and manage that from end to end, plus potentially integrating that with other ITSM, IT service management solutions. Of course, you need to be able to alert the Security Operations Center and analysts. And then I mentioned, you know, terminating processes for the EPDR side. If it realizes there's a malicious process, you know, cut that off, cut off any connections those machines have on the network.

Automatically updating detection rules once, you know, a new type of malicious event is discovered. You'll want to look for that across all your assets and across all your networks and cloud resources. Delete quarantine files. Remove those registry entries that are there to enable persistence. Isolate nodes or even whole networks if necessary.

And, you know, roll back infected endpoints to a known good state. Those are, you know, a good summary list of a lot of the things that can be automated or, you know, available kind of at the click of a button within the EPDR, NDR, and XDR realms. So a little high-level diagram of where these things go. So if it's EPDR, again, it's going to require an agent. So the agent, you know, is sort of the red circle here. You need those pretty much on every endpoint.

You need that on servers, you know, people who are working in offices, cloud VMs, you know, your infrastructure like email and web gateways. And then they all forward their telemetry to the EPDR console, which then can pass it on to SIEM.

I mean, these agents pass it on to SIEM. You can conduct CTI queries from there. And then SOAR sort of rides on top, and we'll talk about this more in a minute, looking at the underlying information in the SIEM. Now compare that to NDR, which has, you know, a very different kind of deployment model.

Again, looking kind of at the same infrastructure, but the NDR sensors here in blue need to be put on all the different subnets, you know, where you have users, applications, or other kinds of equipment. So, you know, in the case of office networks, you'll need agents on your routers and switches there. Same thing for, you know, your infrastructure, you know, firewall, web application firewall, email, web gateways. Remote workers, maybe they're coming in through VPN, so being able to have an agent.

First of all, you need agents on all the remote workers machines, but then also having a sensor, you know, maybe near the VPN concentrator is useful as well. In cloud instances, and then, you know, I mentioned industrial controls, IoT, and operational technology environments. Sometimes endpoint agents don't work in those kinds of environments or can't be placed on machines within those environments.

So, a network layer sensor is probably the best solution there. So, NDR is, again, you know, generally very useful in OT and ICS use cases. Similar to EPDR, this rolls up to the NDR console, also goes into a SIM from the NDR console. You can do CTI queries, and again, hopefully these can be plugged into and orchestrated by a SOAR if you are maintaining multiple different kinds of tools here.

So, XDR. XDR includes all these things that I've been talking about so far.

EPDR, endpoint network, access to cyber threat intelligence subscriptions, and a SIM-like data link, not necessarily needing to work in conjunction with a SIM, but being able to store the same kind of information. Other functions we see in some of the XDR platforms that are out there are cloud workload protection, distributed deception, unified endpoint management, vulnerability management, and user behavioral analysis. And different vendor solutions include different kinds of capabilities here.

So, what's needed? Okay, I've talked about agents and the need for those on every endpoint, on servers, virtual machines, sensors that work on on-prem networks, data centers, and in the cloud, a data lake, an enterprise console, and then an analyst interface.

So, in looking for solutions like this, it's important to understand your environment, what kinds of endpoints you have, what kinds of cloud resources you're using, and then also take a good close look at the enterprise console, analyst interface, how easy is it for your analyst to get their work done?

So, combining, you know, EPDR, NDR, you see, in some ways, it may look like we're doubling up, but it's just really putting those agents on all the devices where possible, and then, you know, putting sensors, network-level sensors, in every area in which you're operating, whether it be cloud or, you know, on-prem. So, XDR versus SOAR, we look at, you know, what does SOAR platform supposed to do? SOAR stands for Security Orchestration Automation and Response.

It's designed to, and you'll see this functions can kind of be similar, you know, aggregating security information from, you know, upstream sources. Those often include EPDR and NDR, web application firewalls, vulnerability management systems. All that gets, hopefully, pushed into a SIEM solution, security, you know, the data lake. This allows you to automate investigations, you know, correlate, deduplicate those entries, and enrich it, you know, in CTI subscriptions, to be able to do threat hunting from the SOAR console, and then to be able to respond.

But responding, in this case, means integrating with the APIs of all those, you know, upstream tools like the EPDR and NDR. So, when we compare, you know, XDR and SOAR have overlapping features in many cases, but I think one of the big differences is, you know, many XDR products are designed to be sort of single vendor stack solutions.

SOAR solutions are probably better for those who have, and really intend to keep, you know, a best of breed security architecture, meaning, you know, you've got lots of different products from lots of different vendors, and you need to be able to orchestrate and respond across all those different kinds of solutions. So, you know, there may be cases where some organizations could go for XDR and maybe not need a separate SOAR. It's a possibility.

So, looking at hype versus reality, you know, this is still an emerging market, and it will take time to get there all the way. You know, it has become a popular term. You've probably seen it a lot in marketing, but, you know, I don't think all products that are marketed that way have all the functionality that I've described here today. Some vendors are positioning their EPDR products as XDR, so they leverage agents on machines to capture all the network traffic, but I think there are some drawbacks to that approach.

First up, performance. If you've got every machine on your network, or, you know, some machines that are trying to read all the traffic that goes by, that's going to be a performance that it has to meet. It requires endpoints that have these EPDR agents on every single subnet, and, you know, again, in the case of things like ICS, OT, IoT, you know, you may not be able to put endpoint agents in those places. That leads to possible observability gaps, and then, really, there are fewer network layer controls that work at the endpoint level.

So, it may not be, you know, as comprehensive of a solution as one that does include, you know, dedicated network layer sensors. However, full XDR solutions do exist.

So, with that, I want to wrap up here with a couple of poll questions. So, after all that description, what do you think? Does your organization have EPDR and NDR in place today? Options here are EPDR only, we have NDR, C, we have both, or D, we have neither.

So, we'll give everybody a few seconds to answer that. Okay, great. And the next question, does your organization have or plan to implement XDR in the near future? And our choices here are, yes, A, it's planned, B, it's deployed, or C, not really under consideration at this point. Okay.

Well, great. So, just encourage you, if you have questions, again, go to the GoToWebinar control panel and feel free to enter those, and we will take those questions at the end after we look at the poll results. And next up, Marco from Sentinel-1.

Well, thanks, John, for the first part. Now, I want to talk a little bit about the XDR's view from the Sentinel-1 perspective. How do we see it?

You know, obviously, it plays along very well with the concepts which John has just mentioned, but also we're going to talk a little bit about the myths, what, you know, sometimes, you know, the misconceptions are when it comes to the XDR role or the XDR functionality. Now, the role of cybersecurity is obviously constantly evolving.

So, we need to meet, you know, the growing list of challenges faced by, you know, everyday organizations. Whether we look at small businesses or large businesses, you know, demand based on the security teams that are constantly, you know, growing exponentially.

Now, also the attack surfaces, they continue to expand. You know, we introduce more potential vulnerabilities for an adversary to exploit. From cloud transformation to IoT, our coverage map has never been more ripe for attack.

Now, what we also see is pretty much most organizations have invested in point solutions to address each area of their security stack. As a result, you know, adopting multiple best-in-place solutions has added complexity.

Now, we see this a lot and also sometimes confusion to the security practitioners, requiring sometimes a very steep learning curve with loosely or rather loosely integrated workflows. What else do we hear from our customers? While adversaries continue to automate the operations and most enterprises struggle to find enough practitioners, we actually see a growing number of threats. There are still not enough, you know, skilled personnel around to actually, you know, keep up with the influx of new threats there as well.

And also, we also continue to delay our early automated detections and responses. You know, adversaries will enjoy a longer trial time.

So, they automate, you know, they potentially get in easier, faster. But again, if we don't keep up with the same trend, obviously, we actually will be a little bit behind when it comes to identifying the attackers in the network and again gives them an upper hand.

Now, this particular problem is certainly new one, right? In fact, most organizations have probably already started with tools to mean to address these very concerns.

So, why is XDR from our perspective and when we talk to our customers, such a hot topic, what's different today and why should we consider a different approach, right? Some of these tools are working, they're doing a decent job, at least they appear to do a decent job.

So, why should we or why do we need to adopt? To start, you know, some of the tools which have been deployed, they have not universally been proven to be effective to detect and prevent all adversarial behavior.

Secondly, the attackers haven't stopped innovating, right? They don't really depend on working or fixed working hours, right? They're not really clogging in, clogging out.

So, they're continuously, you know, sharpening their skills and their tools to put new challenges ahead of the defenders. Also, cloud transformation, right? Organizations continue to, continue their journey on the cloud transformation and that might actually create unexpected blind spots, right? We see it in the news all the time that, you know, some data is being exposed in unsecured locations. There was just the no-fly list as an example, right? Exposed in some airline server.

So, cloud transformation definitely plays also a big picture in the XDR trending or the reason why XDR is trending. Also, with the exponential growth of alert volumes from an ever-expanding footprint of network and security solutions, there's simply not enough time.

You know, if, you know, I don't want to use the phrase alert fatigueness, but we hear it a lot. You know, more and more alerts coming in.

Again, not with enough resources to actually handle them. So, we actually see a lot of alerts being, you know, just bulk approved as an example of bulk acknowledged. And then obviously, as long as you continue to rely on the manual response efforts, attackers are inevitably going to enjoy longer trial times, right?

So, we need to automate more things. We need to automate playbooks. We need to automate responses to protect our ground rules in the networks and, well, identify attackers easier, faster in the network.

Well, this echoes the latest analysts' insights on the growing complexity of managing effective security operations. Now, a recent study here in this case by ASG exposed that today's modern security operations centers or CDCs will rely upon anywhere between 25 to 49 independent tools from, you know, up to 10 or more different vendors in order to do the hunting, triaging, or, you know, security operations.

The study also concluded that so long as these data are forced to reside in separate disconnected silos, it's going to be hard to identify, you know, all of the connected dots or connecting all of the dots, and that typically leads to some misdetections as well. I mean, nothing new here, you know, we're trying to break down these silos for a couple of years now.

Now, today's threat landscape or today's threat detection response landscape is quickly evolving to encompass all, you know, of the solutions which John has also mentioned, right? We're talking about EPP, EDR, or EPDR. We're talking about the network detection response, the cloud detection response side, and then obviously the whole area around SIEM and SOAR solutions which have been already used.

And again, XDR is aiming to become a new cornerstone of connecting these solutions or providing an overall solution for customers, right, to actually connect these different dots, breaking down the silos. But also for years now, right, security vendors are obviously working for one. They all have been promising what has been known as a single pane of glass.

So, there's one console, there's one area where you log in, you have all of the things you need, you just log into that one, and the idea is that this particular console can deliver the visibility, the response capabilities, and, you know, access to information stored in all of these different tools, you know, a customer might have deployed. Yet, while this, you know, was at least the dream everybody wanted to go, what sometimes happened was that, say, a single glass of pane instead of a single pane of glass.

So, each, you know, of the different security vendors typically rely on different consoles, you know, different methods of providing visibility and control. Each platform, you know, usually has some sort of learning curve, right? We expect our people in the SOC and the CDC to become experts in each of these different tools, you know, getting used to and work on a daily basis with these largely disconnected tools. This level of complexity which we introduce here makes it impossible for even the most experienced analysts to respond quickly at scale.

Imagine you have to, you know, log into three, four different consoles, you know, to gather the information, then again into two or three different consoles to actually take some action to, well, react to an incident. I think the most, one of the biggest arsenals in the analysts' toolset is probably the controls, Control-C, Control-V, where we take information from one console, from one disconnected system, trying to move it in a different one to continue our workflows.

Now, XDR, you know, promises again to reduce the complexity, right? So, we're trying to merge multiple consoles' features into a better user experience, which then also increases, you know, the outcomes or, you know, measurably increases the outcomes so that analysts can actually, well, work with the console and improve the overall efficiency.

Now, luckily, there's also a couple of things on which most vendors, you know, and analysts come to some agreement, and that's what are the value drivers. So, you know, we don't want to say, oh, yet another security tool, but what is everybody trying to achieve when they actually go on to an XDR journey?

And again, could be an XDR journey or an XDR vendor who's coming from the EDR side or, you know, also from the NDR side, all of the different areas which are mentioned as well. But one of the key things is reducing mean time to detect, right?

So, or MTDI, MTDI, MTDIR, MTDD, so mean time to detect, investigate, and response. The goal is to reduce the attack surface, improve detection rates, and again, we want to lower the dwell time an attacker is operating undetected in our network.

Second, and it's sometimes actually the first one as well, is reducing cost. Right, from platform consolidations to considerably less dwell time, XDR should yield a net reduction in cost and improve the ROI on your security spend.

So, you know, having everything in one tool, you know, having a measurable ROI, and also the time and efficient return of investments as well, these are definitely some of the key value propositions of XDR as well. Now, also, improved performance and scale, right? It's nice that we can actually save money, and it's also very nice and very important that we actually reduce the dwell time, but we also actually want to improve the scale of our, you know, sometimes limited security teams. The volume of data is only increasing, right?

And the value of the data that grows, you know, the data actually grows, which we have to render with each additional data source. Imagine you take all of the logs from, you know, your IPAM solution, from your proxy solution, from your NDRs, EDRs, all of these things. XDR should cost effectively allow for growth of this particular metadata, right?

So, that is definitely one big thing, so that without a dramatic increase in cost, you know, customers want to actually leverage multiple data sources, increase, you know, the data intake in order to actually improve the detection. And last but not least, improve security operations efficiency, right? Reducing the number and complexity of security consoles, coupled with a couple of simplified and automated response playbooks, XDR can dramatically improve the SecOps analysts' productivity.

So, that's pretty much the, well, the key value propositions which we see a lot from an XR perspective. And obviously, they are also related to the different XDR solutions out of the market, but these are the drivers which we, when we talk to our customers and prospects, obviously, which we see coming up most of the time. But we wanted to talk about debunking some of the myths as well.

So, we put down a couple of myths, and let's just talk about this one. And again, I think that aligns very well with what John mentioned as well, that you actually have to have all of these different areas covered from, you know, the endpoint side, the network side, VPN, as an example. But obviously, one of the big things is, you know, as number one myth, you know, that you don't need a successful EDR anymore, right? XDR can take care of that one.

And, you know, it wouldn't actually rely or, you know, need an EDR solution. Now, if you look at the reality, when we talk about XDR, and again, you know, we've seen it in the previous slides as well, is you need a solid EDR deployment, right?

So, you need to have, you know, agents on systems which actually support agents in order to gather the required information. Modern EDR solutions, right, continue to be one of the most effective security tools used to provide positive business outcomes when it comes to protecting the enterprise. And a lot of the breaches, I mean, you look at the different numbers, right, 70, 75%, they're still rich on the endpoint, right? Would it be through an exploit, right?

Or it actually starts with, you know, some board of identity, and then, you know, somebody's logging into an endpoint again, and then starting the reconnaissance from that endpoint. So, a lot of the time, or most of the, we see 70, 75% of the time, it is actually involving an endpoint.

So, but with most things in life, not every EDR tool is equal, right? So, they all have different, you know, features, functionalities.

So, do the research. I think MITRE provides one of the most comprehensive evaluations, you know, for all of the vendors.

And also, you know, differentiate what capabilities, when it comes to the EDR capabilities, do these different solutions have, detecting different TDPs, different tactics, vendors, actually, or not vendors, sorry, attackers, utilize. And obviously, the importance is, you know, the EDR solution should, you know, cover the majority of your endpoints.

So, if you're a Mac-heavy shop, as an example, obviously, the EDR solution needs to cover the Mac estate, as well as, you know, Linux, Windows X state, or even, let's say, the mobile environment. So, if we look at the amount of events and alerts today, right?

So, how do we actually find the needle in the needle stack, right? The pay stack would be easy, but we actually want to actually find the needle in the needle stack.

So, how do we go from trillions of events, if we look at, you know, all of these different data points, the different solutions, which we want to integrate in XDR? How do we go from those trillions of points of telemetry into, you know, broken down into a couple of hundreds of suspicions, or, you know, potential incidents?

And then, from there, we actually just derive with a handful of incidents. Obviously, the idea here is that we utilize modern technologies, you know, machine learning, AI, all of these things, to actually help us on this journey automate as much as possible. We mentioned it before, right? Nobody wants to actually look at trillions of event logs, you know?

A machine can do that in a much better way, and to actually break this down, correlate all of the data, the raw data coming in, to actually deduct the information, and breaking it down to, again, a handful of incidents, which then your security team can actually analyze. Now, myth number two, right?

I mean, that's something which we also hear from the customers, but also in the market sometimes is, it's just an exchange, right? It just sounds like an evolution of SIEM. With some of the use cases and outcomes of XDR, right? It may sound a lot like one of some of the SIEMs or SOAR platforms, and, you know, they were actually meant to solve a lot of similar problems, but let's have a look at the difference between those technologies.

Now, SIEMs, you know, they were born in an era where compliance in governments mandated the collection and storage of event data from a large number of disparate or separated data sources. Again, there's multiple requirements when it comes to PCI, as example, HIPAA, SOX, and so on and so forth, which require the collection and retainment of logs from multiple sources for a given amount of time.

So, these SIEM solutions have been built to ingest the broad spectrum, you know, of network application security logs, so that you can actually use correlation rules on them as well to detect some obvious patterns, such as proof of login attempts, you know, like how many events in a certain amount of time. Some of the problems which we have seen coming with the SIEM technology is there are sometimes an extremely high barrier of entry, right?

You need to actually, most of the time, write some parsers for the logs, you know, do some normalization of data, feeding third-party logs into these solutions. So, these are some of the challenges which we also see from customers when it comes to the SIEMs.

And, obviously, if you look at the other point, you know, the expensive side, so starting off easy, like getting a happy meal, so to speak, you know, I don't know, one gigabyte per day, but then when you add multiple data sources and more data, you know, into multi-gigs per day or even terabyte per day, it actually becomes sometimes very cost prohibitive. Now, let's look at the comparison between SIEM and XDR.

Now, if you look at the business focus, from a SIEM side, again, as we mentioned, evolutionally created or envisioned to address business risk, providing visibility and search across all of the different security data. Now, from an XDR perspective, it has a more proactive threat-centric approach, you know, it's supposed to help security teams more quickly and effectively detect and respond to advanced threats in near real-time, right, providing a lot of automation or one-click actions to actually start immediately the remediation of an observed attack, as an example.

Now, the deployment models of each technology, sorry, each technology. Now, again, initially, SIEMs were traditionally born out of the on-premise side and then merged into the cloud and the hybrid approach, where, again, XDR solutions typically have been created and developed with cloud-native approaches in mind.

Now, some of the use cases, again, SIEM market was bought from the log management capabilities, where the primary use case, as we discussed already, was the case of compliance and governance, log reporting and log recording, dashboarding, you know, and, you know, keeping the data for the prolonged amount of time, whatever was required from the governance or compliance reasons. Over the years, you know, the vendors actually added the correlation capabilities, you know, and the rule-based detections.

So, we have seen, again, the evolution there, rather, and then also, you know, latest and also real-time search capabilities, which can also show up as some features in the current SIEM solutions. Now, if you look at the use case from an XDR perspective, all around real-time threat detection, leveraging, you know, sophisticated machine learning and AI capabilities.

So, a completely different area where the XDR market sometimes is coming from. Now, from a data method perspective, you know, SIEM vendors, they were forced to adopt some data schemas, you know, pretty much focusing and pausing the data into a structured data schema. XDR solutions, you know, sometimes, you know, they are designed with, well, an open, flexible data structure, so pretty much removing the need for indices, for example, for fixed fields, so that you actually can ingest any kind of third-party telemetry data, as an example.

Now, from an analytics perspective, you mentioned that one already, you know, you're talking about rule-based correlation plus machine learning at a later stage for the SIEM side. And from an XDR perspective, obviously, AI-based detection combined with machine learning and BYOTI or BYOR, so bring your own rules, bring your own threat intelligence, which can be easily combined with the existing native XDR capabilities when it comes for data analytics.

And then, last but not least, operational modes. So, if you look at the operational modes here, you know, consume everything that you can afford, obviously, from a SIEM perspective, we mentioned that one already. Build static detection logic, you know, around tools.

And then, from an XDR perspective, in contrast, we're looking at the relevant actionable data, right, in which the investigations, in which the data set, if possible, you know, draw new conclusions out of the enrichment and then, you know, allow for easy, well, actions out of the XDR platform. So, the one-click responses, one-click remediations, as an example.

Now, if we look at myth number three, loss of control. That sometimes, you know, sometimes we hear that one, it's not that prevalent anymore, but some organizations fear that automating response actions takes the human out of the loop.

So, the whole Skynet philosophy, right, when we try too much on computer-driven, you know, automatic actions and the computer obviously doesn't make any ethical strategic decisions and, you know, it fears also that it might negatively impact the business operation. While automation can certainly improve response velocity, it's important to understand the distinction between action and prescription. Some scenarios might very well lend themselves to automated response actions, such as forcing users to re-authenticate.

Then, we see some suspicious activities, right, frictionless, you know, it affects probably one user. Other action items might be more intrusive, blocking access to an important resource or forcing administrative action in order to restore users to an unrestricted state.

So, XDR, again, is aiming here to, you know, find the right path to actually automate what is, what can be automated, but also allowing pretty much the SOC operator or the SOC analysts to actually take action, you know, drive the workflow, drive the actual decision, the playbook they are required. So, we know from experience that there still exists a divide between, you know, what machines and humans, you know, can do when it comes to decision making.

Now, we mentioned it just now, the machine should, we shouldn't expect the machine to do, you know, intuitive, you know, ethical or strategic decisions, but, you know, these are the areas where we actually need the humans to do. This is actually where we actually need to make use of the human capital we have, you know, in the SOC, the CDC, from a security practitioner in useful, you know, in the right manner.

But we can also, we also need to understand that, you know, a human operator will not be as efficient or effective as in certain tasks as the machine, right, when it comes to going through large data sets, looking for anomalies, looking for certain patterns, looking for the IOCs, which John mentioned earlier.

So, these are obviously tasks where the machine can help a lot, right, sifting through the data, analyzing the data, correlating, doing, you know, some basic decision, but when it comes to the cognitive workloads, obviously, we have to, well, put in the human into the loop again, so to speak, to drive the final decisions, you know, where required. And the last myth I want to talk about is simply having more data will inherently lead to better detections.

So, it's like, give me more, give me more, and then I shall find, you know, the needle in the needle stack easier just because I have a bigger needle stack. Now, reality proves sometimes a little bit otherwise, you know. If the data lake or data lake on their own would be a silver bullet, now we would actually see a lot more organizations have successfully implemented, you know, this one to solve all of their problems. Half of the, or a little bit more than half of the customers which we surveyed, they report that they have an active cybersecurity project involving a data lake.

The more compelling statistic is overwhelming failure rate amongst these efforts, which means, so we actually see a lot of enterprises going for the data lake, but eventually it becomes more like a data swamp, right? So, the promise or the hope for results are not as expected here.

Now, very important here, data ingestion sometimes is hard, right? Just throwing the data in there, you know, what do we do with the data, mapping all of these fields, and again, that could be a challenging topic for data ingestion as well.

Now, again, from a singular XTR platform, again, we have been, or the platform especially, it's in the one case here, has been designed to actually take on a broad set of these different tools, a broad set of these different blocks from all of the deployed best-of-breed solutions, as an example, to help automatically ingest the data, understand the data, and make it useful for analysis. So, actually taking the relevant data, connecting it with the relevant actions to actually drive the detection in our security operations centers.

So, just to close off here, just looking at the time. So, why should we actually think about XTR, you know, just to recap some of the issues which we talked about in the beginning. Speed and scale, right? It's the most important thing for any XTR solution. Complete visibility into all of the different data sources, correlating across the different stacks, you know, John also mentioned the different tools which produce locks, integrating with your existing security stack, right? If you have single-sign-on solutions, VPN solutions, having that single glass of pain, or pain of glass, right?

We don't want to have a glass of pain, but the pain of glass, pretty much helping here, getting a head start on the attacker as well. Automated resolution, where applicable, automating as much as possible, and therefore also reducing complexity. Complexity is obviously always the challenging part. If you remove complexity, you increase the efficiency, and again, it's all about identifying potential attackers earlier in the network. And with that, I'm handing it back to John. Thank you very much.

Great, thanks, Marco. So, let's take a look at our poll results.

So, does your organization have EPDR or NDR in place today? Okay, let's see. 27% say EPDR. Nobody says they have NDR, only. A little more than a third have both. A little more than a third have neither.

Okay, those are interesting results. Next question. It would be interesting to see if we have a split around the customer size there, right? It would be more like, from a size perspective, you know, does it fit into, let's say, the SMB market or more the enterprise market there? True.

So, our second question was, does your organization have or plan to implement XDR in the near future? And this is split about a third on each one.

Planned, deployed, not yet under consideration. Fewer in the deployed category. It's not really surprising, given the relative newness of XDR compared to EPDR, NDR, and other solutions. Any thoughts on that, Marco?

Yeah, it was very interesting. I agree with you. It's like the plan side, obviously, you know, the marketing hype was there for XDR. It kicked off a couple of years ago. And I think that's the, I think you mentioned the, you know, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the. And I think that's the, I think you mentioned it also in, in your slides, right?

The myths, right. And what is the reality?

So, there was a big push, already, from XDR a couple of years now, which obviously drove it forward. Some people, you know, probably had to wait for their renewal cycles. Interesting, but that also, let's say, assert, is, is not on the, on that path yet.

But again, it would be nice to correlate it with the size of the companies there. True. Okay.

So, let's look at our questions here. Can existing data or processes be converted to XDR?

The, that's a, that's an interesting question in itself. I don't think about the, the data side so much as, you know, what's required to deploy it.

So, if you've got, you know, existing EPDR or NDR, I think that, you know, start by looking at what that solution offers. It's not like it's hugely, you know, qualitatively different.

It's just, you know, where, where the telemetry sources are from and then how the solution deals with those different telemetry sources. Much of the underlying information will be very similar, I believe.

Any, what, what do you think about that, Marco? Yeah, I agree.

I mean, ideally, if you already have some data, right, XDR solution should be able to just, you know, use that data, right? And then, you know, maybe if you want to switch at one point, right, see if the data, you know, sources can be just, you know, flipped over to an XDR.

But, I agree. I mean, the ideal part is you don't want to duplicate data, right? It's never a good idea from a cost perspective and complexity.

But, just use the data which is already in the SIEM, you know, on the journey to XDR as an example. Next question. How does one get started with XDR?

Well, I guess there are multiple answers for that. If, if you're, let's say, in a brand new company and you don't have, you know, security solutions, that might be the perfect time to say, look, we're going to go for the most modern thing that we can and look for XDR that covers, you know, our endpoints, our networks, our clouds, and anything else.

If you're established and you, you know, have different EPDR types of solutions or other security architecture components, then I think, well, anytime you begin an analysis such as this, I think you really have to take stock of what you already have in your security architecture inventory, so to speak. Look for gaps in coverage, not only, you know, the observability gaps, but what are the kinds of capabilities that you feel like you're missing and you might want to augment? That would probably be two ideas for where to start there. What are your thoughts, Marco?

Yeah, I completely agree. Like, doing the gap analysis, right? Looking at your maturity level, looking at your exposure level, seeing what's currently possible in the environment and see, okay, we need to either respond faster or, you know, look at different silos. How can we be more efficient?

That's, I think, a good starting point. Unfortunately, not many of us actually have the ability to start with a greenfield, right?

Saying, okay, design it from scratch, right? That's unfortunately not often the case, so there will be always some legacy systems and, you know, seeing, okay, how can we improve these legacy systems? How can we improve the correlation between the systems?

Yeah, that's definitely a good starting point. And our last question may have been inspired by your discussion about data amounts that can be ingested.

So, how much data can be ingested daily? I'll leave that to you. That's definitely a good question.

I mean, that's depending, obviously, on how much data will be produced, right? If we could take everything, we're coming back to, you know, is it useful data?

Is it, you know, useful for our use case, right? You know, operational locks, for example, they probably can generate easily terabyte a day. Question is, would they be relevant for a security use case, right? But obviously, you know, modern solutions from a XDR spectrum, you know, they typically handle gigabytes worth of data a day.

So, it shouldn't be, let's say, the limiting factor for planning that one, but rather the limiting factor or the idea should be, okay, what data is relevant for my security use cases? And then typically, modern solutions, you know, don't struggle with that event load. Great. Let's see. We have one more. Do you think XDR is a fit for DFIR?

Well, yeah. So, well, I think from my perspective, I think from a hunting perspective, right? But when it comes to the response side, right, we need to see what capabilities the platforms have when, you know, fetching the forensic happy meal, right? If you collect all of the things which you would need from a DFIR perspective, memory dumps, shell bits, you know, all of these things, prefetch. Most of these XDR solutions can actually do that one.

But, you know, from analyzing it, right, that's sometimes, you know, there are probably more granular tools available to actually do the deep dive forensics into the forensic evidence, which evidence could be collected by XDR, but analysis probably requires some specialized tools, in my opinion. Sure. Okay.

Well, that's all the time we have today. So, again, I wanted to thank everyone for attending, and thanks, Marco, for your contribution here. Good information. It was a pleasure. Thank you very much, Tom.

And, again, the recording and slides should be available shortly. So, thanks, everyone, and I hope you will join us for our next webinar. Have a good rest of your day. Bye-bye.