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.