Centralizing log collection within a Security Information and Event Management (SIEM) system is a crucial component of information security. However, it's a task that can be both necessary and challenging. Unfortunately, there have been numerous instances of SIEM deployments falling short of expectations. You can find countless articles discussing these failures and their underlying causes with a simple Google search. Here is a list of the primary factors contributing to SIEM deployment failures:
Insufficient Executive Support
Undefined Organizational Requirements
Inadequate Control Over Sensor Instrumentation and Log Pipeline
Limited Effectiveness
Concerns Related to Costs and Vendor Lock-In
Why SIEMs are needed?
SIEMs serve as a central coordination and connector system for cybersecurity organizations. They are designed to function as the hub for aggregating data, primarily logs, from an organization's various sensors and instrumentation.
The SIEM system then functions as a centralized hub where security analysts within the organization can:
Receive alerts about potential security events or issues.
Access additional pertinent data related to the alert from other sensors or instrumentation.
Proactively search through the environment's data to identify potential threats (Threat Hunting)
The subsequent sections of this article will provide high-level explanations related to the common reasons behind SIEM deployment failures.
Lack of executive support
While the most frequently cited cause of SIEM deployment failures mirrors the challenges faced by other IT systems, which is a lack of executive support, it doesn't fully elucidate why organizations with similar levels of executive support can achieve disparate outcomes in their SIEM deployments.
The oversimplification of this issue can be attributed to a common misconception, wherein management often views a SIEM as akin to a cybersecurity tool like a firewall, when in reality, it resembles a large-scale Enterprise Application more closely. Consequently, this misconception frequently leads to the entire SIEM deployment project being delegated to the Security Operations Center (SOC) and, perhaps, a handful of security engineers. While this approach may suffice for other cybersecurity tools such as firewalls, it proves inadequate for systems that require comprehensive support from the organization's Information Technology (IT) resources, including roles like database engineers and programmers.
Many successful SIEM deployments require the expertise of seasoned Enterprise Architects who possess robust Linux system administration and DevOps skills. In cases where SOC engineers or engineers supporting the SOC are highly proficient in Linux system administration and DevOps and are not overwhelmed with other responsibilities, they can sometimes overcome the initial hurdle for a successful SIEM deployment. In both instances, the level of leadership support doesn't necessarily differ; it often comes down to some luck of having cybersecurity engineers that can also do complex IT work. Further evidence supporting this notion is the numerous organizations whose SIEM deployments encounter difficulties once a skilled cybersecurity engineer (the individual with advanced Linux/DevOps skills) departs from the organization.
Organizational Requirements not Defined
Defining requirements is a complex task for all IT systems. Decision-makers often operate at higher conceptual levels (e.g., 10,000 feet), where the overarching requirement might be as broad as 'The SIEM secures the organization.' However, beneath this overarching statement, numerous specific details need to be addressed:
What information or systems need protection?
What data is essential for the SIEM to enhance the security of these information or systems?
Which sensors or instrumentation will gather the necessary data from these information or systems?
How will the sensors or instrumentation transmit the collected data to the SIEM?
What volume of data will be collected?
What is the required duration for storing log data?
What alerting and reporting capabilities are provided for analysts once the data is within the SIEM?
What reporting expectations exist for non-cyber stakeholders?
How will the effectiveness of the SIEM be quantified and measured?"
Control of Sensors, Instrumentation and Log Pipeline
The SIEM serves as a repository for data collected from various instrumentation and sensors deployed throughout an organization's diverse range of systems. These systems often include Windows, Linux, Network, and Application platforms. While many of these systems offer instrumentation capabilities, configuring these features correctly demands a high level of system setup expertise and continuous administration to ensure the SIEM receives and maintains accurate telemetry from the instrumentation.
Furthermore, the challenge doesn't end with setting up instrumentation for correct telemetry. The sensor telemetry needs to get to the SIEM. Furthermore, the telemetry arriving at the SIEM is presented in a multitude of formats that require parsing to enhance the SIEM's effectiveness. Finally, the data needs to be stored and accessible. The intricacies of this process have given rise to entire career fields in SIEM system engineering and detection engineering.
Costs and sizing vendor lock in
The complexity of SIEMs makes their deployment and management costly. This often results in vendor lock-in because vendors are aware of the challenges involved in switching SIEM solutions.
SIEM vendors often incentivize customers to transmit increasingly large volumes of data to their SIEM systems, without necessarily considering the relevance of that data. Their motivation behind this is clear: more data leads to larger SIEM systems, resulting in higher profits for the vendors.
Several commendable industry initiatives aim to mitigate vendor lock-in, such as the open-source Sigma project ( https://github.com/SigmaHQ/sigma ). The Sigma project's primary objective is to formulate log detection rules in a standardized format that can be effortlessly shared and migrated between various SIEM vendors.
Comments