The problem with SIEM 1

For the past several months I have been researching a report into the log and (security) event management market or, as Gartner calls it: SIEM (security information and event management). This is basically a confluence of what were the previously separate SIM (security information management) and log management markets, where the former was concerned with real-time identification of, and response to, external and internal attacks against the corporate IT infrastructure and the latter was used to store the relevant details of those attacks for evidentiary purposes and subsequent analysis, and to support compliance monitoring, both for regulations such as Sarbanes-Oxley, Basel II, PCI DSS, CoCo, Garante, HIPAA and so on, and also to support compliance frameworks such as ITIL and CoBit.

So, why would I, specialising in information management be interested in something that is about security, when Bloor Research has a team of three dedicated security analysts? The short answer is that log management is about storing information and then querying it, while security information processing is about pattern recognition and real-time analytics. In other words, the underlying capabilities required of SIEM products are all about issues that have been and are being addressed by information management vendors.

Perhaps this is why the SIEM vendors have made such a hash of their architectures: because they, and the analysts who otherwise cover this space, don’t know enough about information management. This series of articles will explain why I think the architectures of the SIEM products currently on the market are flawed and what they should do about it. Of course, some are less flawed than others and I’ll point this out as I go along.

Anyway, let’s start by considering data integration. Not that this is a major point but because I am halfway through my allotted space and I will need more space than that for my next two articles, on data storage and event processing respectively. Anyway, as far as integration is concerned, pretty much everybody has huge numbers of integrations with network devices of various sorts, with third-party security devices and with a variety of operating systems (though not usually Apple, which must be a warning against using Apple Macs in a corporate environment), frequently running into many hundreds. There are also plenty of companies collecting non-log data (a hacker might turn off logging) such as configuration, vulnerability and asset data though there are a surprising number of vendors that don’t connect to physical security devices like badge readers. However, that isn’t what I wanted to talk about. Where there is a relative paucity of integration is with application software such as SAP R/3, Oracle PeopleSoft and so on. Most companies can read text files output by these applications but if you really want to understand what is going on within these applications then you should be implementing integration at the ABAP or BAPI level (for example). What occurred to me is this: all the data integration vendors have this level of support (and for all sorts of database technologies as well) so why don’t the SIEM vendors go to talk to those guys about integration instead of trying to reinvent the wheel?

As I said, not a major point but one worth considering. More meat in the next two articles.