With a SIEM solution installed, the security department can think it’s time to grab some popcorn and watch the system perfectly dealing with all possible threats impending their networks. Ah, if only it all would be so easy.
According to the survey conducted by 451 Research, only 31.9% of respondents get more than 80% of the value they expected from their SIEM system, while another 42.8% claim to benefit from only 16-60% of their SIEM system’s capabilities. It means that the majority of implemented SIEM solutions don’t prove even half of their real potential, thus letting intruders stay unseen within corporate networks. But why?
Are SIEM systems to blame?
SIEM software is always the first to blame when a company fails to improve its information security environment. When the system is prone to performance issues or overlooks security events, it’s easy to conclude that this solution doesn’t meet a company’s requirements and thus cannot handle its mission. However, in real-life, issues often result from human negligence towards vital details ensuring an SIEM solution’s viability.
Here are 5 common mistakes companies make while planning, deploying and customizing a
SIEM solution, supported with real-life cases from our SIEM consulting practice proving that
merely installing SIEM software isn’t enough to ensure full-fledged threat management.
Mistake 1: Leaving non-customized correlation rules
One of the solution’s main functions is to correlate security events and detect offenses that
threaten a corporate network. Though modern SIEM systems offer out-of-the-box correlation rules (e.g. in IBM QRadar, over 500 correlation rules are available), they usually cover only the most typical use cases. Customized correlation rules are indispensable to make the system work according to a company’s network topology and security policy.
Case 1: A financial organization implemented a SIEM solution as a part of their security strategy and activated a range of out-of-the-box correlation rules. However, there wasn’t a single custom correlation rule adapted to the company’s domain controller security policy. It meant that the implemented system didn’t qualify cases of multiple user login failures into offenses, failing to detect any attempts of brute-forcing across the network. SIEM consultants built up a relevant correlation rule aligned with the existing domain controller policy, which allowed us to see the first results 24 hours later when the SIEM system-generated 30+ offenses triggered with authentication mistakes. Having investigated the detected offenses and their source IPs, security administrators found out that one of them belonged to a malicious external user persistently trying random passwords to access one of the employees’ workstations.
Case 2: A SIEM system installed at a bank had no customized correlation rules on the traffic baseline analysis, therefore it couldn’t detect abnormal network activities and prohibited communication with important network devices. To fill this gap, the bank turned to SIEM consultants who fine-tuned a set of flow rules, including a custom correlation rule applied to the database production server. With new rules in place, just 3 weeks later an SIEM system identified an abnormal increase in the server traffic by more than 25%, as well as detected a suspicious IP that wasn’t authorized to communicate with the server. Security administrators were then able to start investigating the offense.
Mistake 2: Allowing false-positives to flood out the system
With non-customized correlation rules, organizations are not only unable to capture a whole array of security events, but they also risk to overlook real incidents in the mounting pile of false positives.
This creates an unnecessary workload for security administrators and analysts along with
making an investigation of security offenses cumbersome.
Case 1: A healthcare organization turned to SIEM consultants to fine-tune their SIEM solution.
They discovered that the SIEM solution functioned with out-of-the-box rules activated all at once without any customization. As a result, the system generated 7,000+ offenses daily. It’s obvious that such a volume of security incidents was impossible to analyze manually. By updating the network hierarchy and forming log source groups, the SIEM team fine-tuned the out-of-the-box correlation rules, as well as developed custom rules aligned with the company’s infrastructure.
This allowed to cut down the number of false-positives along with reducing the number of daily generated offenses to only 150.
Mistake 3: Overloading a SIEM solution
The estimated system load (the number of events per second (EPS) and flows per interval
(FPI)) is one of the most important factors to consider while designing a SIEM solution
architecture. If the solution’s actual load mismatches the real number of security events, a huge amount of data will just pass by without being sieved through a SIEM system, putting the organization’s security at stake.
Case 1: An oil company deployed a SIEM solution with a total load of 4,000 EPS. However,
once SIEM consultants came on-site to fine-tune the system, it turned out that the real number of log sources exceeded the default license, generating 8,000+ EPS all together. Without fixing, the system would ignore more than half of security events. To ensure the correct functioning of the solution, the company had to purchase additional licenses extending the load threshold.
Furthermore, the SIEM consultants filtered thoroughly both events and flows coming from all the log sources to improve the system’s general performance.
Mistake 4: Overlooking deployment gaps
Even a well-designed architecture cannot guarantee a SIEM system will be properly deployed. Though the deployment process isn’t rocket science, security administrators should check that the system components and licenses are activated appropriately to ensure the solution functions correctly.
Case 1: A bank deployed a SIEM module to monitor network device configurations but it didn’t operate for an unknown reason. Analyzing the solution, a SIEM consultant discovered that a security administrator activated the license incorrectly, which disabled the entire module. To fix the issue, a SIEM consultant had to redeploy the module in a virtual environment, reactivate the license, then reconfigure it according to the bank’s requirements.
Mistake 5: Neglecting system configuration requirements
SIEM solution configuration is another important aspect to consider during the implementation phase. Misconfigured SIEM systems cause performance issues that impede security event processing and analysis. There can be the following misconfigurations:
No auto-updates
When auto-updates are misconfigured or disabled, a SIEM solution doesn’t receive updated
lists of vulnerabilities and bad IPs, while protocols and modules are not renewed. In essence, such a system doesn’t identify a whole range of recently introduced offense types.
Case 1: A SIEM system didn’t scan vulnerabilities even with appropriate licenses activated. The investigation showed that the company was using an outdated version of the vulnerability scanning module that wasn’t updated for the last 3 months due to misconfigured auto-updates.
Once auto-updates were reconfigured, the system started detecting new security threats.
Inconsistency of backups and available storage volume If not controlled, SIEM system backups can take all available storage slowing down the system and even causing its complete inoperability.
Case 2: While planning out a SIEM solution, a financial services company decided to have the online data access for 1 month and the offline data access for 1 year. After implementing the system, the company increased the term of the online data storage up to 6 months, and the offline data access was prolonged up to 3 years without taking into consideration the system’s initial capabilities, which led to a storage bottleneck. The company had to turn to SIEM consultants to solve the problem. After analyzing the issue, the SIEM team offered to set up external storage that could take the load off the SIEM solution.
Conclusion
Installing SIEM software is not enough to ensure effective threat management. Once deployed, a SIEM solution requires proper fine-tuning to fit an organization’s unique IT landscape and threat profile. To see real returns on their investments into SIEM, companies have to ensure not only a system’s basic configuration but also go through correlation rule customization that allows a SIEM system to show its real capabilities as an advanced analytical security tool, not just to be a mere warehouse of uncontrollable security events.
About the Author
Serguei Tchesnokov Senior SIEM Consultant at ScienceSoft, Serguei is an IBM certified Security Professional with a 9-year background in Security Information and Event Management and 16-year work experience in Information Technology. Serguei’s portfolio includes projects on architecture design, integration, and deployment of security solutions based on IBM Security QRadar SIEM, IBM TSIEM/TCIM, IBM Security Identity Manager (SIM) for healthcare, banking, financial and governmental organizations.
