Detection Rules are defined as conditional logic applied to all ingested logs. Resolution Intelligence® generates a security signal when a single case is matched over a given period of time that is defined in a rule.
With Chronicle detection, you can use more advanced rules, create your own or customize the rules to detect the threats in your IT infrastructure. The rules engine incorporates widely used detection languages globally, YARA - L. Resolution Intelligence enables you to tag rules based on MITRE tactics & techniques, log source type, rule confidence, and severity. For example, configuring a rule that detects an unusual login from different locations at unusual times (12 AM to 3 AM local time).
Detection rules allow you to define the compliance and regulatory policies of your organization to scale your business growth at the enterprise level and improve your relationships with other security-compliant organizations.
Configuring Detection Rules
User Permissions required
A Creator from these categories such as Domain, Organization, and Tenant can create rules.
To create a Rule,
- Navigate to Configurations --> Chronicle CMS at the left navigational bar.
- Click Signal Detection Policies.
- On the Detection Rules listing page, click +Create New --> Detection Rule at the top right corner.
- From the new Rule page, enter Rule Name, and Description(Optional).
- Define the rule syntax (YARA-L) in the Rule Editor.
Sample Rule looks like below:
rule rule_1701861657314 {
// This rule matches single events. Rules can also match multiple events within
// some time window. For details about how to write a multi-event rule, see
// https://cloud.google.com/chronicle/docs/detection/yara-l-2-0-overview#single-event_versus_multi-event
meta:
// Allows for storage of arbitrary key-value pairs of rule details - who
// wrote it, what it detects on, version control, etc.
// The "author" and "severity" fields are special, as they are used as
// columns on the rules dashboard. If you'd like to be able to sort based on
// these fields on the dashboard, make sure to add them here.
// Severity value, by convention, should be "Low", "Medium" or "High"
author = "analyst123"
description = "8:00 AM local time"
severity = "Medium"
events:
$e.metadata.event_type = "USER_CREATION"
outcome:
// For a multi-event rule an aggregation function is required
// e.g., risk_score = max(0)
// See https://cloud.google.com/chronicle/docs/detection/yara-l-2-0-overview#outcome_conditionals_example_rule
$risk_score = 0
condition:
$e
}
- Select Rule Type from the following list
- Real-time: a live instance
- Scheduled: fixed at specific time period
- Add Tags for the following fields.
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 just 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. |
Sub-technique |
A sub-technique is a more specific adversary action. For example, a technique such as Process Injection has 11 sub-techniques to cover (in more detail) the variations of how adversaries have injected code into processes. |
Malware |
A type of malign activity associated with a rule. |
Severity |
Defines the severity of a model. Allowed values are High, Medium, and Low. |
Data Source | The location where the data that is being used originates from. |
Product/Vendor |
The type of vendor to whom this rule belongs to . |
Tool |
A type of tool to which a model belongs to. |
Logsource Type |
A type of source where logs originate from. |
Threat Actor |
An entity that causes a threat to the IT infrastructure. |
Custom |
A special modification of an existing tag. |
False Positive Scenario |
For every behavior, there are few scenarios the detection would be legitimate. So we would keep those details here and recommend to the user to baseline the expected behavior using reference lists. |
Check Box left to Subject from Native Signal |
Helps you apply subject as static values for some detection rules, and for some rules that are intended to only convert native signal from devices like EDR, and antivirus where you can not apply subject as static behavior. In such cases, leverage external subject from native signal checkbox to pickup MITRE details from UDM event in chronicle while transforming the signal. |
Check Box left to Mitre from Native Signal |
Helps you apply Tactic & Techniques as static values for some detection rules, and for some rules that are intended to only convert native signals from devices like EDR, and antivirus where you can not apply tactics and techniques as static behavior. In such cases, leverage the external native MITRE checkbox to pickup MITRE details from the UDM event in chronicle while transforming the signal. |
8. Click Save at the top right corner
Once the changes are saved, Check Rule Syntax button is enabled.
9. Click Check Rule Syntax to verify the syntax of the rule created in the Rule Editor.
10. Once the rule syntax is verified successfully, Actions button will be enabled at the top right corner of screen.
11. Click Actions. A dropdown list appears.
12. From the dropdown list, click Send for Review.
The rule will be sent to Publisher for review and the rule state is moved to Under Review.
Publishing Detection Rules
User Permissions Required
A Publisher from these categories such as Domain, Organization, and Tenant can publish rules.
To publish a Rule,
- Navigate to Configurations --> Chronicle CMS at the left navigational bar.
- Click the Detection Rules tile.
- In the Detection Rules listing page, click the rule that is Under Review state.
- Verify the Rule syntax and click Actions in the top right corner of the screen.
- From the dropdown list,
-
- Click Approve if the rule syntax is appropriate. The rule will be moved to the Approved/Ready to Publish state once it is approved.
- Click Reject, if the rule is not appropriate. The rule will be sent back to the Creator for changes and moved to the Draft state.
- Click Edit, if you wish to modify any details of a rule and it will be moved to Draft state again. Click Send for Review. It will be moved to the Under Review state.
Note: Approved state is only applicable for the rules with version no# 1. The rules with version no # greater than one will be moved to the Ready to Publish state once they are approved.
Adding a Content Pack to the Detection Rule
To publish a rule, you must add at least one content pack that you have subscribed to. The publisher can add packs to any rule in an approved or published or ready-to-publish state.
To add a content pack,
- On the Detection Rules listing page, click a rule that is in the Approved state.
- Click Actions --> Add to pack.
A dialog box appears on the screen: "Please select at least one pack from the dropdown." The rule status will be changed to Ready to Publish. - Now navigate back to the Chronicle Content Management page and click the Content Packs tile.
- Click the pack to which you have added a rule. (or)
- From the Packs page, select the ready-to-publish, published, or approved rule from the dropdown menu in the Rules.
- Click Save at the top right.
- To move a rule to the Published state, you must publish the pack that you have assigned to that rule.
In addition to configuring, you can always simulate, clone, version, disable, edit, delete, find, and filter rules to manage your detection rules effectively.
Comments
0 comments
Please sign in to leave a comment.