Understanding Contrast ADR

Jeff:

Hey, Chris, great to talk to you again.

Chris:
Yeah, definitely. I'm excited to chat. I always have a lot of fun when we sync up and dive into things here.

But you know, one thing I want to ask you about is this rise of application detection and response or ADR as it's called. What do you make of this new category? What makes it different? Why are we seeing this rise of this category here?

Jeff:
Yeah, this is really exciting. I think there's a huge gap in Application Security around detection and response in production for applications and APIs. And if you look at the ecosystem in production, there's XDR and a bunch of sub-DRs like, you know, EDR, CDR and a bunch of others. And there's SIEM and SOAR as well as CNAPP. And all those tools are pretty well-entrenched.

They're doing a good job at detecting network and host-level attacks, but there's this big gap in the XDR picture around applications and APIs. The only thing that we have there that tries to fill that gap is WAF. And frankly, WAFs came out in the late 1990s and they haven't really evolved very much. In fact, the most popular WAF by far is ModSecurity. Many of the cloud offerings, the third-party offerings that offer managed web, they're all just ModSecurity under the hood, which is an open-source OS project. And, you know, it's good stuff, but it's very reactive. It's sort of syntactic pattern-based attack detection and it's always going to over block and under block. So they make a lot of mistakes. 

And I'll tell you, most organizations, they just put the WAFs there as a checkbox in almost all situations. It's not even enabled for blocking and nobody's looking at all the alerts because there's zillions of alerts that get generated of every single thing. So it's really not effective.

And so ADR is targeting, filling that gap. That's the scope of it.

Chris:
Yeah, it makes sense. We think about, you know, this traditional focus of, you know, as you talked about EDR, XDR, you name MDR, like it goes on and on. But the application seems to have been missing from that equation, despite the fact that, you know, things like DBIR point to, you know, web applications being one of the most prevalent, you know, attack surfaces for incidents and exploitation. Increasingly we see attackers targeting, but the app has been left out of the DR, you know, conversation.

So what makes these tools different? How do they work under the hood? You know, what's going on there?

Jeff:
So the idea of ADR is that it uses instrumentation to watch how the application behaves. And using the context, by directly observing the running application, it can make better decisions about whether something is really an attack, really a dangerous attack. And I'll give you a lot more contextual information about what's really going on. And the cool thing about that is, you know, a lot of attacks start in the application and then they move into the host and then they island hop and then it goes. But if we can catch them in the application or in the API early, that's great that you want to stop these things before they get into your operating system and start running native processes and doing all kinds of crazy things. So ADR is, it's exciting that way.

It's very early in the ADR space. And so there's a number of different approaches to doing that instrumentation. There's a number of early startups that are using eBPF to try to do that instrumentation. Have you heard of that?

Chris:
I have, yeah. I've seen a couple of companies working it from that angle for sure.

Jeff:
So eBPF is really to instrument the Linux kernel and it's really cool. It's a way of instrumenting the kernel without having to write a lot of code. You can add little eBPF filters in to gather data from the running kernel, which is exciting, but it doesn't have a lot of visibility into the application layer, which was the whole point. And so I think while you can do a few cool things like eBPF can watch file creations, it can watch process creation, maybe even some network communication.

That's cool, but if you want to really do Application Security, you've got to be able to do things from within the app. Like you've got to be able to see data flow, right? It's hard to do AppSec without data flow because most of the major AppSec issues are injection, SQL injection, command injection, X pathogen, like all of the different injections, and they all require you to trace data through the running application. That's not something that you can do with eBPF.

There's a number of other things that you would want to do. You know, like you want to watch dangerous functions, execute things like parsing XML documents, connecting to the database. All these kinds of methods are in the application space. They don't make kernel calls. Like it's all inside Java or NET or Note or whatever you're using.

And so our approach is to use application layer instrumentation just like an APM tool, like a New Relic or an AppDynamics for performance. We want to monitor the application the same way, but for security. And so, you know, our contention is we can have a much broader rule set, much higher performance and much more complex rules by watching the application directly instead of watching like the plumbing underneath.

And I think about that like, I make an analogy to a building. If you wanted to understand what was going on inside the building, you'd put cameras in the offices. You wouldn't watch the deliveries through the front door and the plumbing go out the bottom into the sewer, right? Like, that's what you can see with eBPF.

And look, those companies are interesting. They're doing some really creative stuff, but I don't believe they're going to be able to create a broad rule set around AppSec.

Chris:
Yeah, it kind of reminds me, like you talked about using that analogy of the building. It reminds me of security observability, like, you know, what's going on underneath the hood rather than this kind of perimeter centric approach of observing, you know, malicious activity, for example.

How do you see this category evolving? How do you see it being used by organizations, as people start to adopt tools like you all and others to carve out this new capability?

Jeff:
Yeah, I think what we'll start to see is some consolidation on what is application detection and response. To me, it's important that it's focused on incidents. This isn't about vulnerabilities as much unless it's a really critical vulnerability like Log4Shell or a critically exploitable SQL injection or something.

Only the highest level vulnerabilities rise to the level of an incident, which is something that demands immediate response from the organization.

And so focusing on those incidents and providing all the context to the incident response team in the form of, you know, details, blueprints, stat traces, and runbooks on how to respond to different kinds of application attacks, that's what the operations team needs because they don't have much history dealing with Application Security problems here. They're not going to know what, you know, unsafe deserialization is.

We're going to have to help them understand that problem and help them figure out a way to respond to it quickly.

Chris:
Yeah, I agree. Typically organizations that, you know, have the SOC, the SIEM, you know, the enterprise security operations team, they're going to lack that context of the application and, you know, that the development team may have, they have to go engage them and ask a bunch of questions. I think empowering them with runbooks and information to you know move out quickly and in form fashion is going to be key.

Jeff:
And I think it has to fit into XDR and CNAPP and SIEM and so on, whatever the organization is already using. ADR is not going to be a standalone dashboard thing that you use. So it'll be more like EDR that feeds into a system that can then correlate the application events with the network events, the server events, the cloud events and build that picture so that the threat researchers can dig in and understand the scope of the full attack and the impact of that full attack.

Chris:
Yeah, I think it gives a much more holistic picture as you talked about, of not just the application, but everything beyond that within your organization from developers, workstations, endpoints, etcetera. And tying all that together.

And I like where you said with not another, yet another dashboard, right? So like that aspect of it as well.

I'm really excited to see where ADR goes. I think what you are doing here is really key. It's been an aspect of, you know, kind of the DR category that's been overlooked when we look at the application aspect of things.

Jeff:
I believe that there's going to be a convergence of pre-production security and operations security around applications.

What I realized was that, you know, a vulnerability starts in development and then as it goes through the development process, eventually it gets closer to production, eventually gets into production, then eventually, you know, maybe somebody attacks that company with the same kind of attack. Eventually they find that vulnerability and try to start exploiting it and eventually they exploit it.

But it's all one journey. It's the story of one vulnerability from birth to exploit.

And I believe developers need that information about what's going on in production in order to prioritize correctly. So we'll start seeing that ADR information about threats in production start feeding the priorities in development. And it could change day by day as the situation in operations changes. Today that communication doesn't exist and it works the other way as well. I think you know some of the information from development informs the response to incidents in production. So having it all in one system that can see that full story I think is really important. We talked earlier about how most AppSec tools create silos and drive teams apart. I think the combination of future AST and ADR tools coming together as one thing is what's going to bring security and development and operations all together and realize the benefits of DevSecOps.

Chris:
Yeah, I really like that framing actually, because when you think about it, it's kind of a threat-informed defense or threat-informed secure software development activity. What are the threats that we're observing or malicious activity that we see at play in the operational environment? How do we align our development activities accordingly to mitigate them? So I really like that framing a lot.

Thanks so much for chatting about ADR and I'm excited to see where it goes.