Understanding Qradar Rules

Rules are the foundation of any Security Information and Event Management (SIEM) solution, including QRadar. They play a crucial role in generating offenses, alerting, correlation, and much more. As a SOC analyst, you may not be directly responsible for creating these rules, but understanding them is vital for effective incident investigation and reducing false positives. Let’s delve into the basics of QRadar rules, their components, and their functions.

Rules in QRadar are sets of conditional statements that trigger specific actions or responses. Simply put, they follow an “If X happens, then do Y” format. For example:

• If more than seven failed authentications occur within 10 minutes, generate an offense.
• If network traffic increases by 200%, generate an alert.

These examples illustrate two types of rules: Custom Rule Engine (CRE) rules and Anomaly Detection Engine (ADE) rules.

On the other hand, Building Blocks are predefined conditions that characterize a group or behavior without triggering any actions. They serve as the foundation for rules. For instance:

• If network traffic is TCP on port 80 or 443, classify it as user browsing traffic.
• If a hostname contains “mail,” classify the server as a mail server.

Building blocks simplify rule creation by allowing reusable conditions across multiple rules. This modular approach ensures that updates to building blocks automatically apply to all related rules, reducing administrative overhead.

QRadar rules can do more than generate offenses. They can:

• Generate alerts.
• Update existing offenses.
• Trigger actions on external devices using custom scripts.

Rule Responses are tasks related to the offense and include actions like sending emails or SNMP traps, running custom scripts, and more. Rule Actions pertain to the event itself, such as adjusting event severity or credibility.

Data sets, also known as reference sets, store lists of dynamic information used in rules. They can be populated manually or via APIs. Examples include:

• A list of employees on vacation, used to trigger alerts if they access the VPN.
• A list of VIP users for specific monitoring.
• A blacklist of IP addresses to generate offenses on network connection attempts.

Consider a scenario where you want to generate an alert for new SSH connections to a DMZ server. Instead of creating a complex all-in-one rule, use building blocks:

• Define a building block for SSH port definitions.
• Define another for DMZ servers.

The rule then becomes: “If network traffic matches the SSH protocol building block and the server matches the DMZ host building block, generate an alert.”

Now, let’s delve deeper into the various types of rules within the Custom Rule Engine (CRE) and the Anomaly Detection Engine (ADE). Understanding these rule types is crucial for effective incident detection and response.

The Custom Rule Engine (CRE) in QRadar supports four distinct types of rules:

1. Event-Based Rules: These rules consider information solely from events. For example, detecting a brute force attack by monitoring failed authentication events.
2. Flow-Based Rules: These rules focus exclusively on network traffic. For instance, a rule to detect port scans would rely on flow traffic data.
3. Common-Based Rules: These complex rules analyze both events and flows. For example, a rule could monitor database logs and network traffic to detect potential data exfiltration activities.
4. Offense-Based Rules: These rules are triggered by offenses. For example, if more than five offenses related to the same user occur within 24 hours, an email alert can be generated.

ADE rules identify anomalies based on various patterns and thresholds. They include:

1. Anomaly-Based Offenses: These offenses detect abnormal traffic or events. For example, if network traffic is 50% higher than the previous week’s average, an offense is generated.
2. Behavior-Based Offenses: These offenses analyze seasonal patterns and volume changes. For instance, if a mail server typically generates 50 network flows per minute at night, but suddenly generates 3,000 flows, this is flagged as anomalous behavior.
3. Threshold-Based Offenses: These offenses are triggered when specific thresholds are met. For example, if more than five active VPN connections are detected between 9 p.m. and 6 a.m., an alert is generated.

Although SOC admins typically manage rules, understanding how to interact with and review these rules is crucial for SOC analysts. Here’s how you can do it in QRadar:

Navigate to the Offense tab and select Rules from the left menu.

Filter rules by category using the Group drop-down menu (e.g., authentication).

View rule details, including type (event or flow-based) and status (active or disabled).
Click on a rule to see its logic and underlying conditions.

Viewing Building Blocks:

• In the Display drop-down menu, select Building Blocks.
• Review all building blocks that help classify events and conditions.

Event Analysis:

• Go to the Log Activity tab and double-click on an event.
• Scroll down to see two key sections: Custom Rules and Custom Rule Partially Matched.
• Custom Rules show rules and building blocks fully triggered by the event.
• Custom Rule Partially Matched lists rules that were partially triggered by the event.