Rules
FortiSIEM continuously monitors your IT infrastructure and provides you with information you can use to analyze performance, availability, and security. There may also be situations in which you want to receive alerts when exceptional, suspicious, or potential failure conditions arise. You can accomplish this by using rules that define the conditions to watch out for, and which trigger an incident when those conditions arise. This incident will appear on the Incident Summary dashboard, and you can also configure a notification policy that will send email and SNMP alerts that the incident has occurred. FortiSIEM includes over 500 system-defined rules, which you can see in Analytics > Rules, but you can also create your own rules as described in the topics in this section.
Creating Rules
FortiSIEM constantly monitors your IT infrastructure for events and collects information about them, but you can also set rules that will trigger incidents from events and send notifications when they occur. These topics describe the concepts and processes for creating rules.
Creating a Rule
Defining Rule Conditions
Example of a Rule with a Single Condition Sub-Pattern
Example of a Rule with Multiple Sub-Patterns
Defining the Incident Generated by a Rule
Defining Rule Exceptions
Defining Clear Conditions Testing a Rule
Creating a Rule
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.
- Go to Analytics > Rules.
- Select the group where you want to add the new rule.
- Click New.
- Enter a Rule Name and Description.
- For Status, keep the rule Inactive.
You can activate the rule after you’re finished creating and testing it.
- Select an Incident Category for the incident triggered by the rule.
You can click Add and enter a custom incident category.
- Select a Severity to associate with the incident triggered by the rule.
- Select Update the Perf Status column on summary dashboard if you want the incident to display in the Performance Status column of the Exec Summary
- For Attributes, enter the functional area, such as Security, that you want to associate the rule with.
- Enter a Notification Frequency for how often you want notifications to be sent when an incident is triggered by this rule.
- Under Conditions, click Add Subpattern to create the rule conditions.
See Defining Rule Conditions for detailed information on selecting event and aggregation attributes to use with rules. You can also see examples of rules with a single subpattern and multiple sub patterns.
- Enter the time interval during which the rule conditions will apply.
The minimal interval is 120 seconds.
- Next to Actions, click Edit to define the incident that will be generated by this rule.
See Defining the Incident Generated by a Rule for more information.
- Next to Watch Lists, click Edit to add a watch list to the rule.
See Adding a Watch List to a Rule for more information.
- If you want to define any Exceptions for the rule, click Edit. See Defining Rule Exceptions for more information.
- If you want to define any Clear Conditions for the rule, click Edit.
See Defining Clear Conditions for more information.
- 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.
Setting the Relationship between Subpatterns
Setting Inter-subpattern Constraints
Examples of inter-subpattern relationships and constraints
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.
Example of a rule with a single subpatten
This screenshot shows an example of a subpattern with a single event filter and a single event aggregation condition. Expressed as a sentence, this rule would be “When there are more than three events on a single Host IP where average CPU utlization is equal to 95%, trigger an incident.”
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. See Selecting Attributes for Structured Searches, Display Fields, and Rules for more information on finding attributes to use in your event filters.
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
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, Destina tion 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, Destina tion IP | COUNT(DISTINCT user) >= 5 |
Setting the Relationship between Subpatterns
Example of a rule with multiple 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
|
Example of a Rule with a Single Condition Sub-Pattern
This topic shows an example of how to create a rule with a single sub-pattern based on the condition that Average CPU on a server is more than 95% over 3 sample measurements.
Attribute | Group By Attribute | Aggregate Conditions |
Avg CPU Util | Host IP | COUNT (Matched Event) >= 3 |
- For Rule Name, enter Hi Avg CPU.
- For Description enter Average CPU on a server is more than 95% over 3 sample measurements.
- For Severity, select 9 – High.
- For Attributes, select All.
- Set the Notification Frequency for 1 Hour.
- Next to Conditions, click Add Subpattern.
- For Subpattern Name, enter Pattern 1.
- Under Filters, set these options:
Option | Setting |
Attribute | Avg CPU Util |
Operator | >= |
Value | 95 |
- Under Aggregate Conditions, click the Expression Builder icon next to the Attribute field, select COUNT(Matched Events) from the Add Function menu, and then click OK.
- Under Aggregate Conditions, select = for Operator and enter 3 for Value.
- Under Group By, select Host IP.
- Click Save.
- Enter 5 for the time interval during which the conditions will apply.
- You would now complete the rule by Defining the Incident Generated by a Rule, and any exceptions or clear conditions. You could also a ssociate it with a notification policy.
This screenshot shows the subpattern settings for this example.
The following steps describe how to create a rule that matches the above example 1:
- Enter a name for the rule in the ‘Rule Name’ text box.
- Enter a description for the rule in the ‘Description’ text box.
- Use the drop down menu to choose a ‘Severity’ for the rule.
- Click on the ‘+ Add Condition’ button.
- Chose the ‘Function’ for the rule. In this case ‘AVG’ is chosen.
- Choose the ‘Attribute’ for the rule. In this case ‘CPU Util’ is chosen.
- Chose the ‘Operator’ for the rule. In this case ‘>=’ is chosen.
- Enter the ‘Value’ for the rule. In this case ’95’ is entered.
- Select the devices to apply the rule to.
- Enter the number of events that must occur for the rule to fire. In this case ‘3’ is used.
- Enter the time frame for the rule. In this case ‘600’ seconds is used.
Example of a Rule with Multiple Sub-Patterns
This topic provides an example of a rule with two sub-patterns, and also how to use the Event Type attribute as a filter.
Rule Conditions
Creating Sub-Pattern P1
Creating Sub-Pattern P2
Defining the Relationship Between Patterns
Defining the Incident to be Generated by the Rule
Rule Conditions
The purpose of this rule is to trigger an incident when five login failures from the same source to a server are not followed by a successful login from the same source to the same server within one hour. This requires two sub-patterns, the first one to detect “five login failures from the same source to a server,” and a second one to detect “a successful logon from the same source to the same server.” The two sub-patterns need to be interrelated to make the complete rule.
Sub-pattern 1 (P1)
Event Filter Attribute | Group By Attributes | Aggregate Conditions |
Event type = Logon Failure | Source IP, Destination IP | COUNT (Matched Event) >= 5 |
Sub-pattern 2 (P2)
Event Filter Attribute | Group By Attributes | Aggregate Conditions |
Event type = Logon Success | Source IP, Destination IP | COUNT(Matched Event) > 0 |
P1/P2 Interrelationships and Constraints
Interrelationships | Constraints |
P1 NOT_FOLLOWED_BY P2 | P1’s Source IP = P2’s Source IP, P1’s Destination IP = P2’s Destination IP |
Creating Sub-Pattern P1
The following steps describe how to create a rule that matches the above example 2:
- Log in to your Supervisor node.
- Go to Analytics > Rules.
- Click New.
- For Rule Name, enter Suspicious Login Failure.
- For Description, enter the rule conditions stated in the introduction to this topic.
- For Severity, select 10 – High.
- For Attributes, select All.
- Next to Conditions, click Add Subpattern.
You will now create the first subpattern for “five login failures from the same source to a server.”.
- For Subpattern Name, enter LogonFailures.
To create this sub pattern you will want to specify that all types of logon failures should be monitored. For this reason, you will want to specify an entire folder of event types as the rule condition, rather than a single attribute of a event.
- For Attribute, select Event Type.
- For Operator, select IN.
- For Value, click … to open the CMDB Browser.
- In the CMDB Browser, go to Event Types > Security > Logon Failure, and click Folder >> to select the Logon Failure events group. Your filter condition, as shown in the screenshot, can be read as “For any type of event in the Logon Failure event group . . .”
- Under Aggregate Conditions, click the Expression Builder icon next to Attribute and select COUNT(Matched Events).
- For Operator, enter >=.
- For Value, enter 5.
- Under Group By, enter Source IP for Attribute, and then click + to add another Group By
- Enter Destination IP.
- Click Save.
This screenshot shows the complete entry for sub-pattern P1.
Creating Sub-Pattern P2
- In your rule, next to Conditions, click Add Subpattern.
- For Subpattern Name, enter LogonSuccess.
- For Attribute, select Event Type.
- For Operator, select IN.
- For Value, click … to open the CMDB Browser.
This button only becomes active if you select Event Type as an attribute.
- In the CMDB Browser, go to Event Types > Security > Logon Failure, and click Folder >> to select the Logon Failure events group. Your filter condition, as shown in the screenshot, can be read as “For any type of event in the Logon Failure event group . . .”
- Under Aggregate Conditions, click the Expression Builder icon next to Attribute and select COUNT(Matched Events).
- For Operator, enter >.
- For Value, enter 0.
- Under Group By, enter Source IP for Attribute, and then click + to add another Group By
- Enter Destination IP.
- Click Save.
This screenshot shows the complete entry for sub-pattern P2.
Defining the Relationship Between Patterns
You will now see both of your sub-patterns listed under the Conditions for your rule definition.
- Makes sure that LogonFailures is selected as the first pattern under If this Pattern occurs, and under Next Op, select NOT_FOLLOW ED_BY.
- Select LoginSuccess as the second subpattern.
- Click AddSubpattern Relationship.
- For the first relationship definition, select LogonFailures for Subpattern, Source IP for Attribute, and = for Operator.
- For the second subpattern, select LogonSuccess for Subpattern, Source IP for Attribute, and AND for Next Op.
- Under Row, click +.
- For the second relationship definition, for the first subpattern, select LogonFailure for Subpattern, Destination IP for Attribute, and = fo r Operator.
- For the second subpattern, select LogonSuccess for Subpattern, and Destination IP for
This screenshot shows the full pattern and relationship definition for the two subpatterns.
Defining the Incident to be Generated by the Rule
- In your rule definition, click Edit next to Generate Incident.
- For Incident Name, enter Suspicious_Login_Failure.
- Under Incident Attributes, select Source IP for Event Attribute, LoginFailures for Subpattern, and Source IP for Filter Attribute.
- Under Row, click +.
- For the second incident attribute, select Destination IP for Event Attribute, LoginFailures for Subpattern, and Destination IP for Filter Attribute.
- Under Triggered Event Attributes, make sure that Event Receive Time, Event Type, Reporting IP, and Raw Event Log are listed in the Selected Attributes.
- Click OK.
This screenshot shows the complete Incident Definition.