LogRhythm SIEM Reviews

We have been using LogRhythm for the last seven to eight years. About a year-and-a-half ago we made a push, which is why I was brought on, to go global with it. The global use case is security only, we're not getting back to the business. It's the first time I've done SIEM that works that way. It's all about feeding the SOC and IR teams and letting them do their job.

We use Dell SecureWorks right now for our SOC. But in a much quicker-than-expected manner - literally a few months after we started really bringing everything in, and we took over teaching them how to use LogRhythm - our SOC has fallen right into line. LogRhythm is already almost replacing Dell SecureWorks and we might be able to get rid of Dell SecureWorks sooner than later.

I was the one who started getting the SOC team involved. I needed to teach them. They were a very frustrating group that didn't want to learn LogRhythm. "No, no, we're doing it our way," and it was very manual. They would pull information from Dell SecureWorks and compare it manually against other information. They were totally against LogRhythm. But very quickly, they changed their minds. Now, we get calls constantly to help support them. The leaders of the SOC, that understood LogRhythm and had some LogRhythm background, have implemented different things that have totally surpassed where we thought, six months ago, we would be. Things are going great.

We have seen a measurable decrease in the meantime to detect and respond to threats.

I've worked with a lot of SIEMs. It's nice that it's straightforward. 

My biggest complaint is documentation. Everyone tells me, "We have documentation on the LogRhythm Community site." I have searched for different types of documentation on numerous occasions, and it might be there, but it's not easily findable.

We're running an HA situation and we wanted to do an upgrade. There was "Oh, and do this," in the documentation. It didn't give you an order, step one, step two. It was just, "You've got to do this and this and this." We decided to do it as they wrote it and it totally messed us up. We had to then reinstall. It just was a mess.

Also, I can't really talk about features I would like until I have a stable environment. Once I have that, there are things that we would like. For example, we're doing a lot of things in-house. We're doing auto-acceptance; LogRhythm doesn't do it quickly enough. We develop something because LogRhythm is taking a long time in developing things, and then we want to present it to LogRhythm and say, "What do you think?" We don't even mind if they steal it and use it. But at the same time, we're getting a response of, "No, you're probably not doing it right. You're probably missing stuff." We're still going to do it.

My biggest issue - I know that they say they're doing it - is that the API-building is extremely important. They keep saying it's coming, it's coming. It's not coming fast enough. I don't care if they need to double their team size to get it out there quicker, the world is already in the cloud and we can't monitor it. That's a big problem for us. My boss keeps coming to me about it. That's an issue.

Finally, writing parsers is much easier - and I can tell you a few things about it - in Security Analytics. I would love LogRhythm to get something similar to that, instead of having to write out RegEX. That's very old-school.

More than five years.

After a year-and-a-half, we're not stable yet. Every time we think we're stable for a week or two, we wake up the next morning to another million logs backlogged somewhere. We're very unhappy with that, very frustrated. We've been working with engineering and upper levels, with everybody. The one positive part of that is that everybody has been very responsive and everybody has been very helpful in trying to stabilize our environment. Version 7.3 destroyed us. There is not one device that we have original code on. Everything is DevCode.

To be fair, we're a very tough company. We're presently at 5.5 billion events a day. We're sustaining 55,000 logs a second. We have a pretty big deployment, but it's not stable.

We were supposedly built for 100,000 logs per second, and if you read the answer I just gave to the "stability" question, you know we're still not stable at 55,000 events.

The tech support is fantastic. The only complaint I have about tech support is that sometimes they'd rather try to hold on and fix something, rather than escalating. Things do need to be escalated more quickly.

The source of the issue - meaning the customer - has to be part of the evaluation. I've been doing this for 15 years. When I go to customer support it's because I've already run every bit of the gamut and my teams have done the same. I'm more than happy to spend a week looking, from a support perspective, at this and this and this. But at the same time, they should be objective enough, so that if I were to say, "Hey, I don't see it coming from that area, let's look someplace else," to take my word for it. They should know me as a customer. Know your customer is more the issue.

They installed two weeks before I got there and I've been miserable about that. I'm in the midst of re-architecting the design.

Installation/upgrade is a complex process. We haven't gone through anything straightforward. I did learn from one of my breakout sessions, here at RhythmWorld 2018, that 8.0 is hopefully going to fix that a bit. There were some things that complicated it when we did our first upgrade to 7.3. We've gotten better at it.

My advice:

1. Get a SIEM.
2. Which SIEM I would suggest really depends on what your key use cases are. There are other SIEMs that do other things better. As an example, Splunk brings in logs wonderfully. But if you're not going to hire a Hadoop engineer who absolutely specializes in it, you're going to bring in a lot of logs that you're not going to be able to do anything with. You really have to look at everything that every piece does. 

In terms of the full-spectrum analytics capabilities, we're not using NetMon, we're not using FIM. We're just collecting logs from every device that we can collect them from. I'm in the process of onboarding hundreds of application logs. We feed them all to our SOC and Instant Response and Compliance teams.

Playbooks, for me, are "N/A." I have an associate that handles all the analytics and reporting and alerting. I'm more of the architect.

We have somewhere around 90,000 log sources. Do remember that Windows takes three log sources each. We're running about 5.5 billion logs a day. We're running a sustained 55,000 logs per second. Our database is somewhere in the neighborhood of 4.5 terabytes in size, over two tables. It's a large installation.

When it comes to our security program maturity, we have built a very strong security team. Since LogRhythm was implemented, the team has exploded, not only because of LogRhythm. We're now implementing many other vendors, cloud and other things.

For deployment and maintenance of the solution, we have three staff. That being said, being Marsh & McLennan Companies, we're running a very big installation where we have several teams that have input. This is my first time being part of that kind of team. I've been in SIEM for 15 years, but until now, every time I've ever done it, I've been the sole "SIEM guy," the one who handled everything. But now, I'm an architect. We have a SIEM analyst. I work directly with one of the heads of the server teams, so when we need to do upgrades we use that team. We also have a SOC, we have an IR team, all in-house. We have a lot of teams that have input into the SIEM.

When selecting a vendor, the most important thing to me is that the product does what it says it's going to do; that and the support.

I've worked with many other SIEMs. I was Professional Services for ArcSight for a year-and-a-half. I've worked with enVision, I've worked with RSA Security Analytics. We were their first customer when they rolled out the analytics and it took a year to get through all the bugs. There are some things that some of the other pieces do better. There are some things that I think that LogRhythm has missed. But all in all, it's one of the best SIEMs, as a total package, that I've worked with. When I hit an issue, the support teams and other teams are there to help.

Because my installation is not stable, I rate the solution at six out of ten. Once I become stable it will be a nine.

We collect from our primary devices and our endpoints and we look to identify any concerns around regulatory requirements in business use. We have payment card industry regulations that we are monitoring, to make sure everything's going the way it's supposed to, as well as for HIPAA, HITECH, and general security practices.

In terms of seeing a measurable decrease in the meantime to detect and respond to threats, we live in the Web Console and we see things when they come in right away, and then we triage.

There's value in all of it. The most valuable is the reduction in time to triage. We take in around 750 million logs a day. We have a lot of products and that would be a lot of different panes of glass that we would have to look through otherwise. By centralizing, we can triage and take steps much more quickly than if we tried to man all the interfaces that come with the products.

There are two improvements we'd like to see. I mentioned these last year and they haven't implemented them yet.

The first one is service protection. I have Windows administrators who will remove the agent when they think that that is what's fouling up their upgrade or their install or their reconfiguration, etc. The first thing they do is to turn off the antivirus, turn down the firewall, and take off anything else. They don't realize that the LogRhythm agent is just sitting there monitoring. Most antivirus products have application protection features built-in where, if I'm an admin on a box, I can't uninstall antivirus. I need to have to the antivirus admin password to do that.

Why does the LogRhythm agent not have that built-in so that I don't have well-intended admins removing things or shutting off agents? I don't like that.

The second one is, you can imagine my logging levels vary. We do about 750 million a day and some days we do 715 million. Some days we do 820 million or 1.2 billion. But there's no way to drill in and find out: "Where did I get 400,000 extra logs today?" What was going on in my environment that I was able to absorb that peak?" I have no way to identify it without running reports, which will produce a long-running PDF that I have to somehow compare to another long-running PDF. I have to analyze it and say, "Well, last month, Exchange entity was only averaging this many logs. Now it jumped up this much. It could have been that." But then, if I find something that spiked, I still have to make sure nothing else bottomed out, because there might be a 600,000 log delta if something else wasn't producing as many logs as it normally does.

I would like to see like profiling behavior awareness around systems, like they've been gunned to do around users with UEBA.

It's a well-written platform. That being said, with our log levels, we ultimately have almost 30 servers involved. Some of them are very large servers. It will bury itself quickly if there's a problem. 

I find the product to be well-written and very efficient. However, sometimes the error-logging is not altogether helpful. For example, on an upgrade, a systems data processor, a Windows box, was throwing an error code like 1083. Then it just stopped and it died right out of the installer and nobody looked. We searched through Google and what it means is the Windows Firewall wasn't turned on so that it could create a rule for the product. Why wouldn't they bubble up that description so that I wouldn't have to call support and I could just know, "Okay, the firewall wasn't turned on. Turn it back on. Re-run the installer and keep going."

There have been many times where I've been disappointed, where I'll ramp an agent up to Verbose and it will say, "LogRhythm critical error, the agent won't bind to a NIC," or the like. I end up with no really actionable or identifiable information coming in, even though I've ramped up the logging level.

There's room for the solution to grow in those situations, especially with regards to a large deployment where it can quickly bury itself if it can't bubble-up something meaningful. I need to be able to differentiate it from other stuff that can be triaged at a much lower priority.

The scalability is good. We're deployed in two data centers at the moment. We had a little bit of difficulty implementing a disaster recovery situation because it was leveraging only Microsoft native DNS and it wouldn't work with the Infoblox DNS deployment that we use in our environment. They've been working on that behind the scenes. That's one of the things that is queued up for me next.

Scalability, volume-wise, the product works very well. As far as the DR piece goes, I think there's room to improve that.

Tech support is good. There are a lot of guys that know what's going on. Sometimes though, I've stood my ground saying, "I don't want to do that." If we have a problem with a server, we can bounce it and maybe it starts running right, but then we don't know what was wrong. We can't do anything about it in the future except bounce it again because that's what worked last time. Sometimes I need to push them and say, "Okay, I want to identify what's wrong. I want to see If I can write a rule that will show me when something's happening," or "I want to figure out if there's something wrong with my scaling and my sizing."

I like support. I think they're customer-focused. But sometimes it seems they've got a lot of tickets in the queue and they want to do the "easy-button." I push back more on some of that. It could just be a situation where the logs aren't going to have that information, and they already know that, but they don't want to say, "Well, our logging is not sufficient. This is the best way forward."

What I find is that there are die-hard Splunkers. The problem is that Splunk is not affordable at a large scale. QRadar is not any better. It's just as bad. LogRhythm, for the price point, is the most reasonable, when you begin to compare apples to apples.

From a performance standpoint, I have no problems recommending LogRhythm because it allows me to get in under the hood and tweak some things. It also comes with stuff out-of-the-box that is usable. I think it's a good product. Things like this RhythmWorld 2018 User Conference help me understand the company's philosophy and intentions and its roadmap, which gives me a little more confidence in the product as well.

Regarding playbooks, we have Demisto which is a security orchestration automation tool, and we're on LogRhythm 7.3. Version 7.4 is not available yet because of the Microsoft patch that took it down. We're looking to go to 7.4 in our test environment and to deploy up to that. I'm not quite sure how its automation, or the playbook piece, will compare with Demisto, which is primarily built around that area and is a mature product. However, from a price point, it is probably going to be very competitive.

In terms of the full-spectrum analytics, some of the visualizations that we have available via the web console are, as others have expressed, short-lived, since they're just a snapshot in time. Whereas, deploying Kibana will, perhaps, give us a trend over time, which we also find to be valuable. We're exploiting what is native to the product, but we're looking to improve that with either going with the Kibana or the ELK Stack to enrich our visualizations and depict greater time periods.

We have somewhere north of 22,000 log sources and we average a little over 12,000 messages per second.

The staff for deployment and maintenance is myself - I'm the primary owner of this product - and I have one guy as a backup. The rest of my team will use it in an analysis role. However, they're owning and managing other products. It's a very hectic environment. We're probably short a few FTEs.

One thing that we've yet to implement very well is the use of cases and metrics. Because oftentimes, if we see something that we know - we glance at it, it's a false positive - we're not going to make a case out of it. We might not close it for a day or two because we know it's nothing, and because we're busy with other things since we are a little bit short on staff.

In terms of our security program maturity we have a fairly mature environment with a lot of in-depth coverage. The biggest plus of LogRhythm is that we can custom-write the rules based on the logs and then speed up time to awareness, the meantime to detect. I can create an alarm for virtually anything I can log.

We work on a dark site. It's the next generation ground station for the Air Force's GPS system. Our use cases are based mostly on an insider-threat perspective.

We utilize a lot of AI Engine rules within the LogRhythm SIEM to detect different types of privileged-user actions, whether it be escalation of privileges, creation of user accounts, or modification of user accounts. We also use it for IDS rules and firewall rules that are met, in terms of the IDS finding signature attacks.

It has helped our organization because we utilize the SIEM for a lot of analysis, not necessarily for malicious threats at this point, because we're in development. It's helping as far as figuring out how something got changed on the system, because it is in development and things are changing constantly. We are then using that forensic analysis to figure out what was changed, so we can turn it back because, a lot of times, in development, we don't know what caused something to happen.

The most valuable feature that we use is the AI Engine itself.

They're addressing a lot of the things that I've thought of over the past four years, in the various releases they're coming out with.

A lot of times they'll say something is coming out in a certain release and then we get to that release and they say, "No, we're pushing it back to a coming release." More engineering thought will go into when they are going to release something. Often, we'll give feedback to our management saying, "Hey it's going to come out in this release." That release comes out and it's not there and we have to go back to management and say, "Hey, they're not going to do it right now." Then management gets frustrated because they don't understand the intricacies of what goes into different components and into different releases.

The stability is very good, now. Initially, when I started working on this four years ago, the actual solution that was brought into our company wasn't very scalable, it wasn't architected properly for our type of environment. I've since re-engineered and architected a different solution with LogRhythm to actually meet our needs.

It's very scalable. It's a matter knowing what you need regarding the quantity of logs you're putting out on a routine basis. If you size it and scale it correctly, you can keep scaling it as far as you need to scale it. We've added data processors, data indexes - we have multiple for each for each environment. And we have close to 20 environments that we have LogRhythm SIEMs in.

I do more the architecting, engineering, and implementation, versus analysis. The only thing I would say in evaluating tech support is that a lot of times, I start out with the tier-1 and it's just not what I need. I need to get to tier-2, tier-3, and usually tier-3, before I get what I need.

If LogRhythm could do something on that side - for people who actually deploy and integrate the SIEM itself, instead of it just being an analyst - by having a different phone number for them, that would be a recommendation I could see going forward.

Was the setup complex? Yes and no. I did a lot of research prior, on my own, regarding using the recommended specifications that LogRhythm puts out. I designed it around that. I didn't utilize customer support a lot, only for a few questions. It was pretty straightforward after the research I put into it.

I would definitely recommend LogRhythm, based on my experience with it. LogRhythm is always trying to change and improve its product which is always a good thing. Other SIEMS are in development to upgrade and better their SIEMs but LogRhythm, across the board, has a great team. They look an inch deep but a mile wide, whereas other companies will look a mile deep and an inch wide. I think it's a lot better to do "across the horizon," instead of a small, six-foot-deep hole.

We are not using the full-spectrum analytics capabilities at this time. We are thinking about it, but there's a process for getting those changes into our baseline, being a development program. We have no playbooks at this time.

We have about 5,000 to 7,000 log sources per environment and there are 20 environments. In terms of logs per second, it all depends. We're in development. Some of our environments are not ramped up and they're all at different stages of development. Where we only get 100,000 to 150,0000 logs a day in some environments, in others we'll get close to 1 billion logs a day.

When it comes to what's important in selecting a vendor, price, names, and support are all great and dandy. Obviously, the big names of the world have a track record. LogRhythm hasn't been huge for a lot of time but they're starting to grow. They were one of the ones recommended by industry reviews in the SIEM world, but they were a relatively small company at the time. When you have industry reviewers recommending a small company, it says a lot for that small company. I know that they are growing now, but back when LogRhythm was first talked about by the industry they weren't very big, compared to the Arclights and IBMs of the world.

I rate it an eight out of ten because I don't have a lot of experience across the board with different SIEMs. I've worked with ArcSight but ArcSight is very expensive. And I've worked a little bit with QRadar. I actually like QRadar as much as LogRhythm.

It came in as a compliance package. Now, it is more of a security analytics platform for us, so we try to route relevant security and computer logs. We also have some use cases that we came up with and some of the stuff that LogRhythm provided, which has been the basis of our use of this security platform. 

The company is dedicating me to working on this solution exclusively, so it has been great.

It has helped operationally with things that I have discovered stuff in logs, like errors. Without it, things going wrong would probably have gone undetected. It has certainly helped with some of the general user behaviors going on out there. 

It provides a measurement of the things going on in our organization from a security standpoint. We can either address the issues, or say, "That's the way it is."

The AI Engine can take an event and correlate it into something else giving meaningful context regarding what is going on. We integrated it in with our ticketing system, so if an alarm fires, it raises a ticket in our system. Therefore, if I find somebody needs to action other things on it, I can just forward the ticket along. This is all done via email, which is pretty slick.

I would like a more fuller implementation of STIX/TAXII so I can pull in some of the government lists without having to go implement a whole new STIX/TAXII platform. 

I'd like to do user based analytics, but that is a funding thing.

Stability has been good. We have been bitten by the knowledge base (KB) twice in the last two years. I had some things that I did that caused the AI Engine to have problems. 

Once you get stuff up tuned, it just runs.

Scalability has been fine. So far, we have been adequate capacity-wise but I can see very soon that we're going to be taking advantage of some of the features that come with the new version. In particular, the data processor arrays which will help us scale out. Then, there is whole mention of hot versus warm and being able to keep data because SecondLook is terrible.

We have a partner, a service provider, who helps me administer the platform. Then, there is me, as the company didn't want to hire additional resources, but this complements the staffing by having somebody else from the outside help with it.

Check it out.

We went through a competitive comparison of the three leading platforms out there. It was an easy win, not only from the technology-side, but from the company with its support. That's a big thing for us, when you are small, that you count on the support team. Some of the competitors, their support is not good.

Our security program is not real mature. The security group just got a CISO within the last year or two, so that has been the focus. The company is bringing up that side of the business. They recognize that it is something that needs to be invested in, along with their investment in LogRhythm.

I don't have playbooks right now. We are still on 7.2. I don't think playbooks are in there yet. It makes sense that we use that functionality, and we're looking to go to 7.4 as soon as the .3 release comes out.

We have about 1800 log sources. 

We are right at 5000 messages per second, and the system is scaled for 10,000.

I use the solution for logistics and metrics. We use LogRhythm SIEM for our company and our clients. The solution is deployed on separate machines.

The log correlation is the most valuable feature.

Our clients enjoy having one dashboard to monitor their environments in real time.

The coordination and load bussing has room for improvement. 

There is room for improvement with separate running sources or better integration.

I would like to have a better way to investigate the logs by adding correlations to the dashboard.

I have been using the solution for one and a half years.

The solution is stable.

The solution is scalable.

The technical support is responsive and always resolves our issues.

I previously used IBM Security QRadar and switched to LogRhythm SIEM because it is the best in the market.

The initial setup is straightforward. The deployment takes between nine to twelve hours.

I give the solution an eight out of ten.

The solution is for medium and large organizations.

I use LogRhythm for PCI DSS compliance. All of our devices are sending logs to LogRhythm. I have set up Silent Integrity Monitoring, Data Loss Prevention, Registry Integrity Monitoring, and other alarms for detection, and we do investigations.

I don't have metrics, but it has really improved the monitoring and alarming for us. 

File Integrity Monitoring is really valuable because we have it set up on our core assets. This is one of the key features that I utilize. We also use it quite a lot for event management to do reporting.

It should have some more message monitoring features. It can also have some free message monitoring tools.

I have been using this solution for about two years.

It has been very stable. There are no major issues. It has been exactly doing what I expected it to do.

It has been very scalable in terms of adding new systems and stuff like that. It has been quite good.

We have plans to increase the usage of LogRhythm. We have some new solutions and new networks coming up. We might be looking to expand within the next two years to onboard new systems.

Technical support has been excellent so far. I never had any issues with technical support. Their support has been excellent.

I didn't use any other solution previously.

It was pretty straightforward. The actual deployment of it took about two days, but the implementation strategy took longer. It took a couple of months for meetings and planning with different experts, project managers, and engineers. They looked at our business requirements and other things.

We have two administrators and two analysts. Four of us are managing the system.

It costs a great amount, but its pricing is competitive with some of the other vendors. For licensing and support, we pay about 20,000. There are no additional costs or anything like that. 

When I was looking for a solution, I looked at Splunk and LogRhythm. There was one from SolarWinds as well. Cost-wise, LogRhythm was the one that impressed me the most. Splunk was really good as well, but it was a little too costly.

I would definitely recommend this solution for compliance requirements, such as PCI DSS compliance. It does cost a great amount, but its pricing is competitive with some of the other vendors. If it is a necessity to have a SIEM solution, I would definitely recommend LogRhythm.

I would rate LogRhythm NextGen SIEM a nine out of ten. It has been really good. So far, my experience has been seamless. They should keep doing what they're doing.

Private monitoring is our primary use case.

In terms of security, LogRhythm NextGen SIEM is great.

I have been using LogRhythm NextGen SIEM for one year.

LogRhythm NextGen SIEM is stable.

Scalability-wise, it's not that great, but integration with other solutions is pretty easy.

The technical support is great.

We also use Splunk, but in terms of security, we always recommend LogRhythm NextGen SIEM.

The initial setup was very straightforward. We deployed LogRhythm very easily. In total, including configuration, we deployed this solution in less than one day.

In the context of our country, the price of this solution is too high.

Overall, on a scale from one to ten, I would give LogRhythm NextGen SIEM a rating of eight. 

I would definitely recommend this solution; my only concern is with the price — it should be lower.

Our primary use case is for financial companies and telcos.

The most valuable feature is that we can alternate incident automations.

We need to get better training for things like creating code and playlists. The way it's done now takes a long time. 

I have been using LogRhythm NextGen SIEM for two years. 

The stability depends on the client we installing or integrating for based on the server's requirements. We can create them according to that defined time period. It's not that difficult but depending on the customer or the other server requirements.

We can have a dashboard in a single platform, we can get notifications via email or SMS, and we have Smart Response actions. So that kind of possibility is there.

Our clients are mostly on a larger scale. 

You can request support and they respond immediately. They're really good. 

The initial setup is easy. It can take two hours. The first day of deployment is easy. Then depending on the devices and log servers, it can take time. We can give them predefined or pre-created devices and logs. The deployment depends on the devices and systems we are integrating. But the initial stage is easy.

Because we are a developing country, the costs depend on country development. We implement it for large-scale companies because normal companies, startup companies, can't afford products at that price. We mainly focus on large-scale companies.

I would definitely recommend this solution if you can afford it. 

We get customized reports and we get reports including all the details, but when we start using them we couldn't start with the Outlook editor. We can customize a document and we can write a report. The dashboards are very user-friendly and very attractive. But when it comes to the reporting part, I think that could use improvement in the next release. 

I would rate it a seven out of ten.