SIEM or not to SIEM- every security analyst dilemma
This article is a dispassionate effort to deconstruct SIEM, its effectiveness, issues, relevance, and remedy.
But first, let’s address the elephant in the room. Organisations are facing a detection capability gap! Period!
There is a flurried effort to fix this and one of the most probable contenders is a SIEM solution.
While SIEM is one of the most capable detection solutions available, it is not a magic wand. Fundamentally, SIEM is a comprehensive approach to security management that uses rules and statistical correlations to turn log entries and events into actionable information. SIEM tools work by gathering event and log data created by host systems, applications, and security devices throughout the organisation’s infrastructure and bring that data together on a centralized platform. The SIEM tools identify and sort the data into such categories as successful and failed logins, malware activity, and other likely malicious activity.
However, with high data traction, it becomes critical for every organization to have infrastructure capable of processing high volumes of data and providing visualization and data pulling across data sources. This would involve scaling up the database that stores the SIEM data, the analytics engine that queries the database, and the infrastructure that hosts it. One would typically argue that legacy SIEMs can manage voluminous data by filtering and abstraction before being ingested to SIEM. However, this approach compromises the resolution of data.
Organizations often make the following assumptions when purchasing a SIEM solution.
a. Super-fast query and response times
b. Ability to share granulised data
c. Inherent threat intelligence that highlights suspicious activities
d. Big data and ML capabilities and analysis
e. Automated data correlation
However, most of these assumptions are incorrect. SIEM is part of a larger security program and other solutions such as UEBA and SOAR are often layered with SIEM to make it successful.
Let’s dig in further!
The marriage of Data and SIEM
SIEM deployment means nothing to your overall security posture if data is not aligned with it. It is data that gives value to SIEM. The challenge however is finding “Suitable Data”. Bad data sources are galore. Take, for example, Windows data, which is almost universally collected and every SOC understands they are the best and the worst data. By default, process and command-line logging, PowerShell logs, and Windows driver framework logs are not enabled. However, enabling this is a cacophony to SIEM. This doesn’t even consider how data is fed into a SIEM. If a log comes via Syslog, a common log transport protocol, the administrator must enforce parsing. This likely means the log’s end state in the SIEM includes the loss of some data and context from the original event. Going back to Windows as an example, a single Windows 10 system has over 800 fields found within the native binary XML log structure. Yet most SIEMs parse, reduce, and convert that source set down to only around 200 fields.
Defining the rules
Can you detect an adversary that used a VBScript to invoke PowerShell, which in turn pulls down base64 obfuscated code, then establishes a backdoor, finally finishing up by scanning your internal network? Every single step of this process is easy to detect with the right logs and application of the logs.
A SIEM can’t automate information security domain expertise and application of your logs to your specific needs. Once the data is in your SIEM, you must be the one to tell the SIEM what to do with it. However, there are common attack methodologies like MITRE ATTACK that can be used to identify the spectrum of techniques that an attacker may exhibit, then look across their processes and controls to identify gaps in detection and prevention coverage.
For the people, by the people
SIEM should be built by analysts, for analysts. This means that when an analyst is reviewing alerts or logs, the SIEM should provide context and information in a meaningful way. Fortunately, log enrichment, or the art of adding context to a log, is something a SIEM is extremely successful at. Unfortunately, most SIEM implementations prioritize data collection over log enrichment.
As an example, assume an analyst is looking at a potentially suspicious domain being accessed called “darkx.com”. A DNS log contains the domain, the source and destination IP header information, resulting in IP address(es), and the DNS record type. Is this enough information to help the analyst decide if the domain is malicious, suspicious, or benign? Clearly, making such a determination based on this limited data set would be speculative at best.
Now, consider what you could deduce if the SIEM added context such as the following:
· The domain is not in the top 1 million sites accessed
· The domain was registered in 2018
· The IP is related to a business in the Bahamas
· The IP belongs to Random Server L.L.C.
· The domain does not appear in threat intelligence databases
· The domain does not appear to be randomly generated
This level of context does not give a 100% certainty of good or evil, but it certainly provides an analyst with the context to make a more informed decision about the domain observation itself.
The options available in the market
Exabeam: Fusion SIEM from Exabeam is a cloud-only solution that combines SIEM analytics with XDR (extended detection and response), which attempts to streamline and unify a range of security capabilities. One key to the software is that it’s as much about the processes involved with triaging, diagnosing, and remediating as it is about any of the technology tools. This focus on processes and the people managing your security posture makes the technology that much more valuable.
IBM: IBM offers its Security QRadar SIEM both on-prem and in the cloud under the banner of “intelligent security analytics.” The SIEM solution works alongside IBM’s Security QRadar Advisor with Watson to automate investigations of anomalies and other security tasks.
LogRhythm: LogRhythm comes with an expansive feature set that includes integration with hundreds of other IT systems, a library of modules to evaluate compliance with various industry standards, and an array of offerings that run the gamut from basic SIEM to advanced SOAR-based automation and response.
DNIF HyperScale SIEM: A new entrant in the segment is DNIF HyperScale SIEM. DNIF HyperScale SIEM is said to offer a composite solution that combines UEBA and SOAR into a single application. Its petabyte-scale data lake can ingest, enrich, store and correlate data in real-time. We also noticed that they offer one of the industry’s best data Compression Values, a general mode for up to 95% compression and the Maximal mode for up to 98.4% compression. It also comes power-packed with a 50K EPS processing capability with a standard 8 CPU server. DNIF HyperScale capabilities include ML-powered behavioural analytics to identify anomalous behaviours, real-time correlation against threat intelligence, predictive analytics, historical correlation, and other intelligent analytics to address a wide range of business-critical security use cases. In addition, the map signals on the MITRE framework can visualise attack progression and gain a timeline view of the events. You can investigate signals, perform incident analysis, hunt for threats, and correlate signals across solutions. The pricing is per device rather than by data volume. DNIF recently released a community edition of their SIEM solution that organisations can use without limits or restrictions.
Azure Sentinel by Microsoft: Azure Sentinel is available only on Microsoft’s cloud, but also offers visibility across on-prem systems. A key differentiation is an easy integration with Microsoft 365 and Windows Defender, but it can ingest logs from a variety of sources. Azure Sentinel bills itself as both a SIEM and a SOAR platform that adds AI, automation, and collaborative tools.
Splunk: Splunk was one of the first software vendors to discover gold in log file analysis. Splunk Enterprise Security draws on the company’s mature data analytics and visualization capabilities to deliver a SIEM solution integrated with threat intelligence and available in the cloud or on-prem.
Securonix: Securonix enhances your log and event data with data enrichment. You can add relationships between different types of events in order to correlate and contextualize your alerting and analysis capabilities. As a bonus, Securonix runs on Hadoop with an open architecture, enabling you to use a wide variety of third-party analytics tools.
In conclusion, SIEM usage is most effective for mature, well-performing security teams. This is by no means a hard and fast rule; I’ve seen a number of security teams that are far from “master defenders” properly implement SIEM and see positive results. However, SIEM should not be your starting point, especially if you are just starting your security department and controls. In the crawl-walk-run world, it’s somewhere around a slow run. First, start with the basics. Things like endpoint security solutions, network segmentation, and firewalls go a long way for prevention but are necessary for detection capabilities. After doing this, the next step is NOT to rush out and buy a SIEM. Only when you meet the requirements above are you ready to purchase, buy, and maintain a SIEM.
Brian is the news author at Research Snipers which mainly covers Technology News, Microsoft News, Google News, Facebook, Apple, Huawei, Xiaomi, and other tech news.