Content Comparison

...

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 Status (started / paused / stopped), and state 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 Signals 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.

...

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.

...

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:

...

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 Learningduring 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.

...

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