Choosing a SIEM Solution

by asdfasdfasdfasdf on August 16, 2012

So many names. It always reminds me of the line from The Devils Advocate when Al says “Oh, I have so many names”. Security Information Management, Security Information and Event Management, SIM, SIEM, Log Management, Log Aggregation. If you really like to use buzz words you could call this Big Data for Security.

This technology can be great. If implemented correctly you can find security and fault management issues in your environment as they are happening rather than trying to figure out if something has happened hours or months later, which is usually what happens IF they are noticed at all. If you are not familiar with the technology the basic concept is to configure all networked elements to forward events to the SIM. This allows you to;

Centralize events – if everything is in one place it’s much easier to search for something.
Normalize events – if the format of the events is the same we can actually search for things.
Search events – perhaps everything for a period of time or for an IP address or username.
Report on events – provide executive summaries on security and fault issues on a regular basis.
Correlate events – configure some logic so that if certain events happen within a specified period of time an alert of some sort can be generated.

If the system is efficient enough to be able to search for events you may as well look for the opportunity to be able to correlate events. A security example could be you have disabled the Windows account named administrator on all systems in favour of using your administrators user ID’s in order to ensure accountability over administrative tasks. You may want to monitor for the use of that user account proactively so that If someone uses the account the SIM will send the relevant information to the entire team right away to take action. A fault management example could be to monitor for critical switch port interfaces or web services and if they go down immediately alert the appropriate people.

There are a few things you will want to discuss with the vendors to ensure you get the solution that’s right for you.

Crucial information to figure out which one will be best for your environment are the types of event sources you want to centralize and approximately how many of each. SIM manufacturers are trying to determine the EPS ratio or Events Per Second. This is required for capacity planning. The other thing you will figure out is whether or not the solution will support all of your devices and applications.

The following factors will make sure your SIM project is a success;

Events Per Second (EPS) – This is the rate at which your networked devices will be sending events to the SIM. If this number is not calculated correctly the first thing that will happen is that the SIM will start to drop events before they are stored in the database. Think about a back catcher trying to catch 10 balls at the same time. If you are dropping events before they are able to get used by the SIM your searches, reporting, and correlation will all be incorrect and misleading. Again most SIM manufacturers will be able to help determine this number by the number of and types of networked devices you have, and the number of users.
Storage – If the SIM is not sized correctly you won’t be able to keep the anticipated number of events for the desired amount of time. It’s like filling a gas tank. If the tank is already full you need to burn off (or delete) the gas before you put more in. The issue is that if you want to be able to look back three months for forensic or compliance requirements you may no longer be able to. Know how long you want to be able to go back on the fly during the sizing phase. Three months is pretty standard.
Parsing – A key feature of log management is to normalize events to put all data in the right fields so that it can be queried. For example a Cisco firewall may have the time in a different format than a network intrusion prevention system. In order to search all events for that specific time they must all look the same, otherwise referred to as normalized or parsed. If the SIM doesn’t support all of your critical systems and applications out of the box it’s not the end of the world. What it does mean is that you are going to have to write some parsing rules. It is not extremely difficult but can be challenging and is definitely time consuming. Compare the list of device types you plan on getting events from to the list of event sources supported by the manufacturer.
Filtering – Because EPS ratios and storage are somewhat precious resources in SIMs there may be certain events from an event source that you don’t want to store in the database. The issue is that some network elements can send either all events or no events to a SIM. For example your Network IPS may have an informational signature for detecting DNS traffic. The only thing you may be using it for is monitoring for volume changes in DNS so storing these billions of events in the SIM may not be desired. Ask the SIM manufacturer about the possibility of filtering events before they get into the database. In some cases the databases are so efficient that it will not matter. Keep in mind the more you send to SIM the more useful it is, and the more costly it is.
Management – SIM architecture is very similar to other servers. You have the hardware, an operating system, a database, and the application. To manage each of these components separately is very cumbersome. It sounds like a normal day at the office but when you consider that some of the best SIMs come as an appliance, why would you waste your time with having to manage each component separately? There is enough to do with a SIM that you don’t want to spend months preparing for an upgrade. Look for SIMs that you can easily download and run a file to upgrade the system like you would a router or switch.
Accountability – who is responsible for managing the system to keep it alive and all the hardware and software up to date? Falling behind with security updates is more like eating stale dairy than stale bread. Making it easy to manage is key and assigning a single team to be in charge of updating the system and it’s content is important. The other responsibility is managing events. I prefer open systems within the organization. The security team may oversee the system and help develop content like correlation rules and filters, but the network, Linux windows, database, and application administers should have access too. They know their systems better than anyone and if they are willing to contribute correlation rule use cases the SIM will only get better. They may even want to be the ones to monitor their custom correlation rules. This will help reduce mean time to resolution of incidents, which is the entire point of the solution.