Recently CS_EDR parser is updated. There were many changes in UDM field mapping. Old field vs new field. Let’s assume that if there are 200 - 500 rules developed for Endpoint category based on CS_EDR logs. How can we identify which rules got impacted and what will be the new rule logic as per the new parser configuration
Unfortunately there is no easy direct answer I could think of, but I will list my thought process. It will be much easier if you have access to a enterprise-grade/local offline LLM recently trained (so that it could have the UDM and parser documentations and knowledge embedded in its corpus) ;
Step A: Identify the fields referenced in your rules and prioritize the rules migration
1. Loop through the rules using regex (?:\$\w+\.(?P<UDM_field1>(about|additional|intermediary|metadata|network|observer|principal|security_result|src|target)(?:.\w+)*))
2. Alternatively loop the rules one by one through an LLM with instructions to identify the UDM field names after the variable starting with $ as a prompt/system message.
Either will generate a list of UDM fields per rule
3. Prioritize the rules using
a) Highest detection numbers in the last 2 quarters.
b) Highest number of referenced fields.
c) Rules Severity
Step B: Identify the categorical fields values referenced in your rules (Optional)
Repeat A but keep the fields value and focus on categorical fields (metadata.event_type/log_type/product_event_type , security_result.category/action/rule_type) to see what are the main values per rule.
You should be able to generate a list of important categorical fields conditions (e.g. event_type = "FILE_COPY" and log_type = "CS_EDR" are the main categorical fields values for Rule 1, so Rule 1 will be impacted by changes in this set of events only)
Step C: Differential Parser or Parser Impact Analysis
1. Use LLM/FileDiff to compare both the outdated and updated parsers code (This may work if the changes are not major or contained within specific blocks).
2. Altenratively ; Use the dashboards to identify the counts of the categorical fields altogether (e.g. metadata.event_type/log_type/product_event_type and/or security_result.category/action/rule_type | Count ) and focus on the entries with the highest frequency (e.g. event_type = “FILE_ACCESSED” has the highest count, so we need to sample some events matching this condition first), then pick some raw events per entry and use the Parser Preview in both parsers to compare the resultant UDM fileDiff or LLM (You might want to sort the UDM fields alphabetically for this).
2. Instead of looking for ALL categorical fields values, Use Step B to prioritize only the fields values referenced in your rules (e.g. no rules reference the event_type = “FILE_COPY” condition, but many rules depend on event_type = “SERVICE_START” so I can just skip “FILE_COPY” events from the comparisons)
3. Alternatively : Use a Schema differencing algorithm with the udmsearch API to identify the schema differences excluding the non-categorical fields (timestamp, files, user names, ports, hostnames, IPs and their attributes) . But this could be too complex.
You should be able to generate a list of impacted field names per categorical field value (e.g. the updated parser for “SERVICE_START” events has the user name parsed into intermediary.username field instead of target.username).
Step D: Migrate the prioritized Rules
Loop through the rules-list of fields of Step A against the list of impacted fields in Step C, higher number of intersections means higher updated parser impact on this rule. (e.g. Rule 1 has higher count of impacted field names, then this is one of the highly impacted rules)
Add this information to the rules priority list in Step A to consider which rules will be prioritized for migration.
From the fields intersection list ;
1. Start with the prioritized rules identified in Step A , rename the existing fields into the new field names.
2. If the rule has connections to data tables/reference lists then they need to be backed up to avoid any possibility of data corruption once the rule is modified.
3. Have some sample test events/activities ready to be executed and ingested to test the new rule.
Sorry for the long answer, but that is all I could think of.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.