There are three things to note.
When performing your UDM search, you are adding a nocase for 'target.resoruce.attribute.labels.value = "auth" and target.resoruce.attribute.labels.value = "authorize"', whilst you aren't for your Rule logic.
The second thing to note is the time frame you're searching on, is this consistent for both the UDM search and the retro hunt being run with your rule logic?
The final thing to note, is if you refer to section 7 of the following document, this explains how to utilise key-value pairs in searching.
"7. You can also use UDM Search to search for specific key-value pairs in the Additional and Label fields.
The Additional and Label fields are used as a customizable 'catch all' for event data that does not fit into a standard UDM field. Additional fields may contain multiple key-value pairs. Label fields may only contain a single key-value pair. However, each instance of the field contains only a single key and single value. The key needs to go inside the brackets and the value must be on the right hand side.
The following examples show how to search for events containing specified key-value pairs:
additional.fields["pod_name"] = "kube-scheduler"
metadata.ingestion_labels["MetadataKeyDeletion"] = "startup-script"
Source: https://cloud.google.com/chronicle/docs/investigation/udm-search
There are three things to note.
When performing your UDM search, you are adding a nocase for 'target.resoruce.attribute.labels.value = "auth" and target.resoruce.attribute.labels.value = "authorize"', whilst you aren't for your Rule logic.
The second thing to note is the time frame you're searching on, is this consistent for both the UDM search and the retro hunt being run with your rule logic?
The final thing to note, is if you refer to section 7 of the following document, this explains how to utilise key-value pairs in searching.
"7. You can also use UDM Search to search for specific key-value pairs in the Additional and Label fields.
The Additional and Label fields are used as a customizable 'catch all' for event data that does not fit into a standard UDM field. Additional fields may contain multiple key-value pairs. Label fields may only contain a single key-value pair. However, each instance of the field contains only a single key and single value. The key needs to go inside the brackets and the value must be on the right hand side.
The following examples show how to search for events containing specified key-value pairs:
additional.fields["pod_name"] = "kube-scheduler"
metadata.ingestion_labels["MetadataKeyDeletion"] = "startup-script"
Source: https://cloud.google.com/chronicle/docs/investigation/udm-search
Screenshot updated, section 7 your talking i know that approach its not dynamic not useful . My only question is its working in UDM search and not in YARA-L.
I did a little bit of testing on this today and at this time, I believe this is one of those instances where the search interface is a little more flexible to handle variability in key names. The rules engine has always had strict named key checking. I will mention that the label side in the rule engine could contain a list or a regular expression, but in the rules engine, the label is expected to have the key in quotes inside the bracket as @AymanC mentioned above.
$e.security_result.rule_labels["rule_details_ip_port_info_ip_protocol"] = /TCP|UDP/
$e.security_result.rule_labels["rule_details_ip_port_info_port_range"] in %acceptable_ports
I did a little bit of testing on this today and at this time, I believe this is one of those instances where the search interface is a little more flexible to handle variability in key names. The rules engine has always had strict named key checking. I will mention that the label side in the rule engine could contain a list or a regular expression, but in the rules engine, the label is expected to have the key in quotes inside the bracket as @AymanC mentioned above.
$e.security_result.rule_labels["rule_details_ip_port_info_ip_protocol"] = /TCP|UDP/
$e.security_result.rule_labels["rule_details_ip_port_info_port_range"] in %acceptable_ports
Hi @jstoner @AymanC
I am taking this approach beacuse in AWS_CLOUDTRAIL logs i have observed this dynamic value in Key field and client wants a dynamic approach. SO, how to handle this type of scenearios. Then i came across this stituation when trying to solve this.
Hi @jstoner @AymanC
I am taking this approach beacuse in AWS_CLOUDTRAIL logs i have observed this dynamic value in Key field and client wants a dynamic approach. SO, how to handle this type of scenearios. Then i came across this stituation when trying to solve this.
Since this appears to be a repeated field, you can use the keyword 'any' to satisfy your requirement, please see the source below.
any
If any element of the repeated field satisfies the condition, the event as a whole satisfies the condition.
event_original satisfies any $e.principal.ip = "192.0.2.1".
event_original fails any $e.repeated_field.field_a = "9.9.9.9.
Since this appears to be a repeated field, you can use the keyword 'any' to satisfy your requirement, please see the source below.
any
If any element of the repeated field satisfies the condition, the event as a whole satisfies the condition.
event_original satisfies any $e.principal.ip = "192.0.2.1".
event_original fails any $e.repeated_field.field_a = "9.9.9.9.
He's asking about repeated values not fields. And we can't use "any" with repeated value as they are mapped values.
