With the growth of cybersecurity and an ever-changing marketplace, there’s been an explosion of acronyms in the tech industry. Here, we will begin a discussion of how SIEM and SOAR have evolved over the decades and how they continue to adapt to today’s cybersecurity challenges.
SIEM and SOAR are causing substantial confusion among the IT community. The high signal-to-noise ratio of traditional SIEM (Security Information and Event Management) solutions, combined with a systemic lack of staffing shortages, have impelled a new generation of SIEM complimented by SOAR (Security Orchestration, Automation, and Response) functionality.
What’s the difference between next-gen (NG) SIEM solutions and SOAR, and how do the new requirements of NG SIEM compare or contrast to the capabilities of a SOAR platform?
It’s imperative that we first define what capabilities must be met by a SIEM solution to be considered NG. In this installment, we’ll explore legacy versus NG SIEM. In Part 2, we’ll look at SOAR, and how both SIEM and SOAR can work together.
History of SIEM
One of the first true SIEM to appear in the market was Intellitactics in the late 1990’s. The product category at the time was referred to as network security management (NSM). Later, the term was replaced with the phrase SIEM, by Gartner in 2005.
The traditional, first-generation SIEM solutions quickly began to prove challenging for talent-starved institutions. They had few internal cybersecurity professionals who certainly didn’t have time to sit in front of a SIEM day in and day out tuning, creating content rules or validating false positives, while looking for false negatives.
The term “event (or alert) fatigue” became a challenge, giving rise to a new market to MSSPs (Managed Security Service Providers) that followed by taking over the burden of monitoring.
MSSPs offered hope by acting as a triage for level 1 and level 2 event analysis for institutions unable to staff an internal security operations center (SOC).
First-generation SIEM solutions started out as log aggregators, powered by relational databases, capping their ability to provide real-time response. The introduction of correlation engines began to give intelligence to first-generation SIEM in an attempt to address the event fatigue problem caused by false positives and an effort to create the equation (A + B + C is related to the same event and = something bad).
Despite the introduction of correlation engines, SIEM still fell short of expectations. SIEM technologies were unable to aggregate and correlate all log and event data from on-premises and cloud workloads, SaaS (Software-as-a-Service) solutions, and system and network data, as well as provide the capability to perform automated response for detected threats.
Next-Gen Security Information and Event Management: A Smarter Detective
This brings us to today’s NG SIEM.
In order to qualify as an NG SIEM, the solution needs to leverage NOSQL databases, such as Hadoop, Elastic, Spark and other technologies that weren’t available in the early part of the 21st century. Data warehouses that were used by first-generation SIEM solutions included MySQL, PostgreSQL, MSSQL, and even Oracle. They overwhelmed the backend and rendered them unusable over time, preventing institutions from sending any new raw event data to their SIEM unless it was absolutely necessary.
During the last two decades, data science has matured at an evolutionary pace, removing the need for false positive-prone pattern-matching engines, also referred to as signatures. NG SIEM solutions incorporate machine learning (ML) capabilities to leverage supervised and unsupervised models to cluster like events together and identify anomalies from learned behavior. This helps prevent overwhelming the analyst by deafening them with too much noise.
One of the most prevalent themes to become part of the daily narrative in SecOps (security operations) is the concept of applying context to security to determine if an event should be considered a true positive. This is the idea that the SIEM solution should be able to take its understanding of a given asset and apply context to an event affecting that asset, if it indeed is relevant.
For example, an event may trigger from an NDR (network detection and response) solution that an Apache buffer overflow attack was detected that may be real, but the target IP address is running Windows and the IIS web server. Context in this case would not apply, despite it being a real attack, saving an analyst time in having to further investigate.
By incorporating more intelligence into the traditional SIEM, which makes it aware of not just asset information but also the learned behaviors of users in the environment, gives NG SIEM the capability to apply UEBA (user entity behavior analytics). NG SIEM solutions don’t simply identify an event as being “bad or good.” Using ML models, they assign a type of score to an event and when that score exceeds a specified threshold, it’s presented to the analyst for further analysis.
Early SIEM solutions typically presented events by categorizing them into tables of high, medium, or low severity without much more context than the potential severity of the event. Using UEBA, an NG SIEM can quickly identify anomalous behavior when, for example, an employee suddenly demonstrates behavior not previously seen by the SIEM (such as logging onto the corporate VPN on Sunday at 2 a.m. when the individual has never previously logged into the VPN outside of work hours).
Because early SIEM products didn’t have much in the way of asset and infrastructure awareness, they were incapable of identifying lateral movement following a foothold by cybercriminals. Conversely, NG SIEM solutions are now capable of tracking the lateral movement of cybercriminals as they pivot from one asset to another in an on-premises or cloud network.
Just like in the investigation of a crime scene, the primary job of an investigator is to piece together the events against an established timeline. Timeline generation of related events is a hallmark capability of NG SIEM solutions that previously had to be reconstructed manually by analysts in a legacy SIEM.
The most powerful capability added to an NG SIEM is the capability to perform automated responses to known threats that are predefined by incident response playbooks.
Unlike their first-generation SIEM solutions, NG SIEMs are capable of pulling event data from applications and systems as well as stacking workflow automation on top of orchestration, such as pushing response actions to devices like firewalls or IPSs (intrusion prevention systems) in response to detected threats.
This makes NG SIEM similar in capability to SOAR technology. And this is why there’s the current confusion in the market.
Finally, NG SIEM solutions have integrated threat hunting capabilities, allowing analysts to uncover suspicious activity and vulnerabilities in their environment, as well as monitor threat intelligence feeds to uncover potential issues, adversaries and indicators of compromise.
In Part 2, I’ll discuss SOAR and how NG SIEM and SOAR can work together to form a powerful partnership in stopping threats while keeping operations running smoothly. In the meantime, check out the resources below for more cybersecurity content.