How to engineer a detection rule for your SIEM

For any SIEM solution, built-in detection rules are key features that can ensure threat detection is easier and more effective. For any security analyst, built-in detection rules are helpful, but being able to utilize custom security detection rules that can be tailored to fit the security strategy of the organization is vital.

Built-in rules focused on threat detection don't tend to age well, as they might not be tuned to detect the most recent threats. Understanding the threats your organization is susceptible to, and creating tailored detection rules is imperative. Custom security detection rules help prevent false positives and ensure your organization's security strategy is more in tune with detecting external threats.

Detection rules, like Rome, aren't going to be built in a day. There's a process to designing them so they can promptly and efficiently identify threats. This post helps you understand how to build a detection rule for your SIEM, and walks you through the lifecycle of a detection rule.

Demand and creation

The first step to create a detection rule is to identify your network's demands. This is based on an evaluation of threats your organization faces, the assets that could be at potential risk, and the SIEM solution you've planned on investing, or have, invested in. These factors can help you determine what detection rule your security solution should be equipped with. Crucial for developing a detection rule is realizing that it depends heavily on the threat sources you're subscribed to.

The threat intelligence you're pulling in will determine the logical conditions to determine your detection rule's necessity and design. For example: in the event of a zero-day attack, you cannot rely on existing signatures to understand the threat and build rules. However, if your SIEM has UEBA capabilities, an analyst can build detection rules to alert administrators on anomalous behavior, such as any unauthorized outbound internet activity on non whitelisted ports.

Configuration and execution

Once you've determined the logical conditions for your detection rule, it's time to configure it. This includes setting up a testing environment that can handle large volumes of logs from several log sources so you can test your detection rule. Creating many log sources only to test your SIEM rule is impractical. This leaves you with the option of ingesting your production logs into your test environment, which can double the ingestion costs since you're ingesting these logs for two environments.

Validation and rectification

If you've figured out a feasible way to ingest the logs into your test environment, it is time to validate the logic of your detection rule. Here's where having a Breach Attack Simulation tool, or a red team that can perform manual pen testing, can help validate your detection rule.

When validating, keep in mind that you'll have to look for these factors for detection rule efficiency:

1. Percentage reduction of raw events. (Ideally this should be a reduction of 99.99%).
2. System performance due to running complex queries. (Ideally this is less than a 1% drop in performance).
3. Percentage of false positives (ideally less than 33%), and percentage of false negatives (ideally less than 10%).
4. Percentage of positively identified correlated threats. (Ideally this is greater than 35%).

The standard SIEM detection rule should be tested for the following test cases.

• Password spraying test
• PowerShell dropper attacks (for Windows)
• PsExecTest
• Failed SudoTes (for Linux)
• Eicar malware test file

After performing these tests, you need to tune your detection rule to root out false positives, which is a common issue with new detection rules. Whitelisting certain applications or ports can help reduce false positives. After tuning, you should run your detection rule again to test its correlation and false positive reductions.

Launch

After fine-tuning your detection rule, you should introduce the new rule into your production environment. This decision requires the participation of all key members of your SOC to review the detection rule, check its performance and suggest improvements.

The ability to enable your security analyst to build bespoke detection rules that can be tuned to the organization's network configuration, is a crucial feature that SIEM solutions should offer. Log360 is a SIEM solution that helps you build custom detection rules using its custom rule builder, enabling you to create specific detection methodologies that provide more personalized and effective security for your organization.