SIEM Rules or Models for Threat Detection?

Ask the Experts Blog Series

In the past, security information and event management (SIEM) technology used to rely primarily on signatures to detect undesirable behavior. Unlike those early days, modern SIEM solutions now provide out of the box correlation rules and sophisticated models to surface a broad range of abnormal behavior and events. Once you understand how they work, you’ll likely want to customize these resources, while also adding your own rules and models to suit your organization’s unique situation.

Both correlation rules and models have their place in SIEM operations. But when do you use SIEM rules, and when do you use models? Let’s examine the differences.

Correlation rules

A correlation rule, a.k.a., fact rule, is a logical expression that causes the system to take a specific action if a particular event occurs. For example, “If a computer has a virus, alert the user.” In other words, a correlation rule is a condition (or set of conditions) that functions as a trigger.

Correlation rules are not smart—they don’t assess the history of the events they evaluate. For example, they don’t care if a computer had a virus yesterday; it’s only interested if a system is infected as the rule is executed.

Also, correlation rules are evaluated each time a set is executed—the system doesn’t consider any other data to determine whether or not to evaluate a correlation rule.

Correlation rules can be simple and operate on their own, or they can be composite rules that handle event combinations.

• Simple SIEM rules detect an event type and trigger a response. For example, if a ZIP file is attached to an email, they trigger an alert.
• Composite rules nest or join two or more rules to achieve a more complex behavior. For example, if seven authentication attempts to the same computer fail from the same IP address within ten minutes and use different user names, and if a successful login occurs on any computer within the network and originates from that same IP address, they trigger an alert.

Correlation rules depend on your knowledge and experience to discover errant behavior, rather than on any attributes of an intelligent system. To write a correlation rule, you must have knowledge of the undesirable behavior you’re trying to discover.

Correlation rule examples

Here are some examples of real-world correlation rules:

• If a user fails more than three login attempts on the same computer within an hour,
  trigger an alert.
• If a large number of failed login attempts is followed by one that is successful, trigger an alert.
• During a company-wide layoff, trigger an alert if more than ten files of specific types are copied to USB drives or sent as email attachments to non-company domains.

Models

A model profiles a user or asset behavior, triggering an alert when the behavior deviates from normal behavior. After the model identifies an abnormal behavior, it uses rules to evaluate and alert in relation to it. Typically, you can define rules within models that classify different behavior types, so that they can produce different alert profiles:

• First-time rule – A rule for a new event that is outside the scope of what you’ve ever seen. (as shown in Figure #1)
• Anomalous behavior – A rule for an event that you’ve seen, but on an infrequent basis.

A characteristic of models that sets them apart from correlation rules is that they’re not always evaluated or triggered—even if the event occurs—whereas correlation rules are always evaluated. A classification expression within a model determines whether it’s rule is triggered. For example, you might want to evaluate a model only if a user is remote and is attempting for the third time to create a new system account.

Compared to SIEM rules, models typically have a much simpler rule expression that triggers an alert—that is, if a behavior is observed more than a specific number of times and the confidence factor is above a predetermined value. A model’s intelligence lies in its classification expression and the event types it monitors.

Models depend on your ability to define the results of unusual behavior, and on the system’s ability to monitor and surface such behavior. They don’t demand that you have a deep understanding of the individual threats that can compromise your organization.

Model examples

Some typical model examples follow. Trigger an alert if:

• A user switches from their normal account to a privileged one, then performs an abnormal data transfer to or from an external service.
• A user VPNs to the network from a new location for the first time, then accesses a shared file system.
• A user logs in remotely at 3 a.m. (usually only doing so locally during normal business hours), then makes repeated attempts to connect to a production database as an administrator.

Note: As with correlation rules, a single model evaluation usually doesn’t trigger an alert. Instead, each model the system applies adds points to that given session. If session points exceed a predetermined value, the system triggers an alert.

Figure 1: A model showing a user accessing a file for the first time from the New York network zone.

When should you use correlation rules?

You might think using models is the best way to handle all threat detection. But there are situations where correlation rules are the best and most straightforward option. Here are some examples best handled by correlation rules:

• Monitoring well-known threats – Correlation rules can easily detect common threats that hackers repeatedly use to attempt access to your resources. Many SIEM solutions come prepopulated with rules to handle these types of threats.
• Compliance violation – Organizations in every industry must demonstrate that they comply with certain laws, rules, and regulations, e.g., GDPR, HITECH, and PCI DSS. Each has requirements you can validate with correlation rules. For example, “Alert if antivirus software is disabled on any network-connected computer.”
• Signature-based threat detection – Malware detection systems have constantly expanding repositories containing hundreds of millions of known threat-identifying signatures. Rules are the best way to detect these.

When should you use models?

You should choose models over rules when:

• You’re unable to precisely define an event that identifies an unwanted behavior.
• Dynamic conditions make rules too complex, or cause them to return too many false positives.

Here are some situations where models excel:

• Behavior-based threats – Dynamic environments having multiple entry points (e.g., organizations where employees can use their own devices or where corporate data is stored in the cloud) place higher demands on your threat detection systems. By tracking both normal and abnormal user behavior, models can surface threats that might otherwise go undetected.
• Data exfiltration detection – No organization wants its valuable data to be copied to unknown external systems. Data exfiltration often takes the form of hackers gaining access, then moving laterally throughout the network to discover assets that can be stolen. And sometimes your own employees or recent ex-employees will try to take whatever they can access.
• Zero-day threats – By definition, zero-day threats have not yet been encountered, and so cannot be precisely identified by a correlation rule. You can use models to detect the result of these threats by identifying their unwanted behavior, e.g., lateral movements, abnormal or remote logins, file access, and abnormal data uploads.

I’ve only touched the surface of the capabilities of rules and models. We have much more detail in our white papers, training, and Ask-an-Expert webinar recordings. Here are some to provide you with a deeper dive into SIEM rules and models:

Rules Vs. Models Whitepaper

Rules in Advanced Analytics: Exabeam Ask-an Expert webinar archives

Models: Exabeam Ask-an Expert webinar archives