Some fields are filled in by the attacker
Hostname, user agent, process name and command line all arrive from the endpoint. A rule resting on a field the adversary writes is a suggestion.
Every field in a log came from somewhere. Some of them came from infrastructure you run. Some came from the machine you are currently investigating, which is the machine the adversary may already own.
That distinction decides how much weight a field can carry.
A source address observed by your firewall was written by your firewall. A hostname inside an endpoint log was written by the endpoint, and it can be changed in about thirty seconds. User agent strings are supplied by the client. A process name is a filename, and filenames get chosen. Command lines can be padded, encoded or split across arguments.
None of this makes those fields useless. It makes them evidence of intent rather than proof of identity, and it means a rule resting entirely on one of them can be stepped around by somebody who reads their own output.
Detections that hold up lean on what the adversary would have to work harder to forge. What the network saw. What the identity provider issued. What the kernel recorded about a parent process. A hash rather than a name.
Take your three highest severity rules. For every field they match on, ask who wrote that value. Where the answer is the host under investigation, add a second condition sourced from somewhere else.
CHECK YOURSELF
A rule alerts when a process named psexec.exe runs. An adversary renames the binary before running it. What is the most durable fix?
SHOW THE ANSWER
Match on properties the adversary does not choose, such as a file hash
Why. Renaming beats a name match because the name belongs to whoever runs the file, so the rule has to move onto something they would have to work harder to change, such as a hash or the service the tool must create in order to run. A list of known aliases is a treadmill that holds until somebody picks a name nobody has catalogued. Severity governs what happens after a match and does nothing for a rule that never matched at all. Watching for changed filenames sounds adjacent but describes a different and far noisier detection, and a binary copied in fresh has no history to compare against.