LinkedIn
Twitter
Hi,
My question is pretty straight forward. I am maintaining a list of blacklisted process in my organization to a reference list (Regex) in Chronicle. However, I am not sure on how to make it case insensitive in the UDM search query and/or on the rule editor. I tried to use the nocase keyword to the search parameter that throws an error, which I assume would be same in the rule editor.
I also tired to add the nocase keyword inside each line of the list as well as (?i) before the words within list. None of the method I tried so far worked
Is there any other alternatives that could help me achieve the use case?
Regards,
Srijan Kafle
Solved
1 ACCEPTED SOLUTION
At the moment there are going to be slightly different processes for search and rules. This is something that I believe will be changing throughout 2024 but it is a little soon to discuss.
Let's start with search since that was the example you first mentioned.
metadata.event_type = "USER_RESOURCE_UPDATE_PERMISSIONS"
metadata.product_name = "Office 365"
metadata.product_event_type = "Add delegated permission grant."
metadata.vendor_name = "Microsoft"
security_result.action = "ALLOW"
target.resource.attribute.labels["delegated_permission_grant_scope_new"] in regex %msgraph_watchlist_permissions_regexThis is my search, i happen to be looking for delegated grants in O365 and the regex list contains the list of the permissions that could be granted that I want to flag on.
securityIncident.ReadWrite.All //Read and write to incidents
securityAlert.ReadWrite.All //Read and write to alerts
securityEvents.ReadWrite.All // Read and update your organization's security events
If my list looks like this, it won't trigger because the event has values in the format of lowercase security where the event is going to be capitalized. And as you mentioned, we can't stick a nocase modifier to the end of the search string.
(?i)securityIncident.ReadWrite.All //Read and write to incidents
(?i)securityAlert.ReadWrite.All //Read and write to alerts
(?i)securityEvents.ReadWrite.All //Read and update your organization's security events
We could resolve this through placing the case insensitivity flag inside the regex list, essentially saying we don't care how the pattern matches from a case sensitivity perspective and when we do this, here is what we get back.
When it comes to rules, we have a few more options available to us because we have the convert to upper/lower functions in addition to the regex case insensitivity tools.
Option 1 - Use the same capability as the example in search (?i) in the regex list for each entry
Option 2 - Remove the (?i) case insensitivity flag from the individual lines in the regex list and just append nocase to the end of the rule criteria (this is an example where we want to better align search and rules)
Option 3 - Use the conversion functions (upper or lower). This does make an assumption that the list is all upper or all lower.
securityincident.readwrite.all //Read and write to incidents
securityalert.readwrite.all //Read and write to alerts
securityevents.readwrite.all // Read and update your organization's security events
Here is a link to a blog I wrote on the regex list functionality coupled with functions.
https://chronicle.security/blog/posts/new-to-chronicle-regular-expressions-and-reference-lists/
The examples in the blog go a little deep because they cover a number of regex functions coupled with base64_decode and the ability to nest these functions, but hopefully this provides a few methods to try and move forward with.
At the moment there are going to be slightly different processes for search and rules. This is something that I believe will be changing throughout 2024 but it is a little soon to discuss.
Let's start with search since that was the example you first mentioned.
metadata.event_type = "USER_RESOURCE_UPDATE_PERMISSIONS"
metadata.product_name = "Office 365"
metadata.product_event_type = "Add delegated permission grant."
metadata.vendor_name = "Microsoft"
security_result.action = "ALLOW"
target.resource.attribute.labels["delegated_permission_grant_scope_new"] in regex %msgraph_watchlist_permissions_regexThis is my search, i happen to be looking for delegated grants in O365 and the regex list contains the list of the permissions that could be granted that I want to flag on.
securityIncident.ReadWrite.All //Read and write to incidents
securityAlert.ReadWrite.All //Read and write to alerts
securityEvents.ReadWrite.All // Read and update your organization's security events
If my list looks like this, it won't trigger because the event has values in the format of lowercase security where the event is going to be capitalized. And as you mentioned, we can't stick a nocase modifier to the end of the search string.
(?i)securityIncident.ReadWrite.All //Read and write to incidents
(?i)securityAlert.ReadWrite.All //Read and write to alerts
(?i)securityEvents.ReadWrite.All //Read and update your organization's security events
We could resolve this through placing the case insensitivity flag inside the regex list, essentially saying we don't care how the pattern matches from a case sensitivity perspective and when we do this, here is what we get back.
When it comes to rules, we have a few more options available to us because we have the convert to upper/lower functions in addition to the regex case insensitivity tools.
Option 1 - Use the same capability as the example in search (?i) in the regex list for each entry
Option 2 - Remove the (?i) case insensitivity flag from the individual lines in the regex list and just append nocase to the end of the rule criteria (this is an example where we want to better align search and rules)
Option 3 - Use the conversion functions (upper or lower). This does make an assumption that the list is all upper or all lower.
securityincident.readwrite.all //Read and write to incidents
securityalert.readwrite.all //Read and write to alerts
securityevents.readwrite.all // Read and update your organization's security events
Here is a link to a blog I wrote on the regex list functionality coupled with functions.
https://chronicle.security/blog/posts/new-to-chronicle-regular-expressions-and-reference-lists/
The examples in the blog go a little deep because they cover a number of regex functions coupled with base64_decode and the ability to nest these functions, but hopefully this provides a few methods to try and move forward with.
