Any system information and event management (SIEM) system will require a good deal of customization out of the box before the organization deploying it will see useful data. Once set up, though, the SIEM quickly becomes an invaluable tool in the engineer's toolbox for identifying risks, trends, malicious activity, and even simple misconfigurations. But how many organizations are treating the SIEM as a static solution and simply "setting and forgetting"?
The reality is that our environments are constantly evolving: data types, endpoints, subnets, compliance requirements, technology and business risk, and other variables we draw upon when we set up the SIEM initially are all dynamic. Of course, in larger organizations there are likely to be teams dedicated to maintaining the SIEM that remain aware of these changes and adjust as necessary. But in smaller organizations, we tend to get bogged down in day-to-day activities that prevent us from capturing all these changes. After all, the shortage of cybersecurity staff is well known and shows no sign of easing. Over time, alerts become stale and incomplete if these changes are neglected, eventually leading to the infamous alert fatigue.
If you find yourself in the latter category, consider treating your SIEM updates like a spring cleaning exercise this year — one or two long days dedicated to reviewing all your alerts, rules, variables, and other criteria in the SIEM to see what is still relevant and what's not, what's changed, and consider some of the following items:
- Have any application updates for the SIEM been released but not applied? Hopefully not, but take this opportunity to confirm and patch your system to the most current, stable release.
- Has the network team stood up any new subnets or equipment, such as DMZ environments, to or from which traffic should be monitored?
- Has the systems team deployed new servers whose logs should be monitored?
- Have your developers released any new applications that should be incorporated?
- Have your endpoints started using any new software (operating systems or productivity applications) that should be monitored?
- Have any applications or services moved to new servers and/or subnets?
- Have any new special access privileges been introduced (vendors and contractors, for example)?
- Have any new users been granted elevated privileges?
- If your organization uses file integrity monitoring or user and entity behavior analytics, is this configured across all nodes where necessary and is it monitoring all the right metrics?
Before moving on, consider one more often-overlooked value: Has the business's risk appetite toward any of the above items changed? What was considered low risk a year ago may be a high risk today or vice versa. Having a good grasp on what is important to the business will pay dividends toward knowing what is critical and what is not — and keep in mind that what is critical to us as security professionals may not always seem critical to the business.
In the interest of being thorough, approach the review as an out-of-the-box setup. Don't assume a rule or alert's configuration is still valid because you remember setting it up and don't think anything needs to be changed. That's the equivalent of not vacuuming under the couch because nothing should be under there, but moving the couch usually disproves this theory.
Just as you would approach spring cleaning your home, overturn the dusty items and look in all the dark corners for anything that could be working better. Engage your SIEM vendor if you can — most will offer a periodic review with your account manager to look over your shoulder and offer guidance on what you may be doing right or wrong, what you could be doing better, and any useful tips or tricks they've seen.
This should not be an evaluation of what else to add to your plate but an opportunity to ensure the information you are receiving is timely, accurate, and relevant. In the end, you should be left with a squeaky-clean environment and a SIEM that behaves as well as it did on Day 1.