Scaling Detection Engineering: How We Built a Better Alert System

Today RunReveal is announcing major improvements to our detection and alerting capabilities that we’ve been working on for the past few months.

Detection engineering looks straightforward until you're staring at 10,000 findings per hour and trying to figure out what went wrong. Writing detections, running them against logs, getting feedback about whether they're working the way you want, and parsing through the findings is as much of an art as it is a science.

Here's the key insight: Your detection findings are not that different from the logs you collect, so we store these in the same place as your logs, attach the same tools, but place them in a different table. This decision paid off in ways we didn't expect—like being able to retroactively enrich findings without reprocessing logs.

A scalable architecture for your detection findings

Alerts aren’t just temporary data; teams often need to look back months for threat hunting, compliance audits, and they need to join them with other logs. But, keeping billions of rows queryable gets expensive fast—unless you architect for it from day one.

RunReveal's detections can either be a query that we run against the RunReveal database or a Sigma rule which is a streaming rule. When a detection fires via a scheduled SQL query or streaming Sigma detection, we duplicate the matched log into our detections table with full enrichment: MITRE techniques, risk scores, and which rule triggered—everything. The original log stays untouched, so you never lose raw data or the details of the detection associated with it.

RunReveal saves the data from the normalized log and additional information about the detection (like MITRE attack techniques, risk scores, detection category names, etc.) alongside each other in the detections table.

This makes it easy to perform analytics, conduct correlation analysis over a certain actor, and maintain the original information from the log—all in one easily accessible place.

Viewing alerts

Once we save all detection findings into a centralized detections table, they are easy to filter by various attributes, including MITRE attack techniques, severity, custom categories, etc.

This makes it nearly instantaneous to find anything specific you're looking for historically, such as when you're looking for every "persistence" MITRE tactic from the past month. Once you want to drill into a specific finding, RunReveal can render its details along with the location of the source IP and all the other attributes from the log.

Your data, made usable

One helpful feature we added was the ability to specify certain fields as more important than others. Our detection data model allows customers to specify which fields in the log, whether Sigma or query-based, are the most important fields. You'll notice that document URL, title, and type below are rendered in the fields section above.

The typical log has 50+ fields. Fields your analyst actually needs: maybe five. This is a major improvement because you can define those five in the detection config and they'll render at the top automatically. Note that this fields section in the detection configuration drives the fields UI above!

name: google-workspace-drive-permissive-visibility
displayName: Google Drive Document with Permissive Visibility
description: Detects when Google Drive documents are created, moved, uploaded, or edited with permissive visibility settings (people_with_link or public_on_the_web) that could expose sensitive information. Extracts document title, ID, and type for detailed analysis.
file: google-workspace-drive-permissive-visibility.sql
categories:
  - google-workspace
  - drive
  - identity-access-management
  - authorization
  - signal
  - document-security
  - data-exposure
  - permissive-visibility
mitreTactics:
  - collection
  - exfiltration
severity: High
riskScore: 75
fields:
  - url
  - doc_title
  - doc_type
schedule: '*/15 * * * *'
parameters:
  window: '30'
sourceTypes:
  - google-workspace
  - gsuite 

Fully integrated with the RunReveal AI Agent

Having humans review thousands of findings is something we know doesn't work. By exposing this data to our AI agent or other AI agents through the RunReveal MCP server, you don't need to lose your weekend during an incident developing the queries you need—you can just ask the AI agent for exactly what you want.

By providing all this data to language models RunReveal customers are able to quickly query the findings they're curious about, summarize the important information, and dramatically speed up the security incident response process.

What's next

We couldn't be more excited about what's coming next. These improvements took iteration and important customer feedback, but they started with a sound data architecture. We love every opportunity to peel back the curtain about what we do and show our customers how our platform works.

This blog post is part of our #RunRevealWeek where our team is sharing product announcements, behind the scenes on how we approach problems, and the unique features that make us, us.