Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor with KuppingerCole Analysts.
Today, again, we have the second Matthew Gardiner. He is a fellow analyst with KuppingerCole, and he's hailing from the United States.
Hi, Matthew. Thank you for having me, and I'm actually specifically in Boston. We want to talk about a topic. First of all, it sounds like a new topic, but it isn't. Everything is better with AI, so it has AI in its name. We want to talk about AI SOC. Before we go into questions, of course, you're doing research on that, and that's the reason why you're the second time here in short succession, because you're working on interesting topics.
AI SOC, what is it? Basically, it's an evolution of security automation. I refer to the whole space as security automation, generally to stay away from acronyms as much as I can, but it's the evolution of what was SOAR, security orchestration, automation, and response, which has been around for 10 years.
Now, the vendors and the customers are heavily applying AI to the existing problems. To spice things up, I called the report the emerging AI SOC, so that people can understand that there's an AI element, but we're still talking about the challenges of basically threat detection and response. I have done quite a list of episodes around this evolution with Alexei, our colleague, and Alexei explained in detail why we need this source to filter the sheer amount of events based on rules, based on pattern matching, and automation based on that. Now it's AI. Why? I go back to the origin story.
Actually, I was present at the birth of SOAR. I was actually at RSA, the company, in 2016. We had a SIM system that was using techniques to detect threats, but we really didn't have anywhere to send them at the time. We started creating a layer on top of it to collect security events so they could be investigated and managed. At the same time, you had independent vendors doing it. That problem has multiplied many factors by now. You have all these event sources. They all need to go someplace to be managed and analyzed.
For the first eight or so years, it was done using rules, and that got some advantages, but it sort of ran into a wall, which I think we're going to talk about. Now, with the arrival of AI, there's an opportunity to address the shortcomings of that approach. That approach helped, but it didn't 100% solve the problem. To touch upon another set of episodes that I did, which were not related to technology. I did two very interesting episodes with psychologists who looked at analyst and CISO burnout and how to counter that.
That is closely related to this overflow of alerts, of false positives, anything that distracts you from doing your actual work because it's hidden in the sheer mass of signals. Why hasn't that changed? You've mentioned AI, so is AI-based attacks being part of the problem as well?
Yeah, absolutely. Like all times, the threat actors apply the most current technology to the attack, which just sort of accelerates their attack and makes it more sophisticated and harder to detect, basically. The techniques to detect and respond need to keep up. On the topic of what we call alert fatigue, or essentially the challenge of being a level one security analyst, sort of on the front lines, if you will. Anytime you're using a human, like a robot, it's not a good idea because humans are very bad at repetition. They get data overload. It's not very intellectually interesting.
The world of computing is all about moving people up the intellectual and abstraction layer to let them do their creative work and have the machine do the grindy work down below. Essentially, traditional security automation, pre-AI, has been still fairly grindy. They were using it with rules and with ingestion and some automation, obviously, to take away some of the robotic work, but ultimately, they sort of run into a wall at the average company.
What I sort of like to joke and say, they're too busy essentially being these robots to then invest in the rules and the playbooks and the workflows necessary to become less busy. They're sort of trapped in that cycle. The exciting part about the emergence of AI is it's a new approach that can be applied to this problem space. I think that's exactly what's happening in the industry. They're doing it 24 7 and they don't get tired. They don't get tired. Yeah. Yeah. You don't have to pay them extra for overtime. It depends on how much the AI stock is.
Yeah, exactly. We'll talk about it. I'm sure it doesn't replace people. It's more of an augmentation thing, but anything that raises the person up a level of abstraction and intellectual creativity to essentially manage the whole thing, to make the big decisions, if you will, the better. We sort of think of these AI agents that we'll probably talk more about as junior analysts that are there to do the grindy work that up till now, often you had level one human analysts doing. So they are doing the heavy lifting.
When you said the emerging AI stock market, I heard some kind of not criticism, but reluctance when it comes to that term. Why is that? Why should security leaders be skeptical? Should they be?
Yeah, I don't know if I'd say skeptical, cautiously optimistic. I mean, I don't love hyperbole. I think part of the analyst's job is to be anti-hyperbole. Don't stoke the fires too aggressively without evidence. So I would say, I think we all agree the problem space that we already talked about, sort of the misuse of people and the fact that rule-based approaches can only take you so far. But I won't say the AI stock is here, it's emerging. So basically it's your classic early adopter market for the AI capabilities.
What was a late stage market of SOAR, traditional SOAR, essentially moved back into being an early adopter market, which is often what happens with innovation. So I think cautiously optimistic would say, that's why I call it the emerging AI stock. It hasn't fully emerged yet. Right. So security leaders shouldn't fire their SOC team and just replace it with this tool of that. I know you like the analogy of the evolution of the driverless car related to the AI SOC. That's actually where we are. We are in the training phase, right? Yeah.
I mean, imagine, it's sort of ridiculous, but I'll say it. Imagine you invented the driverless car 10 or 15 years ago in the lab and then they said, okay, you're in construction.
I mean, no one would do that because you'd be running over people. And the rules of the road are well understood, but all of the chaos of reality have to be trained and engineered. The tree fell into the road or the dog ran in or the ball float rolled into the road. That's not part of the rules of the road. But if you just program to rules of the road, you're not going to have a great effective car.
It's kind of the same idea in the AI SOC is that you need to put it into production in a controlled, managed way, augmenting people to gain experience, and then to figure out the low risk things you can automate and the higher risk things you're going to keep a human in the loop. And we're still in that first year or two of doing that in the AI SOC, like the first year when the driverless car actually had a person sitting in the driver's seat, taking over the wheel when they had to. That's sort of the stage we're at. Right.
The way you describe it, when you said, okay, SOARs were around for 10 years right now, and now we have the AI SOC. I know analysts who know that vendors are really good in changing the labels of what they are selling. So if you think back 10 years or so, everything was with added blockchain and five years ago it was with added Zero Trust, now with Zero Trust. Is this AI SOC just SOAR with some added AI, or is it a genuine architectural shift? It's an interesting question. It's maybe not a complete architectural shift, but it's a significantly incremental change.
I also don't believe it's hyperbole. I believe it's showing early signs of success. And I've been working, as we're going to talk about the leadership compass, closely with 17 vendors of various types and sizes and directions that are coming at the problem. And they're all being pretty judicious in how they approach it. They're going through kind of a similar path, adding the capabilities incrementally to their solutions.
So again, that leaves me cautiously optimistic. Early signs are positive. If I was a CISO or if I had a SOC, I'd definitely be experimenting with it, if you haven't already. Because it's an opportunity to kind of attack those problems you've been probably trying to attack with rules and workflows and playbooks. Now let's try with LLMs and with agents to see if you can make progress in a safe way. But as you said, it's augmentation. It's the AI taking over, they have a lifting, and the first 80% and leave the last 20% to those who are the experts and can understand context much better.
Is that the way that we should look at that? Yeah, I don't even know if 80% might be a little optimistic too. But I don't use the word autonomous unless I highly clarify what I mean. And sometimes you see like autonomous AI SOC or something. And for the most part, they don't mean literally lights off, get rid of all your people. What they mean is there's some autonomy built into the system. But that doesn't mean there's not a human in the loop. So you might have a, this is where sort of the guardrails come in.
The beauty of AI, for example, is you can feed in information into your agent or the AI system and say, here are the whitelisted systems. Here are the systems that we cannot turn off without a human in the loop. So like a domain controller probably is on that list or the CEO's login account or things like that that you want to be very careful with. And then you can have other things like, the rule can be if it's 2 a.m. and a random user has what looks like an account takeover, maybe you just quarantine the account because what's the downside?
You open a ticket and someone's going to look at it and maybe it was a false positive. But you can essentially build in that risk tolerance into the AI system fairly easily without having to write an explicit rule. So those are the kinds of things that early adopters are doing, starting human in the loop all the time and then slowly backing off as they gain trust in essentially the analytics that's going on. But still protecting those super important business processes, people, systems that you don't want to block. Google.com probably ever. So you want to make sure that's on there.
Don't block that even though that will block some command and control that happens to be hosted in Google's environment. And you've mentioned the word trust and I had just had a discussion earlier this week with Martin Kupinger and we talked about a different area, but I think it's the same problem. If you use AI or LLMs to write program code, source code, who's responsible when there's an error in there? When you have a developer, you can say, hey, fix that. If you find an error in the code that an AI created, who is responsible? Who is accountable? Who will fix it?
Who understands what went wrong to prevent it from happening again? And I think the same thing applies to an AI agent in this AI SOC. If they filter out something that should not be filtered out because it's a relevant incident and they think, okay, it's not important, just delete it. It's in the 80% that I mentioned. Trust is important and how does trust look like and how can you increase the trust that you have in the system?
Yeah, and I always think of like the dog, you know, if your dog bites somebody, it's the dog is not legally responsible. You are. So if your AI system does something that is incorrect, the owner of the people that did that own the problem. There are a number of ways to gain trust, obviously, in the system. One is to use it in a controlled way. And essentially you're running it like the early driverless cars. The other one that vendors are doing, are very clearly doing is explainability. So human in the loop. Why did you come up with the conclusion that it's a false positive?
Okay, let me review it. Okay, you reviewed all the things I would have reviewed. So I trust you on that. You never want a black box because then you can't tune it, you can't re-engineer it. So the same thing that's going on now, the responsibility, if you're a developer using AI to develop code, you're responsible for that code. If you deploy an AI agent to do triage of alerts, the person, the entity deploying that triage agent is responsible for its functionality. And it has to be, you know, you can't say, oh, it's the agent did it.
You know, it's just like, you can't say the dog bit you, it's not my responsibility. We're learning while we're walking because we're still in an early phase. Are there any experiences, best practices, where to draw the line between let's make it autonomous, that's fine, and where a human should be in the loop, where AI is an assistant and not the autonomous responder? Any experiences here? At a very high level, probably the way I would think about it is imagine your human junior L1 analyst, what authority would you give that person?
I mean, you certainly don't want to give this agent more authority than that. So for example, just going back to the domain controller, the CEO's account, you have certain systems or google.com, you have certain things that you just shouldn't do without humans in the loop. And so I'd say, take the same philosophy that you have with people, perhaps maybe constrain it further as you're initially deploying. The agent doesn't know unless you tell it what it should and shouldn't do. But fortunately, the part is these systems ingest natural language and lists of things.
And just like you're prompting chat GPT, you can prompt these agents in the same way. And it will take that, it'll weigh those factors in its decisioning. And that obviously put guardrails about what responses you allow it to do. But I like the model of this. Think about your junior analyst that just started yesterday. What authority would you give that person? I think that's a conservative approach and I think it's a good approach. And maybe we come back to this with the next questions.
But first of all, you have written this leadership compass, you have been in touch with very different vendors from the larger ones who are in the market of SOAR and maybe seen before. On the other hand, I expect that that is a wide range of different types of vendors, that there are startups that are maybe just in the market, they are hungry, they are creative, they know the technology very well, and they might also be faster and more experimental, which can or cannot be dangerous when it comes to security in the end. Can that be a risk for when you choose a platform?
I don't want to talk about the vendors that you just looked at. So in general, do you see that tendency that there is this variety, this variance? Exactly what you would expect to happen is exactly what's happening. Call it the platform vendors.
I mean, it's hard to have a security platform without automation. So they've had automation for a long time. So now they've had, some of them still refer to it as a SOAR component. And now that SOAR component is being augmented or incrementally improved with LLMs and with agents to support it. Then you have standalone SOAR vendors that have progressed their solution with AI capabilities. You have startups, lots and lots of startups.
I'm still covering them almost on a daily basis that are entering the automation, but only with an AI-based approach because they don't want to essentially recreate history or recreate a traditional SOAR in all its ways. And then not to be forgotten, a really important part of the market is the managed detection and response providers. The outsourced SOAR providers are also quite active and some of them have a stack that they're applying. Some of them are licensing the underlying infrastructure from some of those third parties I mentioned.
They have this whole, and then finally there's open source, an open source solution that I also write extensively about. Again, so you can, like any open source, you can get it, pull it off of the distribution and use it for free, or you can get a supported version from a vendor. So that whole cornucopia of opportunity and options is out there. And that's why I sort of refer to this as it's a renaissance. So essentially the burst of security automation is now in a renaissance where we've gone from, I guess, the middle ages to the upcoming future, if you will, with the renaissance in between.
And so it's a great time to be an analyst looking at the market because you have so much variety and optionality for people. Question. We talked about the regular, the traditional automation part. Is this dead, or is it part of the solution? And when it comes to AI SOAR, so is this traditional pattern-based, filter-based, is it still there or is it just, yeah, outdated?
Yeah, it's still there. You know, like in any evolving new way, it's hard to say how far the new technique will obviate the old technique. My current view is that they'll continue to complement one another, partly because they're two techniques, if you will, applied to a problem, and sometimes you use one, the other, or both together is the best way to solve it. The simplest way to think about it is rules are deterministic, very inexpensive to operate, but quite rigid.
If something falls outside of the scope, you know, the rule doesn't know what to do unless you update the rule, whereas AI is inherently probabilistic, non-deterministic, much more flexible. And so some of the problems can be solved just by, you know, fast repetition of the rule. Some of the problems, you know, require a more probabilistic approach, and then some require a combination of the two. And so I think for the foreseeable future, you'll use both because, you know, once something becomes repetitive and repeatable, you use a rule because it's super cheap and very reliable.
But, you know, for all that sort of complexity and variety, like the tree falling in the road and the ball, you know, going across the street and all those, and there's a freak snowstorm that, you know, driverless cars have to deal with, having a little bit more of a flexible probabilistic system makes more sense. But, you know, one will not replace the other. They'll complement each other for as far as I can tell. Right. Talking about replacing, do some of these AI SOC vendors actually threaten the MDR market, the managed platforms that act with people plus AI or plus SOA?
Are we already in the situation that they are a threat to this market segment? I mean, it potentially changes the economics in that if you can do smarter, cheaper automation versus hiring people, you'll do it. And so you have the enterprise SOC, you know, for organizations that have it, and then you have the managed service with outsources, big components of the enterprise SOC. And there's this, you know, the way I would distill how I view it is if you're a managed detection and response alert forwarding service, you're going to be vulnerable because, you know, they don't need your service.
They can handle, triage their alerts using AI techniques in the enterprise SOC. But if you're a high valued managed detection and response provider, actually the automation provided by AI helps you provide a more valuable service. The economics are better for you as well. Better automation helps them MDR provider. So I think there's going to be some tension and maybe some recalibration between the two and both, you know, the MDR providers will have to keep innovating to keep their value proposition strong.
But it turns out many of the customers of the AI systems in this space are managed detection and response providers. So there's certainly early signs they're adopting the latest technology, you know, essentially to keep up their value proposition. So we are close to the end of this episode, but I realized that having talked to you and you being so, so deep in that market, it was really a sip from the fire hose to, we see that you have lots of knowledge already gathered during this process of this research for leadership compass.
So if listeners to this podcast are actually interested in learning more, reading more, reading more from you, where can they find anything? And when is the leadership compass actually being out? We are talking about something that's not yet published, but when will it be? So basically the leadership compass is, I have on the draft April. I'm trying to make it faster than that, but some of the things are out of my control. But think about April of this year, it'll be, you know, available via, you know, Coupon and Goal.
In the meantime, there is a blog that basically kind of frames at a high level what we just discussed. It's called, you're living through the security automation renaissance, the emergence of the AI SOC. So you can go there right now. And if you want to read a more structured view of more or less what we just talked about, I would encourage you to do that. And then obviously you can, anyone in this market or, you know, starting to use this technology, I'd be interested to hear from you. Feel free to reach out to me as well. Exactly.
And I think that's also important as it is an emerging market and a changing market. We are heavily also relying on information that we get from our peers, customers, from vendors, from anybody who is actually involved in this technology. And if you have comments, leave them in the comment section on YouTube, reach out to MG or MR at couponandgoal.com. One of the two Matthews, we will reply and we're interested in getting your feedback.
Maybe we can also talk about that at EIC in Berlin in May on beautiful Alexanderplatz close to the TV tower and spend five days and find half an hour to talk about AI SOCs as well. It's lots of identity, but it's not only identity. So cyber security and the SOC also will be there. And so looking forward to seeing you, Matthew, there, looking forward to talking to the audience there, reach out to us. I have been promised that there will be stickers with analyst chat on it. It's promised to me. So I'm looking forward to that and to see people walking around analyst chat stickers on their MacBook.
I think that's the next stage. Can I put it on my Windows machine or is that not okay? Okay. I give you permission. I give you permission. Okay. So thank you very much, Matthew, again, for being my guest. My pleasure. It was really, again, the best episodes are those where I learn from beginning to end and I did today. So thank you very much for being my guest today. My pleasure.