Welcome to the last installment of this blog about SIEM. In the first 3 blogs we’ve covered what SIEMs are, the basics on how they work, and the pitfalls that have befuddled many a SIEM deployment. So what is it you need to get the most out of a SIEM system, and so you don’t become another statistic as a failed SIEM deployment?

Well let’s start off with a bit of planning. Before you send out your first RFI, you should document a few things. First off, make a list of problems you are trying to solve (“buy the right SIEM” is not an IT or infosec problem). What is your driver to get a SIEM in the first place? List the specific goals that will eliminate the problem you’re facing; i.e. what needs to happen for you to reach those goals and to solve the problem?

Second, start breaking down the goals into requirements. Lets take a real life example and say your “goal” is to be PCI compliant, so your problem then would be that you’re not PCI compliant. Start off listing the requirements in PCI that you’re facing. If you can’t list the requirements you need to meet, then you’re on the road to fail-ville. Take a minute and educate yourself on the problems you’re facing. Go over to the PCI counsels web site and spend a few hours getting up to speed so you know what requirements you need met.

Ok, so now you know what your problem is, and you’ve educated yourself on the requirements you need to meet. Nice work! Next we need to create a basic scope of what your SIEM solution needs to do. So if PCI is your driver and you’ve read the PCI requirements you know you need to retain all your log data for 12 months with 3 months available online for the SIEM to access. That’s requirement #1 for your SIEM. You also know you need to collect log data from all devices that have access to your PCI data, so start putting together a list of devices and the logs they generate. And don’t forget to include ALL log sources from each of your devices – a Linux server running Apache and Tomcat for your web site create many other logs then just those two, so don’t forgot to include them (remember what else is in /var/log). So requirement #2 is that the SIEM needs to be able to accept at least the sources you’ve listed. You get the idea, what we’re doing isn’t ground breaking.

So now lets take a look at where you’re at: you have a document explaining what your goals are and the problems that you’re trying to solve, the rough requirements you need to meet in order to reach your goals, a list of devices and log sources you need to collect and you’re starting a list of requirements of the SIEM. Let me tell you right now, if you’ve done this you are already way ahead of most companies when they start looking for a SIEM.

Here is something like what you should have:
Problem statement: We failed our last PCI audit and are not PCI compliant because… (include sections or gaps noted in audit) Goal: Become PCI compliant and pass next audit Requirements: To become PCI compliant we need to meet • PCI 10.1 • PCI 10.2 • Etc… Data Sources: • www1.host.com: Linux o /var/log/secure o /var/log/apache/access.log o Etc… • email.host.com: Windows 2003 Server o Application log o Exchange log o Etc… SIEM requirements: • 12 months data retention (PCI) • 3 months data available for searching (PCI) • Accept all log data list in data sources above • Etc…

Now that you know what it is you’re looking for, it’s time to ask yourself again if you think you still need a SIEM. If you answered no, then I guess you can shut your computer down and go ahead and take the rest of the day off.

Ok, for those of you still with me lets look at the rest of the list of things you’ll need to make your SIEM work. If you haven’t already guessed from the previous postings, the most important thing you need to make SIEM work is resources. If you put zero dedicated resources into your SIEM, you’re guaranteed to fail. Period.

No, this isn’t a “virtual” resource. This isn’t 4 people all spending 1 hour a day “using” the SIEM when they are done with their normal job. No, we’re talking a 100% dedicated SIEM resource.
What people often seem to forget (or maybe mentally block out) is the end product of a SIEM: work. Remember why you wanted a SIEM in the first place? You wanted that automagical correlation that alerts you to all the cool stuff it finds. While the SIEM does find the problems, sadly it’s won’t fix them for you. So yes, you need a resource at 1:00am when the SIEM detects a possible penetration. You’ll need resources from the IT guys for remediation and patching. And who is that person going to be who has to verify all those problems have been fixed?

After all you’ve read, you weren’t still thinking a SIEM was going to make less work, were you?

So what kind of skills does this resource need to have? Again if you remember what we’ve talked about from the previous blogs you might already have a good idea. Your resource obviously needs to be a skilled security analyst so they know what a to look for first and foremost. This person obviously needs to become an expert with your SIEM so they can actually use it, which will require training and time to simply use it.

From here, you now have someone working with and monitoring your SIEM system, at least during business hours. This person isn’t doing much remediation, isn’t doing the bigger in depth investigations, isn’t doing patching or any of the other work that will need to be done – so keep that in mind.

Now lets say you have a larger deployment and you’re collecting gigs and gigs of data per day with hundreds of thousands of events, 24 hours a day. Is that one resource working 9-5 going to cut it for you?

I’m sure you’ve heard the latest buzzword and the hype around “continuous monitoring”. Your SIEM will watch for events 24/7, but whom is it going to talk to? Do you need a SOC, or a virtual SOC of some kind so you can get that kind of coverage? Again, what are your original requirements – look back at them and then you should be able to answer that question.

Of course all this requires a process, and policies wrapped round it so it works correctly. What’s the process for adding a new log source? What’s the process when the SIEM detects a possible event? What’s the process when the SIEM detects something serious? Getting back to PCI, what is your process for PCI compliance (like looking at your reports on a daily basis)? All these things need to be put down on paper. This usually takes about 6 months to get down and refine, all as the SIEM resource learns the product and management learns how the SIEM delivers it’s product and how it all fits in with the companies existing processes.

With the RFI and PoC process taking about 6 months, and once it’s installed and running, another 6 months for the company to get fully up to speed with it, you’re looking at a year or more before you will start to see real value in your SIEM. I think this deserves repeating: it could take 12 months BEFORE you start to see the real value of your SIEM investment.

So there you have it. A SIEM is never as easy as the sales guys pitch it in their power points. It requires you do a lot of work before hand, and once the SIEM is in place, it requires a lot of work to get what you expect out of it and to keep it running. The human factor is the biggest variable in a SIEM deployment and if you go into this process knowing that, you’ll be raising the odds of your success.