Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Creating a Custom Rule

JSA includes rules that detect a wide range of activities, including excessive firewall denies, multiple failed login attempts, and potential botnet activity. You can also create your own rules to detect unusual activity.

Before you begin to create a new rule, you must have the Offenses >Maintain Custom Rules permission.

When you define rule tests, test against the smallest data possible. Testing in this way helps rule test performance and ensures that you don't create expensive rules. To optimize performance, start with broad categories that narrow the data that is evaluated by the rule test. For example, start with a rule test for a specific log source type, network location, flow source, or context (R2L, L2R, L2L). Any mid-level tests might include IP addresses, port traffic, or any other associated test. Payload and regex tests should be the last rule test.

Similar rules are grouped by category. For example, Audit, Exploit, DDoS, Recon, and more. When you delete an item from a group, the rule or building block is only deleted from the group; it remains available on the Rules page. When you delete a group, the rules or building blocks of that group remain available on the Rules page.

  1. From the Offenses, Log Activity, or Network Activity tabs, click Rules.
  2. From the Display list, select Rules to create a new rule.
  3. From the Display list, select Building Blocks to create a new rule by using building blocks.
  4. From the Actions list, select a rule type.

    Each rule type tests against incoming data from different sources in real time. For example, event rules test incoming log source data and offense rules test the parameters of an offense to trigger more responses.

  5. On the Rule Test Stack Editor page, in the Rule pane, type a unique name that you want to assign to this rule in the Apply text box.
  6. From the list box, select Local or Global.
    • If you select Local, all rules are processed on the Event Processor on which they were received and offenses are created only for the events that are processed locally.

    • If you select Global, all matching events are sent to the JSA console for processing and therefore, the JSA console uses more bandwidth and processing resources.

    Learn more about Local and Global rules:

    Global rule tests

    Use global rules to detect things like multiple user login failures where the events from that user might appear on multiple Event Processors. For example, if you configured this rule for 5 login failures in 10 minutes from the same user name, and set as a Local rule, all 5 of those login failures must appear on the same Event Processor. Therefore, if 3 login failures were on one Event Processor and 2 were on another, no offense is generated. However, if you set this rule to Global, it generates an offense.

  7. From the Test Group list, select one or more tests that you want to add to this rule. The CRE evaluates rule tests line-by-line in order. The first test is evaluated and when true, the next line is evaluated until the final test is reached.

    If you select the when the event matches this AQL filter query test for a new event rule, enter an AQL WHERE clause query in the Enter an AQL filter query text box.

    Learn more about using rules for events that are not detected:

    The following rule tests can be triggered individually, but subsequent rule tests in the same rule test stack are not acted upon.

    • when the event(s) have not been detected by one or more of these log source types for this many seconds

    • when the event(s) have not been detected by one or more of these log sources for this many seconds

    • when the event(s) have not been detected by one or more of these log source groups for this many seconds

    These rule tests are not activated by an incoming event, but instead are activated when a specific event is not seen for a specific time interval that you configured. JSA uses a watcher task that periodically queries the last time that an event was seen (last seen time), and stores this time for the event, for each log source. The rule is triggered when the difference between this last seen time and the current time exceeds the number of seconds that is configured in the rule.

  8. To export the configured rule as a building block to use with other rules, click Export as Building Block.
  9. On the Rule Responses page, configure the responses that you want this rule to generate.

    Learn more about rule response page parameters:

    Table 1: Event , Flow and Common Rule, and Offense Rule Response Page Parameters

    Parameter

    Description

    Drop the detected event

    Forces the matched event or flow to bypass all other rules in the rule engine and prevents it from creating an offense. The event is written to storage for searching and reporting.

    Dispatch New Event

    Select this check box to dispatch a new event in addition to the original event or flow, which is processed like all other events in the system.

    Dispatches a new event with the original event, and is processed like all other events in the system.

    The Dispatch New Event parameters are displayed when you select this check box. By default, the check box is clear.

    Severity

    The severity level that you want to assign to the event, where 0 is the lowest and 10 is the highest. The severity is displayed in the Annotation pane of the event details.

    Credibility

    The credibility that you want to assign to the log source. For example, is the log source noisy or expensive? The range is 0 (lowest) to 10 (highest) and the default is 10. Credibility is displayed in the Annotation pane of the event details.

    Relevance

    The relevance that you want to assign to the weight of the asset. For example, how much do you care about the asset? The range is 0 (lowest) to 10 (highest) and the default is 10. Relevance is displayed in the Annotation pane of the event details.

    Email

    To change the Email Locale setting, select System Settings on the Admin tab.

    Enter email addresses to notify

    Use a comma to separate multiple email addresses.

    SNMP Trap

    Enable this function to send an SNMP notification (trap).

    The SNMP trap output includes system time, the trap OID, and the notification data, as defined by the MIB. You can access the MIB from /opt/qradar/conf/Q1LABS-MIB.txt.

    Send to Local SysLog

    If you A forwarding destination is a vendor system, such as SIEM, ticketing, or alerting systems. When you select this check box, a list of forwarding destinations is displayed.want to log the event or flow locally, select this check box.

    By default, this check box is clear.

    Note:

    Note: Only normalized events can be logged locally on an appliance. If you want to send raw event data, you must use the Send to Forwarding Destinations option to send the data to a remote syslog host.

    To add, edit, or delete a forwarding destination, click the Manage Destinations link.

    Send to Forwarding Destinations

    If you want to log the event or flow on a forwarding destination, select this check box.

    A forwarding destination is a vendor system, such as SIEM, ticketing, or alerting systems. When you select this check box, a list of forwarding destinations is displayed.

    To add, edit, or delete a forwarding destination, click the Manage Destinations link.

    Notify

    Displays events that generate as a result of this rule to be displayed in the System Notifications item on the Dashboard tab.

    If you enable notifications, configure the Response Limiter parameter.

    Add to Reference Set

    Adds events that are generated as a result of this rule to a reference set. You must be an administrator to add data to a reference set.

    To add data to a reference set, follow these steps:

    1. From the first list, select the property of the event or flow that you want to add.

    2. From the second list, select the reference set to which you want to add the specified data.

    Add to Reference Data

    To use this rule response, you must create the reference data collection.

    Remove from Reference Set

    If you want this rule to remove data from a reference set, select this check box.

    To remove data from a reference set:

    1. From the first list box, select the property of the event or flow that you want to remove. Options include all normalized or custom data.

    2. From the second list box, select the reference set from which you want to remove the specified data.

    The Remove from Reference Set rule response provides the following function:

    Refresh: Click Refresh to refresh the first list box to ensure that the list is current.

    Remove from Reference Data

    To use this rule response, you must have a reference data collection.

    Execute Custom Action

    You can write scripts that do specific actions in response to network events. For example, you might write a script to create a firewall rule that blocks a particular source IP address from your network in response to repeated login failures.

    You add and configure custom actions by using the Define Actions icon on the Admin tab.

    Publish on the IF-MAP Server

    If the IF-MAP parameters are configured and deployed in the system settings, select this option to publish the event information about the IF-MAP server.

    Response Limiter

    Configures the frequency in which you want this rule to respond.

    Offense Name

    If you want the Event Name information to contribute to the name of the offense, select the This information should contribute to the name of the offense option.

    If you want the configured Event Name to be the name of the offense, select the This information should set or replace the name of the offense option.

    Note:

    This option does not rename existing offenses. To rename an existing offense, you must use the Offense Rule option This information should set or replace the name of the offense.

    An SNMP notification might resemble:

    "Wed Sep 28 12:20:57 GMT 2005, Custom Rule Engine Notification - Rule ’SNMPTRAPTst’ Fired. 172.16.20.98:0 -> 172.16.60.75:0 1, Event Name: ICMP Destination Unreachable Communication with Destination Host is Administratively Prohibited, QID: 1000156, Category: 1014, Notes: Offense description"

    A syslog output might resemble:

    Sep 28 12:39:01 localhost.localdomain ECS: Rule ’Name of Rule’ Fired: 172.16.60.219:12642 -> 172.16.210.126:6666 6, Event Name: SCAN SYN FIN, QID: 1000398, Category: 1011, Notes: Event description

To verify that the event triggers the rule test based on your building block, you can create an email response.