When an out of the box rule doesn't match your use case don't hesitate to modify it or make one that does. Some shops turn off all out of the box content and only enable/create rules that map to their use cases. There are a couple of approaches depending upon your goal. If you want to be notified of particular events, just create a Field Match alarm; it includes Boolean logic so it can serve in place of many simple correlation rules. It also fires much faster since the alarm fires when the log hits the Receiver.
If you are more concerned about the Normalization categories, for reporting or to trigger some other rule, you could create a rule for each category that you were interested in which included the correct Normalization
I would look at the list of categories and depending upon how granular I wanted to be I would either create a rule for each category or group of categories I was interested in.
or if you're feeling adventurous, you could copy the ProxySG parsing rule to a custom rule and hard code the category and desired normalization for each one that you want to break out so it would normalize the way that you want via parsing instead of correlation.
Andy -- I tried to take the 'Copy the ProxySG parsing rule' approach because I want the event to be normalized during parsing. Ultimately I want to build some use cases that would require some base lining and deviation.
I want to normalize the following events as they are coming into the receiver based on the category of the BlueCoat event:
<Malware Monitoring Use Case>
Malicious Outbound Data/Botnets
<Corporate Acceptable Use Policy Violation/Legal Liability Use Case>
<Potentially Malicious Insider Use Case>
Remote Access Tools
I copy/pasted the ProxySG Access Log parser (which we have modified to include all of the useful fields left out of the OOTB parser) and simply added content-strings for the following categories. These have been in place for a week w/ no "matches" or events parsed from those parsers. I can query ESM Category = Remote Access Tools and see it is not parsing w/ the expected 'Remote Access Tools' parser. Not sure what the issue is...
regex in 'Parsing' tab confirmed 'Good'.
1) Are actions set appropriately?
2) If I move from the Data source view to the 'Default Policy' should these parsers be enabled or disabled? (They're currently enabled while the OOTB Proxy parsers are disabled.)
I like your approach. Using the Content Strings is a good idea. I think where you could be getting stuck is that there are auto-learned rules that need to be delete before your custom rules are used to create new auto-learned rules.
You can delete auto-learned rules under Data Source below ASP on the left tree. Delete and reroll your policy for your BCs.