LogRhythm SIEM Reviews

For me, one of the most valuable things about it is it helps me to produce evidence in my compliance role for NERC. It helps me to really bring all my logs together and easily translate that into evidence, to show I’m doing what I’m supposed to be doing.

In the canned reports, I would like to see, rather than a blank report come out, for it to say something like, "No logs found," or "No log sources available." I don’t like blank reports.

I’ve only been using it a couple of months. I started in about March, 2017.

I think it’s wonderful. I use a high-availability version that fails over for me if needed. I’ve got one in one datacenter and one in another. It seems to function properly.

I have not had any issues. Mine is a very small deployment.

The LogRhythm support system is phenomenal. I can’t give those guys enough praise. If I have a problem or a question even, they’re quick to answer or connect me with an engineer to resolve the problem. The support system is really the selling point of this product.

My deployment is very new so we are still implementing it. There’s a little bit of work left to be done to get it to full capacity. I would say that it’s been relatively painless.

I gave it an eight out of 10 because of the ease of use, and the support really deserves high marks.

I would definitely tell colleagues to look into it. Again, the support that they provide, they’re there to hold your hand if you need it, or just give you guidance and let you go. They really do take care of their customers.

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.

It's visibility. Frequently our network team - while our network security is paramount from a security perspective - our network team is really focused on keeping the network up. They're not concerned about intrusions, and potential malicious activity. They're making sure that users can get data from point A to point B successfully without any downtime. With LogRhythm, our SIEM solution offers more of a rounded perspective, especially from security, making sure they are not only operational, but they're operational in a security conscious manner. That's really helped. 

I specifically keyed on the network, but it's really where we're able to add additional visibility across all groups, from a security perspective, that they might not be aware of. Usually a business owner is just focused on, "Is my application up, is it running? Yes." They're happy. We come in and bolt on security, and we're changing the mindset of our company one group at a time.

Most valuable feature is really providing us visibility into our infrastructure. Frequently, I'm reaching out to our partners in the business, and I'm asking them how I can assist them, and how I can improve their visibility from a security perspective. 

Often times, like many of the users I've met this week here at the LogRhythm User conference, we've encountered that the business owners, they're not familiar with their logs. Some of them haven't even really looked at them. But when I delve into the logs with them, and identify some things we can trigger on and alert on, and really help them improve the efficacy of their tool, it's really been a big benefit to have that visibility. Not only from the security perspective, but an operational perspective. It's really helped to build a relationship between us and the business.

There is, of course, always, improved automation. Because, as we are continually needing more and more people from an analyst perspective, the more we can automate, the fewer people we need. If we can automate some of the lower-level things, that can allow our SOC to be trained on the higher-level more technical things that really give the true value. I don't want my analyst to be stuck underneath sending emails, and "alert fatigue" is the buzz word. 

But, on top of that, there has been a market that has grown from SIEM for security orchestration, where it's another tool you have to bolt on top of SIEM to make SIEM as effective as it should be from day one.

I was in a session earlier today here at the LogRhythm User conference where they're mentioning that the web UI, and through the case management, they're actually getting an incident playbook that you can utilize. That's a big step that I'm intrigued by. Hopefully it goes the way that it's planned because that is one that saves me from having to go out and purchase a separate security orchestration tool, which is just another screen I need to look at.

That feature is one that I'm very excited about, and hopefully it follows the roadmap according to what LogRhythm is projecting. That's definitely a feature that I and my managers have identified as a need. I was excited to hear about that at this conference. 

That's probably the only feature request that would be of drastic improvement to our SOC.

We've been on LogRhythm since version 6. We've dealt with some bumps and bruises here and there. However, LogRhythm has clearly been dedicated to improving stability at every turn and every hotfix and every new agent release. It's gotten better and better.

With 7.2.2 we went to High Availability mode. We were having some issues, our deployment is global, we're in multiple datacenters across the world. Having HA has really helped us because if our platform manager went down, we could just failover perfectly to our second one, and not get called at midnight. So that's been great.

However, past 7.2.2, HA has almost become unnecessary because its stability has improved to such a level that HA is now just a bonus feature. It's a security blanket versus a necessity.

Currently, we're running one AI Engine in our local datacenter where we're based out of, in Texas. We have two platform managers like I mentioned, they're both in HA mode. We have a en-clustered DX cluster in that datacenter. We've got at least one data processor, if not multiple, in every other datacenter with its own corresponding indexer as well. 

We treat as many LogRhythm environments across all data centers that funnel up to our main one in Dallas.

The Professional Services as well as the general support has been phenomenal. They're very attentive to our needs. When we submit a ticket we get a pretty quick response back. If they don't know the answer, they're either immediately going over to their buddies down the row, and seeing if they can get help and, if not, they escalate it as quickly as possible. 

Any upgrade of an application this size, you're going to hit some snags and hurdles, but LogRhythm as a SIEM tool company, from a support perspective, has really allowed us to overcome those and we haven't really had any downtime as a result of upgrades.

They go pretty well. Of course there are bumps and bruises, especially with LogRhythm being such a massive application. If it was to go 100% well, I would honestly think that it didn't go that well, and I just don't know about it.

I don't think any application can truly be a 10 out of 10, especially one of LogRhythm's size; that would be very difficult to achieve. But an eight, in my mind, is perfect. That means there is room for improvement, there is room for me to work with the vendor, and talk back and forth about what my needs are specifically so they can work that into a feature request down the line.

The benefits we see are manifold, compliance. We have to store logs. We're under SOX control, we're under now New York Department of Financial Services, cyber regulations, we are under EU GDPR, loads of regulations are coming out. To be able to store these logs and be able to access them if we need to, from an archive point of view, is very valuable.

The most valuable feature of LogRhythm for me is the ability to correlate logs throughout many different log sources. Every different log has a different time stamp, it has a different user, things are in different places. But with LogRhythm you can take all of your logs from all the different sources and make them relevant to each other. 

So if you're looking for a user that is doing something malicious or if you're looking for a computer that is maybe making some calls out to systems that you've never made before, you can correlate based on a user attribute or a computer attribute to say, "Go find me everything that that user is doing." Because of the correlation, you can then have alarms and reporting off of multiple log sources.

I'm not really sure I can pinpoint any particular area that I see LogRhythm needing improvement in. 

I think they probably need to, because a lot of companies are having this cloud-first strategy, where anything that's new has to go into the cloud for some reason. So I think with CloudAI coming out, that's really good. But maybe having more of LogRhythm in the cloud. Educating people about how we get LogRhythm more into the Cloud.

Part of the care and feeding of LogRhythm is staying on top of what's coming out in LogRhythm. I know that their community site has been improved and that they're wanting people to be more involved with the community. But I think making people aware of parts of LogRhythm that are new is very important. 

On the whole it's a stable product. Occasionally we do have issues with upgrades, but Professional Services and the support staff have been very helpful with fixing any of the challenges that we've had.

For us, because we're a small company with not that many locations - we only have seven datacenters in seven offices - we haven't had any problems with scale. 

We did purchase a company a few years ago and adding their log sources into LogRhythm did not pose a challenge. We always know that with the system that we purchased, there's a certain limitation of messages per second that we have to watch out for, and we've never gone over that. So for us there have been no issues with scale.

Whenever we've had Professional Services on site to work through new alarms, to implement a new feature that we haven't used before, they're always very professional, they're always very responsive. They follow up on items that they said they would, which is always good. We're paying them to do a service, and that's always nice, that they perform their service.

We have had challenges in the past with EU-based support - most of this is run out of Dublin and London - and those challenges were overcome by LogRhythm bringing their support back in-house. They were using a second-level team to perform the support. But once they fixed that, we get great support from LogRhythm. 

When you open a ticket they acknowledge that a ticket has been put in, and then somebody will get back to us. We also have 24/7 support, so sometimes our ticket can move from the EU to the US, and we have people in the US that are able to take over the tickets. They seem to be very good at managing that. 

We did not have a SIEM solution in place at all. I was told to go out and look for one, so I did, and LogRhythm definitely came out on top for what we needed it for.

The main challenge with setting up LogRhythm is you cannot just put LogRhythm in and let it run. You have to put some care and feeding into it. You really have to work on it.

LogRhythm gives you a lot of standard rules, but some of those, a lot of them, do need tweaking, and there are reasons for it. They can create a global rule that would work for maybe 20% of their customers, but everyone needs to go in and actually make changes. You have to have a staff on prem to be able to know your organization, know what your organizations looking for, and to be able to make those tweaks.

So the challenge with setting up LogRhythm is you don't just flip it on, you work at it, you make sure that you're invested in it. You have to have a team. It doesn't necessarily have to be a huge team of people that are working on LogRhythm 24/7. I'm sure for some financial institutions, or some institutions, that has to happen. But you need to align resources internally to be able to know the product. 

It's almost best if you have a first-line support for LogRhythm internally, because you can't always rely on somebody else to fix your problems. You really have to know your system. So taking the LogRhythm training - when we've had other people come on to our staff - I've done a lot of training, but we have had Professional Services come back and do more internal training. 

In terms of criteria for choosing a vendor, when you go through an RFP process there are always weighted criteria. We went through that whole process and started out with eight vendors, got it down to two and then selected LogRhythm. For me it's relationship, I want to feel that the product that we're buying is going to be supported, and that we have almost a team behind us that is there. When we did purchase LogRhythm we felt that. We bought a lot of Professional Services time to help us implement. 

It's not like the sales guy says, "Okay bye," and never talks to you again, and just takes in the money for the license renewal every year. They have customer boards, the sales engineers will talk to you and will bring things to the table. They'll come and do a health check. I don't feel like we just bought a product with LogRhythm, I felt that we bought a team.

You have to allocate resources, and that's why I've recommended LogRhythm to a few friends and colleagues. To get the best out of LogRhythm you really have to put the time in.

I believe the most valuable feature for us has been that we have all the logs together. We can query them, we can find all kinds of different situations that are going on in our network that we wouldn't have knowledge of without searching many different servers and logs.

Quicker ability to troubleshoot the problem, find the problem, get it fixed, and get the customers back up and using our system. 

I'm sure there are always areas, in stability and scaling, that need improvement. I don't have anything right off that I can say I know needs improvement right at this point.

We installed in 2009, and the stability has improved over the years. I consider it to be quite a stable product now. It seems to work day after day, week after week.

With version 7, we feel the scaling improved a lot. We are a large health system and we are quite often adding new businesses, new healthcare offices, new hospitals to our system. We we are able to add those extra logs into our system without causing any issues.

Tech support has always been good from the very first. In most cases the first response is a good one. It does the job, and if not, then you get back to them and they stay with you until they get it fixed.

We thought the setup was very quick and easy, of course we didn't try to boil the ocean all at once. We've been, over the years, adding more and more phases to our system, completed it in phases.

Really figure out what you want it to do for you, because it is very flexible and can be used for many different purposes. Determine what you want to use it for, and then get the assistance from LogRhythm to help implement it in that way. Then you can always expand it and take in other areas. But your primary goals need to be met right up front.

We are very happy with it.

• 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.

We have about 170,000 employees worldwide. We have thousands of unique log sources we're ingesting. Right now, it's kind of information overload in what we're trying to create logs off of.

Our key challenges are staffing and, right now, we're just trying to get the best bang for the buck on what we can create for alarms, so that's what we're trying to get out of being at the LogRhythm User conference.

We're about to ingest pretty much all of our log sources and write alarms based off the log sources. That's what we're working towards right now, getting valuable alarms to trigger for our SOC to action.

LogRhythm meets our problem statement, as a solution.

The UI. We can give it down to our SOC and we can train them.

The CloudAI obviously, that's going to be big for us. Hopefully that matures. I saw the problem statement video they did today at this conference, which is great. But I haven't seen anything tangible out of that yet, so looking forward to that.

I wouldn't give them a 10 out of 10 because there is definitely some room for improvement as far as in the GUI. Some of the things don't make sense. I think they need to better understand how a SOC would use that platform.

I don't think they understand that every morning we do a case review and we need a quick dashboard to go review open cases for our SOC. And that's not built into the dashboard, so we have to create that. There are some use cases that I think they should sit down a little bit more with the customer and understand how we use it.

It's pretty stable.

It was scaled inappropriately when we got it, so we had to buy a bunch of hardware after that. But, it's working now.

I don't use it. My cohort, who is more of the SIEM admin, he uses it quite a bit. I think he's happy with it, as far as I know.

We used Q1 QRadar. After IBM bought it, it kind of died on a vine. They quit supporting it, so that was the main driver for getting off of that and going to LogRhythm.

Pretty straightforward.

We did a RFP for all the major vendors, ArcSight, all the big ones. LogRhythm came out as the best SIEM tool.

When selecting a vendor, for us, the platform has to be a unified, end-to-end solution. We've got so many unique platforms around our business that it has to be.

All SIEMs suck, but LogRhythm is the best.