Hello!
1. Check out these posts from John's same blog series on single event rules and multi-event rules. In the example from the multi-event blog post, note how there are three (aka multiple) different event variables: "create", "login", and "delete". Also note how those three event variables are joined together using a placeholder variable called $targetUser, and the criteria defined in the "match" section. Generally speaking when you have multiple event variables in the events section, you have a multi-event rule. Your example has just a single event variable, "event", so it is a single event rule. It does not matter how many different UDM fields are evaluated per event variable. Just think of those as filters for the event data represented by the event variable. Each event variable can have its own set of these filters.
2. The outcome section tells Chronicle what extra information to include in any detection created by this rule. Outcomes provide extra context to human analysts who are investigating these detections. In your example a risk score is computed, and other key info from the UDM events is also included. None of those values would be included in the detection if the rule-writer had not explicitly define them as outcome variables. Outcome variables are also used extensively by downstream systems like SOAR platforms, and by some advanced features in Chronicle SIEM itself.
Hello!
1. Check out these posts from John's same blog series on single event rules and multi-event rules. In the example from the multi-event blog post, note how there are three (aka multiple) different event variables: "create", "login", and "delete". Also note how those three event variables are joined together using a placeholder variable called $targetUser, and the criteria defined in the "match" section. Generally speaking when you have multiple event variables in the events section, you have a multi-event rule. Your example has just a single event variable, "event", so it is a single event rule. It does not matter how many different UDM fields are evaluated per event variable. Just think of those as filters for the event data represented by the event variable. Each event variable can have its own set of these filters.
2. The outcome section tells Chronicle what extra information to include in any detection created by this rule. Outcomes provide extra context to human analysts who are investigating these detections. In your example a risk score is computed, and other key info from the UDM events is also included. None of those values would be included in the detection if the rule-writer had not explicitly define them as outcome variables. Outcome variables are also used extensively by downstream systems like SOAR platforms, and by some advanced features in Chronicle SIEM itself.
Hi @herrald
Thank you for weighing in. I have a few follow-up queries please.
1. **Outcome variables - additional context**
The rule that i shared in my query yields in the following detections (from the blog post):
Now each of the fields in the preceding screenshot map to the outcome variables defined in the outcome section. Is this what you mean when you say:
"Outcomes provide extra context to human analysts who are investigating these detections. In your example a risk score is computed, and other key info from the UDM events is also included. None of those values would be included in the detection if the rule-writer had not explicitly define them as outcome variables."
2. **Difference between single-event and multi-event rules**
Now the same [blog post](https://chronicle.security/blog/posts/new-to-chronicle-rule-outcomes/), also shares the use of outcomes with multiple events:
```
events:
$event.metadata.event_type = "USER_LOGIN"
$event.metadata.vendor_name = "Microsoft"
$event.principal.hostname = $targetHost
$event.target.user.userid = $targetUser
$event.security_result.category = "AUTH_VIOLATION"
$event.security_result.action = "BLOCK"
match:
$targetHost over 60m
outcome:
$risk_score = max(50)
$target_user_distinct_count = count_distinct($targetUser)
$target_user_count = count($targetUser)
$target_user_distinct = array_distinct($targetUser)
$target_user = array($targetUser)
$tlp = array_distinct("amber")
condition:
#targetUser > 10 and $target_user_count > 600
```
Now the preceding example strikes to me as a single-event rule as it also uses a single event variable, `event`. So how is this an example of using outcome in a multi-event rule?
1. Yes.
2. The example you provided is a multi-event rule because it includes a match section. You can experiment by removing the match section, saving the rule, and observing that it turns to single-event. While there is only a single event variable (called "event") in the events section, the existence of the match section will always cause the rule type to be multi-event.
Thank you, @herrald.
You say: While there is only a single event variable (called "event") in the events section, the existence of the match section will always cause the rule type to be multi-event.
Why does the existence of a match section cause the rule type to be multi-event?
Thank you, @herrald.
You say: While there is only a single event variable (called "event") in the events section, the existence of the match section will always cause the rule type to be multi-event.
Why does the existence of a match section cause the rule type to be multi-event?
Why? Well just because that's how the feature works 🙂 More in the docs here.
The way I think about it is that the match section performs a "join" operation between the log events represented by the event variables. When you have a match section with only a single event variable, you are essentially joining the event data with itself.
Would visualizing about single-event and multiple-event rules in a certain way help discern the difference between the two.
If yes, what would be the correct way to visualize them. @herrald
