Selecting an SIEM Solution For Your Organization Simplified

Selecting the correct Security Information and Event Management (SIEM) solution for an organization is not an easy task. The purpose of this article is to educate you why you should or should not have a 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 a 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 a SIEM Solution?


Deploying a 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 the organization going for SIEM solutions too early and losing faith in the solution. Therefore make sure that your organization has matured enough for a SIEM solution.

Building from Ground Up

 

Most of the organization do not straightaway go for event correlation with a 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 centralized log management in place. So the individual does not have many ideas about the volume, storage requirements, another 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 a 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 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 the different requirements of these business units. Some are achievable other are not through a 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. An optional requirement is "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.

Sizing

 

The two main components 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 the number of log sources, etc.

How Do I Calculate My EPS Value?

 

If you do not have any idea about the 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 to 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.

Retention 

 

The second most important factor in sizing the solution is the log retention period. The 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 the ability to analyze and generate reports on the logs in its 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 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 solutions 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 let's say that your organization's management requires to 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 its storage, typically about 10:1. So when a SIEM vendor says 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.


Summary

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





Comments

Popular posts from this blog

Configure Policy-Based Routing On Check Point Secure Platform

Disable DNS Lookup on Cisco Routers and Switches

gnmap2csv - Generate a CSV File from Nmap Scan Results