Since the term security information and event management, or SIEM, was coined by Gartner in 2005 there have been a lot of changes in what constitutes a SIEM product. Originally, the acronym was a combination of security information management (SIM) and security event management (SEM). This was presumably fairly straightforward. Today, a scant eight years later, what goes into a SIEM is not quite so well-defined.
According to Gartner, a SIEM should have the abilities of "gathering, analyzing and presenting information from network and security devices; identity and access management applications; vulnerability management and policy compliance tools; operating system, database and application logs; and external threat data." That seems pretty broad, but actually it comes down to some pretty specific requirements.
In order for a SIEM to work, it needs data. It gets its data from a wide variety of sources that we can think of as sensors. However, all of this data needs to be aggregated into a single addressable dataset. SIEMS do that. Then, they correlate the aggregated data to make sense of it. That includes normalizing disparate data formats into a single form that can be consumed by the analysis engine of the SIEM.
Once the data is correlated, there is a lot that can be done with it. First, of course, is that it can alert to security conditions that need addressing immediately. In this regard it is sort of an intrusion detection system (IDS) on steroids. It is receiving data from lots of sources and each of those sources is contributing to the picture the tool sees. How that picture is interpreted should be, in large measure, configurable. Most capable SIEMs have robust policy engines that allow customization, but also have many commonly used policies available right out of the box.
Second, the data can be used for reporting. Reporting is a critical aspect of regulatory compliance. It also allows administrators to see what the SIEM sees broken down into meaningful charts and graphs. Reporting can be file- or paper-based or it can be real-time displays useful for analysis. Analysis is another important aspect of the SIEM. In the early days of these solutions, they were much better for analysis than they were for compliance reporting. Today, SIEMs should be able to create regulatory compliance-specific reports.
Because these offerings often can take vulnerability data from tools such as Nessus, they have the ability to calculate IT risk. The data that comes from various sensors is threat data and this is the meat and potatoes of the classic SIEM. However, risk is a combination of threats and vulnerabilities, so when the SIEM takes vulnerability data as well as threat data, there is the potential for risk measurement.
Developing a risk picture, however, is not quite that simple. If we look at the enterprise on an asset-by-asset basis, we find that some assets are more critical or sensitive than others. So, for a credible risk picture, the SIEM must not only be able to take both threat and vulnerability data, it must be able to parse down to the asset level. And, from there it must be able to weigh assets based on sensitivity, criticality or both.
Further, SIEMs retain data in a variety of ways. Some keep entire logs, and their drill-down capabilities let administrators go all the way to the source files. Some retain metadata parsed from the logs. In that case, drill-down usually gets header information and that is all. The tradeoff is the space required for archiving full logs.
While SIEMS are not inexpensive, prices have come down over the past few years. When selecting a SIEM, don't judge cost of ownership based solely on price. The most important metric is the value in your environment.
The number and types of sensors are the only criteria to consider. Where the data is being collected on the enterprise is critically important. Also, it is useful to be able to feed flow data into the SIEM. This provides data flow vectors that help identify paths that attackers or malware take.
