SIEM: Comparing available SIEMs

This is an article of a series on a group of security products known as SIEM: security information and event management. This article introduces SIEM.

You have decided to get a SIEM since you need it in your environment. Vendors will soon present to you on the merits of their SIEM and how their product is superior to the competitions. How do you cut through the jargon and understand whether the product fits your needs? Here are some of the things that different SIEM products perform differently.

User-friendliness
This might be harder to measure than you think. Note that there are different types of users in every environment. “Using” the SIEM (i.e. running reports and searches and looking at dashboards requires one level of user). With some SIEMs, the user can simply type in a keyword or an IP address and instantly get query results from days of logs. With others, they may need to learn the syntax of a search query. In some cases the search query syntax can be learned in minutes. In other cases, a really good query may require knowledge of regular expressions which require analysts with technical talent.

Administering the SIEM and creating reports and rules typically requires users with a higher degree of technical knowledge. They also need to find the SIEM friendly to use. In some cases, it is very easy to extract out the results of a search as a report and save the format for later use. In others, it is more complex, with multiple modules needing to be created prior to arriving at the final output. Likewise some SIEMs allow correlation rules to be created with just a series of mouse-clicks from a search output. Some others may not have this functionality.

User-friendliness should be a key criteria when there are no dedicated personnel handling the SIEM. If you have a small security team (or worse, if you have no dedicated security team, this will be a significant criteria).

Setup time
Some vendors advertise ‘turn-key’ products that can get up and running in minutes. Always take with a pinch of salt any promise of instant security. What these provide are a check in the “do we have a SIEM?” checkbox for people with compliance requirements. Given that, setup time still varies among products. Some vendors will have multiple types of products with differing setup times that are worth considering.

Why do these setup times vary? Often the products may be a ‘starter pack’ with a small subset of features or they may turn out to be not very customisable or extensible. Consider whether the product will also fit your needs a few years on when purchasing something that has a short setup time.

Extensibility
Depending upon the environment and the your initial motivations behind getting a SIEM, your need for storage space may change slightly or drastically over the life of the product. Enterprise-grade products ought to be extensible, either by adding storage to the existing setup or by having another instance of the product software running that can be integrated into the current setup. In some architectures it is possible to run a search from one component on all components in the infrastructure. In some other architectures, a selection of events flow up to a higher level manager where these key events are analysed.

Customisability
Customisability, along with extensibility, are occasionally antithetical to user-friendliness and setup time. Some products come with a large number of use cases that are effective out of the box, but are not customisable or are hard to customise. Others are used best when they are heavily tailored to the environment and allow a great deal of customisability.

Environments with fewer analysts (or no analysts) may not need the customisability option so much. Security operation centres and large environments will work best when the use cases are tailored. These environments are also more likely to have dedicated personnel who can learn the SIEM thoroughly such that the user-friendliness and intuitiveness of the SIEM is less likely to be a problem.

The above four are criteria that help with evaluating traditional SIEM. The below capabilities are now becoming more relevant and useful in improving the effectiveness of SIEMs.

User behavior analytics
While dealing with ‘events’ generated by devices is key to SIEM functionality, attaching those events to actual flesh and blood users performing actions, legitimate and illegitimate, is of considerable value. Today’s SIEMs either have this capability built in or can add in this capability as an extra module. This should be a part of your consideration especially if you look into insider threat (you absolutely should)!

Artificial intelligence / machine learning / anomaly detection
Different companies will call it by different names. The crux is to go beyond pre-built rules to let the machine analyse normal patterns of behavior and inform the analyst of anomalies. The technology is not foolproof, but this is the future.

Get your vendors to do a proof of concept (POC) so that the SIEM demonstrates its value. Have your technical staff evaluate the product based on the criteria for your environment before you make your decision.

Also check out these resources:
My previous article introducing SIEM
Anton Chuvakin’s blog at Gartner is a great SIEM resource 

I am speaking at the CSX 2016 Asia Pacific conference (14-16th November 2016) on SIEM. Check it out: http://www.isaca.org/cyber-conference/csxasia.html

SIEM: Security information and event management

This is the first article of a series on a group of security products known as SIEM: security information and event management.

You are probably familiar with the fact that most computing devices log a number of events that happen on their systems, e.g. a user logs into Windows; an antivirus scanner detects a virus; a switch port is disabled; etc. As in a plane’s black box or a written log of events, the events happening inside computer systems have value: an administrator can understand what caused a user to get locked out of his computer; why the web server is no longer receiving traffic; where the origin of a worm is; etc. Since the logs are available, it will be of much more use if they can be readily accessed from a purpose-built system than if we had to go to each individual machine to retrieve them. Log management systems (LMS) were born out of this requirement.

A log management system collects logs in a central repository. This can be useful for after-the-fact reviews of incidents. What if you want to know in close to real-time what is going on in your computer infrastructure? This is where the SIEM comes in. SIEMs have considerably enhanced capabilities over LMS, but usually may not retain the logs for as long as purpose-built LMS.

SIEMs perform a few functions: they normalise, aggregate and correlate the logs. They present the logs in an easy to understand GUI. They are able to provide trending and analysis.

Normalisation: Logs come in various formats. It can require a bit of an effort to understand what logs from different products/manufacturers are trying to say. SIEMs simplify this by standardising the log content into fields that are common to the SIEM. The analyst has to understand the field within the SIEM. This is adequate to comprehend the logs.

Aggregation: There are some devices that send hundreds, perhaps thousands of similar events with just a few parameters including the timestamp differentiating between them. In the event that the distinctions are not relevant, a number of events within a short timeframe can be aggregated into one event, along with the total number of events represented in a field. This reduces the number of lines than an analyst has to look at.

Correlation: This is the key strength of the SIEM. Correlation is the ability to see relationships between distinct events that happen in the infrastructure. The events may originate from distinct products and can sometimes be separated by hours. If such relationships can be automatically found, it drastically reduces human effort in analysis. If a person’s remote login account is used and within a few minutes, their door card is used to access an office building, this might be something that security has an interest in. A SIEM can detect this sort of correlations.

Alerting:
The obvious next thing to do after detecting a correlation that is security-critical would be to notify the analysts of the event. This can be done via email, SMS, popups on their console, etc. SIEMs have the ability to send alerts close to real-time once an event or a correlation occurs.

Dashboards and reporting:
SIEMs come with nice interfaces that provide snapshots or current states of security in one’s environment. These may be snapshots in the form of reports, presented as charts, tables or a combination or they may be dashboards that show current states, maxima, minima, averages, etc.

 

SIEMs have evolved over the last decade and they now come with even more features. The ability to do user behavior analysis and integrate threat and network models are features that you will see in today’s SIEMs.

The ubiquitous Gartner magic quadrant for SIEM will give you an idea of the major players in the SIEM market as Gartner sees it. Take care to actually read their analysis and to look beyond the picture when you consider buying a SIEM for your organisation.

I will make a few more posts on SIEM in the next few weeks. I am speaking at the CSX 2016 Asia Pacific conference (14-16th November 2016) on SIEM. Check it out: http://www.isaca.org/cyber-conference/csxasia.html