It looks as though my comments on OSSIM did not fall on deaf ears. They have, in fact, caused my comments to be lumped in with Anton Chuvakin‘s and massaged into something that reads as “OSSIM is not a SIEM” and “OSSIM is too difficult for S/MB and not reliable enough for the Enterprise”. Ummm….alright. Let’s clarify a few things here:

I have never said that OSSIM was not a SIEM.

In fact I was a big supporter of it early on but fell out of love with it when there was no visible progress over a 2 year period. I’m not blaming the developers, and I totally understand the Open Source ideals, but you can’t argue that a product is as good or better than a commercial alternative just because it is free and Open Source. To quote a Southern friend of mine – that dog won’t hunt.

Is it an Enterprise SIEM?

No, I don’t believe it is (but am willing to be corrected). I see it as a great SIEM solution if you’re feeding it data from other Open Source products. Looking at the “collector” page, that lists the supported data sources, shows me that either the integration points are very generalized or the marketing material needs updating (for example it looks as though OSSIM can collect data from Microsoft Office and Netscape based on the logos). If I were in the market for a SIEM solution and saw the “collector” page I’d be just as confused as when I started looking.

When I last tried to use OSSIM I deduced it wasn’t user friendly enough for a SMB to use.

When I install a product, I don’t want to have to jump through numerous hoops to get it up and running. Back when I tried to install OSSIM I was sent all over hell and creation to find the required packages to get it up and running. This is not user friendly. Maybe I’m lazy…maybe I’m just too busy to screw around with a product to poke and prod it into working for me. Maybe this has changed since I last tried it but I’d need some serious convincing to go back.

Am I willing to give it a second chance?

Sure! I’m a big proponent of all SIEM technologies and would certainly open my mind to trying it again. I would, however, want to run it along side of a couple of enterprise SIEM solutions to see how it stacks up. I wouldn’t want to just evaluate the technology but would also like to see how the paid support stacks up against enterprise SIEM support channels.

Dom, If you’re up for the challenge, let me know 🙂

If you expose the dirt on your lawn by cutting a big square out of your grass, you can’t just stop there and say “Done, I now have a garden.” In fact, all you have is a big dirt square that will eventually regrow the grass you just removed from it. In order to create an actual garden you need to build the foundation, plant the flowers, and maintain the garden so that it continues to flourish.

The same can be said with any Security Incident and Event Management (SIEM) solution you buy. Just because you purchase a box, or a piece of software, that the marketing material says is a “SIEM Solution”, doesn’t mean that racking it and turning it on is the end of the project life cycle. Just like a garden there needs to be proper preparation, implementation, and maintenance for the program to succeed.

Preparation

Alright, so Vendor A calls you up and tells you how great their SIEM solution is, what it will do for your [security | compliance | log management] project, and why you should buy it before their end of quarter. That’s all well and good but you’ll also get the exact same calls from Vendor B, and Vendor C before the week is over all promising the same puppy dogs, ice cream and unicorns that the others were. The question is – Which one is right for my environment?

When you decide that you’re going to plant a garden, there are several factors you need to consider before rushing into it. The first question is – Where do I put it? This is a very important question because it will influence the types of plants that will grow in your garden. Most, if not all, plants and/or seeds you buy from a store will have some manner of instructions on them. Seeds will usually explain the conditions required for optimal growth on the back of the package while plants will usually have one of those plastic/paper inserts inserted into the soil. Some plants require full sun while others require some measure of shade. Do you put it out front where your kids play or out back where the dog, or other animals, might dig through it? How much natural rain water will the garden get or will you have to rely totally on manual watering?

These are the same kinds of questions you should be asking yourself when deciding on a SIEM solution. Not only do you need to read about what the product can do but you need to be able to distill what is important to your environment. If you are a predominantly Cisco and Microsoft Windows shop, what good is a product that prides itself on Juniper and Solaris integration but has serious deficiencies when it comes to Cisco and Microsoft integration? That is like planting a flower that requires full sun in the shade. It’ll look nice until it dies a horrible sunless death.

You also need to figure out where the best location is in your network for this solution. Most SIEM products are made up of collectors and centralized processing points. One thing you need to consider is if you put a collector in one [rack | building | city | country] will it be able to offer you the visibility that you’re looking for or will that location only be giving you a portion of the total picture? Maybe your collection infrastructure needs to be bigger or maybe, like a small garden, it can be built out over time.

Keep in mind that, like a garden, you’re probably not the first person to ever undertake such a project. When starting a big garden project you will typically ask the experts, such as greenhouse workers, friends, and colleagues, for their input. These people have valuable advice as they have made the mistakes already and can offer you advice on how to avoid the roadblocks that they encountered. Just as you would ask a greenhouse worker for advice, ask the vendor for references that you can speak to without the vendor on the phone. The reason you don’t want the vendor on the phone is because you want the people you are talking with to feel like they can discuss the solutions pros and cons without feeling cornered. Often, when the vendor is on the phone with them, they’ll hold their tongue and that doesn’t give you the full picture you’re looking for. You’ll also want to ensure you talk to both management references and technical references because each will have a different view on how the project progressed.

Hopefully this gives you some things to think about before rushing into purchasing a SIEM solution (or starting a garden for that matter). In my next post I’ll discuss the implementation phase of your SIEM project.

If you find yourself explaining how network address translation (NAT) works, you might know more than your SE.

If you find yourself having to explain what certain acronyms mean (like NAT), you might know more than your SE.

If you have to explain the difference between a Crossover cable and a Straight-Through cable, and why it matters that they are different, you might know more than your SE.

If they have ever muttered the phrase “Well, it’s never done that before”, you might know more than your SE.

If they admit to you that they have never before used the product themselves, you might know more than your SE.

If they truly believe that their product is “hack proof”, you might know more than your SE.

If talking to the SE at their booth has you wondering if they are the “booth babe” or not, you might know more than your SE.

If they think that a packet is something that chips come in, you might know more than your SE.

If they have never heard of a competing product for their offering, in a space where there are at least 20 competitors, you might know more than your SE.

If they think cryptography has something to do with cemeteries, you might know more than your SE.

If they think that Open Source is a skin condition, you might know more than your SE.

If they giggle when they hear the terms intrusion, breach, or IP, they could be either be 7 years old or it might just be that you know more than your SE.