Skip to main content Link Menu Expand (external link) Document Search Copy Copied

Event Watch

Page Layout

This table lists every event bucket currently configured. Buckets can be searched and filtered using the facet on the left of the table.

The leftmost column of the table contains the “Status” toggles. Event buckets can be toggled on or off using these toggles.

The rightmost column of the table contains three “Action” buttons. The first button clones the rule, allowing the user to make changes and save it as a new rule. The second button, a pencil icon, allows the user to edit the bucket. The third button, a trash can icon, deletes the bucket.

The “EXPORT” button can be used to export all currently configured event buckets as a JSON file. Likewise, the “IMPORT” button in the top right corner of the table can be used to import a JSON file containing buckets that have already been configured. The “CREATE” button will open an “Event Watch Configuration” box to add a new event bucket. Additionally, Github integration allows downloading pre-configured rules directly from Fluency’s public Github repository.

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 both metaflow data and event 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. This input should be an event expected to trigger the behavior model. If the test is run and a green check mark is displayed, this means the event will 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.