Do you have something cool to share? Some questions? Let us know:
These notes summarize the discussion on the evolution of Google's detection engineering program, its challenges, and its strategic direction, focusing on the journey from a small corpus of rules to a large, scalable, and professionalized operation.
Key Takeaways:
Scaling and Professionalization of Detection Engineering: The core of the conversation centered on the program's massive scaling from approximately 70 rules to nearly 5,000. This was a direct result of the merger with Mandiant, which provided access to hundreds of new security engineers capable of contributing. The team's strategy shifted from an internal, single-team rule-building model to enabling a broader community of contributors.
Detection as a Software Engineering Discipline: A significant inflection point was the adoption of software engineering principles for detection. The team developed dedicated tooling, including an internal IDE, to streamline the contribution process. This approach introduced critical practices such as a CI/CD pipeline, automated testing, and code standards (e.g., linting for MITRE tags). This professionalization was essential for maintaining quality and consistency with over 100 unique authors contributing to the rule corpus. The goal is to make detections fluid, maintainable, and easy to understand, countering the "five-page, unmaintainable rule" problem that often plagues large security teams.
The "Curated" vs. "Opaque" Rules Debate: The discussion clarified the meaning of "curated" in the context of Google's rules. It is not an archaeological term but rather signifies that the rules are actively owned, maintained, and tuned by a dedicated team of Googlers to prevent false positives and maintain performance boundaries. The shift from opaque rules—necessary to protect embargoed, pre-public vulnerability intelligence from partners like TAG—to a more transparent marketplace model was a deliberate, multi-stage journey. This transparency allows customers to see the logic, tune rules for their specific environments, and use them as a foundation for building their own custom detections.
The "Goldilocks" Number of Rules: The team strongly rejects the practice of vendors competing on the sheer number of rules, especially when that number is inflated with low-quality or IOC-based detections. The focus is not on quantity but on the quality and actionability of the alerts produced. The metric for success is not the number of rules or alerts but the value derived by the customer. An alert is valuable if it is both explainable and actionable, preventing wasted time for analysts.
Modular and Composite Detections (The "Building Blocks" Approach): A key innovation is the use of composite rules, which break down complex detections into modular, reusable components. This "building blocks" approach allows security teams to create sophisticated, multi-stage detections without building a monolithic rule from scratch. By chaining "signal rules" (e.g., detecting a VPN login from an unusual ASN) with "action rules" (e.g., detecting an admin action), customers can build robust, highly specific detections for their unique environments. This paradigm shift democratizes advanced detection capabilities, making them more accessible and maintainable.
The Role of AI and LLMs: The team is actively exploring the use of Large Language Models (LLMs) in detection engineering. While not a silver bullet, LLMs are proving highly effective at reducing technical debt and automating tedious, repetitive tasks, thereby freeing up engineers to focus on more complex problems. The ability of LLMs to generate and tune rules is a work in progress, but advancements in prompting and model maturity are showing promising results, especially when provided with clear guardrails and specific telemetry data.
Guidance for New Practitioners: The advice for those beginning their journey in detection engineering is to start with first principles. This includes starting with a small problem, collecting relevant logs, and establishing a baseline for "normal" behavior. The key takeaway is to "get your hands dirty" with small-scale experiments and lab environments before attempting to implement complex solutions.
Timeline of Key Topics
Introduction and Podcast Purpose: The hosts introduce themselves, the podcast, and the guest, Rick Correa. The episode's focus is introduced: scaling a detection program and the lessons learned.
The Scaling Journey: Rick explains the program's growth from 70 to 4,700 rules, driven by the Mandiant merger. The conversation shifts to a discussion of adopting software engineering principles for detection.
The "Curated" Rules Discussion: Anton raises a question about the term "curated." Rick clarifies its meaning in the context of active ownership and maintenance, contrasting it with a passive, "archaeological" approach.
The Shift to Transparency: The discussion moves to the decision-making process behind moving from opaque to transparent detection rules in a marketplace model. Rick explains the necessity of opacity for embargoed threat intelligence and the benefits of transparency for customers.
Detection as a Software Engineering Discipline: Rick elaborates on how software engineering practices like CI/CD, linting, and internal IDEs were implemented to manage contributions from over 100 authors and ensure code quality and consistency.
The Building Blocks Approach: The concept of composite rules and modular detection logic is introduced. Rick uses the example of a remote IT worker scam to illustrate how separate "signal" rules can be chained together to create a single, robust detection, improving maintainability and reusability.
Maturity and Accessibility: The hosts and Rick discuss whether this advanced approach is only for large, well-resourced organizations. They conclude that it depends on the organization's maturity, but the principles are valuable for any team with more than two or three detection authors.
The Problem with Rule Counts: The conversation shifts to the futility of competing on the sheer number of rules. Rick argues that the focus should be on the actionability and quality of alerts, not on a "Goldilocks" number of rules.
The Role of AI and LLMs: Rick discusses the current and future role of LLMs in detection engineering, highlighting their effectiveness in reducing technical debt and the ongoing work in using them to generate detection rules.
Closing Advice: The podcast concludes with Rick providing his final tip for practitioners: "start with first principles" by performing small-scale experiments, and he offers book recommendations for further reading.
