This reference article details the specifics of creating a behavior model to detect unusual behavior of users. Creating a behavior model involves three stages:
- Defining the model attributes – UDM fields – the model will train on
- Selecting the model type and
- Defining the data aggregation type and alerting condition
Single-Tenant Model Creation and Publishing
To create a behavior model at this level, refer to Creating a Model section.
Multi-Tenant Model Creation and Publishing
In a multi-tenant hierarchy, models can be created and published at various levels, including the domain, organization, or tenant levels.
Domain Level publishing:
At the Domain level, you can create a model and associate it with content packs to publish to child accounts (organizations and tenants). Models are only published to child accounts when they are linked to a content pack. For example, if the content pack "xyz" is associated with the "abc" organization, the model will be published only to the "abc" organization and its tenant accounts, and then to BigQuery.
To create a behavior model at the domain level, refer to Creating a Model section. The models created at this level are published to the organization and its tenants, provided they are selected in the content packs associated with the model.
Organizational Level publishing:
At the Organizational level, you can create a model and associate it with a content pack for publication to child accounts. You can also view models published from the parent account (Domain level). However, models published from the parent account cannot be edited at this level. If you create a model at this level and associate it with a content pack, the model will be published to the tenant accounts selected in the content pack and then to Bigquery.
To create a behavior model at the organization level, refer to Creating a Model section.
If the models are published at the domain level, you can only view the model details and the associated packs. The packs will display the tenant accounts to which the model has been published.
Tenant Level publishing:
At the Tenant level, you can create a model and associate it with a content pack to publish to child accounts. You can also view models published from the parent account (Domain or Organizational levels). Models inherited from parent accounts cannot be edited at this level. If a model is created at this level and associated with a content pack, it will be published to Bigquery to create the model in the Bigquery table. Once created, the status of the model changes to Published.
To create a behavior model at the tenant level, refer to Creating a Model section.
If the models are published from the domain level to child accounts, you can only view the model details but cannot edit them. Clicking the model will display the behavior trends.
Publishing Summary
Hierarchy Level | Model Creation | Linking to Content Packs and Publish | Publishing Destination | View Inherited Models | Editable Inherited Models |
Domain | Yes | Yes | Organizations, Tenants, Chronicle | N/A | N/A |
Organization | Yes | Yes | Tenant Accounts, Chronicle | Yes | No |
Tenant | Yes | Yes | Chronicle | Yes | No |
User Permissions
Users with the following roles can create, view, edit, and delete the behavior models:
- Owner (Create and Publish models)
- Global Admin (Create and Publish models)
- A user with Manager role (Create and view models)
- Configuration Manager (Create and Publish models)
Creating a Model
- Navigate to Behavior Analytics under Security from the left menu, click Create Behavior Model.
A model creation page opens.
Note: To use an existing model with slight changes, duplicate the model and make the necessary adjustments. To do this, select the model you want to copy and click Duplicate Model.
2. Provide a model name and description.
Model Dimensions
3. Click Add UDM Field under the Model Dimensions section. Now, select UDM fields. This opens the Select UDM fields side panel where you can view the list all the UDM fields.
4. On the Select UDM Fields side panel, you can search for the desired UDM field or browse through the UDM structure on the left to find the required field. Once you find it, add it to your behavior model, as the data in these fields will be used to train the model. This data is fetched from the UDM events table. The model will learn from the data in this field and any other fields you select.
-
Data sources
A model can be created on any of the default fields that have been created in UDM. -
Cardinality and model efficacy
While creating a behavior profile, it is important to keep track of cardinality, which means the unique combination of rows for the selected UDM fields. A behavior model with a high number of UDM fields will result in high cardinality. This will affect a model’s performance and efficacy – true positivity.
However, a limit of 5 is set on the number of UDM fields a company can train the model on.
Model filters
Model Filters are the conditions that enable you to define the set of data that the model should train on.
Construct a conditional expression by selecting a field and operator from the drop-down lists. For the value, select a value from the drop-down list or enter it manually, depending on the field type. The condition is used to determine the records to which the rule will apply.
A condition expression can consist of several phrases, joined by an And or OR. For each phrase, select a field, operator, and value. Click the + button to add an additional row. Use the parentheses and And/Or options to join the phrases together to form a conditional expression.
Turning on case insensitive for the values defined as conditions, allows you to search and find the models based on the values irrespective of their character cases.
For example, the product event type ENDS WITH REFERENCE LIST ase_typosquatted_domain_netenrich_com and turned on case insensitive toggle. This means that if you search the model based on the value, either upper case or lower case, given next to the product event type, the model will be retrieved in the behavior analytics listing page irrespective of their character cases.
The case insensitive toggle is enabled for the following operators while defining the model filters:
- STARTS_WITH
- ENDS_WITH
- CONTAINS_SUBSTR
- REGEXP_CONTAINS
- EQUALS
- IN
- NOT IN
- IN REFERENCE LIST
- NOT IN REFERENCE LIST
- STARTS WITH REFERENCE LIST
- ENDS WITH REFERENCE LIST
- CONTAINS REFERENCE LIST
5. Do one of the following:
- Select the check box corresponding to Match All to receive all signals. (or)
- Clear the Match all check box to enable add conditions. Once enabled:
- Click +Add Condition or +Add Group
- Select an attribute, operator (Equals or in) from the drop-down list and enter their respective value.
- Click And (or) Or conditions. For example, if you set the key to
principal.domain.name
, the operator to AND, and the value towww.abc.com
, the model will be trained using only the signal data that meet this specific condition.
- Applying model filters is optional. If no filters are applied, the model will be trained on data from the past 60 days
Selecting the model type
6. Select the behavior model appropriate to your use case. Supported are four behavior models:
- Deviation in Count
- Deviation in Volume
- Enumeration
- Rare behavior
Defining the data aggregation and alerting condition
The behavior analytic models support data completeness to ensure that the predictions are accurate, which enhances the decision-making potential of an enterprise.
7. To train a behavior model, Resolution Intelligence Cloud aggregates the past 60 days of data, either hourly, daily, weekly, hour of the day, or day of the week.
-
- Hourly scans the data for each hour
- Daily looks at the past 60 days of data to baseline a daily behavior
- Weekly aggregates a week's activity for the last four weeks to profile what is a normal weekly behavior
- Day of the week profiles behavior for each day of the week – Monday, Tuesday, and so on – and compares a day’s behavior against the behavior of the same day of the week in the past
- Hour of the day aggregates activity hourly to train the behavior model for every hour -- 9 to 10, 10 to 11, and so on
8. Choose any one of the conditions to compute deviation from baseline
-
- Each combination of dimensional values (ex: entity behavior) will be compared with its baseline to identify deviation: Let's compare your model against the past models created by you.
- Each combination of dimensional values (ex: entity behavior) will be compared with the baseline of its peer group: Let's compare your model against the past models created by your peers.
Abnormality score
9. To define alerting conditions on the model, specify the degree of deviation from the baseline that you consider to be anomalous. For example, a value of 0.5 implies a 0.5 standard deviation from the learned behavior.
Defining an alerting condition like this allows you to monitor and tune the model for the right deviation that requires your attention.
-
- Higher than baseline / Lower than baseline allows you to track deviations in either direction—above, below, or both. For example, setting a standard deviation of 0.5 with both above and below deviations enabled would filter signals for any deviation between -0.5 and 0.5 from the baseline among a large number of signals. Note that the score cannot be below 0.05.
- Select the check box corresponding to the Generate a signal when the abnormality condition is met if you would like to define the confidence level of a signal.
- Set minimum confidence level for signals enables you to define how confident the incoming signal is that it carries an abnormality. It generally ranges from 0 to 1.
- Check box next to Apply grouping on selected dimensions to group the generated signals on the selected UDM fields while configuring a behavior model. This grouping is allowed for only one dimension if you have selected more than one UDM field.
10. Add Metadata tags to categorize the signals:
Metadata field |
Description |
Tactics |
Represent the "why" of an ATT&CK technique or sub-technique. Refer to this article for more information. |
Vulnerability | A weakness, flaw, or other shortcoming in a system (infrastructure, database, or software), but it can also exist in a process, a set of controls, or simply the way that something has been implemented or deployed. |
Confidence | Denotes the percentage of probability that a signal carries risk or not |
Technique |
Represents 'how' an adversary achieves a tactical goal by performing an action. Refer to this article for more information. |
Severity |
Defines the severity of a model. Allowed values are High, Medium, and Low |
Data Source | The location where data that is being used originates from |
Product/Vendor |
The type of vendor to whom this rule applies |
Tool |
A type of tool to which a model belongs |
Logsource Type |
A type of source where logs originates from |
Threat Actor |
An entity which causes a threat in the IT infrastructure |
Custom |
A special modification of an existing tag |
False Positive Scenario |
For every behavior, there are a few scenarios in which the detection would be legitimate. So we would keep those details here and recommend to the user that they baseline the expected behavior using reference lists. |
11. Click Send for Review to submit the model for review. To save the model as a draft without sending it for review, use the Save as Draft option. This allows you to make changes and submit it for review later.
12. Click Approve or send the model to request changes. Clicking Approve will display a dialog box. Only the user with the publisher role can approve models.
13. Click Approve. This changes the status from Under Review to Approved.
You can now view the content packs. Models can only be published to Chronicle when they are associated with content packs.
14. Click Associate Packs. This opens the side panel where you can view the list of content packs available for the tenant.
15. Select the pack with which you want to associate the model.
16. Click Associate & Publish to publish the pack associated with the models to Chronicle. You can also click Associate to link the model and publish it later. This only changes the status to Ready to Publish. Until the model is published, you can keep adding the packs to which you want to associate the model.
Once published, the model's status changes to Published after being sent to Bigquery. It is now available and can be found in the generated list of models
Comments
0 comments
Please sign in to leave a comment.