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. The rule must test payload and regex expression last.

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 a Local rule for five login failures in 10 minutes from the same username, all 5 of those login failures must appear on the same Event Processor. Therefore, if three 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.

    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

    Severity

    Select this checkbox to assign a severity level 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

    Select this checkbox to assign credibility 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

    Select this checkbox to assign relevance 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.
    Bypass further rule correlation event

    Select this checkbox to match an event or flow to bypass all other rules in the rule engine and prevent it from creating an offense. The event is written to storage for searching and reporting.
    Dispatch New Event

    Select this checkbox 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 checkbox . By default, the checkbox is clear.
    Email

    Select this checkbox to change the Email Locale setting from the System Settings on the Admin tab.
    Send to Local Syslog Select this checkbox to log the event or flow locally. By default, this checkbox is clear.
    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.

    Send to Forwarding Destinations

    Select this checkbox to log the event or flow on a forwarding destination.

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

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

    Notify

    Select this checkbox to display events that are generated as a result of this rule in the System Notifications item on the Dashboard tab.

    If you enable notifications, configure the Response Limiter parameter.

    Add to Reference Set

    Select this checkbox to add 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

    Select this checkbox to remove data from a reference set.

    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

    Select this checkbox to 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.

    Response Limiter

    Select this checkbox to configure the frequency in which you want this rule to respond.

    An SNMP notification might resemble the following example:

    "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 the following example:

    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.

Related Documentation