10 Reasons SIEM Should Remain Dedicated to Security — Part 5

We’ve seen many reasons already why SIEMs should be focused on Security. In the last blog, we discussed data considerations. Here, we’ll address the simple question “Can’t we just use other correlation rules and also serve ITOM and APM use cases with our SIEM?” Finally, we will wrap up this series which I hope you found valuable.

8. Differing analytics methods and rules — deterministic vs. heuristic

The analytics engines and rules vary drastically across different use cases, and are based on the insights that the tools are expected to provide. ITOM and APM/observability mainly concentrate on machine behaviors, such as connectivity, loads, and machine-to-machine communication within IT networks, or the performance of application code within a container. These behaviors can usually be modeled using finite state machines, and deterministic approaches provide solutions for most issues. They are often addressed through conditional “if -then-else” rules, or simple mathematical formulas to compute variables like the average round-trip delay between two systems or the mean response time for a specific application.

In contrast, security — especially when dealing with active attackers — is anything but deterministic. The unpredictable nature of human behavior leads to an endless array of attack vectors and creative misuse of an organization’s resources. To efficiently address security issues, heuristic approaches are essential, heavily relying on advanced analytics and machine learning models. For example, UEBA is designed to establish norms for behavior, and can flag anomalies typically indicative of an active attack.

These deterministic and heuristic analytics have fundamental differences and require different engines and content (for example, different input data, rules, etc.) to operate effectively. The best SIEMs often include several analytics methods running in parallel, what can be called “Analytics in depth”. For more details on this, please see my previous blog “A crash course on security analytics”.

A tool running several of these analytics engine, with rules and content focused on security, plus ITOM and APM would require massive computing resources to be effective and be very complex to manage. Some of our customers ask us to manage a few thousand correlation rules just for security. Adding the same amount for ITOM and for APM in a single tool would be hard to manage.

9. Complexity in parsing and modeling

With the varying fields required to handle ITOM, APM/observability, and security (even when working with the same data sources and logs), specific parsers are necessary for each log. This introduces two major challenges for a single tool trying to cover all three use cases:

1. There would be a significant computational load and temporary storage demand to parse all logs for all use cases.

2. A highly complex data model would be required to accommodate all use cases.

These demands could contribute to performance problems. Only a handful of SIEM solutions can scale beyond a million events per second (EPS), and yes this includes Exabeam. Adding the task of parsing for non-security use cases like ITOM and APM/observability would necessitate a prohibitively high investment to sustain an acceptable performance level. This investment covers not only the license costs (hot/cold storage) but the compute costs of querying across days, weeks, months, or years of data.

10. Unique requirements for compliance and segregation of duties

Segregation of duties is a fundamental principle in demonstrating compliance with external regulations like PCI, HIPAA, and GDPR, as well as internal policies that ensure protection against malicious insiders. For a single tool, it’s crucial not to play the roles of both judge and jury, as this could compromise the demonstration of compliance and jeopardize the validity of the process.

Using a joint tool for security and compliance, ITOM, and APM/observability could easily violate key tenets of duty segregation. Potential conflict areas include:

• Ownership governance: Could there be conflicts of interest with a single owner or joint ownership?
• Administrative governance: How would admin privilege sharing be handled?
• Engineering team governance: Who is responsible for developing disjointed use cases?
• User governance: How would role over-provisioning be managed?
• Long term data storage and archiving: how many years of data are you required to maintain?

Maintaining proof of custody, proper accountability and role-based access control (RBAC) becomes exponentially more complicated when too many individuals have access to the tool. The well-known saying rings true here: too many cooks in the kitchen can spoil the food.

Conclusion

Many organizations would like to have a single joint tool capable of handling security, ITOM, and APM/observability. In theory, this might seem achievable, beneficial, cost effective, and there are fringe cases where a reduced scope might make this viable for smaller or very specialized organizations. However, a deeper examination of the 10 distinct aspects discussed in this paper reveals that this is generally an unwise strategy.

The drive towards unification should be carefully balanced against the unique requirements, complexities, and costs associated with each field. Attempting to create a “one size fits all” solution might compromise the efficiency and effectiveness of each individual component, diluting the success of them all.

While it’s understandable that organizations wish to reduce complexity and cost, the ambitious endeavor of creating a unified solution for security, ITOM, and APM/observability may result in a tool that doesn’t perform optimally in any of these areas. It’s essential to remember that the more features a tool aims to cover, the more complex it becomes to manage, maintain, and secure — often in an exponential manner — which could lead to elevated costs and decreased performance.

Additionally, compliance requirements and the necessity of maintaining segregation of duties makes it much more difficult to use tools for security, ITOM and APM/observability.

In summary, while it’s an appealing concept, it’s often best to let the SIEM focus on security use cases. Always remember that the dream of simplicity and unification may turn into a nightmare of complexity and increased overhead.

I hope that you found this series of blogs informative. If you want to see other topics addressed, please let me know by sending me a message to my LinkedIn profile.