By Augusto Barros, VP, Cyber Security Evangelist
Fallacy: A fallacy, also known as paralogia in modern psychology, is the use of invalid or otherwise faulty reasoning in the construction of an argument that may appear to be well-reasoned if unnoticed – Wikipedia
The SIEM is one of the oldest tools in the cybersecurity arsenal, having passed through multiple generations and with a long evolutionary history. Security incident and event management is a technology solution with a broad range of use cases, from simple compliance reporting to advanced threat detection and threat hunting. Still, the cybersecurity space keeps seeing many technology providers pushing for the adoption of SIEM alternatives. As part of those efforts, they appeal to multiple claims, from the silly “SIEM is dead” (the recent acquisition of Splunk by Cisco seems to say something different) to concerns about complexity and cost. At first, some of those claims may seem reasonable, but most of them are good examples of logical fallacies. Let’s see why.
The most common logical fallacy used against SIEM is known as the “strawman argument”. In fact, this fallacy is very often used in marketing efforts to sell a product as an alternative to something else. A strawman argument misrepresents the other side’s point of view, in our case specifically, they say the SIEM is so easy to attack. There are many cases where alternative SIEM products market themselves as being clearly superior to “the slow, basic Boolean rules only” that they claim a SIEM is. Well, SIEMs were certainly something like that…about 15, even 20 years ago. A modern SIEM is cloud native, with advanced analytics capabilities and expanded to include features that came from the process of absorbing other product categories, such as UEBA and SOAR. When a cloud-based XDR provides claims its product is better because it is not an on-premises technology like SIEM, it’s clearly misrepresenting SIEM in order to make the claim.
Entering the SIEM market is a considerable challenge to any technology company these days. SIEMs have evolved to encompass a large set of features and cover a broad range of use cases. For new entrants, the apples-to-apples comparison is very hard, as they usually have considerable gaps in capabilities, integrations and content to address as they evolve. In order to avoid the undesirable comparison against more mature products, avoiding the SIEM label altogether is a common strategy. The use of the strawman argument is a way to make an artificial differentiation, avoiding the direct comparison.
But how can prospective buyers make sure they won’t fall for these fallacies? They need to examine the “not a SIEM” claim. Is this product really different from SIEMs, or is it just avoiding the label? Fortunately, identifying a SIEM is quite simple; we can just ask a few questions about the product’s capabilities:
- Does it collect data, such as logs and events, from multiple sources?
- Does it apply some type of logic, such as rules, search queries, statistics, ML-based magic, to that data to identify threats?
- Does it provide alerts to analysts to investigate or take any other response action?
- Does it store the collected data for long periods, making it available for searches and reports?
If the answer to those questions is “yes”…it walks like a SIEM, it quacks like a SIEM, so it must be a SIEM!
Watch out for distractions; these providers will often claim their product is not a SIEM because it does something more than those points. But SIEMs continue to evolve to include many additional capabilities, such as response features often attributed to SOAR products. Including a feature in addition to those commonly present in a SIEM is not enough to make something “not-a-SIEM”.
Confused? Analogy time!
Tesla was the first car maker to include full self-driving in their cars; now, imagine if Tesla decided to market their vehicles as “car alternatives” because they included full self-driving! It doesn’t make sense, right? That’s similar to what we are seeing in the cybersecurity industry regarding SIEM.
But why are these vendors so afraid of being compared with other SIEMs? Because they lack very important SIEM capabilities. Some examples of those gaps are:
- Data sources: Some products are very limited in terms of the data sources they can use. Some of them can support mostly products from the same vendor, locking the customer in their “ecosystem”. Some can ingest data from other sources, but are very limited in terms of what they can do with them.
- Enrichment: They can enrich a very small subset of events from certain data sources with a limited number of enrichment data sources. External threat intel, for example: They may be able to integrate with something like Virustotal only, or just from their own proprietary threat intelligence service.
- Analytics: They provide limited out of the box, non-transparent (you don’t know what the system is doing to generate results) analytics, but you cannot write your own. You can write very simple rules (often with a proprietary language, or just simple SQML), and those rules can only look at a very small number of parameters. Check, for example, if their “behavior” analytics can be applied to not only users, but also other entities, such as endpoint or network hosts activity.
- Smart lists and lookup tables: Basic items for any advanced analytics, but apart from a basic, single watchlist, they usually do not exist or are very simplistic and hard to manage.
Many of these products try to be different by relying on automated actions and responses. What seems to be a good idea is, in fact, one of the main problems with these solutions. The SIEM is a solution to be used by humans, and some vendors claim their solution is built for a fully automated scenario. Well, I don’t know a single SOC that is fully automated, and most organizations do not want to rely on full automation for response. So far, these fully autonomous solutions are built for a model that no one wants to use!
A SIEM, such as Securonix Unified Defense SIEM, provides automation where it makes sense, but its focus is to provide the necessary functionality to the analyst with the best, most streamlined experience. Securonix SIEM includes automation, for sure, but a fully automated SOC is still beyond the capabilities of current AI systems. Properly identifying and responding to threats has nuances that many times will require human intervention, so it’s better to rely on products that make that intervention simple and fast.
There are inefficient, expensive and slow SIEMs out there, but there are SIEMs that are efficient, cost-conscious and fast at scale. Do not let the strawman argument fool you and look carefully at these self-proclaimed SIEM alternatives. They are probably just an expensive subset of capabilities available on a modern SIEM disguised as the next big thing.