Part two of a three part series - A SOAPA Discussion on EDR and XDR With Jon Oltsik and Dave Gruber
Watch more in this series:
- SOAPA Discussion on EDR and XDR With Jon Oltsik and Dave Gruber Part 1
- SOAPA Discussion on EDR and XDR With Jon Oltsik and Dave Gruber Part 3
Jon: Welcome to part two of the ESG SOAPA video series. And I'm joined by my sagacious colleague, Dave Gruber. Dave, welcome back.
Dave: Thanks, Jon. Always a pleasure to be here.
Jon: So Dave, you and I are collaborating on coverage of something called XDR. And I've written about it, you've written about it, but can you tell the audience what the heck is XDR. Why should anyone even care?
Dave: So XDR, I'll start off by calling it a movement, because I feel like it is. It's a movement in security operations centers to bring together telemetry from many security controls to paint a more clear picture about what's happening in the environment, and then to add a level of automation to help people respond more effectively based on that environment.
So XDR, some are translating it into formalized product. Other are translating it into architecture. You and I have had many conversations about that and I'd love to hear your thoughts there as well. And then, sort of, others have put it together as an assembly of different products from different companies.
Jon: Yeah, I'm glad you brought up architecture, because I remember the first time you and I talked about XDR, or maybe an early time, I said, "Dave, draw me XDR on a whiteboard." You drew it and I said, "Dave, that's SOAPA." And you and I, kind of, agreed on that. Is XDR SOAPA or is it, sort of, proprietary SOAPA? What do you think?
Dave: I think it starts to blur the lines there, and you've asked me before about what's the difference between the SOAPA architecture and what we see vendors doing in the industry to bring these pieces together. For me, much of it is around packaging and simplifications. It's taking the concepts that, Jon, you've been talking about for a long time, for SOAPA, and it's packaging them in a way that makes it more turnkey for organizations, so they don't have to do the heavy lifting to assemble the pieces themselves in their own form of architecture.
But yeah, they have a more tightly integrated set from an individual vendor or a handful of vendors.
Jon: Yeah, absolutely. And you and I have talked about this vision of, sort of, controls on one hand meeting security operations on the other hand, so you've got, kind of, a closed-loop process between them. But that's vision. So where do you think we are today and what are the phases that you see, at least in the immediate future?
Dave: Yeah, so you know, step one for bringing the pieces together is data correlation. That's no easy task. When you try to bring all the security data together and there's lots of vendors in the marketplace that are working hard to try to do so, each selling their own sets of controls, so different vendors bring together different controls, but correlating that data, sort of the upfront piece, and people will talk about that as we're building a data lake for you, if you're not building your own, and putting the data together.
But that's only the beginning of the equation. The next step to then is having a level of analytics that can take that data and start to have some pattern recognition about what's happening, so we can understand attacks, we can understand indicators of attacks versus individual indicators of compromise that we often see from the silos. And then, sort of, the final step in that equation is the response process.
Once we understand and we correlate the data, we can understand what's happening, how do we respond to that? And it could be a recommended set of response actions or, hopefully, a more automated set of actions that push those response actions right directly back to the controls, multiple controls, all in an automated fashion.
Jon: What I'd add to that is we've got to think of attacks as attacks. They're campaigns. They take multiple phases or steps. That's why we have something called the Kill Chain. That's why we have the MITRE ATT&CK; framework. And to me, XDR is an analytics tool that looks across the components in an IT infrastructure, and seeks to piece those attacks together versus looking at discrete security alerts or security events, and then trying to figure that out after the fact.
So once again, you nailed it, great job. This is a great discussion. And so I'm going to do something I never do. Dave, can you stick around for part three of our video?
Dave: I can talk about this all day. I'm in.
Jon: Okay, sounds great. We'll be back with more from Dave and I, really soon.