Security information and event management, or SIEM—once upon a time referred to as SEM (security event management), SIM (security information management), SIM/SEM, or (insert your preferred acronym here)—is a category of software that surfaced in the late '90s with Intellitactics (1996), netForensics (1999), Arcsight (2000), Q1 Labs (2001), LogRhythm (2003), and Splunk (2003). SIEM solutions would offer hope to security analysts looking to aggregate and correlate all of the log and other event information from different servers and devices on their network in a single place. The efficacy of such a solution was wholly predicated on the power of its correlation engine, which gave it the ability to see similar indications of compromise generated across different devices and systems in the network in order to eliminate false positives and validate true positives—the concept that A plus B plus C equals something bad happening. SIEM solutions became the syslog-ng on steroids. Syslog-NG is an open-source distributed agent-log server released in 1998 for centralized logging in the enterprise environments of systems that supported the syslog format. Syslog was developed in the 1980s by Eric Allman as part of the Sendmail project. It was readily adopted by other applications and has since become the standard logging solution on Unix-like systems for both servers and networked devices.
Unlike central log servers, such as syslog-ng, SIEM solutions were able, through native support, syslog support, application programming interfaces (APIs), and other plugins, to centralize events from not just syslog-enabled endpoints but also intrusion detection systems, firewalls, antivirus, network access control solutions, and even NetFlow data from routers.
Unfortunately, though, despite efforts to continue to improve he efficacy of their correlation engines, SIEM solutions continued to generate too many false positives, causing systemic event fatigue with analysts.
Anecdotally, I recall a news report that was playing on NPR news as I drove to the office in 2014. It discussed the growing problem of alarm fatigue in emergency rooms. In the case of Boston Medical Center, an analysis found that 7 North was experiencing 12,000 alarms a day on average. “Alarm fatigue” referred to the nursing staff’s desensitization to the many noises in the unit, which was causing increased patient deaths.
A survey by FireEye polled C-level security executives at large enterprises worldwide and found that 36% of respondents receive more than 10,000 alerts each month from their SIEM. Of those alerts, 52% were false positives and 64% were redundant, costing companies an average of US$1.27 million every year.
And unfortunately, as history has proven in infamous breaches such as the Target breach whose costs approached US$300 million in 2017, the alarm fatigue problem has led many security operations centers running SIEM solutions to mistakenly close real alarms as false positives.
SIEMs have quickly lost their luster as security analysts continue to get hit with false positives on a daily basis or take fire from the managed security service providers they had to retain for the daily care and feeding and 24/7 monitoring. It quickly became obvious that an SIEM required daily, round-the-clock tuning by a seasoned staff member capable of creating rules for that specific platform in order to lower the amount of noise—with no end in sight. The dream of effective centralized monitoring of events in the enterprise would need to be reimagined.
Enter SOAR—security orchestration and response. New startups such as Exabeam, Swimlane, ServiceNow, Siemplify, Rapid7, DFLabs, Demisto, Cyberbit, and ThreatConnect have come to the rescue, with more startups sure to show up as more venture capital from Sand Hill Road is poured into this new area of cybersecurity.
Unlike SIEM solutions, which gather and analyze data produced from different formats and sources and rely on the fallible human to make judgement calls on events in an exceptionally manual and nondeliberate way, SOAR solutions expand and improve security Operations (SecOps), mechanizing and organizing activities that the human analyst previously relied on across all sense and response actions. They take SIEM further by combining data collection, threat and vulnerability management, incident response and case management, workflow, and analytics to provide organizations the ability to implement autonomous workflow and process execution and response actions through what are referred to as "playbooks." Additionally, SOAR solutions integrate with a wider range of internal and external applications, unlike their SIEM predecessors, not only combining IT-related controls but also tying together non-IT-related processes and procedures.
It's anticipated that, because SOAR and SIEM solutions are such close cousins, the two product lines will eventually converge through mergers and acquisitions or as SIEM vendors respond to lost market share and begin to add SOAR capabilities to their platforms. Many previous SIEM platforms, such as LogRhythm, have already begun to mature in this direction as they quickly try and react to buyer demands and market forces.
I've interviewed many chief information security officers (CISOs) in this debate on whether the SIEM is now considered legacy and will soon die out. CISOs across organizations of different sizes are carefully looking at their budgets to determine if they should continue investing in their licensing renewals with vendors such as HP or IBM. The responses to my questions have been thus far the same. I get a question as a response instead: "Why put more money into a solution that does half the things my SOAR solution can do without losing any functionality?"
But at the moment, the jury is still out on whether the body is beginning to get cold on SIEM solutions as SOAR continues to evolve and IT service management companies, such as ServiceNow, enter the market.
I will be releasing a research report on the new SOAR market this year, which will be followed by several case studies on some of the SOAR solutions I've mentioned in this report.