LogRhythm NextGen SIEM Review

Delivers actionable intelligence to our security engineers but we need it to ingest more sources

Video Review:

How has it helped my organization?

We did a bake-off with several others when we brought in LogRhythm, 10 months ago. And a lot of it was around a cost perspective. Also, its capability of easily ingesting event data from many different types of platforms. 

Some of the competitors require the use of agents that are deployed on those various end-points, or they'd be servers or otherwise, to ingest it. So this is a much quicker deployment. 

And through their upgrade processes that we've seen, it makes it a much more streamlined process, rather than having to touch on multiple end-points.

What is most valuable?

Any SIEM, in and of itself, should be easy to ingest data, it should also be easy for the analyst to assess the different types of events that are coming through, be able to sift through false positives, and ensure that they are only acting on things that are truly actionable, that need to have attention. It's not one of those things that you want to have analysts spending a lot of time on, and then seeing false positives in the system. It just gets to a lack of trust within the system.

LogRhythm has shown to us, to this point in time, that it has the capabilities of being able to deliver actionable intelligence to the security engineers and analysts.

What needs improvement?

The biggest thing that we need - in one of the presentations today here at the LogRhythm User conference they were talking about it - is automating your SOC and trying to get your systems to do as much as they can do without human intervention. Which is great. 

I provided feedback afterwards to say, "We need to be able to ingest all data. And we need to be able to parse all data." What that means is, my Checkpoints that I have today, which is my unified-threat management system, I'm only able to ingest firewall logs and events from the blade. I own all the other blades from Checkpoint: IPS, Threat Emulation, threat detection, Data Loss Prevention. All of those blades have data that I need to be able to feed down into LogRhythm. From there, we also need to be able to truly parse the data. I've had to have a couple of custom collectors built specifically for SQL Server-type events, for database analysis, to ensure that the data that's being brought in, the events are parsed, we can be actionable on that.

What do I think about the stability of the solution?

Stability has been, for the most part, quite good. We do have a HA, High Availability configuration, between two different datacenters. 

There have been a few challenges that we're working through. Mostly it's a Windows-based, all-in-one appliance that we have. We are in discussions with LogRhythm support right now in respect to HA breaking through automated patching. But we're encouraged that we're going to be able to get over that hurdle, and then we'll have a 100% up-time with it.

How is customer service and technical support?

As the Security Officer of the organization, I don't have to interact with them directly. My team has found that there are some very good engineers that they've been engaged with, and have been able to work with them throughout different issues. They've said a lot of good things about the support portals; better than some of the other technology products that we offer. 

I know some of the other technologies that we use for our unified-threat management systems and the like, some of those portals are a little bit more cumbersome to actually put in support tickets. LogRhythm seems as if they want to really engage with you, so they don't make it overly cumbersome to put in a ticket.

It's been fairly good interaction, with the capabilities that they offer to quickly get an engineer on the line.

Which solutions did we use previously?

We were a QRadar shop for five years prior. To be honest, the product was great initially, when it was a Q1 Labs product. Things started to change a bit after IBM's acquisition of it. So we were looking to see if there were better alternatives. The top-two were LogRhythm and Splunk. 

We did a several week SIEM solutions comparison between the two of them. Splunk is a great product in and of itself, but it was too massive for us, for our size of organization. As well, it looked like it would require a little bit too much of an analytical programming background for my engineers and analysts, which they don't have. So they were really most satisfied with the LogRhythm platform, its capabilities, the ease of use. And then, from my perspective, from the company's checkbook, the sustainability of it, the upfront cost, and the long-term ownership of it.

How was the initial setup?

I did oversee the implementation, and the initial setup that we did seemed to be fairly straightforward. My engineers were very happy with the simplified installation process. 

Being an all-in-one appliance, that helps a lot in the initial setup. You rack it, you perform the updates, being a Windows box. And even some of the software upgrades that we've done since our initial purchase and installation, those have been fairly trivial as well.

Which other solutions did I evaluate?

A lot of the competitors, IBM specifically, there's these WinCollector and other types of agents that you have to install and push the event data to the SIEM. 

LogRhythm is more of a collection using APIs to pull the data down, so it's much more efficient. And you don't have to get any of the other areas within infrastructure, or the application teams, to participate. You just go and point at the systems, assuming you have the correct level of authorization and credentials, and then the data is ingested naturally.

What other advice do I have?

The solution, one to 10 at this time, would probably be a strong seven. Right now there is the concern about being able to gather all of the data into the system. That's key. It's one of those things, pre-sales versus post-sales, what is said can be done, and then what actually is fruition. There is only so much you can do in a proof of value, or what they sometimes call proof of concepts - in those bake-offs - because you only have a limited amount of time with it to do that connectivity, and analyze. It really is that integration and some of the customization that we've had to do from parsing rules, not only for SQL Server, but also for ingesting NetFlow data from our Gigamons - which is the core of all of the network activity that happens within our environment.

With this or any technologies, that pre-sales process is key. Really asking the intricate questions, try to get them to talk in-depth about the capabilities. Just saying that, "We have integration with this technology or the other," is not sufficient. You really need to have a good understanding of the capabilities that you are looking for, what your systems are capable of, and what you need that integration to be. The last thing that you want is to get in there and say, "Well, it works. But it only works 30% with that." You want it to be 80% at a minimum or better.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Add a Comment
Sign Up with Email