September 29, 2026
Summary: Curated Detections are YARA-L 2.0 rule sets that Google and Mandiant write and maintain. They run against your UDM-normalized telemetry. Enabling them gives you vendor-maintained coverage of known threat techniques without adding to your custom rule backlog.
1. How they work
| Aspect | Detail |
|---|---|
| Rule language | YARA-L 2.0, the same engine as custom rules |
| Data model | Runs on UDM events and entity context. Parsers must normalize your logs correctly or the rules won't fire. |
| Authorship | Google Cloud Threat Intelligence and Mandiant, based on incident response findings and tracked threat actor TTPs |
| Update model | Google pushes changes to the rule logic. You get new coverage (including for actively exploited zero-days) without redeploying anything. |
| Visibility | You can't edit the rule logic. You can see each rule's metadata: what it detects, the log types it needs, its severity, and its MITRE ATT&CK mapping. |
| Output | Standard detections and alerts, labeled with the rule set and rule name. You can query them the same way as custom rule detections. |
2. Coverage by category
- Cloud (GCP / AWS / Azure): Privilege escalation through IAM changes, abuse of service account keys, cryptomining and resource hijacking, data exfiltration from storage services, unusual control-plane API activity. Needs cloud audit logs, e.g. GCP Cloud Audit Logs, AWS CloudTrail, Azure Activity/Entra ID.
- Windows: Credential access (LSASS access, SAM/NTDS dumping), lateral movement (remote services, WMI, PsExec patterns), persistence (Run keys, scheduled tasks, services), and defense evasion. Needs EDR or Sysmon process telemetry, plus command lines.
- Linux: Suspicious process lineage, privilege escalation (sudo/SUID abuse), rootkit and kernel-module indicators, unauthorized access. Needs auditd or EDR process telemetry.
- Network: C2 beaconing, DNS tunneling and exfiltration, lateral movement traffic, scanning. Needs DNS, proxy, firewall, or flow logs.
- SaaS / identity: OAuth token and consent abuse, mailbox delegation and forwarding changes, admin role manipulation. Needs Workspace, M365, or IdP audit logs.
Prerequisite: Each rule set lists the log types it depends on. Check that those sources are being ingested and parsed to UDM before you rely on the rule set. Without them it will enable fine and silently detect nothing.
3. Deployment procedure
- Inventory: Open Curated Detections in the SecOps UI and review each rule set's rules, required log types, and severities.
- Validate data dependencies: Compare the required log types against what you actually ingest. Use UDM search to confirm the key fields are populated, such as
principal.process.command_lineandtarget.resource.name. - Enable with alerting off first: Turn the rule set on with alerting disabled. Detections still get recorded but don't create alerts, so you can measure volume without adding load to the SOC queue.
- Baseline for 1–2 weeks: Look at detection volume for each rule, the entities involved, and the true positive vs. benign rate.
- Tune (section 4), then turn alerting on one rule set at a time.
- Route the alerts: Map them into your SOAR playbooks and case management the same way you handle custom rule alerts.
4. Tuning controls
You can't change the rule logic, so tuning happens around the rules:
- Alerting on/off per rule set: This is your main control over volume.
- Exclusions: Suppress known-good entities such as service accounts, scanner IPs, admin jump hosts, and sanctioned tools. Manage these lists centrally so they get reviewed and expire, not as scattered one-off suppressions.
- Severity and priority handling: Align curated alert severity with your response thresholds in your triage and SOAR logic.
- Downstream correlation: Custom YARA-L rules can use curated detections as building blocks. For example, you can escalate when a curated detection coincides with a high-risk asset or a second signal.
5. Curated vs. custom
| Curated | Custom | |
|---|---|---|
| Maintenance | Google/Mandiant | Your team |
| Threat intel freshness | Updated centrally as TTPs change | Depends on your team's capacity |
| Environment specificity | Generic across all customers | Tuned to your assets, business logic, and risk |
| Logic visibility and editing | Metadata only, can't edit | Full control |
| Best use | Baseline coverage of known TTPs | Crown-jewel assets, insider risk, business-logic abuse, gaps in curated coverage |
Recommended model: Use curated detections as the baseline layer and put custom rules on top for environment-specific risks. Track both against MITRE ATT&CK so you can see where coverage overlaps and where the gaps are.
6. Action items
- Map currently ingested log types to the curated rule set prerequisites
- Enable priority rule sets with alerting off
- Review detection volume after 7–14 days and build exclusion lists
- Turn alerting on in stages, and wire the alerts into SOAR playbooks
- Retire custom rules that duplicate curated coverage, and point custom work at the gaps
