| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Introduction
The content manager is where the behavioral models can be deployed. To get to the content manager, click the Content Manager button in the far right of the application. Once you open the content manager, a list of all models that can be deployed are displayed. By default, there are 10 models default per page and you can toggle between the different pages to find more models.
There are three columns displayed for each model: behavior Behavior Analytics Use Case (the name of the model), Description, table Required Table (the required Devo table for deploying the model), and status (enabled / disabled). If a model is not enabled, then it must be turned on in order to start running.
In order to deploy a model, click the Configure and Enable button. A new screen providing options for configuring the behavior alert will appear. Historic Time Period, Risk Score, and Alert Priority are shown by default. Set the time period you would like the model to track against, the minimum risk threshold for alerting, and the minimum alert priority you’d like to see for the alerts. In addition, there is an advanced functionality option that allows you to override a table. This allows you to deploy the model on a different table if the naming configuration within your org is different than default. If using the table override, make sure that the field names and types in your table match those of the original Devo table 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), a signal risk score, and set a custom table as an advanced option (not recommended unless you consult with Devo support first). 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.
If you stop a model there is a disable option that allows you to pause the model.
| Note |
|---|
Do not deploy all the models at once to ensure that performance does not suffer. |
Deploying
...
behavior alerts
...
The Credentials section contains the following parameters:
Name | Description |
API Key | The API Key identifier from the Devo domain. |
API Secret | The API key secrete from the Devo Domain. |
...
The Signals section contains the following parameters:
Name | Description |
Signal Threshold | Threshold by which the behavior signal is added to the entity.behavior.signal.events table. Signals above the threshold are counted in entity risk scores. |
Create Alerts?
Select when an alert is created for the behavior signal for SOC analysts to triage.
Final outcome alerting threshold
Threshold for the behavior signal alert that causes the alert to fire and be triaged by SOC analysts.
Alert Priority
The priority of the alert that’s set on a scale of 1 - Informational through 5 - Critical.
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. |
Advanced Configurations | Configuration options to only be used under special circumstances and Devo table configurations. Contact support to see if these options make sense. |
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. |
...
The Whitelist section contains the following sections:
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. Example users: David Dark |
Content Manager SecOps Alerts:
...
Ddark | |
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. Example hostname: MacBookPro_0002 Example IP Address Entries: 174.1.54.54 Example IP Address Range: 173.1.54.100-173.1.54.130 Example CIDR Block: 172.16.14.128/25 |
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. Example domain: poc.devo.com |
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.
...
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. |
Content manager SecOps alerts
...
As seen in the image above, all SecOps alerts enabled in your domain will show up in the Behavior Analytics App. Any time 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).
...