How a SIEM Actually Works

A machine that watches everything else. Companies pour millions into it, aim every log they own at it, and staff whole rooms around what it says. And there is no good public explanation of how it actually works. This essay is that explanation, in two movements: first the story of why this machine matters more than almost any system you’ve heard more about, and then the machine itself ; every gear, followed by a single suspicious login all the way from a raw log line to an alert on a screen.

Here is the map of where we’re going. If you only look at the pictures, this one tells you the shape of the whole thing.

P.s. Thanks to Fable 5 for helping me draft this long article, every research done is manual, only help of AI to draft in sequence.

Part One; story

What a SIEM is, and how much security it quietly carries

A SIEM ; Security Information and Event Management, a name so beige it actively resists understanding ; is one place where every log from every system in a company lands, gets stored, and gets watched. That’s it. Your servers, laptops, firewalls, cloud accounts, badge readers, and login systems all ship their logs to this one machine, and this one machine keeps them and stares at them.

Say it as three jobs, because a SIEM is really three things wearing one invoice.

It is the security team’s eyes. When someone is attacking you right now, the SIEM is what notices ; or doesn’t. This is detection, and it’s half of the machine nobody explains.

It is the security team’s memory. After the fact, when you need to know what a compromised account touched over the last ninety days, the SIEM is the only system that can answer, because it kept everything. This is forensics.

And it is the security team’s paperwork. The reason an auditor signs off on your company, the reason a regulator is satisfied you can see what happens inside your own walls, is that the SIEM exists and retains what it’s supposed to. This is compliance, and it is often the real reason the thing was bought.

The room you picture when you think “cybersecurity” ; the SOC, the security operations center, the wall of monitors ; is, architecturally, a room full of people arranged around this one system’s output. The whole job is reading what the SIEM decided to surface.

The money and the dependency

None of this is cheap, and the pricing is where it gets interesting.

The SIEM market is measured in billions of dollars a year. A large company routinely spends seven figures annually on licensing alone ; before a single analyst’s salary. And here’s the detail that quietly shapes everything: many SIEMs are priced per gigabyte of data you send them. Think about what that does. It means every decision to watch a new system is also a decision to pay more, forever. The pricing model doesn’t just cost money; it quietly edits what a company is willing to see. Whole categories of logs get dropped not because they’re useless but because they’re expensive.

Diagram 1 The room around the machine. Everything a company runs streams its logs into one system; a room of humans reads the few things it surfaces. The suspicious login (red) enters like any other log line. The dotted arrows are the two forces that make a SIEM unlike other software: it bills by the gigabyte, and once installed, it is almost impossible to leave.

Because it is also one of the stickiest systems in the whole enterprise. Years of carefully tuned detection rules. Years of historical data you’re legally required to keep. Analysts whose instincts are shaped around this specific tool. Migrating off a SIEM means rebuilding all three at once, so companies effectively never do. The dependency is total.

And here’s the uncomfortable part. The dependency is total, and the understanding is optional. Almost nobody who depends on this machine ; not the executives who sign for it, often not even the analysts who live in it ; can tell you how it actually works inside.

Why does nobody write about this

You’d think something this important and this expensive would be thoroughly explained somewhere. It isn’t. Fragments exist; the synthesis doesn’t. There are a few honest reasons.

The knowledge spans two tribes that don’t talk to each other. The storage half of a SIEM is a database problem, and the people who deeply understand databases mostly don’t care about security operations. The detection half is a security problem, and the detection engineers who live in it rarely look below the query language to the machinery underneath. The full picture requires standing in both rooms, and almost nobody does.

The people who do understand it best sell that understanding by the hour. A clear, free explainer works directly against the interest of every consultant whose day rate depends on this being mysterious.

The vendors, for their part, prefer the machine magic-shaped. “It’s a search engine, a scheduler, and a scorekeeping table” is a sentence that makes a seven-figure invoice start asking itself hard questions. Mystery is a feature of the business model.

And writing about internals invites the worst genre of reply ; the “well, actually…” from someone reciting a conference talk. Most people won’t take the risk. I’ll take the risk, and where something is only community-documented rather than officially confirmed, I’ll say so plainly. That honesty is the whole method here.

So let’s open it up.

Part Two ; The machine

Here is the frame, and I’ll state it once because it structures everything that follows: a SIEM is storage plus detection. Half of it is a database problem the industry has solved many times over. The other half ; the detection machine ; is the part nobody explains, and the part that makes a SIEM a SIEM rather than an expensive log archive.

We’ll spend two pages on the solved half and the rest of the essay on the untold half, following our user one stage at a time. This is the whole machine on one page; every stage below is one box in it.

Diagram 2; The machine running. The suspicious login (red, top) travels down through every stage of Part Two and comes out as a single alert (red, bottom). Three independent signals ; the login pattern, a rare-country rule, and a threat-intel match ; all pour into the same ledger before anything alerts. Each section below zooms into one of these boxes.

The solved half: getting a log into a searchable pile

The storage half is a known problem with a known shape, so we’ll go fast and honestly. There are three parts, and none of them is magic.

First, an agent on every machine. Its whole job is to read log files and ship the new lines somewhere. The clever bit is small: it keeps a little checkpoint of how far it has read each file ; a fingerprint of the file plus a position (Splunk calls this the fishbucket) ; and a local disk queue. So when the network sulks or the receiver is busy, nothing is lost; the agent parks the data on disk and catches up later. An agent is a checkpointed file reader with a buffer. That’s the whole trick.

Second, a parsing pipeline. Raw bytes arrive as an undifferentiated stream, and something has to find where one event ends and the next begins, and ; the part that earns its own paragraph ; find the timestamp. Get the timestamp wrong, and everything downstream silently breaks, because in a SIEM, time is the master index. An event stamped with the wrong hour lands in the wrong place, and every time-based detection looks straight past it. More detections die of bad timestamps than of bad logic.

Third, storage as time-sliced, immutable chunks. The data is written into buckets, each one covering a slice of time, each one never modified after it’s sealed. Glued onto every chunk are two accelerators: a word index (Splunk calls it tsidx) that maps each distinct word to the events containing it, and a “definitely not here” filter (a Bloom filter) that can rule a whole chunk out without opening it. Both exist to let a search avoid reading data, which is the entire performance religion of the next section.

That’s the solved half. It’s genuinely elegant, and you could assemble a workable version of it from open-source parts in about a week. Now the interesting half.

Reading a billion lines before your coffee cools

A SIEM holds an absurd amount of data, and yet a search over it comes back in seconds. The secret is that the searcher never reads everything. It eliminates.

Diagram 3; The elimination funnel. A search reads a billion lines by refusing to read almost all of them. The time range eliminates whole chunks unopened; the bloom filter eliminates more; the word index narrows to a handful; only then is any raw data decompressed. This is why every performance tip reduces to “narrow the time, add a rare word.”

Watch a question run. The time range you asked for immediately kills every chunk outside it, unopened. The bloom filter on each surviving chunk rules out most of the rest ; “that username is definitely not in here.” The word index on what remains says exactly which events could match. And only then, for that final handful, does anyone decompress raw bytes. A billion down to six, and five of those six eliminations happened without reading the actual data. This is why the entire folk wisdom of SIEM performance is “narrow the time range and add a distinctive word.” You’re not tuning; you’re feeding the funnel.

Now scale it out. One machine can’t hold all the data, so the data is spread across many, and the question is spread with it. The heavy lifting ; the filtering and counting ; runs on every storage node in parallel, over its own local slice. Each node sends back not raw events but a small summary, and a coordinating node assembles the summaries into the final answer. That’s map-reduce, if you want the term; “many workers each count their own pile, one boss adds up the notes” if you don’t. Crucially, the coordinating node ships its dictionaries and rules ; the field definitions, the lookup tables ; down to every worker along with the question (Splunk calls this the knowledge bundle). This bundle-that-travels-with-the-query is a detail that quietly explains a dozen strange behaviors later, so remember it: the knowledge goes to the data, not the other way around.

The language for all this is SPL, and you can understand it as a pipeline of verbs joined by pipes: filter, then compute a field, then group and count, then keep the weird groups. Search narrows, eval shapes each row, stats collapses rows into per-entity counts. Read enough detections, and they all have the same skeleton ; shape the events, summarize them per entity, keep the anomalies.

Which sets up the single most important sentence in this essay: a detection is just one of these questions, put on a timer. Everything in the rest of Part Two is that sentence, elaborated.

One honest warning, because it’s the first appearance of a theme that will haunt us. Some ways of combining data in SPL ; the ones that feel most like a database join ; silently throw away results past a hidden limit. The query doesn’t error. It just quietly returns less than the truth. A detection built on one of those can drop the very rows that prove the attack, and no one is told. Hold that thought. Silent failure is the villain of this whole story.

The data is immutable; the meaning is editable.

Here’s the philosophical center of the storage story, and it’s genuinely counterintuitive.

The raw events are never modified. Not once, ever. But the meaning of those events ; the fields, the labels, the categories ; is an overlay applied fresh every time you read them. Splunk calls these overlays knowledge objects. The picture to hold is a stack of clear plastic sheets laid over a printed map: the map underneath never changes, but you can add, remove, and reorder the transparent sheets on top, and the next time you look, you see a different combined picture.

Why is this the right call for security data specifically? Because security data is hostile, messy, and your understanding of it changes weekly. A new attack teaches you that a field you ignored actually mattered. If meaning were baked in at write time, you’d have to re-ingest years of logs to reinterpret them. Because meaning is an overlay, you fix the overlay once and instantly re-read all of history through the new understanding. Re-interpreting beats re-ingesting. That is the entire reason a SIEM stores raw and interprets late.

Then there’s the vocabulary problem, and it’s a real one. Forty different products log in forty different ways. One says src_ip, one says ClientIP, one says source_address. A shared dictionary ; Splunk calls it the Common Information Model, the CIM ; maps them all onto the same handful of words: user, src, action. Normalize each source into that dictionary once, and every detection you ever write against the standard words automatically covers all forty sources without naming any of them. This is the quiet superpower. A detection for “suspicious login” is written once and works across Linux, Windows, VPN, and cloud because they were all taught to speak the same three words.

The catch is speed. Interpreting a billion raw events at read time is slow, and you can’t do it thousands of times a minute. So a background process keeps pre-computed summaries fresh ; Splunk calls this data-model acceleration ; and detections read the compact summary instead of the raw pile. The whole detection machine runs at the speed of “read the summary,” not “re-parse everything.”

Which leaves you with a triangle you’ll spend a career tuning: flexibility, speed, and storage. Interpret-on-read gives you flexibility. Summaries give you speed. Both cost storage and background compute. Pick two; pay for the third. There is no configuration that gives you all three, and anyone selling you one is selling you a budget decision wearing an architecture costume.

The heartbeat: a rule that doesn’t run is a rule that doesn’t exist

Now we reach the most under-appreciated component in all of security, the one that gets zero conference talks and causes most of the misses: the scheduler.

A SIEM runs hundreds of detections, each a search on a timer, all competing for a fixed number of execution slots. Picture a kitchen with a set number of burners and far more recipes than burners. When more detections come due than there are slots, the overflow doesn’t wait its turn. It is skipped. Not delayed, not queued, not retried ; skipped. The time window that would have been examined is simply never examined by anyone.

Diagram 4; The heartbeat as a timeline, with its two silent deaths. Left to right: the 09:00 run finds nothing because the events haven’t arrived; the 09:05 run is skipped outright when execution slots run out (dark red) ; and a skipped window is never examined by anyone; the late events land at 09:08 and are caught only because the 09:10 run deliberately re-reads recent history by arrival time instead of trusting exact windows.

Sit with how dangerous that is. A skipped rule and a rule that ran and found nothing look identical from the outside. Both produce no alert. There is no error, no apology, no red light. Your coverage can quietly drop by a third on a busy Monday morning, and nothing tells you. The single most important number to watch in an entire SIEM is the skip ratio, precisely because it’s the only thing that reveals a failure everything else hides.

There’s a second quiet killer at this stage: late-arriving data. Every event has two times ; when it happened, and when the SIEM actually received it. Usually they’re close. But a forwarder hiccup or a network outage can make an event that happened at 10:00 arrive at 10:40. Now the trap: the detection that ran at 10:05 looked at the 10:00–10:05 window, found nothing because the event hadn’t arrived, and by the time it lands at 10:40, no run is looking at that window anymore. The event is never evaluated. This is exactly what happened to our user ; the log lines took a detour. The fix is a deliberate overlap: instead of tiling exact five-minute windows, each run re-reads a wider window of history but keeps only the events that arrived since the last run. It costs a little redundant work, and it catches the late data. Naive exact windows feel correct and are a classic silent miss.

The thesis of this whole section, and it’s one detection engineers learn late: coverage is a property of the scheduler, not of the rule. Your logic can be perfect. If it doesn’t run or runs over the wrong slice, it catches nothing. Most missed attacks at well-run companies are missed right here ; not in the cleverness of the detection, but in the plumbing that decides whether and when it runs.

What a detection actually is (the query is the smallest part)

Let’s open the hood on the actual detection hunting for our user and count the parts. The surprise is that the query ; the SPL that finds the pattern ; is maybe twenty percent of it. The rest is the wrapper, and the wrapper is where a detection becomes good or noisy.

Diagram 5 ; A detection, exploded. The query in the center is the small part. The wrapper around it ; who it’s about, how bad it is, what a human should read, which attacker technique it maps to (the shared catalogue is MITRE ATT&CK), and above all the output type ; is what makes it useful. The single most load-bearing setting is in gold: this rule will not page anyone. Below: nearly all detection logic reduces to six shapes; the sequence shape (red) is the one hunting our user.

The wrapper answers a fixed set of questions. Who is this about? ; the entity, in our case the user account. Get this wrong or leave it blank, and the whole downstream machine has nothing to attach risk to. How bad is it? ; a risk score, a number of points. What should a human read? ; a message written in advance, in plain language, so the analyst isn’t staring at raw logs. What attacker move is this? ; a tag from the MITRE ATT&CK catalogue, a shared taxonomy of attacker techniques, which turns out to matter enormously in a minute.

And then the single most load-bearing setting in the entire machine: the output type. This detection can either page a human directly or quietly add points to a file. For our brute-force rule, the answer is the second one ; it will not alert anyone; it will add points. Plant that flag firmly, because the next section is the whole reason it matters. “Some failed logins then a success” is medium-precision at best; plenty of those are just someone fat-fingering a password. A rule that noise should never wake a human on its own. So it doesn’t.

Now the genuinely useful creative observation. Detection logic isn’t infinite. In practice, there are about six shapes, and once you can name them, you can read almost any rule.

Threshold ; too many of something. A hundred logins in a minute. Evaded by staying one under the line.

Sequence ; the wrong things in the wrong order. Failures, then a success, within a few minutes. This is the shape catching our user, and it’s compact enough to show the whole.

The whole trick is the running memory: walk each user’s events in order, count recent failures, and fire the moment a success lands while that count is high. Evaded by spacing attempts out past the window, or rotating source addresses.

Rare / first-seen ; something never observed before. A login from a country this user has never used. Evaded by “aging in” slowly so the new thing looks established.

Beaconing ; too regular to be human. Malware phoning home every sixty seconds is more punctual than any person. You detect the regularity of the gaps, not the volume. Evaded by adding random jitter.

Spike ; today looks nothing like yesterday. A server that sends a gigabyte a day suddenly sends fifty. Evaded by ramping up slowly enough that the baseline drifts with you.

Cross-source ; innocent alone, damning together. One weak signal from the login system, one from the endpoint agent, one from the proxy, all pointing at the same entity. Evaded by staying inside one source’s threshold.

Notice the pattern in every “evaded by.” Every single-source shape has a way past it. That’s not a flaw to be fixed inside the shape. It’s the reason the next section exists.

The scorekeeper: how a thousand mediocre rules make one good alert

This is the summit. If you take one idea away from this essay, take this one. It’s the idea that took the security industry roughly twenty years to arrive at, and most people who use a SIEM daily still can’t state it.

Start at an airport. The old way to run security is to wire every scanner to its own loud alarm. Metal detector beeps ; alarm. Passenger looks nervous ; alarm. Someone’s sweating ; alarm. Guards sprint to every beep, almost all of which are a belt buckle or a nervous flyer, and within a week, the guards have learned to ignore alarms entirely. That is a traditional SIEM: one rule, one alert, and an exhausted analyst who has stopped reading.

The smart way: no scanner has its own alarm. Instead, each one quietly adds points to a passenger’s file. Belt buckle, plus five. Sweating, plus ten. One-way ticket paid in cash, plus forty. Nobody is dispatched for any single signal. Only when one passenger’s total crosses a line does one guard walk over ; holding the whole file, the entire story, already assembled.

This is Risk-Based Alerting, and here is the sentence to hold: detections stop paging people; they add risk points to whoever is involved, and only when one person or machine collects enough points does a human get alerted.

Diagram 6; The scorekeeper, in two stages that must never be confused. Stage 1: every rule drops points into one shared ledger, and nobody is paged; risk factors then rescale the points centrally, so “the same act is worse on a crown-jewel server” is encoded once, not copied into every rule. Stage 2: a single watcher fires only when one entity has accumulated enough points, from enough different rules, across enough attacker tactics. Our user’s three mediocre signals (red) converge into exactly one high-quality alert.

The machinery is two stages, and keeping them apart in your head is the whole game.

Stage one: detections write their little findings into a shared ledger ; an index literally named risk. Each note says who it’s about, how many points, and why, in a human sentence. Nobody is paged. Then, centrally, risk factors scale those points based on who’s involved: a privileged user multiplies the score, a critical asset multiplies it again. The order is fixed and worth knowing ; all additions happen first, then all multiplications ; so “the same act is worse on a crown-jewel server” is encoded once, in one place, instead of copy-pasted into every rule. Our user base of sixty, multiplied because the account is privileged, becomes ninety before anything else even happens.

Stage two: a second detection watches the ledger itself. It doesn’t look at the world; it looks at the accumulated points. It fires when a single entity has crossed a line ; enough total points, ideally from enough distinct rules, spanning enough distinct attacker tactics, inside a time window. The distinctness is the clever part. One noisy rule firing five hundred times is still just one rule being noisy. But three different rules, mapping to three different stages of an attack, all pointing at the same entity ; that’s not noise, that’s a story. And it produces exactly one alert, carrying that whole story.

Now the intellectual payoff, stated flat. Each individual rule is allowed to be mediocre. Not encouraged ; allowed. Because the system doesn’t act on any single rule. It acts on accumulation against one entity. The alert isn’t a rule firing; the alert is the bookkeeping noticing that too many rules have fired about the same entity. That inversion is the entire idea, and it does two things at once: alert volume drops by roughly an order of magnitude, and alert quality goes up, because every alert that survives comes pre-assembled with its evidence.

Watch it closely on our user. The brute-force rule adds points. The rare-country rule, firing on the very same login, adds more. And a third signal ; a threat-intel match we’ll get to shortly ; adds a third. Three mediocre signals, each worthless alone, each easily evaded in isolation, all landing on the same file. None of them would or should have paged anyone. Together they cross the line, and the user becomes exactly one alert that reads like a sentence a human wrote: privileged Finance admin, brute-forced from a rare country, from a known scanner IP, against a critical domain controller. That is the machine doing the one thing traditional SIEMs never could.

Context: the same event is boring or terrifying depending on who

Everything in the last section leaned on a phrase I slipped past you ; “the account is privileged,” “a critical asset.” Where does the machine learn that? From a context engine that keeps a merged phonebook of everything and everyone in the company.

It’s built by merging the registries no single team keeps clean: the HR export of who people are, the corporate directory of accounts, the inventory of machines. Each is messy and partial. Merged, they resolve into entities with the fields that actually change a decision ; is this person privileged, is this machine critical, who owns it, is anyone on a watchlist, which business unit. Every finding gets decorated with this context the moment it’s born, and this same phonebook feeds the risk multipliers from the last section. No context engine, and every entity looks equally important, and the whole scoring idea collapses into noise.

Underneath sits a genuinely hard problem that’s easy to under-rate: identity resolution. The account’s short username, its email-style form in another log, and the IP address it logged in from all have to resolve to the same file. If they don’t ; if the machine treats them as three different actors ; then our user’s three risk signals scatter across three files, none of them crosses the threshold, and the alarm never trips. The attack becomes invisible not because any rule failed but because the bookkeeping filed the evidence under three names. Getting this merge right is quietly load-bearing for the entire scoring idea. And there’s a matching failure in the other direction: two genuinely different machines that happen to share an internal IP in two offices must not be merged, or the machine invents risk that isn’t there and cries wolf. So the phonebook also tracks which “zone” an entity lives in, to keep things separate. Context is what turns a shrug on a test box into an emergency on a domain controller, and it’s the difference between a page and silence.

When to know things: the three moments you can attach a fact.

Every fact you attach to an event costs something, and when you attach it, it decides what it costs and what it’s worth. There are exactly three moments, and choosing well is an underrated craft.

Diagram 7; The three checkpoints and where threat intel joins. An event passes three “attach a fact here?” decisions: on arrival (pay once, stale if it changes), at question time (always current, pay per query), at alert time (cheapest, but nothing that didn’t alert gets context). How fast a fact changes decides where it lives. Below: threat intel is not a separate alarm ; it matches write points into the same ledger as everything else.

On arrival. Bake the fact into the event before it’s stored permanently. This is right for facts that never change ; the country an IP address sits in is a good example, stable for months. You pay the cost once, and every future search gets the fact for free. It’s exactly wrong for anything that goes stale: bake in “this user is privileged” today and next year’s logs will cheerfully lie to you about someone who changed roles.

At question time. Look the fact up fresh, every time a search runs, from a reference table. This is right for volatile facts ; the user’s privilege level, the current criticality of a host ; because you always get today’s answer, even when reading old events. The cost is that you pay for the lookup on every single run.

At alert time. Attach the fact only to the tiny number of events that made it all the way to a finding. This is where you put the expensive checks ; a live reputation query, a WHOIS lookup, the on-call owner ; because they run a handful of times a day instead of a billion. The gap: events that never alerted have none of this context, so an investigator pivoting to the surrounding logs has to go fetch it.

The decision rule fits on one line: how fast the fact changes decides where it lives. Stable and everywhere, bake it in. Volatile, look it up. Expensive and rare, wait for the alert.

The plumbing behind the middle option deserves one honest look, because it bites people. Those reference tables have to be shipped down to every worker along with the distributed question ; remember the knowledge bundle from earlier. A small table is nothing. But one oversized table gets copied to every machine on every search, and can quietly slow every query in the building. So the tables come in two flavors: a simple file, copied everywhere, fine when small and static; and a central live database, queried in place, right when the table is large or changes constantly. Choosing wrong is a self-inflicted, cluster-wide slowdown that looks like a mystery for weeks.

The list of known bad

Threat intelligence sounds like a dark art. Demystified in one sentence: it’s a subscription to lists of addresses, domains, and file fingerprints that someone else already caught misbehaving. That’s it. Known bad things, compiled by other people, delivered on a schedule.

The pipeline is five verbs. Pull the feeds from the outside world, in whatever standard format they arrive. Normalize them into per-type collections ; IPs here, file hashes there, domains in a third drawer ; because sorting by type is what makes matching fast. Prepare them into quick match tables. Match those tables continuously against the shared-vocabulary fields of incoming events ; and note that this only works because of the shared dictionary from earlier; the feeds are compared against src and file_hash, so every normalized source is checked at once, for free. And finally, write every match as ; say it one more time ; points on the entity’s file.

That last verb is the whole point, and it’s why threat intel composes so cleanly with everything else. A match is not a separate alarm system with its own screen and its own fatigue. It’s one more voice feeding the same ledger as the brute-force rule and the rare-country rule. When 203.0.113.9 ; the address our attacker came from ; turns out to sit on a known-scanner feed, that doesn’t fire its own page. It adds the user’s third signal to the same file, and that is what pushes the total over the threshold into a single undeniable story. Threat intel didn’t sound the alarm. It made the alarm’s story impossible to argue with.

Two operational truths to end on, because this is where the demystifying earns its keep. First, when a company says “we integrated threat intelligence,” it almost always means “we match IPs and hashes” ; the easy indicator types ; while the harder ones quietly go unmatched. And second, indicators age. An address that was a malware server last year might be an innocent recycled cloud address today. A dead indicator left on a live list is a permanent false-positive machine, generating fake matches forever until someone prunes it. The feeds are only as good as their freshness, and freshness is nobody’s favorite chore.

The machine that keeps the machine honest

One last subsystem, quiet and easy to skip, and it exists because of a failure mode we’ve now seen three times. Rules rot. Log formats drift. A vendor renames a field in an update, and a detection that quietly depended on that field stops catching anything ; the scheduler section’s ghost, back again. No errors. The rule just goes dark, and in a badly run shop, it can stay dark for eight months before anyone notices, usually because of an incident it should have caught.

The mature answer is to stop treating detections as things you click together in a GUI and start treating them as code. Each detection lives as a versioned text file in git, reviewed like software by a second engineer, with its history intact so you can answer “who made this rule less sensitive, and when, and why” months later. And ; this is the part that actually kills the silent-rot problem ; each detection ships with a recording of a real attack, and an automated test replays that recording and confirms the rule still fires on it. A rule that stops catching its own attack fails a build. The failure becomes a red mark on a screen at nine in the morning instead of a blind spot discovered during a breach. That single mechanism ; a detection that proves itself, automatically, forever ; is the difference between a detection program and a pile of forgotten saved searches.

Code the machine, run once

Let’s run the whole thing one time, fast, and watch our users’ logins travel through every gear we’ve named.

The raw SSH log line is stored untouched, then made queryable by an overlay of meaning applied at read time and normalized into a shared vocabulary. The scheduler runs the detection over the right window ; and because the data arrived late, it catches anything at all only thanks to a deliberate overlap. The detection spots the failures-then-success sequence, but doesn’t page anyone; it writes sixty points to a ledger. The context engine multiplies those points because the account is privileged and the target machine is critical. A rare-country rule adds a second signal. A threat-intel match on the attacker’s address adds a third. All three land on the same file because the identity merge correctly decided they’re all about one account. A watcher notices the pile has crossed the line ; enough points, from enough different rules, across enough attacker tactics ; and emits one alert, carrying the entire narrative. An analyst reads a sentence, not a mystery.

One log line. A dozen subsystems. One alert. And now you know every gear that turned between them.

The machine’s real achievement isn’t any single component ; not the funnel, not the overlay, not even the scorekeeper. It’s a change in the question. The industry spent twenty years asking “Is this rule right?” and drowning in the answer. Then it learned to ask something better: “Is this entity’s story concerning?” Every mediocre rule, every stale feed, every imperfect signal is allowed to be wrong, because the machine no longer bets on any one of them. It bets on the accumulation.

Understand this machine, and you understand how any SIEM must work.