1 of 1 people found this helpful
The big use case for the infer alert action is to escalate normal activity to abnormal activity without generating email alerts and other actions.
For example, the OOTB rules try to identify things like "excessive logon failures" and infer suspicious activity. You could then focus on suspicious activity, rather than focusing on all the logon failures (or building rules specifically for logon failures).
PortScans are a good example - you get TCP traffic all the time, but when you see a certain quantity coming from a single IP to many ports on a single IP, that's scan behavior. Some devices (IDSes for example) will trigger a PortScan event directly and we have a PortScan event type in our taxonomy, but firewalls often just tell you everything (deny, deny, deny, deny, allow, deny, deny...) and we're able to "infer" that a PortScan has occurred based on the pattern.
A related action is the Create Incident action - which is a way to filter semi-high priority or actionable events without receiving email on everything (or at the same time, so you know what was sent) making it easier to report on and audit just important stuff. Those tend to be business specific, but we have some OOTB rules that infer incidents as examples.
Interesting concepts. I am glad you mentioned the Incident Action because I had never really noticed that before. Now that you mentioned it I was able to go check it out and see how it correlates to those alerts in the taxonomy.
LEM has so many clever concepts that are not immediately obvious. I would love to sit in a room with you and just have a brain dump of LEM top to bottom to be able to understand all the thought and concepts behind the design of the product to be able to leverage it better.