How AI Is Changing the Threat Landscape
The Rilevera team just got back from Black Hat 2026, where AI was the topic of nearly every conversation. Early in the week, a talk from Jason Clinton, Deputy CISO at Anthropic, and Michael Aiello, Head of Product for Cyber at OpenAI, set the tone for the rest of the conference: attackers are already using AI models just months behind the frontier labs. Attacks are getting more sophisticated and moving faster than ever as a direct result, and we've already seen it play out in the real world, as with the Hugging Face incident.
What This Means for Security Professionals
Jason Clinton put it best at Black Hat: the genie isn't going back in the bottle. As security professionals, we have a responsibility to adapt with the ever-changing landscape and respond to AI threats. At the end of the day, humans aren't machines, and machines will always be able to think and act faster than us when it comes to computer terminals. This leaves us at a big disadvantage out of the gate, and it's the reason why most of the companies we saw at Black Hat were pitching some version of an AI SOC. Responding to threats at machine speed is the only way to keep up. This is a belief held by the industry as a whole, including Rilevera. Surprisingly, the missing piece we noticed was Detection Engineering. The practice is, after all, named "Incident Detection and Response." This is, of course, our specialty and why Rilevera was founded, and we walked away from the week with a core belief reaffirmed: the time to create new detections can no longer be measured in months or weeks, it has to be measured in hours or minutes.
Solving the Problem
We're well on our way to achieving this outcome and helping the industry adapt. We'll share more in the future as we continue to progress towards a full solution to this problem, but for now I want to focus on what we're doing to help today. If you've read my previous blog on MITRE, you will be familiar with the idea of how ATT&CK is oftentimes misapplied as a vanity metric and not usually a very accurate representation of detection coverage. I've seen it more times than I'm comfortable admitting; a rule will be created to detect Mimikatz and it gives the false impression that an organization is covered for Credential Dumping, but in reality this covers one method of Credential Dumping and usually only on a portion of the environment that's susceptible to that type of compromise. We have a very different approach to MITRE. We work backwards from the logs to understand how the systems, services, and infrastructure sending logs to your SIEM can actually be compromised in relation to the MITRE ATT&CK Framework, and then understand how your current detections cover your log sources for these techniques of compromise. We now have views in our tool that outline exactly which techniques don't have rules that cover applicable log sources, and views that show which techniques are applicable to all of your unique log sources.
Putting It to the Test
Building effective detection rules is hard. You have to understand not just the logs you're looking at, but how they fit into the larger picture that is your threat landscape and how those logs can be compromised, before you even begin authoring the detection rule. One of the first things I did when I started at Rilevera was building detection rules. It helped me get familiar with our platform, understand how we can help our customers, and provide feedback to our engineering team. I used our platform as a starting place because it was the quickest and easiest way to understand which log sources didn't have rules associated with them, but it still took me over eight hours to really understand where I needed to start in order to bolster our detection coverage. Yes, I knew which log sources we didn't have rules for, but that's only half of the picture. I still had to do manual research to understand what I should be looking for in these logs to build effective detection rules and where in the attack chain these rules would help us. It took me about 15 hours to go from looking at a brand new environment to having a completed detection rule. Without Rilevera, it would have conservatively taken me a week, as there was nothing in the SIEM to help me understand what my coverage looked like.
Today I retried the exercise of bolstering our coverage using Rilevera as a starting place, and the results did not disappoint. With our new MITRE Coverage Intelligence feature, we've completely eliminated the time needed to understand your coverage and where to start bolstering it. We've effectively shaved off an entire week from the process of building new detection rules that cover gaps that existed before. We're not quite to our ideal world of having new detections within seconds or minutes, but we're so much closer to that goal, and we'll be there before we know it.
