nw0xxxxx APP Rule names on the decoder (was this in the hunting guide named)
Wondering if anyone has the naming convention for the nwxxxxxx app rules (screenshot) that are part of the decoder "apprule" process. These map to an "Alert" meta key in our environment. Seems like these might be a legacy pull in...
anyone else run into this? I know you can go through each one and put a custom name, but with like 100 of these, that could take a bit to go through and plus review the log to see if the naming makes sense. Did know if RSA had this in the hunting guide, I recall them discussing several meta keys there. Anyone have this top of mind?
The nwXXXX rule naming is historical, but the rules are still valid. These rules write to the "alert.id" key which is used by the "investigate" feed (historically it was used in the "alert.info", "alert.suspicious", and "alert.warning " feeds to populate the risk.info, risk.suspicious, risk.warning keys along with the threat.source, thread,category and threat.description and alert keyts"). So they are used to populate multiple other keys from this one piece of information, ( One to Many ).
The numeric part of the name denoted different "categories" of rules, and in the past were meant to be placed in the ruleset in numeric order from smallest to largest, as the rules are processed from top to bottom order. The reason for this was in older versions of NetWitness there were rules that referenced other NW rule names, so had to be in order to work properly (i.e. if rule NW45678 had a where clause that included alert.id='NW12345' but was placed BEFORE the rule NW12345, then it would NEVER trigger) .
Also at times I see people writing their own rules and sending them to alert.id, this should NOT be done, as the alert.id field is really ONLY used to trigger the "investigation" feed
Eventually these rules will be replaced with a more descriptive name, but that will take coordination with customers to change their "live" rules to the new names when it happens (you'll notice that newer app rules have actual descriptive names)
Example for rule
nw60005 service = 53 && udp.dstport = l-52,54-u && streams =2 (service is DNS, but UDP destination port is not 53, and traffic contains request & response packet streams)
so this writes "nw60005" to the alert.id key, triggering the investigation feed to run which has a matching index line for nw60005, and writes the following metakeys
* inv.category = 'operations'
* inv.context = 'event analysis'
* inv.contex t= 'protocol analysis'
* feed.name = 'investigation'
* analysis.service = 'dns over non-standard port'
* attack.tactic = 'command and control'
* attack.technique = "uncommonly used port"
I was wondering if they were remnants of the legacy deployments. I think those might have got loaded right when we went to 11.0....I have reviewed a few of them and I think they can be useful and renamed.
Thank you for the extra comment on DONT use alert.id for meta creation, we dont, we typically will use the "Alert" function for app rule creation and data truncating. But I had no knowledge of this.
Question: In 11.5.3 do the app rules still work top - down?
Thank you John!!!
I see what you are saying is they are a placeholder and going to the next meta. I will share this with my team as well.
So, thinking this through. Alert.id should not be in any of the search meta criteria is what you are saying so pivoting off them is not the intended use.