Every SIEM has two failure modes. Too quiet, and it misses the incident. Too loud, and it trains a human to ignore it, which is the same failure with extra steps. Tuning is the whole craft of staying between those two cliffs.
EventLog Analyzer can alert in real time on events and on correlated patterns across sources, by console, email and other channels. The defaults and the predefined alert profiles are a starting menu, not a finished system. An alert earns its place only if the person receiving it would act on it at 2 AM. This page is the honest routine for getting there: few rules, real thresholds, and a weekly review that keeps the list true.
Begin with three to five alerts you would defend in an argument: a burst of failed logons against one account, any addition to a high-privilege group, the audit log being cleared (event 1102), and your firewall reporting a source it has never reported before. Run only those for the first fortnight.
A small list teaches you the tool's rhythm and your network's normal. Every alert after that is added because a real event taught you something, not because a menu looked impressive.
A failed logon alert set to fire at five failures will cry wolf in an office where forgotten phone passwords generate twenty before breakfast. Watch the failed logon report for two weeks, note your normal peak, and set the threshold just above real life. The same goes for lockouts, traffic spikes and after-hours logons.
This is also why alert settings copied from another organisation misfire. Their normal is not your normal; the numbers must be measured on your own wire.
Single events are weak signals; sequences are stories. EventLog Analyzer's correlation can chain them: many failed logons, then a success, then a group change is a very different animal from any of those alone. Reserve correlation rules for the few sequences that would genuinely wake you up.
Keep the logic explainable. If you cannot describe in one sentence what a rule catches and what you will do when it fires, the rule is decoration and should wait.
Decide, per alert, who receives it and how fast they are expected to move. Real-time channels for the waking-up class; a daily digest for the interesting class; the weekly report pack for the rest. An alert sent to a group mailbox nobody opens is a diary entry, not an alert.
Test the route, not just the rule. Fire each new alert deliberately once, and confirm a human saw it, understood it, and knew the first step. Untested alerting is hope wearing a uniform.
Fifteen minutes a week keeps the system honest: which alerts fired, which were noise, which real thing had no alert. Tune the noisy, write the missing, and disable the useless with a note about why. An alert list that only grows becomes the ignored console this page is named after.
Keep a tiny change log of alert edits. During an investigation, knowing that a rule was off last month is itself important evidence about your own process.
The install in the video gets alerts within reach. Use this page in week two, once your own baseline exists to tune against.
▶️ Watch Full VideoAs few as cover your real risks, and that number is usually smaller than people expect: a tight core of high-signal alerts, reviewed weekly, beats fifty defaults. Grow the list only when an incident or a near miss shows you a specific gap.
For most Windows networks, a burst of failed logons against a single account, and any change to high-privilege groups. Both are cheap to configure, rare in normal life, and directly tied to the incidents that hurt.
The waking-up class should go to named people with an agreed response, not to a crowd. Diffusion of responsibility is how a real alert gets read by everyone and acted on by no one.