How not to suck in SIEM implementation

How not to suck in SIEM implementation

As it seems to be, security professionals are pretty aware of the importance of SIEM systems as well as their intricacy and cumbersome operational modus. Whatever the underlying technology is, that can for instance range from the traditional store and search capabilities to advanced machine learning based platforms, a SIEM requires good planning and real dedication in order to ensure delivery of the promised value to the organization’s security strategy. In this article, I will focus mainly on important considerations when it comes to SIEM implementation and operations.

Sure enough, when a SIEM is implemented and operated as it should, it can deliver much value to different parties within an organization. A SIEM can be leveraged in order to ensure proper threat detection services as well as advanced network and host-based forensics. It can also provide great reporting capabilities that would help benefit a large scope of compliance assessments. On the other hand, as they can integrate an interesting spectrum of possibilities, ranging from log retention capabilities to advanced event correlation for incident detection and remediation, SIEM systems can present a serious challenge as well. So, what are the common oversights regarding a SIEM system implementation? And what can organizations expect to face vis-à-vis its operations?

Common oversights regarding SIEM systems implementation


SIEM implementation can be an intimidating part due to the complexity that the integration in a heterogeneous environment can bring. As the SIEM system should often be integrated with more than a few log sources and reporting services, it may be a big challenge for organizations to plan a proper implementation strategy. Another obstacle is the requirement of involving different parties emerging from the security staff to IT admins and other operational entities. This difficulty is clearer if we take into account that a SIEM system implementation is an ongoing process and as a result, continuous involvement of different parties is to be required. In order to ensure minimum impact on service request rates for different parties outside the security teams, it is important to set in place a dedicated continuous integration unit (it could be one resource within the security team) with proper delegated roles.  This unit can also be responsible for the operational part of the SIEM. Dedicated personnel must be given in order to make a SIEM implementation successful.

Lack of proper planning

Resource overhead and scoping are common challenges when an organization is planning a SIEM system deployment. One should be very careful when scoping such systems because organizations tend to throw to it anything that can produce a log, sometimes without even thinking of possible benefits from doing so. Improper scoping means complex outcomes, resources overhead and very verbose outputs that can lead to disastrous operations afterwards. Also, tuning is a large and difficult part of the SIEM deployment project, so plan ahead with a decent scoping and a well-designed architecture.

On the other hand, failures on a SIEM correlation and alerting engine has a big impact, especially if we consider that organization rely on the SIEM system as the focal point for detection mechanisms. It is a great deal to use proper monitoring tools in order to track its resources utilization and detect possible failures that can lead to SIEM supported services down times.

Common oversights regarding SIEM operations


Since SIEM systems are very engaging in the run phase, they essentially require continuous integration processes. One risk that is regularly raising is forgetting to ensure source logs are correctly parsed. Detection and alerting rules rely on critical information parsed from the raw received logs and as a result, for example, if after a firewall system upgrade, the newly received logs are not parsed correctly, then there is a huge risk that detection and alerting rules will fail to trigger as the embedded conditions will not be met.

To ensure parsers are always up to date, a continuous monitoring process is required along with the run phase to ensure that everything that has been implemented continues to work as expected.

Tuning and continuous improvement

Before a SIEM is fully beneficial, months of iterated tuning should be operated after the end of its implementation. There is a huge gap between what a SIEM can offer and what it is capable of doing just after it has been deployed in the hosting environment. This gap is essentially due to the complexity of the required detection, correlation and alerting rules that can suite the exact organization’s hosting environment. We typically see organizations making big mistakes when relying solely on the default rules and settings as they think it would be best practices in the domain. Sure enough, it is good as a starting point, but operational teams should take the time and efforts needed to tune and configure all the required aspects in order to enhance at least the following:

  • Environment definition (SIEM environment awareness)
  • Detection rules (with advanced correlation and IOCs integration)
  • Alerting rules (reduce false positives and false negatives)
  • Reporting services

The shipped default detection/alerting rules require tremendous inputs from the organization’s environment definition and other threat intelligence resources. So please mind the gap that exists between what a SIEM is able to offer out-of-the-box without tuning and continuous improvement and what it can do for you if properly tuned to better suit your environment.


Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.