ArcSight Rules - ESM is not meant to be broken
One of the most important content types you will create in ArcSight ESM will be rules. In this post, I will try to offer some guidance based on the past seven years I've been exposed to ESM. The heart of the correlation engine is driven by rules. The decisions your rules make will ultimately drive the decisions and workflow in your detection and response program. You can get a false sense of security or wind up trying to drink water from a fire hose if you're not careful.
I have overwhelmed myself a few times working with rules. At other times, I've waited and wondered why a rule was not firing only to find out I forgot a key condition or aggregation field. Hopefully, you will further along after reading this post.
With rules there are four key areas to pay attention to:
1. Conditions * Order your condition filter from most specific to least specific condition. This will allow ESM to quickly eliminate events that do not match. * Use = instead of !=. This also helps ESM eliminate events quicker. * When possible use exact case. This will reduce the resources the rule needs. * Using indexed fields reduces load on the database server. 2. Aggregation * Keep timeframe to less than five minutes. Partial matches have be kept in memory. * For timeframes > than five minutes use Active List to eliminate partial matches. * Any field used in the rule condition must be added on the Aggregation tab or the rule will never fire. This has bitten me many times. 3. Actions * Use notification templates to help make email alerts more readable. The easiest way to do this is using a combination of the "Set event field" action plus some magic on the manager in $ARCSIGHT_HOME/config. Details will come in a later blog post. * Actions also are where you would add/remove things from Active Lists to help with throttling or prioritization. 4. Throttling * This is a term I use. It is using an Active List in the Condition statement of a rule to keep the rule from firing all the time. Essentially, the first time your rule fires, it can add values to an Active List. The condition would include a check of that Active List. If the value exists, then the condition of the rule would not be met. This eliminates what I call "The boy cried Wolf" syndrome. We've all had monitoring systems that email mail bomb us when there is a problem in the network. This use of Throttling unleashes the power of ArcSight ESM to make your monitoring much more intelligent.
ArcSight ESM rules are a very powerful and flexible resource if you use them well. Things like this are what turn a SIEM into a way to augment your existing headcount. It frees your people up to work on higher quality problems instead of wading through tons of false positives. I hope this overview has been helpful and will go into detail on some of these in later posts.
How do you use rules in ArcSight (or another SIEM) to make your team more effective?