What I will do is:
1. In event view, do a filter on normalisation = malware, event subtype != block, and threat_handled != yes; and see if you can see any events in normal event view. If there is definitely events that fit those criteria,
2. Test your correlation rule by introducing one condition at a time, and see at which step it stops correlating
also check your grouping by option and other logical settings. Looks like #2 should work and it's the most clean one.
That's the thing though.
I've done this. It's the first thing I do. If I can find it in a view I should be able to write a correlated rule on this based on the criteria seen in the fields provided. Also for #2 I based my previous rules on pre-existing templates (that "clean look") and they simply do not fire.
This past weekend I had a rule for looking for events "Normalization: Malware, Subtype "Pass", Threat Handled: "No". Well one of those events came through and this rule didn't fire. It's extremely frustrating...
Regarding the "grouping by" option and other logical settings....those are blank. Should I have something in them?
I just went into the viewer:
Event Subtype: ! Block
Threat Handled: ! Yes
There's one event there....
NONE of the four templates fired. What gives?
I think the issue is the "group by". I should set the rule for "Normalization Rule".
Just for the hell of it...
In terms of group by. Does the arrangement matter? Normalization before Event Sub-type for instance?
Also should I just do normalization? I'm going basic just to understand how it works. If and when I add "Threat_Handled" do I want to put that into group by as well?
Just put the threat_handled back into the logic after event type. Group by go with source IP.
Is the malware event coming from ePO or any other data source? If so, you can also bind it using device IN "data source", but not required.
The malware events are coming from the ACE and EPO.
Why source IP?
I'm going to add back in Threat Handled
For Group By use source IP.