gerald (Gerald)

Yes, and it is less circular than it sounds. Somebody with log access could read things they should not, or check what evidence exists before deciding what to do next. Recording who looked is how you catch that.

Practically it means individual accounts on the log platform. If everyone shares one login to the SIEM this requirement is not met regardless of what the SIEM records.

It gets written up.

Logs contain usernames, internal addresses, and periodically a password somebody typed into the username field. That is exactly what an attacker already inside your network wants to read.

You will spend longer arguing the exception than turning it on.

Which means the window between a bug existing and somebody finding it gets shorter for everyone, defenders included. Not sure yet whether that is good news.

Our assessor asked for three months of alert history and picked one at random to ask what we did about it. Have the answer ready.

A few hundred a day is not an alerting system, it is a report nobody asked for.

The fix is unpleasant and simple. Turn nearly all of them off. Under ten a day, each being something a person would genuinely act on at 3am. Everything else becomes a weekly review, which is a different thing with a different urgency.

The test per alert: what would I do when this fires? If the answer is look at it and usually nothing, it is not an alert.

Both, for different reasons. Blocks tell you what somebody tried. Allows tell you what actually happened, which is the question during an incident when you need to know what a compromised host talked to.

In practice: store blocks, count allows. You keep the picture without four hundred million session records. If your platform cannot count without storing, store blocks and sample the allows.

Add 4776 if you still have anything doing NTLM. Often the only place a failed authentication against a local account shows up.

Our QSA also wanted the segmentation evidence to justify the scope boundary, which took longer than the logging work itself.

Worth knowing this is a PCI requirement now rather than just good practice. 10.7.2 covers failure of the logging mechanism itself and it stopped being future dated in March 2025.

Not an attack. That is a scheduled task with a stale password.

Type 4 is batch, so a task rather than a person. services.exe with Logon ID 0x3e7 is SYSTEM starting it locally. Source Network Address will be blank. And 0xc000006a is specifically wrong password, not unknown user.

Somebody rotated the account password and did not update the task. It will fail at the same time forever, and whatever the task was meant to do is not getting done.

That is more or less exactly what I needed. The "why that number" on retention is the bit I would have skipped and then been asked about.

Insist on a price per GB per day and a retention figure before any demo. Every vendor can answer that in one line and the ones who will not are telling you something.

Also ask what happens when you exceed your tier mid month. Some throttle, some silently drop, some bill you. That difference matters more than the headline number.

Third one of these this month. Not having a go at you, it just tells you something that everyone asks and nobody answers.

The reason is the answer really is "it depends", and what it depends on is budget, who operates it, and what you already have. Post those three and you get useful replies instead of a list of vendor names.

Depends on size. Under 200 staff it is Sentinel or something open source. Over 5000 it is Splunk and a team of six to run it.