Excessive Alert Generation in SIEM Products

Introduction: SIEM solutions analyze security events collected on a centralized platform and generate alerts or alarms when necessary, enabling security analysts to identify threats faster and more efficiently. However, excessive alert generation is one of the significant challenges that SIEM systems face. Generating too many alerts does not mean that a SIEM product is working "too well"; on the contrary, in many cases, a large portion of these alerts may be unnecessary. This can lead to threats being overlooked and SOC (Security Operations Center) analysts being overwhelmed.

The following image shows the number of alerts generated in one day by a global SIEM solution. This volume of alerts was captured from a structure with around 5000 EPS log flow and approximately 150 log sources. On the security side alone, 5,500 alert events are displayed in one day. Even a fully equipped SOC center would struggle to analyze this volume of events in a single day, and it would be challenging to determine which ones are genuinely dangerous.

So, what is the solution? The number of these alerts needs to be reduced to a reasonable level, ensuring that they are free from false positives. All SIEMs come with predefined rules for general attacks, but they require tuning to reduce false positives in the environment. These predefined rules serve as useful guidance for creating custom rules using the platform. Different SIEM products have various methods for adjusting existing rules and creating new ones. Since support from the vendor and technical support or consulting teams will be required to customize these rules, the document will not delve into how each product handles this. Additionally, it should be considered that not all desired rules may be written or updated in every product.

How are rules adjusted and developed? As seen from the above screen, for example, hundreds of alerts related to login failures may occur within a single day. It is clear that these are false positives. So, should we not track login failure events? Of course, we should, but instead of blindly activating rules that come with the product, we should design smarter scenarios.

Here are three example scenarios that can eliminate false positives for login failures:

1. If a failed login event occurs on a machine that has an active VPN connection, an alert should be generated immediately upon the first failed attempt. (VPN machines should be automatically monitored by the system. For instance, if the VPN connection to a machine drops, the rule should recognize this and not generate an alert for the first failed login attempt. Once the VPN connection is re-established, the system should automatically resume alerting for failed login attempts on these devices.)
2. If a user attempts more than two failed logins without a successful login in between, with at least an hour between attempts, an alert should be generated.
3. If a user repeatedly makes failed login attempts at regular intervals without any successful login, this could indicate a security breach. This scenario is a well-tuned strategy for identifying advanced attackers. An attacker may know that a SIEM system exists and that rules are set for multiple failed login events within short periods (e.g., 5 or 10 minutes). Knowing this, they might attempt failed logins at intervals longer than the time threshold of the correlation rule, such as every hour.
4. If a user enters the wrong password no more than twice within the first 5 minutes and then successfully logs in, it is likely that they simply forgot the password or made typographical errors, such as misusing upper/lower case or Turkish characters. However, if they are then able to log in and continue their work, no alert should be generated. If it is an admin account, an alert should be generated.

This scenario explains that no alert should be generated if a user successfully logs in after entering the wrong password due to common errors. It is a reasonable approach, as most users may mistype their passwords due to keyboard issues, case sensitivity, or special characters. Implementing this scenario can eliminate such false positives.

1. If a user enters the wrong password and does not successfully log in within an hour, an alert should be generated. However, if they enter the correct password shortly after (e.g., within 5 minutes), no alert should be generated.

In this scenario, it is suggested that an alert should not be generated if a user quickly corrects their mistake and logs in successfully. However, if the correct password is never entered, this could indicate a brute-force attack.

By making such improvements and optimizations, not just for login failures but for all rules that generate excessive or false-positive alerts, the volume of events can be reduced, and false positives can be eliminated. Implementing such strategies requires knowledge, expertise, and experience, and the teams that carry out these efforts should be chosen accordingly.

Solutions and Recommendations

Excessive alert generation hinders accurate detection and increases the workload of the SOC team. Therefore, reducing the number of alerts and ensuring that only genuine threats are captured is crucial. Here are some recommendations:

• Rule Development: Instead of blindly using default rules integrated into the SIEM, create optimized rules based on environment-specific threat intelligence and historical event data.
• Reducing False Positives: Optimizing rules to eliminate false positives will enhance the effectiveness of the SIEM. The scenarios provided above are a good starting point for this.
• Correlation Rules: Write correlation rules that associate login failure events with larger security incidents. For example, combine failed login attempts with traffic from suspicious IP addresses to make more sophisticated detections.
• Risk-Based Alerts: Classify alerts based on risk levels and generate immediate alerts only for high-risk events. Different workflows (such as daily reporting) can be used for low-risk events.

Leveraging AI for Enhanced Alert Management

It is important to clarify that addressing the challenges inherent in SIEM technologies does not necessarily mean investing in an entirely new technology. Instead, organizations can maximize the value of their existing SIEM infrastructure by incorporating intelligent enhancements. As mentioned in the solutions above, there are several strategies to improve the efficiency of SIEM alerting. However, another powerful approach involves leveraging Artificial Intelligence (AI) for rule analysis and alert filtering.

AI-Driven Rule Optimization and Alert Filtering: By employing AI technologies, organizations can automatically analyze and refine SIEM rules to improve accuracy and reduce false positives. AI can continuously learn from historical data and real-time events, identifying patterns and making rule adjustments more efficiently than manual processes. This ensures that rules remain relevant and effective in a dynamic threat landscape.

Furthermore, AI can act as an intelligent intermediary before alerts are sent to SOAR platforms or incident response mechanisms. Instead of flooding these systems with alerts, AI algorithms can evaluate and filter out noise or low-risk events, ensuring that only high-confidence, actionable threats are escalated. For example, AI can identify anomalies and correlate them with external threat intelligence feeds, making informed decisions about which alerts require immediate action and which can be deprioritized or dismissed.

This integration of AI not only enhances the accuracy of threat detection but also prevents unnecessary strain on incident response teams and SOAR platforms, optimizing resource allocation and response times. By leveraging AI, organizations can transform their SIEM operations, achieving a more proactive and intelligent security posture without the need for significant additional investments in new technologies.

Contribution of Tuned SIEM Alerts to SOAR and Incident Response Processes

Tuned SIEM alerts, free from false positives, play a crucial role in enhancing the efficiency and effectiveness of Security Orchestration, Automation, and Response (SOAR) platforms and overall incident response workflows. By reducing the volume of unnecessary alerts, SOC teams can focus their efforts on genuine threats, leading to faster detection and response times.

When integrated with a SOAR platform, tuned SIEM alerts enable automated or semi-automated responses to security incidents. For example, a well-optimized SIEM rule may generate an alert for a suspicious login attempt pattern, which the SOAR system can immediately act upon by executing predefined playbooks. These automated playbooks may include actions such as blocking an IP address, isolating a compromised endpoint, or escalating the incident to security analysts with enriched contextual data. This automation ensures that critical threats are swiftly contained and mitigated, reducing the potential impact on the organization.

Additionally, tuned SIEM alerts help streamline incident response processes by providing high-confidence, actionable intelligence. Incident response teams can trust that the alerts they receive are meaningful and require attention, thus reducing alert fatigue and improving the accuracy of threat investigations. By minimizing false positives, the SOC team’s workload is balanced, enabling a more proactive approach to security management and improving overall incident response effectiveness.

Conclusion

The effectiveness of a SIEM system is measured not by the number of alerts it generates but by its ability to prevent unnecessary alerts and detect real threats. Effective SIEM management reduces alert volume, allowing for faster responses to real threats and easing the SOC team's workload. Therefore, for successful SIEM configuration, continuous review, optimization of rules, and minimizing false positives are essential.