Creating Rules

Creating a new rule involves defining the attributes of the incident that is triggered by the rule, as well as the triggering conditions and any exceptions or clear conditions. You can also create a rule by cloning an existing rule using the Clone button and editing it. 

Note: Do not use certain keywords in sub-pattern names - regexp.

Creating a Rule

Complete these steps to create a rule:

  1. Go to RESOURCES > Rules.
  2. Select the group where you want to add the new rule.
  3. Click New to create a new rule.
    SettingsGuidelines
    Step 1: General

     

    GroupFrom the drop-down list, select the group the rule will belong to.
    Rule NameEnter a name for the new Rule.
    DescriptionEnter a description of the new Rule.
    Data SourceSelect or enter the source where the data comes from for the rule to define its data source.
    Detection Technology

    Provide the detection technology method used by the rule by selecting from the drop-down list. The choices are:

    • Correlation - Uses an association between variables for discovery.
    • Correlation Using Lookup Table - Uses lookup table for discovery.
    • Machine Learning - Uses machine learning models for discovery.
    • Profiling - Collects specific data for discovery.
    Event TypeThe name you enter in the Rule Type field is replicated in the Event Type field.
    Evaluation Mode

    Select Streaming or Scheduled. Streaming rules are rules that are run in real-time. Scheduled rules are rules that run on a defined schedule. Rules in scheduled mode requires configuration of Query Time Window and Schedule.


    Note: This option is only made available with a ClickHouse database. In contrast to Streaming, Scheduled rules require disk access and does not scale comparably. In-memory Streaming option is faster and a large number of rules can be evaluated concurrently. However, Scheduled reports have the following advantages:

    • Rules can be written using the complex analytic functions introduced in 7.0.
    • Rules can be evaluated over larger time intervals.
    • Once the scheduled rule conditions are met, Incidents are created the same way as Streaming rules.
    Remediation NoteEnter the Remediation script. Make sure that the Remediation script for your scenario is defined. Check the existing Remediation scripts under ADMIN > Settings > General > Notification Policy > Action column. If your device is not in the list, add the needed Remediation script.
    Query Time Window

    For Scheduled Mode, the following configuration is required.

    Time Zone - Configure the Time Zone by selecting from the drop-down list(s), and configure the frequency that the rule will be run in the following row.

    Schedule Time Window

    For Scheduled Mode, the following configuration is required.

    Schedule Time Range - In the Start Time field, enter/select the time to start the scheduled rule.

    Schedule Recurrence Range - In the Start From field, enter the time when the scheduled rule should run. Next, configure when the scheduled rule should end from the following choices: No end date, End after, or End by. For End after, enter the number of occurrence(s) needed to stop the scheduled rule. For End by, enter the date when the scheduled rule will stop running.

    Step 2: Define Conditions

     

    Conditions Click Condition to create the rule conditions. See Defining Rule Conditions.
    Step 3: Define Actions

     

    SeveritySelect a Severity to associate with the incident triggered by the rule. 
    CategorySelect the Category of incidents to be triggered by the rule.
    SubcategorySelect the Subcategory from the available list based on the selected incident Category. To add custom subcategories, follow the steps under Setting Rule Subcategory.
    TechniqueSelect any techniques from the available Technique list. You can choose to select zero, one, or multiple techniques. The Tactics row will update itself based on the techniques selected.
    ActionClick the edit icon to define the incident (Incident Attributes and Triggered Attributes) that will be generated by this rule. You must have at least one incident defined before you can save your rule.
    ExceptionClick the edit icon to define any Exceptions for the rule. See Defining Rule Exceptions.
    TagClick the drop-down list icon to view the tag list. If no tags appear, it means no tags have been created. From the drop-down list, select any tags you wish to associate with the rule. From Incidents View (by Time, by Device, by Incident), tags are displayed in the Tag column. See Tags for more information.
    Update Status on Summary DashboardAdd a check mark to the Update Status on Summary Dashboard checkbox to add this rule update in the Summary Dashboard, under the DASHBOARD tab.
    NotificationEnter a Notification frequency for how often you want notifications to be sent when an incident is triggered by this rule. 
    ImpactsSelect the Impacts of the incident triggered by this rule from the drop-down.
    Watch ListClick the edit icon to add the rule you want to add to the watch list.

    Note: The Type that you set for the watch list must match the Incident Attribute Types for the rule. For example, if your watch list Type is IP, and the Incident Attribute Type for the rule is string, you will not be able to associate the watch list to the rule.
    ClearClick the edit icon to define any Clear conditions for the rule. See Defining Clear Conditions.
  4. Click Save.
    Your new rule will be saved to the group you selected in an inactive state. Before you activate the rule, you should test it. 

Defining Rule Conditions

Rule conditions define the event attributes and thresholds that will trigger an incident. Rule conditions are built from sub-patterns of event attribute filters and aggregation functions. You can specify more than one subpattern and the relationships and constraints between them. 

Specifying a Subpattern

A subpattern defines the characteristics of events that will cause a rule to trigger an incident. A subpattern involves defining event attributes that will be monitored, and then defining the threshold values for aggregations of event attributes that will trigger an incident.

Note: Only one subpattern is allowed for Scheduled Rules.

Event Filters

Event filter criteria determine which event attributes and values will be monitored by the rule, and are set in a way that is similar to the way you set event attributes for structured historical searches and real time searches. 

Event Aggregation

While you could have a rule that triggers an incident on a single instance of a particular event, it is more likely that you will want your rule to trigger an incident when some number of events have been found that meet your event filter criteria.

Group By Attributes

This determines which event attributes will be used to group the events before the group constraints are applied, in a way that is similar to the way the Group By attribute is used to aggregate the results of structured searches. 

Aggregate Conditions

The group aggregation conditions set the threshold at which some aggregation of events will trigger a rule to create an incident. You create an aggregation condition by using the Expression Builder to set a function, and then enter the Operator and Value for the aggregation condition. Examples of Group By and Aggregate Conditions Settings are shown below:

Scenario Group By Attributes Aggregate Conditions
10 or more events none COUNT(Matched events) >= 10
Connections to 100 or more distinct destination IPs from the same source IP Source IP COUNT (DISTINCT Destination IP) >= 100
Connections to 100 or more distinct destination IPs from the same source IP on the same destination port Source IP,Destination Port COUNT (DISTINCT destination IP) >= 100
Average CPU Utilization on the same server > 95% over 3 samples Host IP COUNT (Matched Events) >= 3 AND AVG(CPU Util) > 95
Logins from the same source workstation to 5 or more accounts on the same target server Source IP, Destination IP COUNT(DISTINCT user) >= 5

Setting the Relationship between Subpatterns

If you have more than one sub-pattern, you must specify the relationship between them with these operators.

Operator Meaning
AND Sub-pattern P1 AND Sub-pattern P2 means both sub-patterns P1 and P2 have to occur
OR Sub-pattern P1 OR Sub-pattern P2 means either P1 or P2 have to occur
FOLLOWED-BY Sub-pattern P1 FOLLOWED-BY Sub-pattern P2 means P1 has to be followed by P2 in time
AND-NOT Sub-pattern P1 AND-NOT Sub-pattern P2 means P1 must occur while P2 must not; the time order between P1 and P2 is not important
NOT-FOLLOWED-BY Sub-pattern P1 NOT-FOLLOWED-BY P2 means P1 must occur and P2 must not occur after P1

Setting Inter-subpattern Constraints

You may want to relate attributes of a sub-pattern to the corresponding attributes of another sub-pattern, in a way that is similar to a JOIN operation in an SQL, by using the relationship operators  <, >, <=, >=, =, !=.

Examples of inter-subpattern relationships and constraints

Scenario Sub-pattern P1 - filter P1 - Group-by attribute set P1 Group constraint Sub-pattern P2 filter P2-group-by attribute P2 group constraint Inter-P1-P2 relationships Inter-P1-P2 constraints
5 login failures from the same source to a server not followed by a successful logon from the same source to the same server Event type = Login Success Source IP, Destination IP COUNT (Matched Event) >= 5 Event type = Login failure Source IP, Destination IP COUNT(Matched Event) > 0 P1 NOT_FOLLOWED_BY P2 P1's Source IP = P2's Source IP
An security attack to a server followed by the server scanning the network, that is, attempting to communicate to 100 distinct destination IP addresses in 5 minute time windows Event type = Attack Destination IP COUNT (Matched Event) > 0 Event Type = Connection Attempted Source IP COUNT (DISTINCT Destination IP) > 100 P1 FOLLOWED_BY P2 P1's Destination IP = P2's Source IP
Average CPU > 95% over 3 sample on a server AND Ping loss > 75% Event Type = CPU_Stat Host IP COUNT(Matched Event) >= 3 AND AVG(cpuUtil) > 95 Event Type = PING Stat Host IP pingLossPct > 75 P1 AND P2 P1's Host IP = P2's Host IP

Defining the Incident Generated by a Rule

Defining an incident involves setting attributes for the incident based on the subpatterns you created as conditions for the rule, and then setting attributes for the incident that will be used in analytics and reports.

Note: You must have at least one incident defined before you can save your rule.  

  1. Select the rule you want to define an incident for.
  2. Click Edit and go to Step 2: Define Condition.
  3. Select a Subpattern from the drop-down list and click the edit icon to define the conditions for the rule. See Defining Rule Conditions.

    Define attributes for the incident based on the Filter, Aggregate, and Group By attributes you set for your subpatterns. Typically, you will set the Incident attributes to be the same as the Group By attributes in the subpattern:

    1. Select the Attribute you want to add to Incident.
    2. Select a Subpattern. 
    3. This will populate values from the Group By attributes in the subpattern to the Filter menu. 
    4. In the Filter menu, select the attribute you want to set as equivalent to the Event Attribute.

  4. In Step 3: Define Action, provide values for the Severity, Category, Subcategory, Dashboard, Notification, Impacts, and Watch List fields as described in Creating a Rule. For information on exceptions, see Defining Rule Exceptions.
  5. Click the Action edit icon to define the incident events and triggered attributes in the Generate Incident for dialog box. This dialog box is is pre-populated with typical attributes you would want included in an incident report.
  6. Under Triggered Attributes, select the attributes from the triggering events that you want to include in Dashboards and Analytics for this event. 
  7. Click Save. 

Defining Rule Exceptions

Once you activate a rule, it continuously monitors your IT infrastructure for conditions that would trigger an event. However, you may also want to define exceptions to those conditions. For example, you may know that a server will be going down for maintenance during a specific time period and you don't want your Server Down - No Ping Response rule to trigger an incident for it. 

  1. In RESOURCES > Rules, select the rule you want to add the exception to, and click Edit. 
  2. Select Step 3: Define Action.
  3. Next to Exceptions, click Edit.
  4. Select an Attribute and Operator, and enter a Value, for the conditions that will prevent an incident from being generated. 
    The values in the Attribute menu are from the Event Attributes associated with the incident definition. 
  5. Click the + icon to set an effective time period for the exception.
    You can set effective time periods for single and recurring events, and for durations of time from hours to days.
  6. Enter any Notes about the exception. 
  7. Click Save.

Defining Clear Conditions

Clear conditions specify conditions in which incidents will have their status changed from Active to Cleared. You can set the time period that must elapse for the clear condition to occur, and then set the conditions based on the triggering of the original rule, or on a sub pattern based on the Incident Attributes.

  1. In RESOURCES > Rules, select the rule you want to add the clear condition to, and click Edit. 
  2. Select Step 3: Define Action.
  3. Next to Clear Condition, click Edit.
  4. Set the Time Period that should elapse for the clear condition to go into effect.
  5. If you want the clear condition to go into effect based on the firing of the original rule, select the Original Rule Does Not Trigger.
    Note: For Scheduled Rules, this is not selectable.
    For example, if you wanted the clear condition to change the status of Active incidents to Cleared after the original rule had not been triggered for ten minutes,  you would set Cleared Within to 10 Minutes and select this option. 
  6. If you want to base the clear condition on a sub-pattern of the incident attributes, select the following conditions are met.
    The incident attributes from your rule will load and the clear condition attributes will be set to match. 
  7. Define the pattern to use by clicking the Edit icon next to the clear sub pattern.
  8. Click Save.

Defining an Incident Title

Defining an incident title makes it convenient to identify an incident without having to search on incident source, target, and details. You can define titles for both user-defined rules and system rules.

These steps assume you have already created a rule or are editing a system rule.

  1. In RESOURCES > Rules, select the rule you want to add a title to, and click Edit. 
  2. Select Step 3: Define Action.
  3. You can either enter text for the title or build the title using incident attributes defined for the rule.

    To use the incident attributes to build the title, follow these steps:

    1. Open the drop-down list next to Insert Attribute.

      Notice that the list contains all of the attributes defined in the Incident Attributes field.

    2. Select an attribute and click the + symbol to the right of the Insert Attribute list.

      The attribute appears in the Incident Title field prefixed by a "$" symbol, for example, $user.

    3. Repeat the previous step for all of the attributes you want to appear in the title.
    4. You can add text to the Incident Title field to make it more meaningful to you, for example: $user created $fileName on $hostName.
  4. Click Save when you have finished your edits.

Once the title is defined in a rule definition, FortiSIEM will populate Incident Title field for all new instances of the Incidents.

To Display the Incident Title Field

Follow these steps to display the Incident Title column in the list of incidents table.

  1. Go to INCIDENTS > List by Time view.
  2. Open the Actions drop-down list and select Change Display Columns.
  3. Select Incident Title from the list.
  4. Click Close.

The Incident Title column appears in the incidents table.