To rule or not to rule: SIEMs and their false positives

Security Information and Event Management (SIEM) systems are essential IT security tools for countless small to medium businesses (SMBs) and enterprises. SIEM systems monitor log data from a vast number of applications and devices, looking for indications of suspicious activity or security events.

To parse all that data, SIEM systems rely on rules. When real-world conditions match the rules, SIEM systems generate alerts, notifying security analysts that IT events require a closer look.

But these rules, which are typically defined by an organization’s Security Operations Center (SOC), can be a double-edged sword. Define too few rules and organizations are liable to miss security threats. Define too many and the number of false positives soars. Then security analysts find themselves scrambling to investigate hundreds of alerts, the vast majority of which turn out to be meaningless. These false positives consume staff time and increase the chances that a genuine threat will be overlooked.

What’s the best approach to using rules in SIEMs? Do security-focused SMBs and enterprises need more rules or fewer? And what role are rules likely to play in future solutions for threat detection?

The advantages of rules

Obviously, rules offer many advantages for SOC teams defending against security threats such as malware and data breaches. By defining conditions and thresholds, rules enable SOC teams to narrow billions of events down into a subset of events that merit raising an alert.

In addition, rules provide a straightforward means of detecting threats. For example, if a known threat involves sending a specific type of message to a specific port, a rule for detecting that message going to that port is an obvious way of identifying that threat.

It’s easy for SOCs to create basic rules, such as rules that check for known bad IP addresses. Advanced users can create more complex rules that depend on the correlation of multiple events or conditions. However, to craft these more complex rules, analysts must understand not only what to correlate but also how to define in the language of the organization’s SIEM system.

The challenges of rules

For all their advantages, SIEM rules have drawbacks, too. At nearly every SIEM installation, they generate too many false positives. To be effective, they require advanced security expertise, even though an SOC may have only a few security experts—or it may have none and depend on outside consultants. Rules also require constant tuning and upkeep, as new systems come online, new software releases are deployed, and new vulnerabilities are discovered.

Another really glaring shortcoming is that SOCs can only craft rules to detect threats they already know about. Rules are poor defenses against Zero Day threats and other threats unknown to the security community at large. A key reason is that it’s extremely difficult, almost impossible, to build deep correlations that can identify behavior exhibited by a genuine unknown threat.

We need much deeper correlation that can sift through the vast majority of security events and deprioritize all but the handful of events that really need to be escalated. Imagine a “Threat Ranking Engine” that works like a modern web search engine. A good search engine improves its results by relying on relevance and context from multiple sources to rank the results, not just by conducting keyword matching. You usually find what you’re looking for on the first page of search results. We need to do the same for security events, bubble up the top threats on the first page of a ranked list.

Moving forward: to use rules or not to use rules?

For the near future, rules will remain a necessary tool for detecting and combating known security threats.

Having said that, to offer the maximum benefit for IT security, rules need to evolve from today’s static criteria to adaptive conditions that create and update themselves automatically. These adaptive rules will continually evolve based on the latest data about security events, threat intelligence, business context, and changes in the IT environment. Additionally, we need deeper rules with the ability to analyze a series of events the way a human analyst would.

How will these rules be implemented? They will require intelligent automation, but this automation goes beyond that used in SIEM systems today. Today’s automation is limited to the output of SIEM rules. For example, a suspicious IP address is scanning ports. Once that activity triggers a rule, a simple automation system can automatically issue a command to a firewall to block that IP address. Automating responses clearly has benefits. In the case of suspicious port-scanning, it’s a good idea to stop this activity before a hostile party finds an open port for launching an attack.

But if the goal is to improve detection through more comprehensive and dynamic rules, then automating responses is clearly not sufficient. Instead, we need new solutions that will provide a way to automate rule creation and maintenance. These solutions will need to be able to scan threat environments, IT configurations, business activity, and intelligently craft rules on the fly, using advanced big data techniques and artificial intelligence.

The mechanisms by which security analysts are able to tune and adapt their SIEM rules today are archaic and cumbersome. It is the equivalent of using an old school thermostat in the age of smart ones like Nest. The Nest uses intelligence and context about you to dynamically adjust the temperature without requiring any clunky programming. Good UX and AI in SecOps solutions can similarly provide a much better interface for gathering the feedback from security analysts and adapting autonomously.

With a combination of pattern detection, Machine Learning, and human guidance, we will soon see dynamic automation systems that detect more threats more quickly, reduce false positives, and transform the double-edged sword that rules are today into an agile, razor-sharp tool far more effective at protecting SMBs and enterprises from security threats.

More on SIEM:

• What is SIEM software? How it works and how to choose the right tool
• ArcSight vs. Splunk? Why you might want both
• Evaluation criteria for SIEM
• SIEM: 14 questions to ask before you buy
• Log management basics
• SIEMs-as-a-service addresses needs of small, midsize enterprises