SIEM products are evolving to take advantage of machine learning; better integrate with other enterprise security controls; and identify suspicious activity involving an ever-broadening range of hosts, services, applications and networks. Although keeping up with this pace can seem futile, there are steps you can take today to ensure your SIEM architecture will be prepared to make the most of tomorrow's products. Even better, these same steps can improve your SIEM's performance now.
Consider following any of these tips you haven't already.
Improve the quality of the data being fed into the SIEM. If the SIEM's inputs are incomplete, inaccurate or even just slow, the SIEM's decision-making will be negatively affected. Make sure all log sources are promptly reporting events to the SIEM and that each source is logging the necessary detail for every type of security event of interest. Correct deficiencies you find and deploy SIEM agents to hosts as needed to collect additional information that hosts' native logging services cannot. Finally, make sure timestamps are synchronized across all the log sources to aid in correlation.
Make sure the SIEM has the necessary information available for truly understanding the significance of events and correlating events with each other. Having context is absolutely vital for this. The SIEM architecture itself and the people using it need immediate access to organization-specific knowledge to provide that context. For example, what purpose does each host have? Where is it located? What software does it use? What services does it provide? What vulnerabilities does it have? How should it be used? How should it be interacting with other hosts? There are many other questions along these lines that your SIEM and SIEM analysts should be able to answer on demand.
Custom SIEM architecture
Customize the SIEM to support in-house services and applications that need their security events monitored. For example, your organization may have written its own business applications that use your customer databases. It is important to monitor the security events involving these applications, but the SIEM won't understand what it sees unless you educate it. There's a huge difference between a SIEM seeing a code 427 and a SIEM understanding a code 427 means someone is downloading a copy of a database.
Reduce your SIEM's false positives and negatives by tuning the SIEM architecture itself. For example, instead of ignoring and suppressing alerts that are unimportant in your environment, disable the alerts and simply log the information instead. Adjust the thresholds and other configuration settings for SIEM rules to better account for your environment's unique characteristics. For disabled alerts that would be helpful if they had acceptable false positive and negative rates, can you tune the SIEM to achieve those rates? Also, determining under what circumstances and conditions to log events versus triggering alerts or conducting automatic actions to stop possible malicious activity in progress is key to shortening response times and reducing the impact of incidents.
If you work to reduce false positives and negatives for your SIEM, you are better prepared to teach future machine learning technologies what's malicious and what's benign.
Adjustments -- both large and small -- will help prep your SIEM architecture to meet future demands. And they're also beneficial in the short term as well.