How to reduce the number of alerts in ESET Inspect without losing critical information?
The console has been showing over twenty new detections since this morning. Most of them are the same patterns you saw a week ago and a month ago – administrative processes, logon scripts, and activity that almost always turns out to be harmless.
Somewhere among them, a signal that genuinely requires attention might be hiding. Will you catch it in time? Before repetitve fatigue causes you to dismiss the next alert event faster that the last one?
This is precisely the moment when an excessive number of ESET Inspect alerts stops being proof of a well-functioning system and becomes a problem in its own right. It is worth emphasizing that this is characteristic of every cyber threat tracking tool (not just ESET Inspect). Very often, something that appears dangerous turns out to be a false positive, while a completely unassuming action might actually be the initial phase of an attack. Find out how to approach reducing this volume without losing vital information.
Why a higher volume of detections does not always mean better protection?
More alerts are intuitively associated with a more vigilant system, but in practice, the opposite is true. An overly sensitive detection system generates dozens of notifications about activity that is a normal part of the organization’s daily work, including administrative logins, standard maintenance scripts, and tools routinely used by the IT department. Every single one of these events technically matches the pattern described in a rule, yet none of them carry any decision-making value.
This side effect even has its own name – alert fatigue. The more low-value notifications reach the administrator, the less attention each subsequent one receives – including the one that actually demands a response. No one is able to maintain the same level of focus on the thirtieth repetitive detection of the day as on the first.
The quality of a detection system is not measured by the number of generated alerts, but by the signal-to-noise ratio. An EDR-class system that generates fewer notifications – where every single on carries concrete information requiring evaluation – is vastly more effective.
The difference between filtering and ignoring alerts
This distinction often blurs under time pressure, but operationally it represents a massive divide
- Filtering EDR alerts means a deliberate, documented narrowing of detection scope. You do this based on a thorough understanding of why a given event poses no risk within a strictly defined context.
- Ignoring alerts, on the other hand, means reacting to overload by reflexively dismissing notifications without analysis – “the same thing again, surely nothing happened.”
The difference is not cosmetic. A well-designed exclusion functions like this: a specific process, executed by a specific account or group of accounts, on a specific set of devices, within a defined context and only within this exact scope does it cease to generate an alert. If any of these conditions are not met – for instance, the same process appears on a device outside the predetermined group – the alert returns.
A rule that stops being taken seriously because it is “always a false alarm anyway” loses its value. This is the exact mechanism exploited by Living Off The Land (LotL) attacks, where hackers use legitimate administrative tools (such as Power Shell or PsExec) in an environment that looks familiar until someone realizes that this time, the intent is malicious.
If you cannot explain why a particular activity has been excluded from alerting, you are likely not filtering alerts – you are simply ignoring them.
How to analyze sources of repetitive events
Before you proceed to editing rules, you must determine where the repetition originates in the first place. Most often, it involves one of several scenarios.
Logon scripts, scheduled tasks, and remote management software – if the same processes execute daily from the same sources within the same time windows, they are strong candidates for precisely defined exclusions.
The IT department will generate more alerts related to administrative tools than the sales department – not because someone is doing something suspicious, but because it is a natural part of their job. A rule that fails to account for this difference will, by definition, generate unnecessary noise on administrative accounts.
A new version of a business tool may introduce behavior that the ESET Inspect rules engine classifies as unusual – even though it is intentional on the software vendor’s part. It is worth checking whether a repetitive detection coincides with the update cycle of a specific application.
If a rule has been written too broadly – for example, triggering on the mere execution of a tool rather than on a specific, suspicious sequence of its use – it will generate alerts with every legitimate application of that tool within the organization.
ESET Inspect allows you to group detections by rule, process, user, and device. The starting point for optimization is establishing whether the repetition stems from a misconfiguration of the tool itself, or because the rule cannot distinguish a benign context from a malicious one.
The role of exclusions, user profiles, and business context
Optimization that genuinely reduces noise without losing warning signals relies on an ironclad principle: context determines the significance of an event far more than the event itself.
The same execution of the aforementioned PowerShell can mean two entirely different things. An administrator performing database maintenance on Tuesday at 2:00 PM is one context. An accounting intern’s account launching that same process on Sunday at 11:47 PM while simultaneously establishing a connection to a Russian IP address is an entirely different story.
A practical approach to tuning EDR rules and building exclusions relies on three layers:
- Role and department profiles. Instead of a single rule for the entire organization, consider separate thresholds and exclusions for user groups with distinctly different activity profiles – IT department, finance department, or workstations without administrative privileges.
- Time and location. Utilize operational windows. Activity during business hours from a known IP location carries a different weight than weekend logins from unusual locations.
- Account and device history. Verify whether the user has ever exhibited similar activity. The occurrence of something for the first time in an account’s lifecycle always raises the event’s priority.
None of these layers function well in isolation from knowledge of the organization’s actual structure. It is the administrator or the team responsible for the environment who knows which accounts should genuinely use administrative tools and which should not. It is this knowledge, rather than the technology alone, that ensures an exclusion is precise rather than accidental.
Why do alert filtering rules require periodic review?
The IT environment is not static, and a rule configured correctly six months ago is not necessarily up to date today (e.g., matching the current organizational structure). New employees, role changes, new tools, infrastructure updates – any of these factors can make a previously established exclusion too narrow (generating noise once again). Or, more dangerously, too broad, causing it to stop catching things it should.
An unmaintained rule tends toward one of two scenarios:
- It starts generating more false positives that it should.
- It becomes so bloated with exclusions in response to individual cases that it eventually stops catching threatening behaviors altogether.
Tuning EDR rules is not a “set-and-forget” activity; it is an ongoing, repeatable process. A solid benchmark is reviewing exclusions and thresholds at regular intervals – frequent enough to keep pace with changes in the environment, but not so frequent that it becomes an operational burden no one has time to execute.
How MDR leverages lessons from handled incidents to refine configuration
There is another dimension to this problem that is easy to overlook. Tuning rules based on a single environment has a limitation – you learn exclusively from your own events and false alarms.
In the Perceptus MDR model, this process looks different. After handling each event, the team analyzes not only whether the incident was an actual threat, but also whether the way it was detected and qualified says something about the quality of the rule itself. If an investigation confirms that a sequence was harmless, that finding feeds directly back into the configuration as a refined exclusion.
This is the key difference compared to an administrator tuning rules in brief intervals between other duties. Updating and developing the configuration happens continuously as a natural byproduct of daily incident handling, rather than as a separate project requiring dedicated time. We present recommendations regarding rules and exclusions to you along with justifications – so that you retain full decision-making power over whether a change fits your organization’s actual structure and risk appetite.
If you are wondering whether your current rules are filtering the signal or merely silencing it, a good starting point is reviewing how many of your last thirty detections had documented decision rationales versus how many were simply dismissed without analysis.
FAQ – Frequently asked questions about EDR alert management
What is alert fatigue and why is it dangerous?
Zmęczenie alertami to spadek czujności administratora wywołany nadmiarem fałszywych powiadomień. Dotyczy to każdego narzędzia bezpieczeństwa. Skutkuje to rutynowym i mechanicznym odrzucaniem alertów, przez co łatwo przeoczyć rzeczywiste, ukryte zagrożenie.
Does a high volume of alerts in an EDR system mean better protection?
No. The effectiveness of a system depends on the ratio of real threats (the signal) to false alarms (the noise). A good EDR system generates fewer notifications, but each one delivers concrete decision-making value. An inconspicuous action is often far more dangerous than a loud false alarm.
What is the difference between filtering EDR alerts and ignoring them?
Filtering is a deliberate narrowing of detection rules based on IT environment analysis. Ignoring is the reflexive dismissal of alerts under time pressure – a mistake that hackers deliberately exploit in attacks based on legitimate system tools (Living Off The Land).
How do you properly create exclusions in ESET Inspect to avoid missing threats?
You should base the configuration on strict business context, taking into account three layers:
Role profiles: Distinct rules for the IT department versus standard workstations.
Time and location: Legitimate activity has its operational windows and regular IP addresses.
History: The first atypical use of a tool on a given account is always an alarm signal.
Why do alert filtering rules require periodic review?
The IT environment is constantly evolving (new systems, employee role changes). Over time, outdated alert filtering rules become either too narrow (generating false noise) or too broad, effectively making them “blind” to genuine attacks.
If you feel that your IT environment needs support – contact us!
Looking to enhance your cybersecurity?
Contact us!
Leave your details – we’ll call you back
Our specialist will get back to you no later than the next business day. You don’t have to fill in the message field, but a brief note about the topic you’re interested in will be a valuable hint for us.
