The SIEM (Security Information and Event Management) concept is heading into the third phase of its evolution.
In the first phase, SIM (Security Information Management) products developed to collect logs from multiple sources to aid in compliance and “log review” activities.
In the second phase, SEM (Security Event Management) emerged to find security events. SEM correlated multiple items across application, host, and network security logs to help security analysts detect and respond to attacks.
These two activities have provided little value to many organizations. While they may have seemed reasonable in theory, they were not designed from the ground up to solve the business problems that organizations actually face.
The SIEM product space has spurred novel database concepts, computationally expensive correlation algorithms, and complex tools for managing large amounts of log information. But ultimately, these approaches have failed to solve the real problem customers face in managing their security. They address the wrong problem because they started by looking at the symptoms — lots of logs that produce largely meaningless information.
The real business problem is to know exactly when an incident has occurred, respond to it (ideally in a real-time, automated fashion where appropriate), and prevent it from happening again. All the device configuration, log correlation logic, data storage, compute power, and bandwidth required to correlate disparate logs into a set of possible events to investigate produces a lot of work for analysts with far too many false positives.
For this reason, we’ve started too see companies changing the way they use SIEM products. Call it the third stage of SIEM’s evolution.
Traditional security products such as firewalls, IPS, Web filtering and antivirus (AV) software produce vast amounts of false positives, necessitating the SIEM. But companies that have invested in advanced threat protection solutions (such as the FireEye platform) find that detected malware incidents are nearly always real events — and their analysts trust this source of information more than a post-event correlation of likely irrelevant data.
In one company, I’ve seen the security operations center (SOC) changing its operations to largely respond to FireEye events. About 95 percent of the security events it responds to are detected by the FireEye Multi-Vector Virtual Execution (MVX) engines, either in email or web vectors. The remaining events are from other threat types, such as inappropriate access (access that violates of separation-of-duties and compliance rules), data loss prevention (DLP) events (insider threats), or distributed denial-of-service (DDOS) events.
As a result, SIEM deployment has refocused towards identifying compliance events rather than trying to correlate network and AV data. This improves the performance of the SOC, reduces the burden on development of SIEM configuration, and lets organizations separate their security logging architecture from their incident detection infrastructure. This shift makes the job of forensics much simpler; the analyst has far fewer events to examine and doesn’t use the overloaded (read: S-L-O-W) SIEM infrastructure to analyze events. Tools such Splunk are progressing nicely in facilitating this new model of security operations in the enterprise.
By splitting up malware threat protection, security compliance monitoring, and log-based investigations and forensics, organizations can better leverage their investments. They reduce the time to value of log management, speed up detection and response to advanced threats, and avoid the headaches of false positives.
From a business perspective, this means a smaller investment in log collection, storage and processing. Organizations can leverage the same stores for application, network, and security operations, for instance. It also means fewer specialists are needed to tune and operate the correlation machinery. And of course, it means fewer hours of analysts’ time sifting through hundreds of false-positive incident correlations.
In other words, that time and money can be better spent on what matters: finding and fixing your security vulnerabilities, looking for insider threats, and preparing your incident response team to efficiently deal with breaches.