The cloud detection rule has become the rule the SOC analyst has been writing, the rule the cloud architect has been reviewing, the rule the breach disclosure will reference when the rule fired but the SOC missed the alert. The honest framing matters here, because the cloud detection rule the SIEM has been counting on sits as the cloud detection rule the SOC never actually read closely enough to action.
What follows runs as the working version of the field guide. The shorter version is what the SOC analyst and the cloud architect actually have time to read.
What the cloud detection rule actually is
Three things, in roughly that order of how much each one matters. The first runs as the query, where the query the analyst writes, the query that says what the SIEM should look for in the cloud audit log, the query that fires the alert the analyst will eventually triage, the query that sits as the heart of the rule. The second runs as the threshold, where the threshold the analyst sets, the threshold that says how many events in what time window the analyst considers suspicious, the threshold that the analyst tunes to balance the false positive the analyst cannot afford against the false negative the analyst cannot ignore. The third runs as the enrichment, where the enrichment the analyst adds, the enrichment that puts the user, the role, the resource, the recent activity into the alert, the enrichment that tells the analyst whether the alert counts as the legitimate user doing the legitimate thing or the attacker using the stolen credential.
Where the rule goes wrong
Three places, in roughly that order of how often each one shows up. The first runs as the stale query, where the query the analyst wrote two years ago, the query that no longer reflects the cloud service the cloud provider has been changing, the query that fires on the legitimate activity the new service has been introducing, the query that the analyst never updated because the analyst forgot the rule was in the production SIEM. The second runs as the noisy threshold, where the threshold the analyst set too low, the threshold that produces the hundred alerts a day the analyst has been ignoring, the threshold that the SOC has been treating as the background noise, the noise that hides the real alert the analyst would have caught. The third runs as the missing context, where the context the rule did not include, the context that the alert does not tell the analyst what the user should have been doing, the context that the analyst needs to make the triage decision, the context that the rule fired but did not include.
How to write a rule that actually works
Three moves if you are the SOC analyst or the cloud architect who wants the cloud detection rule to actually catch the breach the rule is supposed to catch. Tie the rule to the threat, where the threat the rule should map to (the MITRE ATT&CK technique, the known attacker pattern, the recent incident the SOC has been investigating), the threat that justifies the rule, the threat that gives the rule the context the rule needs to be prioritised. Test the rule in staging, where the staging the analyst should run the rule against, the staging that has the known attack data, the staging that produces the baseline the analyst needs to tune the threshold, the staging the analyst should use before the rule ships to production. Review the rule quarterly, where the review the SOC manager should run, the review that finds the stale query, the noisy threshold, the missing context, the review the SOC manager should add to the quarterly cadence the SOC has been keeping. The analyst or the architect that ties to the threat, tests in staging, and reviews quarterly serves as the analyst or the architect that has written the rule that actually catches the breach.
The bottom line
Cloud detection in 2026 sits as the rule the SOC has been writing that the SOC has not been maintaining. The query, the threshold, the enrichment, those three are what the rule is. The stale query, the noisy threshold, the missing context, those three are what goes wrong. The tie to the threat, the test in staging, the quarterly review, those three are the moves. The analyst that does the three catches the breach. The analyst that has the rule on autopilot does not.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
