Content manager
- Former user (Deleted)
- Borja Moro Moreno
- Juan Tomás Alonso Nieto (Deactivated)
Introduction
The content manager is where the behavioral models can be deployed. To get to the content manager, click the Content Manager button at the top right of the application. Once you open the content manager, a list of all models that can be deployed are displayed (a total of the 32 models).
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). If a model is not enabled, then it must be turned on in order to start 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 it 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 the signals as needed.
Deploying behavior models
In order to deploy a model, click the Configure and Start button. A new screen providing options for configuring the behavior alert will appear. The full configuration of the behavior alerts happens in four steps: Credentials, Signals, Whitelist, and Alerts.
The credentials section allows the modeling process to have access to the data within your domain.
The signals sections are used to set a signal threshold (if applicable) and a signal risk score.
The whitelist section enables users to enter or upload CSV lists of users, devices, and domains into the use cases configuration to filter those entities from the use case.
The alerts section enables users to optionally create an alert directly on the signal if they feel it achieves a high level of fidelity for their organization.
Do not deploy all the models at once to ensure that performance does not suffer.
Credentials
Name | Description |
API Key | The API Key identifier from the Devo domain. |
API Secret | The API key secrete from the Devo Domain. |
Signals
Name | Description |
Signal Threshold | Threshold by which the behavior signal is added to the |
Signal Risk Score | Risk score given to the behavior signal that is sent back to Devo. Entity risk score is calculated based on the risk score value given. |
Table Override | The table that can be used to override the behavior signal query. The table must match specific fields in the original table used in order to function correctly. |
Whitelist
Name | Description |
Users | Displays all of the current users that are whitelisted from the current use cases. Additionally users can be entered manually in the textbox or uploaded via CSV. Users are all direct match string values.
|
Devices | Displays all of the current devices that are whitelisted from the current use cases. Additionally devices can be entered manually in the textbox or uploaded via CSV. Devices can be hostname, IP addresses, ranges of IP Addresses, and CIDR blocks.
|
Domains | Displays all of the current domains that are whitelisted from the current use cases. Additionally domains can be entered manually in the textbox or uploaded via CSV. Domains are all direct match string values.
|
User, Device, and Domain whitelists are included in each use case whether or not they are present in the use case. If the use case does not include ones of entity types then a warning message like the one below is displayed:
The upload CSV section enables users to take a CSV they have from another tool or from lookups within Devo and upload them. The upload section provides a couple of tools to make working CSVs easier. The CSV can be dropped in and previewed within the screen. If the right column is not selected then the user can utilize the “Values Column” drop down to select the correct column to be added to the whitelist. Only one column can be selected at a time, but multiple uploads can be used to add multiple columns from the same CSV. The user can also specify whether the CSV has a header row or not, if specified the first row in the CSV file will be ignored when adding it to the whitelist. The last option is to add or replace the existing whitelist with the contents that are being uploaded, if add is selected then all the values will be appended to the whitelist, if replace is selected the entire whitelist will be overwritten by the uploaded values.
Alerts
Name | Description |
Yes, trigger an alert | Select whether to trigger an alert when a signal is created for SOC analysts to triage. |
Alert Threshold | The threshold for signal that causes the alert to fire and be triaged by SOC analysts. (Not always present) |
Alert Priority | The priority of the alert that’s set on a scale of 1 - Informational through 5 - Critical. |
Apply Whitelisting | Add the SecOpsGWL whitelist lookup to the alert that is created such globally whitelisted entities will not trigger behavior signal alerts. |
Working with models
Once a behavior model has been started, it begins a learning period of 30 days. 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. 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, it can be paused. Once it is paused, it can be resumed or stopped. Both pausing & stopping will prevent the model from generating more signals, but pausing a model will preserve the model’s configuration and its learned data. Thus the model will not require another 30-day learning period when it is subsequently resumed.
In contrast, stopping a model will clear the model’s configuration settings and delete all of the data that the model has learned since it was started. Unlike pausing and resuming a model, stopping and restarting a model will require a new 30-day learning period before the model can generate signals again. For this reason, stopping a model is not recommended in most cases.
SecOps Alerts Risk Score
As seen in the image above, all SecOps alerts enabled in your domain will show up in the Behavior Analytics App, in the SecOps Alerts Risk Score tab. Anytime these alerts are set off, they will be correlated to the associated entity. You can tune the risk score of a specific SecOps alert (if you want to set a risk score of 55 for the SecOpsLoginFailAttempts alert, for example).
To do this, go to the action menu to the very right of the alert name to find the Edit option, where you can set a risk score for the specific SecOps alert. Once the risk score is added to the SecOps alert, the alert’s contribution to the risk score of an entity will increase. If you wish to remove the risk score, there is also a Remove Risk Score option in the action menu.