Security Information and Event Management system (SIEM) watches your network 24 hours a day and evaluates suspicious activity. Once deployed, the security team often feels that it finally has a comprehensive view of what is happening across the company. This is where one of the most common misunderstandings in security monitoring begins. A SIEM is a tool that, much like your network, constantly evolves. If you do not take care of it, an expensive technology can quickly become a reason why your overall security posture deteriorates.
A SIEM is like a “big brother” that looks at your network every day and evaluates whether something is happening that is not quite right. User X repeatedly entered the wrong password? Administrator Y is doing something unusual at three in the morning? Employee Z is in a part of the network where they have no business being? A SIEM observes and evaluates these events. If it considers an event suspicious, it creates an alert and sends it to a human analyst.
The problem is that a security tool may see an IP address, a port, a user, or repeated logins, but that does not automatically mean it understands the situation. “Many people expect that they will install a SIEM, turn on the rules provided by the vendor, and that is it. But a good SIEM requires constant work and is a continuous process. It is not something you set up once and then consider finished,” explains Radovan Andráš, Security Analyst at Binary Confidence.
An out-of-the-box SIEM floods your team with false alerts
Every company environment has its own specifics. Different servers, cloud services, user accounts, working habits, and exceptions. What is suspicious in one company may be completely normal operations in another. That is why universal rules are never enough.
After the initial launch, a SIEM may generate hundreds or even thousands of detections every day. Some of them may represent genuinely important security events, but a large portion is often just operational noise, such as failed logins, repeated system errors, expected communication between services, or changes caused by new technology.
Radovan Andráš points out that if a SIEM is simply turned on and no one pays attention to it, it may be only around 30% functional. “In a typical small to medium-sized company, thousands of detections can pop up every day, and someone has to deal with them.”
Around 50 alerts per analyst during an eight-hour shift is still a relatively manageable number. If the system generates a thousand detections per day, we are talking about a volume that would theoretically require dozens of analysts in your company. And that still says nothing about the quality of decision-making.
Read how we at Binary Confidence can eliminate most alerts.
“The more false positives there are, the higher the chance that an analyst will burn out. They have to do a lot of unnecessary work, which leaves them with less time, motivation, and energy for alerts that may actually indicate a real problem,” explains Radovan Andráš.
A well-tuned SIEM therefore does not simply produce more detection, but better detection. Instead of thousands of isolated alerts, it helps connect events into meaningful context and reduce noise to a level the team can realistically process.
An effective SIEM needs context and analyst care:
1. Context
The biggest difference between functional and dysfunctional monitoring lies in context. If we set machines aside for a moment, even the security analyst needs to know what is normal in the company in order to recognize what is not. Standard sources that help identify your company’s context include:
- network map
- list of critical services
- overview of servers
- list of user accounts
- permission structure
- normal communication flows
If an analyst sees an IP address, port, or user, they need to know what those data points mean in that specific company. Is it a mail server? An internal system? Or an access attempt that should not be happening at all? “Context is always important. For the analyst as well as for the automated system. Without context, tuning SIEM rules is very difficult,” says Rado Andráš.
Context allows the system to distinguish normal operations from suspicious behavior. For example, a failed login on its own may mean nothing. Ten failed login attempts from an unusual location to a critical server may be a completely different story.
2. Analyst
The human role in working with a SIEM is mainly about understanding context and connecting it with current information from the security community. An analyst can assess which alerts are truly relevant, which are just false positives, and which rules need to be adjusted, added, or suppressed.
The person tuning a SIEM should follow public vulnerability databases, incident reports, new CVEs, detection rules, threat intelligence sources, expert blogs, discussions among security researchers, and rule formats such as Sigma. This is where detection engineering comes into play: the ability to work not only with built-in SIEM rules, but also with external sources of detection logic and continuously translate them into usable monitoring.
Creating custom detection rules is just as important. Some organizations use proprietary or custom-developed systems for which no publicly available detection rules exist. In such cases, a more expert human perspective is needed — someone who understands security, the technology, and the customer’s specific environment.
SIEM tuning is a never-ending process
There are many SIEM vendors on the market. During the technology implementation process, you can choose from a wide range of products, from Elastic Security and Palo Alto Networks Cortex XSIAM to Splunk Enterprise Security, CrowdStrike Falcon, Rapid7, and Microsoft Sentinel. But if someone tells you that a one-time purchase is enough, you should probably reject that offer. A SIEM is like a musical instrument. It needs to be properly tuned at the beginning, but over time it will drift out of tune again. A company adds a new service, moves part of its infrastructure to the cloud, changes a firewall, and such a change can create new alerts, exceptions, and blind spots.
SIEM tuning is therefore a continuous process. It includes adjusting existing rules, removing false positives, adding new detections, following current campaigns and vulnerabilities, and working with the output of detection engineers. In practice, this is where monitoring naturally moves closer to threat hunting: actively searching to see whether something similar to current real-world attacks could happen in your own environment at any time.
The project, funded under grant agreement number 101145856, is supported by the European Cybersecurity Competence Centre.
