Tuning is scoping, not deleting
Suppressing an alert hides the noise and the attack together. Narrowing the rule removes only the noise, and leaves a record of what you decided.
Every noisy rule gets tuned eventually. The question is whether tuning means “see less of this” or “describe the benign case precisely”.
Suppression is the fast option. Mute the account, silence the host, drop the alert. It works immediately and it removes the attack alongside the noise, because the thing you muted is often exactly the thing an attacker would use. Service accounts are noisy for the same reason they are valuable.
Scoping is slower and keeps the coverage. Instead of “ignore this account”, write “ignore this account when it runs from its own host, during its scheduled window, doing its expected action”. Anything outside that shape still alerts. You have not removed the detection, you have described normal.
The second difference matters more over time. A suppression is usually a checkbox somewhere with no explanation. A scoped condition lives in the rule, in version control, next to a comment saying why. Six months later, somebody can read what past-you decided and whether it still holds. Nobody can read a checkbox.
A useful test before you tune: if an attacker knew about this exclusion, could they operate inside it? If the honest answer is yes, you suppressed rather than scoped.
CHECK YOURSELF
A rule fires constantly on your backup service account. Which response keeps the most coverage?
SHOW THE ANSWER
Exclude that account when it runs from its own host, during its window
Why. Suppressing the account blinds you to that account being abused, which is exactly what an attacker would want to use. Narrowing on account plus host plus time removes the routine behaviour while still alerting if the same account acts from somewhere new or at the wrong hour. Severity and disabling both drop coverage without recording why.