Skip to main content

Creating a Behavior Rule

Legacy interface

The screenshots in the worked example below, other than those on its v2 interface tabs, show the legacy "Event Watch Configuration" dialog. In the current interface, the equivalent is the Add Behavior Rule wizard opened by + Create Rule on the Configuration → Behavior Rules page (v1: Create Rule on SIEM → Behavior Rules); its steps are Bucket Definition, Selection Criteria, and Activity Performed. The rule-building concepts carry over, but the controls within each step may differ from those shown.

Page Layout​

Sign in to your Fluency portal at https://<companyname>.app.ingext.io; see Fluency Web Interface for the URL formats.

In the navigation rail, open Configuration and choose Behavior Rules.

Behavior Rules page showing the search bar with the sort drop-down and the Search, Behavior Filters, and Create Rule buttons, the facet panel on the left, and the rule table with name, category, tags, active switch, and last-updated columns

This page lists every behavior rule (event bucket) currently configured, one row per rule. Rules can be searched, and filtered using the FILTERS panel to the left of the list.

Each rule has an Active switch: blue means the rule is on, and clicking it switches the rule off (grey). Clicking a rule's row opens its detail panel, with Clone (make a copy to change and save as a new rule), Download JSON, and either View Rule (open a repository rule read-only) or Edit (open a rule of your own for editing).

Import and Create Rule​

At the right end of the search bar there are two buttons: Behavior Filters (which opens the Behavior Filters page of rule exceptions) and + Create Rule.

Create Rule: add a behavior model​

Clicking + Create Rule opens the Add Behavior Rule dialog (Define the bucket, how events are selected, and the activity that raises a behavior.), a three-step wizard whose steps are shown across the top: 01 Bucket Definition, 02 Selection Criteria, and 03 Activity Performed.

Add Behavior Rule dialog on the Bucket Definition step, with Name, Description, Bucket Category, Tags, Event Type, and Search Profile fields and the Import Rule, Cancel, and Next buttons

The first step, Bucket Definition, contains a required Name text field, a multi-line Description, a Bucket Category text field, a Tags multi-select (Add…), an Event Type drop-down preset to event (the options are metaflow, event, and resource, which adds a Resource Type drop-down), and a Search Profile drop-down preset to None. At the bottom of the dialog, Import Rule loads an existing rule definition instead of building one from scratch, Cancel closes the dialog, and Next advances to the following step; the × in the upper-right corner also closes the dialog.

Import Rule​

To import an existing rule definition instead of building one from scratch, use the Import Rule button at the bottom of the Add Behavior Rule dialog.

As an example, you are going to create a model to collect events where the "FilePreviewed" or "FileDownloaded" operations were performed. This alert will trigger when a user previews or downloads more than 20 files in an hour. The steps are described below.

(1) Bucket Definition

Give the event a name; in this case you will call it "O365_Files_Accessed". Optionally, give it a description as well. Next, assign the bucket a category. In this case, the category is "Office365". This allows buckets to be grouped more easily for usage and search purposes. Multiple tags can be attached to the bucket; these can also be used for searching.

Select an Event type from the dropdown menu. Event buckets can be applied to both metaflow data and event data. In this case, you want to apply this bucket to event data.

Bucket Definition step with the bucket name, category, tags and event type set

NOTE: Bucket naming convention typically consists of underscores between each word.
The v2 wizard accepts only letters, digits, underscores and hyphens in the name.

(2) Selection Criteria

Leave Match All unticked and click + Add Search Filter: the filter's editor opens in the step itself, with Name (the event field to test), Filter Type, Terms, and Exclude Field. Filter Type offers nine types: content, contains, startswith, endswith, regexp, field (the default), entityinfo, exists, and feed. "field" matches values to the field named. "entityinfo" uses a defined entity list to match multiple values, and potentially translates them as well. "regexp" allows you to use a regular expression. "exists" determines if the field exists or not.

In this case, you want "field". Type the field into Name (here @fields.Operation), then type each value into Terms and press Enter to add it as a chip. Click Save filter to attach the filter to the rule; it then reads @fields.Operation must be FilePreviewed OR FileDownloaded. Every field of the editor is described under Selection Criteria.

Selection Criteria step of the Add Behavior Rule wizard, with the Match All and LVDB Query checkboxes, the Event Filter field, and the search filter editor open with an empty Name, Filter Type set to field, the Terms field, the Exclude Field checkbox, and Cancel and Save filter buttons

More matches can continue to be added in this manner. For this model, you also want a filter that selects only O365 events with the "FilePreviewed" or "FileDownloaded" operation.

Selection Criteria showing the saved field filter attached to the bucket

Selection can also be written as a query (in the v2 wizard, in the Event Filter field under QUERY). For example, say you want to find bidirectional communication on the Windows remote desktop port (3389). You can create a search to look for this activity:

dp:3389 AND NOT rxB:0 AND NOT txB:0

The same selection can be done in the Event table by fully listing the field name. The disadvantage is that event data is not normally parsed to normalize protocol fields. The following is the above example, but this time writing the selection against the Event table:

@peplink.dpt:3389 AND NOT @peplink.bytes_recvd:0 AND NOT @peplink.bytes_sent:0

More complex selection logic is best done with a query tree.

(3) Activity Performed

Click Next to reach the third step, Activity Performed. Its Behavior Name is the rule's name, filled in and read-only. Select the type of behavior in Behavior Type, which is required: "network access", "account login", "application activity", or "security alert". Then, enter the key in Entity / Key (here @fields.UserId) and choose its Key Type (username). This key will display at the top of a behavior alert, and is the field used for sorting alerts.

Next, add attributes to the rule. These attributes will appear attached to each alert. Click + Add Attribute, type the event field into Field (here @fields.UserId), and give it an alias in Alias (here Username). This alias allows the attribute to display on an alert with a more clear name.

NOTE: The alias cannot contain spaces, and should be written in camelcase with the first letter capitalized (Ex. FieldName).

Once Save attribute is clicked, the attribute appears in the list as Username ← @fields.UserId, with Edit and Delete. More attributes can be added in this manner, with a maximum of 16 total; for this rule, also add the file name (@fields.SourceFileName, alias FileName), which the correlation rule below counts.

Once all the desired attributes have been added, a description can be written. This should describe what has occurred when an alert is triggered. In this case, you want to write something that a large number of files was previewed or downloaded, and include details on the user that performed this action, in addition to location details.

NOTE: Attributes can be referenced in the description. This allows attributes to be filled in with the proper values attached to an alert. This can be done by enclosing it in double brackets with a period preceding the alias.

The description is "{{.Username}} previewed or downloaded more than 20 files in an hour from {{.IP}} in {{.City}}, {{.Country}}.” The username, IP, city, and country fields will be populated with the appropriate values when an alert triggers.

(4) Correlation Rules

The last step is to add correlation rules, under CORRELATION RULES on the same step. There are two buttons for the two types: + Add First-Occurrence Rule and + Add Aggregation Rule.

The first-occurrence rule will trigger whenever a value associated with a chosen field appears for the first time. The aggregation rule has three types, Count, Sum, and Cardinality, and will trigger when the aggregation of this type crosses a specified value within a window.

For this rule, you want an aggregation rule to trigger when there are more than 20 unique files accessed within an hour. Click + Add Aggregation Rule; since you are looking at unique files, set Type to Cardinality. The Name of this rule is FilesAccessed and the Description is "A user previewed or downloaded more than 20 files in an hour." For Field, pick FileName: the drop-down lists the aliases of the attributes added above.

Next, define the window and the match, and add risks. The window, in this case, is 1 hour (Window Size 1, Window Unit Hours), and the match is Greater Than with a Value of 20, since you are looking for a trigger on more than 20 unique files in an hour. The Risks drop-down contains a list of pre-written risks. Choose the risk(s) that apply the closest to the correlation rule. Click Save rule to add the rule; it appears under CORRELATION RULES as FilesAccessed · cardinality. Multiple correlation rules can be added to each behavior. The editors' fields and defaults are listed under Activity Performed.

Aggregation rule editor in the Activity Performed step, with Type Cardinality, the name FilesAccessed, a description, Field FileName, the ALERT_SEVERITY_MEDIUM risk, Window Size 1, Window Unit Hours, Match Operator Greater Than, and Value 20

(5) Test

Models can be tested using the test tab at the bottom of the window. This opens up a text box that allows an input to be entered. Both an event that is expected to trigger the behavior and an event that is NOT expected to trigger the behavior should be tested in order to ensure the model is working as expected.

If the test runs and a green check mark is displayed, this means the event will trigger the behavior.

If the test runs and a red "x" is displayed, this means the event will NOT trigger the behavior. Sample events for pre-written models are available in the Fluency rules manual.

Once the model is written as desired, click Save on the Activity Performed step. A new rule is active by default: the SET AS ACTIVE RULE switch at the bottom of the step reads Active; turn it off to save the rule without it being evaluated. Saving closes the wizard with the notice Successfully added behavior rule, and an active rule begins aggregating data.

Editing an Existing Model​

On the rules page, click the rule's row to open its detail panel.

  • For a rule supplied by a repository such as Fluency, repository rule (read-only) in the panel's header, the panel offers View Rule, which opens the rule read-only in the same three-step wizard, titled View Behavior Rule.
  • For a rule of your own, the panel offers Edit, which opens the wizard titled Update Behavior Rule, pre-filled with the rule (its Name cannot be changed), and a red Delete.

Opened this way, the wizard's footer carries a Test Rule button beside Cancel and Next.

To customize a repository rule, clone it (Clone, in the rule's detail panel; v1: the Clone option in the same menu) and edit the copy. See Managing Rules for best practices on duplicating a rule before editing it.

Last updated on