Untangling events part 2

The purpose of this series of articles is to identify if all of the different approaches to handling events are part of a single market or whether they should be treated as separate. In the first article I outlined six characteristics for handling events: monitor, filter/aggregate, correlate, alert, store and report. However, we were unable to reach any conclusions based on this a priori analysis so I promised to look at individual market sectors to see if we could learn anything from them. In this article I am going to focus on SIEM (security information and event management).

Way back when, there were intrusion detection solutions but these were blunt instruments and evolved into SEM (security event management) packages that provided software-based solutions to monitoring attacks against your firewall and the like. Subsequently, and separately, vendors started to appear that were specialising in log management. That is, taking your syslog data, database logs, network logs, web logs and so on, and storing this for compliance reasons and to enable forensics and eDiscovery against the retained data. These solutions were (and are) usually appliance based, though this is not always the case.

It rapidly became clear that there were synergies between SEM and log management and thus, although there are still suppliers concentrating on each of these separately, we are now seeing the emergence of the SIEM market, which covers both. In some cases these combined offerings are very much hybrid ones, with separate solutions that are more or less cobbled together, but there are also newer vendors, such as LogRhythm, that have been purpose built for the SIEM market.

If we take LogRhythm as an example, it monitors events in real-time (typically security events but also log events such as an employee accessing a prohibited web site). Following this, the software can correlate these events with business rules that you define to create relevant alerts and the data is stored in the product’s appliance for reporting purposes. In this last case, LogRhythm provides compliance reports (for SOX, PCI, HIPAA, the UK government’s GCSx and many others), analytics, data mining and search capabilities.

As an aside I should mention the market for data retention (for call detail records and the like). It should be clear that these are events and what you need to do is to store these and then search against them. Of course, there may be very large numbers of transactions to process but leaving aside questions of scalability it should be clear that an SIEM solution such as LogRhythm and, indeed, any log management application that has search capability, should be capable of handling data retention requirements.

So, let us consider how LogRhythm meets some of our other requirements for event processing more generally. The first thing that we might not expect LogRhythm to provide is filtering capability but in fact it does offer this. In some cases this may be at source (for example, database logs) or, where this is not available (for instance, badge readers) then there are filtering capabilities in the platform that allow you to ignore uninteresting data. Thus LogRhythm could potentially address the sensor-based market for RFID, SCADA, ANPR (automatic number plate recognition), GPS and so on.

Where there is a limitation is with respect to the correlation step. In my previous article I identified three possible correlations: with other events, with patterns of historic events and with business rules. Working backwards, LogRhythm includes business rule capability and it has data mining and trend analysis capabilities as well as anomaly detection so it is only when it comes to complex event interactions and such things as derived events that it is likely to fall short.

One other feature that is lacking in LogRhythm is with respect to alerts. The product certainly supports alerts but there is no facility for alerts to automatically start a business process, for example, or to trigger other sort of actions. This wouldn’t be hard to incorporate but has to be considered a weakness if we are thinking about using LogRhythm outside of its native markets.

To conclude, taking LogRhythm as an exemplar of a company addressing the SIEM market it is not far away, if at all, from addressing all of the needs of what we might refer to as the business event market with the exception of the more sophisticated correlation of events and the ability to trigger business processes. In my next article I will look at this from the other side of the coin, before we start to reach any conclusions.