LogRhythm SIEM Reviews

I would say to us, the thing that matters most is the automation of the AI rules that are being sent to our emails to let us know what's happening within our network and within our environment.

When we set it up, we went through and probably turned on about 14 AI rules that we found to be really advantageous to us, and have tuned those over the past couple years. It's just worked out really well for us.

PCI compliance was our main driver for purchasing LogRhythm, but it turns out there was just a ton of other information that really came from having that appliance, other than just being PCI compliant and checking that box for us. 

Like I said, it was just more insight into our own network, our own users, our own flow of traffic, helping to alleviate a lot of that burden from our system admins by automating some of those alerts. So, all in all, it's just been a great fit for us.

I'm really excited about the CloudAI stuff. One thing I've asked, and I don't know if it's in the works or not, is for a better way to test our AI rules, to make sure they're working correctly, instead of having to manually go in to each one and doing an invalid login to see if the rule fires. Some better way to test all those rules that we have turned on and enabled would help.

Out of 10, I would give it an eight. We upgraded our firewall and that broke our parsing rules and it took a while to get that all fixed, but other than that it's been great.

We haven't taken in a whole lot of logs since our initial setup, so we haven't scaled it, I'd say, to its potential yet. 

We're on an upgrade path, we just got to 7.2.5 and we're on the beta program for 7.3 to get to CloudAI. Once we get that done, we plan on ingesting more logs, going to Office 365, pulling those down. So, we plan on really growing it.

Technical support has been great. I will be honest with you, I think that's one of the strengths of LogRhythm. Every time I've opened a ticket I've gotten a response back that day. They're great, they work through it. Even when we did our upgrade through Professional Services, she was great. She recorded the whole session so we could use that at our next upgrade. 

I've just found them to be tremendous.

For me, not having been in the security world, at least on the SIEM appliance side, it was a lot to take in at first. We had an onsite engineer come in, help us put it in play. We had a week's worth of training. All in all, it went pretty smoothly. 

There were gaps in our knowledge, I think, but that's where we opened up customer service requests and they came through and helped us out. But for me, personally, I would say it went well. It was just "a lot," it was new to us, it was new to our organization, so it was just a lot of information, but as far as it goes, it was pretty smooth.

We're really happy with it.

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.

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.

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.

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.

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.

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.

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.

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.

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.

• Visibility
• The AI Engine for rule generation

We have two facilities, a combination of all different platforms, Linux, Windows, etc. It's just all across the board.

It's definitely given us a lot of visibility into areas that we probably wouldn't have normal visibility into, such as code execution and things like that. It allows us to really drill down as to what's happening on the servers as they are being used in production, to where we can really get in and figure out what's going on.

It's pretty effective. In some cases we have run into some issues: The way that the rules work, and the alarms trigger. We get a good number of false positives.

I wish that there were more instructional videos on how to do different things and more walk-throughs.

Also, easier generation of AIE rules, or custom ones.

So far it's been really good.

Scalability is very good.

I've used LogRhythm tech support. I would rate it as very good, not excellent. For instance, we were trying to deal with pass the hash, which is a very common exploit and LogRhythm tech support told us they were just going turn that rule off, that we can't use it. We had to keep pushing until we had someone in another department push to an upper level of tech support to finally get it to where it was working.

It's very important for a solution to be a unified, end-to-end platform for us.

It's a really good solution. It's been very stable. At the same time, we have had some issues, some false positives.

And that issue I told you with tech support, there have been some challenges getting it to be where we wanted it to be, for a solution, like LogRhythm, that is supposedly best in the industry. I just thought it was kind of poor that they would take a common exploit that's been in use for years and say we can't get it to work when, obviously, they could get it work. It was kind of lazy.

Still, I would say go with LogRhythm.

• SmartResponse flexibility
• Ease of use
• Ease of administration

Overall, versus competitors, it is a lot easier to use, a lot more user friendly, but it still gives you a lot of flexibility to do whatever you want. The limit is your imagination, for SmartResponses at least.

We've actually been able to use it to show that we need more people, because we're going to be doing more. It's the center of our SOC, but we are starting to use it for operational things as well, not just security.

I would like to be able to use the Web Console, but because of our volume I can't.

Also, it needs to stay healthy. A lot of the problems seem to pop up out of nowhere, and a lot of them seem to be somewhat debilitating. We were fine for a long time, and then eventually one day our processing just dropped. I ended up talking to support for something like a month, and eventually I got to someone who said, "You should check the BIOS settings on your data processors and your indexers." Turned out there was some read-head caching setting that wasn't enabled by Dell. We were fine for over a year, and then all of a sudden, problems.

It's a great tool, just random dragons seem to cause problems.

Hit or miss, it depends. A month or two will go by and everything will be fine, and all of a sudden, something breaks. Then it's in the air for a little while, and then I manage to figure out what is causing the problem, fix that, and then everything is fine for a couple months. Then something else happens.

It's different every time. One specific example, I think it was related to a KB-update that basically broke a log source type, that was doing tens of millions of logs per day. And that just trashed our data processors. It put everything behind, we went down to single-digit processing, blocks-per-second processing, for a period a few weeks. I had to rebuild all the MPE rules into a new log source policy, and then everything was fine.

For a few months everything was working and then all of a sudden one day it just goes into the toilet. We didn't do any upgrades, nothing like that, so that is why I'm thinking KB-update, but I haven't pushed it.

It's pretty good, it's easy to add parts, it's pretty easy to do that. It's just expensive sometimes.

When we started, we had one platform manager, and two DPXs. And then we added this second organization, network domain, etc. Then we realized that we didn't have the infrastructure we needed to support everything. We were able to buy five DPXs, etc.

On a scale of one to 10 , it's a seven to eight.

Once you have escalate and validate, it's pretty easy to get to someone who knows what they're doing, and has a lot of the expertise in that specific area.

I know that it came down to LogRhythm, Splunk and ArcSight. They ideally wanted one person to administrate and run the whole system, which is why the other two got the boot and LogRhythm was chosen. That was the most important criterion in selecting a vendor.

It's not perfect, but no solution is going to be perfect. If you have one person that you can dedicate forty hours a week to the SIEM it will be fine.

• The SmartResponse and the alarming
• The ability to write your own rule set

It allows us to delegate some of the alarming, where there's not just one person looking at it all the time. Some lower-level techs can handle basic alarming.

Sometimes our rules don't fire correctly, events don't get created correctly, but that's mostly just because we have to write custom regex.

Also, moving from away from the fat console, more into the web console for log sources and tuning and things like that, would be helpful.

At times It gets a little clunky, or resource-intensive, but it works.

It works pretty well. It's somewhat hard to delete something out of the system. That's probably our only challenge, because we reuse an IP address and then it's difficult.

We've used them a few times. They were pretty good.

We actually weren't using anything before. It was a conglomerate of a firewall and the Windows logs. But we had an IT architect that was more into security.

It was pretty easy.

Regarding a solution being a unified, end-to-end platfrom, it helps, but it's not completely necessary.

For what it does, LogRhythm works pretty well.

If I were to advise a colleague who is looking into a this solution, I would say train someone, as their full-time, job to use it. It's not an easy product to get around.

• Log correlation
• Aggregation
• Being able to quickly identify threats in our network.

Key challenges, right now, are just having the resources. Whether it be humans in the seats, because, as of know, it's just me. I'm our security program. So the challenges involve just having the time and the resources to stay on top of threats.

The solution is pretty effective towards meeting these challenges. Though we don't utilize it heavily at this point in time, but we're looking to it. I think it will be a big help to us in the future.

There are a lot of pieces of it that are very complex and time consuming. If we can try somehow to just make it more simple, that would be better.

I would like to see more pre-integrated SmartResponses. Right now, I'm on 7.1.10, so I'm not even to the current version. If there were more pre-integrated SmartResponses, that would be really cool.

We are in our infancy stage right now.

It was deployed before I was there.

It's very scalable. Right now, we have the XML appliance cell all-in-one, but I am looking to move the web platform off to another server. Clustering has really been impressive to me with the product.

It is really good. I've had a few interactions with them. The first was really good. The second one, he was good, but I could tell he was new, which isn't a problem. Overall, I've been really satisfied with it.

Really understand what's important to you as far as what are you hoping to gain out of the product, what threats are you looking at, and what are your critical logs sources. Just have a fundamental foundation before you start looking into it.

Having a unified end-to-end platform is really important to me, because I am the only security professional at the college. If I can avoid having systems all over the place, that is only going to be beneficial.

Most important criteria when selecting a vendor:

• It is the problem that they are solving and solving effectively.
• Being able to rely on really good support.

It is creating a whole ecosystem, integrating different security components together, whether it is bringing the CloudAI, a UABE solution or smart response case management.

Definitely, the LogRhythm solution is a central piece. It helps us in visualization, it helps us in monitoring of our different log sources, and helps us with auditing compliance.

This is all tying things together, bringing a lot of functionality and benefit to us.

One of the features that we'd definitely like to see is the user inference, entity inference, where one entity would have a unique ID and then with that unique identity you could pull out the information or log associated with that. It helps a lot in the investigation, because currently what happens when we get an alert from LogRhythm it's just the tip of the iceberg. Then we need to do lot of investigation. But having this entity inference kind of tool would help us. We could tie all the logs with that unique entity, and we would be able to collect the information, I think it would be really cool to have something like that.

Also, with automation, like identifying new log sources and the environment, or automation of log sources that have not been reported from last month or a week. You can put up some kind of alerting system there so you can retire or look into it.

It is quite scalable. This whole solution, you can have different components on different servers or platforms. For example, I was in that meeting, and we were talking about collecting 50,000 to 60,000 messages per second, which is really a high number. I was very impressed to see how many records, 12 DPX or five or six AIE servers or similar platform managers. It looks like it's quite scalable and they are quite happy with that.

LogRythm technical support is really excellent, very good in timing and answering questions very quickly. I have not seen such a good time response with any other product we are using. In those terms they are very good.

Though we had some issues initially in terms of technical support, the expertise of technical people, but I am seeing that they have improved a lot now, so a lot of our questions and queries get solved with the technical support.

I was not initially involved in the deployment but I read all of them on the business case at that time: Splunk and ArcSight and one other.

We've got around 2500 logs per second, and primarily a Windows-based environment. We have around 300 Windows-based servers, and we are also collecting a lot of logs from the end-user devices, which are primarily on the Windows base. We also have some Lynux-based servers and also some network component firewall proxies.

Over a period of time, LogRythm has improved a lot and the future, the road map of the product, really looks nice.

The most important criteria when selecting a vendor is the scope you have defined for the business objective you want to solve, whether it will meet that objective or not. Also, for us, feedback from industry peers matters a lot, and the people who are really using a product help us a lot. It needs to suit the budget as well. So financial, commercial and meeting the business objectives.

It is quiet important that a solution be a unified, end-to-end platform
because we have limited resources. It's very difficult if we have to scale and train on all the different platforms or security tools; and once someone leaves the organization it is difficult to hire a new resource. So having something unified under one platform means that scalability. We can have someone and utilize their skills to fulfill our requirements.

I would definitely recommend LogRhythm to someone looking for this kind of solution.

The software needs to work on its pricing. 

I have been using the tool for five years. 

The product is very stable. I would rate its stability a nine out of ten. 

I would rate the tool's scalability a ten out of ten. 

The tool's support is good. They support us 24/7. 

Positive

The tool's setup is very straightforward. I would rate the tool's setup a ten out of ten. The tool's deployment depends on the use cases, environment, etc. The tool's deployment takes one month to complete. 

I would rate the tool's pricing around eight out of ten. 

I would rate the product a ten out of ten. The solution is very user-friendly and straightforward. The tool's report customization is interesting.