Behavior Models

About this page

The Content Manager > Behavior Models page is for configuring, deploying and monitoring your behavior models.

This page displays a table of the models that can be deployed out of the box. (The list is also included in the last section of this document, “List of supported behavior models”, for reference below.)

Open

Content Manager > Behavior Models displays a table of available models. Initially all models are stopped.

There are several columns in the table: Behavior Model (the name of the model), Required Table (the required Devo table for deploying the model), status (started / paused / stopped), and state (Running / Learning). Initially all models are stopped by default. Each model must be started in order to begin learning and running.

Additionally, the Behavior Models table shows a column with a micro trend chart displaying the signal volume during the last 7 days for each behavior model. Clicking on a model’s chart will open Devo’s Search window with the signals table (entity.behavior.signals.filtered) in a separate browser tab, so that you can browse the details of that model’s signals as needed.

Open

Once a model has started running, the volume of signals produced by the model over the last 7 days is shown as a micro chart in the Signals column.

Deploying behavior models

In order to deploy a model, click the Configure and Start button for that model. The configuration editor for the behavior model will appear. The editor has 4 tabs (sections) of configuration options: Signals, Whitelist, Alerts, and Advanced. The contents of each of these sections is described in more detail below.

Note that each of these sections is optional. If desired, the user may simply click the Start button at the bottom of the editor, in which case the default values for the configuration options will be applied.

For optimal performance and memory usage, stagger the deployment of your models rather than deploying all the models at once.

Signals

The Signals section of the configuration editor enables users to assign a risk score for each signal from the selected model. The risk score must be a number from zero to 100. This risk score will subsequently be used to compute the entity risk scores by the risk calculator. Note that the same risk score is applied to every signal from the selected model.

By default, a risk score of 20 is assumed for every model. This implies that every model is given equal weight by default. The user may adjust the signal risk scores of their models in order to give certain models more or less weight than other models.

Whitelist

The Whitelist section of the configuration editor enables users to specify lists of entities to be excluded from triggering signals by the selected model. Each model can be configured with 3 separate optional whitelists: users, devices, and domains.

Each of the 3 whitelists can be either entered manually or uploaded from a text file. The whitelist entries should be separated by carriage returns. The format for these entries is as follows:

To upload values from a file, click the Upload CSV button to open the Upload Whitelist popup.

Select the file by either clicking Browse or dropping the file into the gray File box (left). Once a file has been selected, the start of the file’s contents will be shown in the Preview area (right).

• Use the Values Column drop down to choose which column contains the values that you wish to whitelist. (Only one column can be selected at a time, but multiple uploads can be used to add multiple columns from the same CSV.)

• Use the Header Row option to specify whether the CSV has a header row or not. If so, the first row in the CSV file will be ignored when adding it to the whitelist. 

• Use the Add / Replace option to specify how the prior whitelist values should be handled. If “Add” is selected then all the uploaded values will be appended to the prior whitelist values; if “Replace” is selected then the prior whitelist values will be removed and the entire whitelist will be overwritten by the uploaded values. 

Note that User, Device, and Domain whitelists are included in each model configuration whether or not they are present in the model’s logic. If the model logic does not include ones of the 3 entity types then a warning message like the one below is displayed:

Alerts

The Alerts section of the configuration editor enables users to optionally trigger an alert for each of the model’s signals. By default, when a behavior model detects anomalous behavior it will produce only a behavior signal, not an alert. These so-called “behavior alerts” are not required for risk calculation; the behavior signals are sufficient. Nevertheless, behavior alerts can be useful for triaging, or simply for notifying the security analyst every time that a signal is generated by the selected behavior model.

• To configure a new alert for each new signal from the selected model, choose the “Yes, trigger an alert” option.

• You may then choose a priority for the behavior alert (Very high, high, medium, low, or very low).

• If desired, you may also apply an additional level of whitelisting to the behavior alert. Check the Apply SecOps Asset Whitelisting option to prevent assets in your SecOps global whitelist lookup (SecOpsGWL) from triggering this behavior alert. (Note that for this feature to be enabled, you must install the SecOpsGWL and SecOpsAssetRole lookups from Devo exchange.)

Advanced

The Advanced section enables users to tune the model’s resources and performance. Internally, Devo behavior models operate in a distributed system of drivers and executors with flexible deployment configurations. The options in the Advanced section enable users to tune those configurations if needed. However, this is typically not necessary and only done in conjunction with guidance from Devo technical support. In most cases, the default values should suffice and should be left unmodified.

Working with models

Once a behavior model has been started, it begins a learning period. During the learning period, the model will monitor data without outputting any behavior signals. The model’s state will be shown as Learning during this time, as well as when the model was started and how much time remains in the model’s learning period. (The length of the learning period varies per model. “First Time” models typically require a 30 day learning period, whereas “Auth Impossible Travel” only requires 24 hours.) Once the learning period is over, the model’s state will be shown as Running to indicate that the model is ready to produce behavior signals.

Once a behavior model has been started, an action menu (labeled “…”) will be shown on the far right of the model’s row.

From this action menu, the user can:

• Modify the model configuration. This will re-open the behavior model configuration editor.

• Mute the model. A muted model is one in which data processing is proceeding normally, however the generation of signals is temporarily suppressed. Muting a model does not interrupt the model’s learning nor analysis. A muted model can be “unmuted” in order to unsuppress (i.e., re-enable) the generation of signals.

• Pause the model. A paused model is one in which data processing has been temporarily disabled. The model is no longer processing incoming data and thus will not generate signals. A paused model can be “resumed” in order to continue its processing of incoming data. A paused model will preserve its configuration and its learned data. Therefore a model that is paused and then resumed will not need to restart its learning period from the beginning.

• Stop the model. Like a paused model, a stopped model is no longer processing incoming data and will not generate signals. However, stopping a model is a more destructive action. Unlike pausing a model, stopping a model will delete the model’s learning data and its configuration. If the model is subsequently restarted later, the user will need to re-configure the model, and the model will require another learning period once it starts. For this reason, stopping a model is not recommended in most cases; it is typically done only for troubleshooting purposes under the guidance of Devo technical support.

List of supported behavior models

The table below enumerates the behavior models that are provided out of the box in Behavior Analytics.