Debunking Common Myths About XDR

Thank you so much. It's a pleasure to be here. Speaking to you about exactly the new three letter that has showed up to kind of storm the market. And it's funny, as we were actually talking about standards, I was actually looking through the previous presentation and it's important to understand that XDR by itself is not a standard, it's a, it's a vision or philosophy at best. And that's exactly why there's so many different interpretations of what XDR means, even from an Analyst point of view. We know that there's there ample disagreement of what it actually is supposed to be.

But anyways, XDR means extended detection and responds. And then, hello everyone. My name is Antonio, I'm from Sentinel One. I work here as a technology strategist. For people that don't know Sentinel One, we're a cybersecurity company offering cloud services. We've been redefining cybersecurity for work quite a while now. We basically really find EDR and we'll, we're now trying also to actually doing it, really find HDR as as we speak.

And today the core of the presentation is really to go over some of those concepts of what XDR might mean to you, again, because it is an open element for interpretation, but also what might be like the caveats, the eventually the myths that circle around xdr. All in all, it's not a product pitch. I'm really here to try give you top of mind insights for you to take with the, on your XDR journey, Right? So we've all been, you know, trying to get this, I would call it Olympus, this dream of a single painted glass for all of our security operations.

And to an extent we've been trying to do that collectively for the past decades, right? Through various forms of single painted glass. But unfortunately the reality is that it's more of a single glass of pain than anything else in one element that definitely XDR is trying to redefine is really this aspect of trying to provide a single painted glass, the empowerment tool for the SecOps in trying to mitigate eventually the shorts of the previous products or platforms or tools, whatever you want to call it, that eventually have these same promises.

And the reason why it, it basically happens to be a glass of pain and not a single paine of glass. There's multiple reasons for that. I'm sure that many of you are aware of these. Number one is the rapid expansion of the tax surface. I mean we've all went through that process of going into like traditional or legacy lift and shift of our data center through the cloud. And eventually gradually organizations started doing more native adoption of cloud. We're talking also about business to business identity, business to customer identity, supply chain.

I mean the lot, the reality is that slowly, slowly organizations are often faced with a very large attack surface and very often even unknownly, they have specific attack surfaces that are completely open and not, are not being protected or not even having visibility over them. And then there's also like this kind of reflects, which I call like a knee jerk reaction or whackamole. It is what it is, right?

To, to a certain extent. It's also our own fault, meaning like collectively in the industry we like to paint the scene with a lot of, you know, fear and, and, and doubt with some very nasty statistics about all of the threats that appear out there every single year. And that's okay. I mean it's important to have a, a sense of the reality and what we need to address, but that often this behavior of just going into outside, into the market and buying a new box with three letter condoms that does something to you to protect against something.

Whether there's like a new threat, a new attack vector and and so on. But the reality is that, and it's okay to be multi-vendor. I mean there's no no wrong with that, but we're talking about individual boxes that are by themselves siloed. They're not actually working to your benefit because eventually organizations will have to stitch that data, correlate creating sites, automate, orchestrate manually or by themselves. And not all of the organizations out there have the capability to do so. Even the ones that have, they spend probably like thousands or millions of dollars trying to do it.

So the complexity just obviously increases by the day. And that leads us eventually to this manual triage behavior investigation because our teams are completely over flooded with signals and like very disconnected alert centric tools.

Again, those stacked boxes that I was talking about and not actually offering context, not offering insights, actionable insights by the way for things to be action upon or even more for things to be actually done automatically. And we know that again, threats are increasing exponentially where we're just talking about that, right? We're not advancing at the same pace that threats are, tools are not advancing also at the same pace that threats are. And I mean from a entropy point of view, we could add as much energy as we wished we could. Unfortunately it is not possible, right?

Because there's obviously a cybersecurity skill shortage as we all know and fundings are not a limited. But even if we had, that would not scale in the same linear way that threats are scaling. So there's two points here that I wanna mention. Like tools have to empower people and we should not expect people to be empowering tools. And even like it's not only a question of hiring, it's also a question of retention of personnel.

Just think about like your, your SOC team, your SEC ops team, just being day in and day out, just reviewing and triaging alerts without actually doing any meaningful work on them or working on the exactly like the mitigation and the security posture improvement of what happened yesterday. That is going to obviously affect their willingness to continue working for you, right?

And again, that might be derived exactly also processes or tools that are clearly inefficient and are not working to their advantage. And this all tops into like reactive processes and flows, which we then again just get into this perpetual cycle of disconnected lack of context, very manual driven operations in obviously reactive. So the evolving landscape for condition response, I mean we've, we've all went through this, right? It's a and ADR coming with other tools like, and the animation here trick me, apologies like ndr.

So network detection response, cloud detection response, we all top this with Siemens. So to try to bridge the gap in between all of these different set of tools and insights and data. But obviously it was a lot of complexity into it, it still is. So this is exactly what XDR is trying to do is the convergence of all of these elements into a easy to use, easy to adopt as a journey platform, a vision to really enable and empower security operations.

Now the, the problem with that is that again, here's the hype of a new three letter economy and out of the sudden everyone shifts their product in marketing saying that, Oh I have xdr, you probably didn't know it but I have it for like X amount of years, which just now happened to call it xdr. Nothing specifically bad about that, right? But the point here is it is bad for you in the way that you might actually not get the clarity that you desire to understand where to invest or what to do next.

Now my point here to begin with is that there is not nothing necessarily wrong with many of these strategies. Meaning that there's like no right or wrong path. You'll have to define this for yourself, what is the best strategy for you? But obviously there are ones that have more shortcomings than others. So we have like the first one, which is like the mega products, security defenders that have now integrated all of their portfolio into a single product from a marketing perspective and aren't calling it xpr.

That obviously has the constraint of going a single vendor and probably also not allowing you to do or continue the investment that you have done in other best of breed solutions within your own organization.

Then you have, again because XDR is also focused at data at its core, whether that is like native integration or custom data, you actually have these vendors that are coming from the security analytics space or even log management or data analytics and now are saying, hey we have some machine learning and ai, we have some detection capabilities, there's some top of mind integrations available there we have xdr. But the reality is that it doesn't actually help on the infrastructure side on things like the prevention or the protection or the response and the radiation.

So those are lacking components that are actually organizations are struggling to mitigate with other tooling and just again perpetuating that cycle of stack boxes disconnected that are not actually working to your benefit. And then you have EDR vendors that are doing integrations or point integrations with selected partners and are calling obviously XDR solutions.

Again, the extension of the ecosystem is important. Definitely, I mean from our point of view, open XDR together with a native XDR approach and by open I mean being open with the ecosystem is important. Not in closing organizations into buying just a single stack in my opinion is one of the right directions.

But again, we have to keep in mind that these might be shallow integrations that will probably not offer you exactly what you are looking for. Like the data ingestion, the fusion and the orchestration of response and automation. And then we have the same in the, so obviously because they were already there trying to exactly mitigate those challenges that we've tried to to you know solve during decades and now they're doing this integration and like we have a lot of playbooks and we have ML and AI detections and here, here it is like hbr, but at its core it's still gonna be like a Seymour.

So it's gonna lack many of the other elements that I've mentioned here before, like the infrastructure for example. Last but not least, we have the MSSP integrations with again shared workflows. And those tools have been built in rightfully so by MSPs over the past decades bespoke tools.

So again, they are serving a niche of a need for those MSPs specifically. They are actually caring for all of the requirements that eventually are out there for the majority of organizations. So still there is a ample agreement on what are the key value propositions for xdr. That is the reduced meantime to detect investigative response. It is the question of reducing complexity and therefore reducing cost. It is improving performance in scale.

I mean we don't want to actually be limited once more by the legacy constructs of doing set ops, by using the same set of, you know, concepts and technologies that we have been using for the last decade, unless is obviously improving the SEC ops efficiency and skill. As I said, empowering the human, not actually empowering the technology with the human. So we are now into the first myth and very often there's this misconception that XDR can again exist without a solid IDR foundation.

The reality is that XDR was born and this is like something that there's some ample agreement on, was born from EDR itself by the success of edr, by the efficacy of EDR that has proven and shown into the market. And now we're going into more than just endpoint and again looking into statistics and our identity is today at its core when it comes to unfortunately like compromising organizations, but endpoint is still very much a part of that attack chain very often.

So it's still very important also to first and foremost as you go into your XDR journey, start simple and start with things that are proven. Don't overwhelm your SEC ops teams or your security engineering team just by going into every single possible surface out there that eventually HDR can cover. Just overwhelming nationally, everyone. And like I said before, HDR is adding exactly those vital non endpoint telemetry data points in into the whole scene.

So it's again, bridging the endpoint data with email network cloud identity and transforming that from billions of points of telemetry to eventually hundreds of suspicious events to shrinking that down into a handful of incidents that actually have a story to tell that actually have a kill chain to tell, have actionable insights once more that have recommendations, automated orchestration capabilities into it so that it actually empowers you once more. Myth number two is well x, there is just a next scene, right?

Because again, like I said, it's data edits for, it's about also interesting custom data. So it's a theme. Well reality is first and foremost, not all data is equal.

And again, scene and XDR are in reality complementary. They're not trying here to overcome one or the other scene has very specific use cases in scenarios that XDR is not at all, you know, trying to solve or trying to mitigate because it's simply outside of its scope. We can eventually give you an example of compliance or data retention for long, long term that eventually not even from a threat hunting perspective or threat detection perspective might be actually useful. And also not all data is equal.

So we have to keep in mind that even if some set of data might have a a glimpse of security benefits, again the volume, the value of that data is obviously different and we have to understand that it is still important to determine which data might actually go into one platform or the other. Or even like from a time period point of view, it first goes into XDR and then obviously goes into scene for long term data retention and and seen by itself.

We know the challenges that our companies go over it not only is again complex from a definition in architecture point of view, eventually what data to ingest, how to store it for how long, what type of data, types of data, cool data, archive data, the cost inherent to it, but also like very much nowadays what we're seeing is this shift into not only ingestion of data and storing the data, but also the actual billing of querying the data. And obviously from a security point of view, this cannot happen.

I mean XD is here to help you to democratize the access to that security data so that you can actually empower yourself in not thinking about the cost of doing hunting at long scale for example, or a larger scale for example. But again, XDR in are complementary. This is something to be really top of mind.

Myth number three is as as we go and expand XDR visibility and scope, specifically the orchestration bits that I mentioned across multiple surfaces, many organizations are concerned with the lack of control or the loss of control trumpet or Trump by the automation that the platform might actually inflict. Well naturally this is going to depend on the approach of the vendor, not saying the opposite, but again, the automated response and recommendations obviously attached to detection of possible threats or behaviors and threats is definitely important.

I mean we've seen the dwell time with attackers being very, very small for very disruptive attacks. There is no other way to respond to actually, again, the evolution of threats if we don't make use of automation. The other element, like I was saying, is really dependent on how the actual vendor is approaching automation.

To us, what's important is that the platform respects the human element and that it learns from the human element and it learns from the context of the organization what can be safely automated as time goes by. Not that are things that we know today by default, by experience on elements like EDR for example, of things that can be already safely automated. And we can talk about like threat intelligence ingestion or use authentication in many others.

But again, the point here is really about understanding the place of human and the place of machine, of where a machine is very good at doing data collection and search at scale. The pattern matching the summarization and much more human adds. The intuition, the context, the ethics, the creativity and the strategy that the machine cannot add.

So again, it's important to respect the Iman element exactly as I was saying within that automation. And once we are able to achieve that, you'll see exactly the synchrony in between all of the surfaces that are being protected and having visibility upon and being able to respond much more quicker for any type of threat showing up. And again, as I was mentioning previously, xdr at its core, it's all about data, right? We know that data is the core for cybersecurity and often there's this misconception that more data that I ingest into something will probably yield better detections.

Not so, not so true, right? We've unfortunately seen this from other records that we have with our history of cybersecurity that more mature organizations, for example, that were capable of going by themselves and doing projects like security data lakes even before it was a thing in the market. It was super complex. Super complex, exactly because of all types of data and eventually also the technology that was actually being used forcing specific requirements in terms of normalization of data ingestion example or the complexity of building parcels for every single type of data.

So we have to almost come to, you know, an agreement that there is gonna be data that is gonna be structured, there is data that is gonna be unstructured. What is important to be there is really the platform, the Xbr platform to be able to do detection and threat hunting across regardless of whether it is normalized or not normalized. And also making sure that once more, you're not actually concerned on the cost of that data, but you are focused on the benefits of the data.

But still, like I've mentioned, not all data is equal. So the platform also has to understand what data is best for its capabilities of detection and prevention. And actually as we go in, offer more integrations out of the box exactly to bootstrap the process and reduce the load on organizations to actually manually build integrations, maintain those integrations, and understand what data to be interested or not that the platform itself does it and understand what data might actually be yielding more benefits as as we go. So I'll end here and I'll, I'll finish with a six.

Top of mind points for me are important for your XDR journey you brought into the XDR journey. Number one is like, don't try to solve new challenges and very complex challenges with legacy constructs. And specifically, again, while data being at its core focused on the platform that actually provides you the data analytics at scale without diminishing speed or access to data or again, the actual costs accessing that data.

Otherwise you're gonna go exactly where we departed from or you probably departed from, which is with a segregated or limited platform in terms of cost or architecture that doesn't actually provides you the, the visibility that you need. And again, visibility is going to be key. A element that XDR is definitely trying to mitigate is the ability for organizations to have visibility across all of their acids, all of their surface protection platforms in a single pane of glass that will allow you to do exactly that more than just correlation. It's all about actionability, right?

Insights and actionable insights. So it's very important to go just beyond the correlation, here's an alert, here's an alert, those two are, you know, eventually related, I'll create an instant for you. And that's it, right? There's no other context added, there's no recommendations, there's no ability to eventually even prescribe a guidance on automated radiation or response that is once more not exactly what we're trying to do here with xdr. We're trying to achieve that beyond correlation.

So threat fusion, again with the contextualized insights and recommendation is, is really top of mind foster or really understand that the platforms that provides you out of the box easy to use integrations is going to give you the, the most benefit, the most, the biggest return on investment and eventually also going to allow you to do a very rapid adoption of your vision of the, the connection of all of the surface that you have within the organization.

So I, I mean let's, let's be honest, there's gonna be always an element where there might be the, the, the requirement of the necessity to actually build something from scratch.

But 80% of use cases that typically organizations require whether there's like connecting identity or email or cloud in building not only intuitions but also the automated orchestration for response and radiation, but also anticipation of possible issues should be done out of the box exactly to overcome the challenges that we had before for companies that cannot do them by themselves or eventually the companies that do not want to spend large portions of money just maintaining those orchestrations and playbooks and and so on. And again focuses on the reduction of complexity.

We talked about consolidation here. In my mind, consolidation is not only going to a single vendor, consolidation is not having just one box. Consolidation means exactly the reduction of complexity of your security program and eventually having a middleware layer, having a layer that is capable of aggregating other things, concentrating them, converging them so that it can actually do much more and much better than you were doing before.

Thank you very much and Antonio, you've gone through a great deal in over 20 minutes and I'm free, we're gonna have to call time there because we've now got a very reduced networking break. Thank you very much. Okay Guys, thank you so much.