Thursday, May 23, 2013

Selecting an SIEM Solution For Your Organization Simplified

Selecting the correct Security Information and Event Management (SIEM) solution for your organization is not an easy task. The purpose of this article is to educate you why you should or should not have an SIEM solution, what key areas to look at when acquiring and SIEM solution and I'll also give you some of my own opinions or certain vendors and options.

SIEM is an hybrid of two products SIM (security information management) and SEM (security event management). SEM technology evolves with real-time activities such as real-time correlation, alerting, dashboards, etc. SIM component is responsible for retention of logs for log-term analysis and forensics, reporting, pattern discovery, etc. Most of the leading SIEM vendors now provide ticketing/workflow management systems, integrated knowledge-bases various other components integrated to their SIEM solution.


Are You Ready for an SIEM Solution?

Deploying an SIEM solution is not like deploying a point security product; it requires a lot of integrations, tuning and customizations to be done. SIEM solutions require organizations having a certain level of maturity in their information security posture. This maturity should be there in IT infrastructure, IT governance/security practices and in the workforce in the organization.

SIEM solution is only good as what you feed into it. So if your organization still do not have a firewall, anti-virus solution or an IPS, SIEM solution is not going to help much. It's also true for information security practices in your company. If you do not have any information and asset classification scheme, policy for logging, incident response plans and procedures, etc., the SIEM will not be effective in the organization.

I have personally seen organization going for SIEM solutions too early and loosing faith in the solution. Therefore make sure that your organization has matured enough for an SIEM solution.

Building from Ground Up


Most of the organization do not straightaway go for event correlation with an SIEM system. They initially start with SIM (log management). Then they transition to a full SIEM deployment. This is beneficial for organizations who do not even have a centralized log management in place. So the individual do not have much idea about the volume, storage requirements, other resource such as bandwidth required to collect, store and analyze logs centrally.

SIEM solutions generally cost a lot. If your SIEM solution is not doing anything for few months is a waste of money. SIEMs in fact require some getting used to. Identifying and familiarizing with the logs takes some time too. So having a log consolidation solution first is a good transition for the the IT staff.

Identify Stakeholder requirements


Generally SIEM has a lot of business units that interact with it. Information security/risk and compliance, internal;/external audit, incident response, networking, sys admins, system owners, etc. So you need to identify different requirements of these business units. Some are achievable other are not through an SIEM.

In my experience, when we say correlation people think SIEM as a mysterious box that can do magic and give them everything they need.

Let me give you an example. One question I got from a client of mine was that "can your SIEM solution checked who viewed the files on my file server". Then I asked, "do you have any solution to monitor that activity". He stated that they were just using a windows share. I explained to my client that, if there's a separate solution/mechanism to monitor users activity on the file server and log it, then I can incorporate that log into the SIEM, otherwise SIEM product alone does not have any capability to do such thing.

After identifying the requirements, you should determine weather the requirements are mandatory or optional. Optional requirement are "the thing that you can live without". It'll also be beneficial, if you can assign a priority value for these requirements. So if the budget permits, you can select the most important optional requirements first.



The two main component that you should determine if the rate of logs produced in your organization and the log retention requirement. The rate of logs is typically denoted as Events Per Second (EPS). Most of the SIEM solutions are based on EPS value, plus some additional criteria such as number of log sources, etc.

How Do I Calculate My EPS Value?


If you do not have any idea about EPS value of your organization, there are ways that you can estimate these values. Most of the vendors have created EPS calculators. These calculators use typical EPS values that each device produce. We'll look at this in detail later. However this is an estimation. However I have been able to estimate average ESP values using such calculators quite accurately. Similarly you SIEM vendor or the systems integrator will be able to estimate your EPS value if you do not have any idea about it.

The second and the more accurate way to calculate this EPS is through a PoC (Proof of Concept) implementation of the product. Most of the vendors welcome the opportunity do a PoC with their product in your environment.This is also a good opportunity for to get a taste of the product. The other benefit you get from the PoC is a sense of what the EPS in your environment is. You can easily extrapolate the EPS value from your PoC to your organization.



The second most important factor in sizing the solution is the log retention period. Retention period is generally dictated by a regulatory or internal security policy requirement. There's a good chance that you don't have any say in the retention period.

However when sizing you SIEM solution, you must take one other factor into account. That is, how long do you want the logs to be "online"? SIEM gives you ability to analyze and generate reports on the logs in it's storage. It only has the ability to do this while logs are in it's "online" storage. When the online storage is filled or once a log reaches its "online retention period" it's either moved to a secondary storage (SAN, NAS, file server, etc.) Once that's moved you do not have the capability to analyze it (there are few exceptions for this, but for most of the cases this is the case).

Most of the SIEM soltions give you the ability to bring back archived logs into the online storage and make them "online" again. So you still have the ability to analyze archived logs. But lets say that your organizations management require give them quarterly reports. Then you should consider at least keeping 3 months of events in the online storage.

It's ideal if you can keep all your logs online for the entire retention period, but it would be very expansive to do so. Therefore the total retention period is divided into two: online retention period and offline retention period.

Once you know the online retention period, you must determine how much storage is required to retain logs. Again, you can use the same techniques that you used to calculate/estimate EPS to determine the storage requirement

Sid note: SIEM solution compress events in it's storage, typically about 10:1. So when an SIEM vendor say they have 42 TBs of event storage, it means that the device can support up to that much uncompressed event; not that the SIEM box has 42 TBs of hard disk storage.


By now, I hope you have some understanding about what you should look at when you are selecting an SIEM solution for you. In part two, I'll be comparing products.

No comments:

Post a Comment

Please note that comments are moderated in order to stop comment spam. Comments with unwanted links (those who are trying to use blackhat SEO) are reported as spam.