SIEM

SIEM - security information and event managers - have been with us officially in one form or another since 1996, although the term was not coined until 2005. Today they are a combination of classic SIEM functionality and log management. If we were to characterize classic SIEM capabilities, they would be aggregation, correlation and alerting. However, today there are many other functions that we expect from a competent SIEM.

SIEMs are made to order for compliance reporting because they have an ongoing view of the network as a whole. Equally, they are important forensic tools for the same reason. When an event happens - no matter when or where on the enterprise - the SIEM likely is the one device that is likely to see it.

SIEMs depend on data feeds from other sensors on the enterprise. These sensors may be netflow devices, such as routers and switches, or event devices, such as system logs, intrusion detection/prevention devices or firewalls. These provide data to the SIEM allowing it to see across VLANs, subnets, switches and routers within the enterprise. 

Most serious SIEMs have good log management/retention capabilities as well. Some SIEMs today correlate with cloud data - giving them the ability to see what is happening with other SIEMs around the world. This helps them make decisions about whether an event is likely to be malicious or not. 

Can your SIEM consume all of the data formats that your sensors create? For our purposes, a sensor is any device that sees events or flow data and can report it out of the device to the SIEM. Depending on the architecture of your enterprise, your SIEM should be capable of pushing or pulling from the sensor. In other words, it should be able to allow the sensor to push data to it - netflow devices like to do this - or to pull data (polling) from the device.

Is it appropriate for your SIEM to be a log manager as well as a SIEM? Storing and managing logs from numerous sensors is an important feature - especially in larger enterprises - because the logs need to be available for drill-down.

Next, what about reporting? Do you need compliance reporting? If so, does your SIEM have a selection of canned compliance reports that meet the appropriate regulatory content and format? Also, regarding reporting, what other reports do you need? You might want - and just about all SIEMs provide - executive reports. But how about remediation, technical details, etc.? You also might want to build your own reports, but even if you do, your SIEM should come with some canned reports ready to use.

How hard is it to deploy the device? Is it hardware, software or a virtual appliance? If you are in a virtual environment does your SIEM play nice with your hypervisor and guest devices and virtual routers and switches?

These are just some of the things that you need to consider. Today, a competent SIEM should be able to discover the network and develop an asset inventory, consume both threat (from your sensors) and vulnerability (from a vulnerability scanner) data, and apply that data to the asset inventory. Weighting the threat, vulnerability and asset data allows risk calculation, and that is an important capability of modern SIEMs.

Finally, the user interface (UI) is extremely important. There is a lot of information in a solid SIEM product and that information can be hard to sort out if the UI is cluttered. Look closely at your SIEM's UI and determine if it is too busy to be useful. In the heat of an incident, a cluttered UI can mean that you miss something important. Further, make sure that you can use the SIEM as an analytical tool under the pressure of an ongoing event. SIEMs are particularly useful in this situation, but if you have trouble sorting out what the device is trying to tell you, it loses some of its usefulness and adds to the frustration of an already difficult situation.

We believe that we have a good selection of competent SIEMs for you to peruse, so, in the words of emcee's everywhere, "On with the show!"