Another “me two” enters the SIEM space

The recent announcement of “yet another” entry into the security information and event management (SIEM) market got me thinking about how the entire SIEM market needs to change.

Most SIEM vendors offer a two-part solution to the security information and event management problem. The system design generally consists of one system that acts as an aggregation point for log data, and another that correlates the data and sends alerts. Most of the time these are sold as separate line items or SKUs. This new entrant differs slightly in that it leverages agents to monitor configuration with the information going to a central console. It also deposits log data into a separate system it calls the “Log Center”.

With the PCI market still growing and vendor churn resulting from disillusionment with what one large enterprise customer calls SIEM “snake oil”, it’s not surprising that a new vendor with adjacent functionality would to try and cover more ground in the compliance market.

While acquiring solutions for a wide variety of security and compliance needs from a single vendor has its advantages, in reality, most log management and SIEM solutions actually create additional silos that IT operations and security teams have to deal with. Most SIEMs support an artificial barrier between configuration management by IT Operations and security event and log review performed by security personnel. Some claim there’s a good reason for this. They justify it as a separation-of-duties issue. This is a ‘red herring.’

Splunk customers continue to tell us that a single solution that monitors system configuration, collects log data, saves and automatically runs complex searches and alerts on specific conditions all in a single pane of glass, is the right answer. By unifying Security and IT Operations team efforts, working within a unified, single solution to solve problems and investigate incidents, these teams are able to generate real ROI by reducing mean-time-to-repair (MTTR) and mean-time-to-identify (MTTI) issues from hours to minutes or days to hours. In addition, these teams get kudos from upper management by responding to over-the-shoulder auditor requests and providing meaningful trend reports and dashboards that enable better visibility and business decision making.

A whitepaper from this new entrant offers a brief phrase stating:

“It applies normalization rules to the raw log data after they’ve been captured rather than before, which eliminates the need to know the log schema before capturing a new device log. This means Log Center can capture raw logs from any device. Plus you can dynamically edit the schema later to support the log format when generating reports and queries.”

My interpretation of this is that for unknown log sources, the user has to edit a schema to get meaningful reports. This extra step, editing a fixed schema, can be difficult for the uninitiated, and creates the risk of breaking work done by someone else. It’s not clear from the documentation whether there’s any audit trail for schema changes. Having to edit a schema to support custom log sources (yourself or through a professional services engagement) is common to a lot of SIEMs and can add unexpected cost and time delays. It also presents an added burden of tracking new versions of software that require SIEM support. On the contrary, Splunk indexes all logs, all the time. With Splunk’s universal indexing capabilities, end-users can keep pace as an IT infrastructure changes. Schemas don’t exist, and therefore don’t need to be changed. Splunk identifies new log data from the same source and provides you a choice to use it or not use it. Pretty simple.

Finally, and most important, SIEMs need to scale. In these two-part solutions, customers have to choose what to send to a SIEM solution and what not to send as well as what correlation rules to set up. This really covers up a SIEM shortcoming because in reality sending all the logs to a SIEM would knock it over. So instead SIEM vendors ask you to make a false choice between operational and security use cases. Usually the operational use cases get the short straw. While a small subset of log data may be important to the customer’s security team, another portion of the data can troubleshoot systems and in some cases predict problems before they happen. This is extremely important to the operations team and the business.

Splunk consumes all the data and lets you decide what you want to retain for compliance. Any data on a spinning disk is searchable at any time. Forrester analyst and security expert, Andrew Jaquith’s, book, Security Metrics: Replacing Fear, Uncertainty and Doubt, talks about SIEM and the fact that its focus is primarily on what happened over the last few seconds, minutes, or hours. Jaquith argues that for a SIEM to be useful for real metrics, the timeframe needs to cover days, weeks, months or even years.

The last thing the SIEM market needs is another complex offering that can’t scale to meet the converging data requirements of Security, Compliance and Operations teams. Splunk’s integrated solution unites IT operations and security teams, scales to terabytes per day, and doesn’t force users to learn to manipulate schemas. Available as a free download, Splunk installs in minutes and delivers immediate value … quite possibly before a SIEM appliance gets processed for shipping.

Posted by


Join the Discussion