NetIQ Sentinel Correlation Server
A badly written correlation rule or too many rules deployed to one correlation engine can cause performance problems on your Sentinel system. It is very possible this type of scenario could render Sentinel unusable and result in data loss.
Best practices when creating correlation rules
1. Try not to create correlation rules that have filters that call for the message field to match a regular expression value. Using a regex operator against the message field can be very costly.2. If you are creating multiple complex correlation rules, spread out the deployment so that the health of Sentinel can be monitored along the way.3. Test new correlation rules before deployment.4. Only create correlation rules that are useful and relevent.5. The rule should not generate undue noise. Think about how many correlated events you can reasonable respond to during the course of your daily activities.6. The correlation rule/alert should clearly match a security condition, either a known security problem or a potential policy violation.7. The correlation rules are not simply to populate report data, but each and every one of these rules are designed to present an alert to the user. As such, rules will need to meet a certain bar in order to be considered useful/relevant in the Sentinel System.8. If you have to use regular expression, write them in a way that avoids unnecessary backtracking
9. Try to make your rules generally applicable by filtering on taxonomy rather than event source specific data.10. Events that donât match any correlation rule (or SI dashboard) filter can be routed to âEvent store onlyâCorrelation health checks1. under the individual rule there is a Rule Health Statistics view.2. under sentinel web interface | storage | health there are several correlation and alert health information entries.3. In the /var/opt/novell/sentinel/log/server0 logs performance snapshot section there are some utilization and queue entries that can be monitored.