The pipe is measured; the reading is a record

The indicator is called Operating SIEM Capability, and its text asks that a security information and event management system — NIST’s glossary defines one, plainly, as a program that provides centralised logging for many log types — “is used and persistently reviewed for centralized, tamper-resistant logging of events, activities, and changes.” The question your team will be asked is “what do we scan to prove that?” Read the sentence again and notice it has two verbs. Used is a property of a pipe, and every piece of the pipe is a rule. Reviewed is something a person does, and no API in the estate returns it.

The pipe is unusually well served. A trail is on or it is not; it covers every Region or it does not; it delivers hashed files and a signed digest every hour or it does not; an alarm has an action or it does not. Each of those is an AWS Config managed rule with an empty non-compliant set as the pass. For once the indicator’s own adjective — tamper-resistant— is the measured part: AWS documents log-file validation as SHA-256 hashing with RSA-signed digests, which makes editing, deleting or forging a delivered file detectable. The word the machine cannot reach is the verb after it.

The two measured limbs are properties of the trail. The three unmeasured ones fail in three different ways, and the step turns on keeping them apart. An inventory— which patterns are watched, how long each log group is kept — is complete and silent on whether it is the set you meant. A query over the log proves an event landed, at a time: a fact about the past, and not the fact you were asked for. And the review was never in the estate at all.

Here is the distinction in two recipes from this site’s own corpus. Same plane, the same rule engine, neighbouring subject matter — and different ratings:

Now look at what neither recipe claims. Neither reads a single event out of the log. That is a third thing a machine can do — lookup-events, a Logs Insights query, Athena over the trail bucket — and it is worth knowing what it proves: that a particular event landed, with a timestamp, or that the signed digest chain has no missing hour. AWS’s own documentation says validation lets you “assert positively that no log files were delivered to your account during a given period.” Those are facts about the past. A row in a query result is not a review of that row.

So the judgement, stated plainly: the pipeis measured — generated, tamper-evident, alarmed, routed to a person, each as a rule with an empty set. What is watched and kept is an inventory: a listing whose verdict is your comparison against the events you meant to watch and the retention you promised. That events landedis the log’s own testimony about the past. And the reviewis a record — the ticket an alert opened, the judgement written in it, the person it was reported to. A team that answers the question with the four managed rules has proved that the SIEM is used. It has not proved that it is reviewed, and the indicator asks for both.

Eight questions follow. Sort each into the thing that answers it. Two belong to the log itself and two to a review record, and one of the record’s two is designed to feel like an alarm-history lookup.

The deliverable this step points at is a join. On one side, the alarm list for the period, dated, from the estate. On the other, the case record: one entry per alert that fired, with who looked, what they decided, and where a real finding went. Where the two sides match one-for-one, the review is evidenced. Where an alarm fired and no entry exists, the honest finding is the one the indicator anticipates — the pipe is used; the reading has a gap — and the fix is a process, not a rule.

Every recipe named here is at /collect, and the controls behind this indicator — including the one about someone else’s estate that closes as an agreement rather than a scan — are on /frontier.