10 Reasons SIEM Should Remain Dedicated to Security — Part 2
Different user needs implies different tools
The previous intro blog (10 Reasons SIEM Should Remain Dedicated to Security — Part 1) paved the way for this series. It is a bad idea to use a SIEM for IT Operations, application performance management and observability use cases. These are 10 primary reasons for this:
A. User needs
- Different stakeholders or owners
- Varying user profiles, leading to unique workflows
- Diversity in use cases resulting in unique outcomes
B. Data characteristics
4. Varied data sources across use cases
5. Variances in logs originating from the same data source
6. Field variations within the same log from the same data source
7. Different context enrichment sources
C. Analytical outcomes
8. Differing analytics methods and rules
9. Complexity in parsing and modeling
D. Governance practices
10. Unique requirements for compliance and segregation of duties
User needs
1. Different stakeholders or owners
The notion of shared tools can initially seem enticing, with the promise of cost sharing among different teams including Security, ITOM, and APM/observability. However, such arrangements often get more complicated when divergent stakeholder priorities arise. Balancing a range of complex use cases in a single tool often leads to operational issues, decision inefficiencies and performance degradation across the board.
If a tool is shared, who will pay for the tool, or who will pay how much of the tool? Which use cases are more complex, require more compute or are more data-intensive — and hence should be considered “more expensive”? If the system is at or near capacity, which use cases will be decommissioned to make room for a newly prioritized use case? Who will make those decisions?
Be ready for a long list of existential questions, power plays, frustrations and grievances. Driving the complexity of sharing tools is hard, and although an agreement “in principle” could be obtained before a joint tool is purchased, disagreements during the lifecycle of the tool could take a bite out of a previously good relationship among Security, ITOM and APM teams.
2. Varying user profiles, leading to unique workflows
The distinct nature of security, ITOM, and APM/observability results in unique user needs and, consequently, different workflows.
For example, SIEM and security log management (SLM) users focused on threat detection, investigation, and response (TDIR) are concerned with monitoring the environment, detecting attacks, validating incidents, investigating blast radius, identifying root cause, making sure the environment is cleaned and improved, and demonstrating that all of this happens in compliance with internal and external regulations. The workflow required for this is different than the one for APM/observability. The latter are primarily concerned with measuring and improving the performance of applications. Similarly, ITOM users follow another distinct workflow aligned to tracking the operational aspects of an IT organization, its assets, and its resources.
Because tools come last in the people, process and technology (PPT) approach, we know that different workflows and processes require different tools. The attempt to blend these distinct workflows into a single tool might not only compromise efficiency, but also lead to conflicts and operational challenges.
3. Diversity in use cases, resulting in unique outcomes
Trying to serve a wide range of use cases and outcomes with a single, general-purpose tool can be analogous to trying to “converge a toaster and a refrigerator,” as Apple CEO Tim Cook once quipped. The resulting product may be neither satisfactory nor efficient.
Security use cases usually assume that a bad actor is actively and creatively trying to do bad things. This assumption is used as guiding principle by all SIEM vendors, in terms of requirements, users, workflows, use cases and outcomes. Likewise, APM use cases usually assume a “good faith error” somewhere in the operational model of an application. And again this assumption is used as a guiding principle by the APM tool vendors, which will lead to a tool different than a SIEM.
Security, ITOM, and APM/observability operate using distinct use cases and desired outcomes. Attempting to unify these within a single tool is asking a lot and increases the degree of difficulty in achieving the intended outcomes. Instead of attaining efficiency, such a strategy might lead to suboptimal performance across all disciplines. SIEM, on the other hand, is a solution that was designed by security professionals specifically for use by other security professionals, a.k.a. “Made by security for security”.
Our next blog will do a deep dive on the data required to power security use cases, ITOM use cases and APM use cases.
