Rule Writing to Risk Reduction
A field-grade essay on the discipline that turns a rule writer into a detection engineer.
There is a moment in every SOC engineer’s growth where the job quietly changes shape. For a while, the work is consumption — you learn the platform, you respond to alerts, you write rules that fire when X happens. Then one day the right question stops being how do I write this rule and becomes why am I writing it at all. That shift is the whole journey. Everything before it is operating someone else’s system. Everything after it is engineering your own.
Most engineers never make the shift. They get very good at the mechanics — thresholds, correlation syntax, the quirks of their particular platform — and they mistake fluency in the mechanics for maturity in the craft. It isn’t. A senior detection engineer is not someone who writes more rules, or faster ones. It is someone who can hold two viewpoints at once: the L1 analyst staring at an alert at 3 a.m., and the CISO who needs to know what that alert means in terms of business risk. The ability to span that distance — from the tactical to the strategic, from detection logic to the decision it ultimately supports — is what separates a rule writer from an engineer.
Design before you author
The instinct, when you are handed a detection requirement, is to open the rule editor and start writing. Resist it. Mature SIEM engineering begins before your fingers touch the keyboard, with a question the rule editor cannot answer: what business problem does this detection serve?
A rule is a sentence — “if five failed logins occur within ten minutes from one source, alert.” A use case is a paragraph. It begins with the problem worth detecting, names who owns it and who benefits when it is solved, and only then works backward into the observable events that would indicate the problem is occurring. The rule is the last thing you build, not the first. Start at the rule and you get a detection that fires correctly and means nothing. Start at the problem and you get a detection that earns its place.
This is why “design before you author” is not a slogan about being tidy. It is the recognition that you are not designing detections — you are engineering decision-support logic. The rule is the cheapest part. The thinking around it is the work.
The thresholds tell the story
Watch how someone sets a threshold and you will know everything about their seniority. “Ten failed logins” is what a junior writes. The senior engineer asks: ten over what period, from what source types, against what kind of account, measured against what baseline? Is ten even the right number for this environment, or did it come from a vendor template that has never met your network? Thresholds are not universal constants. They are environment-specific judgments, and the best of them are not static numbers at all but dynamic baselines that learn what normal looks like and flag the deviation.
The same discipline runs through every design choice. When a rule fires, what does the analyst actually need to decide quickly and correctly? If the alert arrives without context — without the business unit, the asset’s criticality, the owner to notify, the threat classification — it is not a signal. It is noise wearing a signal’s clothes. The correlation rule must not only detect; it must annotate. Detection becomes intelligent only when it is relevant, and relevance is something you engineer in deliberately: the vulnerability posture of the target, the criticality of the asset, the intelligence about whether this matches a known adversary’s behavior. A hit on an unpatched crown-jewel server and a hit on a honeypot are not the same event, and a mature SOC does not pretend they are.
Raw severity is not priority
This is the distinction that most cleanly separates the engineered SOC from the accumulated one. A device reports severity — its own narrow read of how bad a thing looks, stripped of all context. But priority is an all-things-considered judgment, and the two are not the same number.
Consider a textbook exploit landing cleanly on one of your systems. Raw severity: critical. But the system is a honeypot — it exists precisely to be attacked. Seen through the all-things-considered lens, the implication drops to near nothing. The exploit is genuinely malicious; the event is genuinely unimportant. A SOC that cannot tell the difference between the severity a tool assigns and the priority the business should actually feel is a SOC drowning in its own alerts. Good content removes that ambiguity. It makes the raw signal arrive already qualified — already weighted by what the organization stands to lose.
That qualification is the work the diagram describes: raw events enter, and as they pass through enrichment — threat intelligence, asset criticality, vulnerability posture, business context — they stop being undifferentiated severity and become risk-aligned priority. The endpoint is not “an alert fired.” It is “here is what matters, and here is why.”
Design for the analyst, not the engine
The last discipline is the one most engineers forget: every detection eventually lands in front of a human, and where it lands is a design decision. A high-urgency finding belongs on the video wall, flashing, with an escalation path attached. A low-urgency one belongs in a weekly trend report, not interrupting anyone. Tag your alerts consistently so they fall into the right visual buckets every time — because the difference between a well-tagged alert system and an improvised one is the difference between operational discipline and tribal knowledge, and that difference shows up most painfully at shift handover, when the person who knew the workaround has gone home.
None of this is exotic. It is just the refusal to treat detection as a pile of independent rules, and the insistence on treating it as a system where every piece is designed in awareness of the others. That is the entire distance between writing rules and reducing risk. The names of the platforms change — ArcSight, QRadar, Sentinel, Splunk, the next one. The discipline doesn’t.
— Damanjit Singh Uberoi · Founder, CyberSecure Vertex