A SIEM or
Security Information and Event Management is only as good as its logs. People can think of logs as the fuel for the engine. Without logs (
log management), the SIEM will never be useful. Selecting the right types of logs to ingest in your SIEM is a complex undertaking.
On one hand, it is easy to say “Log it all!” but you will inevitably reach the glass ceiling of your SIEM, which will either be your licensing or you will cap the performance of the SIEM hardware.
Furthermore, each SIEM
deployment should have in place a periodic log review to make sure the logs you are ingesting are useful to your deployment. There is no need to ingest logs that aren’t useful to correlating events, as there are performance costs. SIEM licensing is also usually a number based on logs/sec.
After we decide which areas of the environment provide the most value to the SIEM, the next steps are to build rules. Rules evaluate the logs for predefined conditions.
If the conditions are true, the rule is said to “fire” and bring an alert or alarm to the security monitoring team’s attention. It is impossible for any human to evaluate the billions of logs a day a large scale SIEM deployment will ingest, so rules are a way to test these logs automatically.
When creating rules, we should first define the logic that you want to see fire. For instance, if we are evaluating for “multiple account lockouts,” we would want to define how many times an account would be locked out before raising an alarm to the security monitoring team.
When the logic of the conditions that we would like to meet has been agreed upon, it is not suggested to put this rule into production immediately. If your SIEM deployment is lucky enough to have a test environment, this should be deployed in the test environment and monitored first.
The very nature of rules is that they need to be constantly and consistently tuned. It is possible that anyone sets the threshold of the rule far too low and the rule will fire hundreds of times a second, resulting in an overwhelming amount of alarms raised to your security monitoring team.
In some SIEM products, it is possible to set a rule to “enabled” but not “alarming.”
The idea is that when someone creates a rule, there is a tuning period of at least a week. During the tuning period, changes should be made to the logic of the rule to make sure that it only fires with a high percentage of true positives.
This monitoring period is imperative. Creating a rule in production that is far too noisy will result in alarm fatigue by your security monitoring team as they will be reviewing hundreds if not thousands of false positives while overlooking the true threats to your environment.
On a quarterly basis, all the rules should be audited for their individual performance. Rules that have not fired at all should be revisited.
If the rule is not providing value, the rule’s criteria should be modified, so the logic fires on the intended threats should they exist. If the rule cannot be modified to provide value, it should be deleted to optimize on the performance of the SIEM.
Rules that fire too frequently should be evaluated on the ratio of false vs. true positive. If the rule has a very high false positive rate, the criteria should be evaluated to filter events better. The rule needs to be tuned better.
About the Author: Tyler Wall is a security fanatic. Employed as a Senior Security Engineer by day and born with a natural curiosity for anything and everything that spills over into everyday life by form of his many (mis)adventures. He holds numerous security certifications and degrees and describes himself a catalyst for positive change.
Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
