Creating a Behavior Model

Adding an Behavior Rule

As an example, we’re 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. First, give the event a name; in this case we’ll call it O365_Files_Accessed. Optionally, give it a description as well.

NOTE: Bucket naming convention typically consists of underscores between each word.

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 metaflow, event, and resource data. In this case, we want to apply this bucket to event data.

Once the Match All box is unchecked, clicked the “+ADD FILTER” button that appears to open this window. There are five filter types: field, entityinfo, regexp, exists, and feed. Field matches values to a key field selected. Entityinfo uses a defined entity list to match multiple values, and potentially translate them as well. Regexp allows you to use a regular expression. Exists determines if the field exists or not.

In this case, we want field. Select/search the desired field from the dropdown, or type it into the box, then add values to the “Match” box.

Once you’ve typed in a match, press enter to add it to the list. Once added, the match will look like this. More matches can continue to be added in this manner. Once done, press the “SAVE” button to attach this filter to the event bucket.

For this model, we also want a filter that selects only O365 events with the FilePreviewed or FileDownloaded operation.

The next step is to create the behavior model. Scroll down to the “Activity Performed” section and choose the Behavior tab to begin this process.

Begin by giving the behavior model a name. Next, select the type of behavior from the following: network access, account login, application activity, and security alert. Then, select a key and key type. This key will display at the top of a behavior alert, and is the field used for sorting alerts.

NOTE: The name of the behavior should match the name of the bucket.

Next, add attributes to the bucket. These attributes will appear attached to each alert.

As you type in the fields box, search options will appear in the dropdown populated with already existing fields from event data. Values not appearing in this search can also be entered. In this case, we want @fields.UserId, so we can select it from the dropdown.

Next, give the attribute an alias. 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” is clicked, the attribute will appear in the list, with options to edit or discard each attribute. More attributes can be added in this manner, with a maximum of 16 total.

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, we want to write something that details 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 (Ex. {{.FileName}}).

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.

The last step is to add correlation rules. There are two options for types of correlation rules: First Occurrence and Metric Aggregation. The first occurrence rule will trigger whenever a value associated with a chosen field appears for the first time. The metric aggregation rule has different types, such as sum or cardinality, and will trigger when the aggregation of this type exceeds a specified value.

For this bucket, we want a metric aggregation rule to trigger when there are 20 unique files accessed within an hour. Since we are looking at unique files, we want to use the cardinality type. The name of this rule is FilesAccessed and the description is “A user previewed or downloaded more than 20 files in an hour.” The selected field is FileName.

The last step is to define the window and operand, and add risks. The window, in this case, is 1 hour, and the operand is gt (greater than) 20, since we are looking for a trigger on more than 20 unique files in an hour. The risks dropdown contains a list of prewritten risks. Choose the risk(s) that apply the closest to the correlation rule. Click “SAVE” to add the rule to the table.

Once the model is saved, it should appear like above. Multiple correlation rules can be added to each behavior.

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 is run and a green check mark is displayed, this means the event will trigger the behavior. If the test is run and a red x is displayed, this means the event will NOT trigger the behavior. Sample events for prewritten models are available in the Fluency rules manual.

Once the model is written as desired, click “SAVE.” This will save the bucket, and allow it to begin aggregating data.

Page last updated: 2021 Oct 18