LogRhythm SIEM Reviews

My primary use case is for log retention. I've been using it for analysis, and to troubleshoot potential issues on my network and infrastructure. To find out what I have in my network that may be causing problems.

We can sit and see what's going on, as well as to be able to see errors as they populate immediately since spending time looking at logs is ridiculous, trying to put all that in place.

We will be using the playbooks in the future as we get everything implemented and put in place. The idea is it's going to help automate a lot of what we're doing and make it more efficient, as well as be able to preempt, potentially, a lot of other errors.

The most valuable feature has just been the log reporting. Within three hours of installation of LogRhythm, we were pulling error reports that actually indicated we had a switch about to fail. It saved us about ten thousand dollars of a potential failed switch.

We are ramping up the analysis and the analytics part of the LogRhythm. We're in the process of building a lot of that. We're trying to build out as clean as possible, so what we have in place is a lot of the intrusion detection and basic PCI compliance.

For me it would be the efficiency and signing up and standing up systems, as well as a little bit cleaner on case management. That can be a little bit complicated to go through and actually be able to analyze it and compile the information that I have. At least that's what I've found so far. Those would be the two biggest things.

Stability thus far has been really good. We've had it up for about six months and I've had no failure points with it. Little bugs here and there, but that's expected as you're working through and getting everything stood up. But it's been pretty stable and pretty rock-solid.

I'm probably gonna be around seven hundred and fifty sources that I'm using right now. Somewhere in that realm. It's been robust enough to handle everything that we've been putting through it. I have about 150 to 200 more that I need to stand into it, but it's been pretty stable there.

The times I've used tech support, it's been really efficient. I've gotten responses usually within 24 hours.

The initial setup was actually me and the technician. I did 90% of the installation myself and he basically came on board and verified everything I did and gave me some pointers as I went through.

Installation was incredibly straightforward. I was able to get it set up. I said, I stood it up on my own about ninety percent of the way, without any input from anybody else and just the final pieces of staging was done with somebody else.

We needed to set up a new solution based on our company requirements that were being ruled out. We needed to step-up and add something. When I came on with the company, I wanted to add-on a SIEM solution immediately, I just got the funding and benefit because the company said we had to. There wasn't anything in place before hand. So it was just very much me saying this is what we need and this is how we need to roll it out. Through my research is where I fell back on to LogRhythm.

The most important criteria on a vendor is ease of use. Since I have a small team, it's pretty much me running everything, so I need to make sure that I am able to do it efficiently and be able to pass it off to somebody when I need to be able to hand it off to do. Next piece is what it can provide and the amount of tools they can provide to me in a very short order.

My short list for SIEM solutions would have been Splunk. Also looked at Spiceworks, SolarWinds, and a few other smaller ones out there. But basically Splunk and LogRhythm are my primary two.

My security program was non-existent when I started, so this was basically one of the first implementations that I did to step-up my security implementation. Before this there really wasn't anything to work with. So it's slowly building its maturity through LogRhythm and a couple of other sources.

I would rate this product an eight out of ten, just because there's always room for improvement and there's always room we can work on. So there's always benefits, but it's been really good with what we needed and it's been very stable for our implementation.

My advice to somebody who's looking to stand-up a SIEM solution is to do your research, look at the white papers, look at their documentation they have available on how other people have responded and how many people have stood it up on their own. Get this information and then start playing with it before you start doing implementation. Gives you a lot of foundation and makes the implementation part a lot easier.

My primary use case for this solution is to basically monitor the network to make sure that we don't have unknown users or individuals that should not be in our network. So we use it basically to aggregate our logs within our system and to watch it for possible threats.

It has improved the organization a great deal. Now we're able to see what activity that's actually being used, or what activity is actually being found in the network. So we're monitoring our firewall systems and different areas like that. So it's a great help to us because we're able to see whatever that's out there that would not have been seen previously because it aggregates all the logs together and it flags us according to the alerts that are being triggered at that time.

Right now we have just grown to eight security analysts in our group, but all have different roles. Now there's two individuals that's mainly responsible for SIEM and that's myself and my coworker and he's been cross trained. He just recently went through the LogRhythm University training which is great. So right now we do have about four analysts in this system but the main number is two.

Currently we haven't seen a measurable mean time to detect because we're not using that at this time. But after this session, we will probably go ahead and start using that for metrics.

Our security improvement or maturity level definitely has increased. We started out with three security analysts and it has grown to eight. LogRhythm has improved it because we're able to see much more data. We're able to see much more of what's out there, what type of threats we're encountering, different things like that. So it's been a great improvement.

The most valuable features for me is just to be able know who's in the network, being able to drill down on the alarms, to being able to look at the different rules or whatever that's been impacted within the network for anyone being in the network.

At this point we don't use the full spectrum of analytics. We're still fairly new and trying to tweak our system to get the information that we want out of it. So we're still at the beginning stage.

We are not using the playbooks, we're still on a version that doesn't support them. But yes, after going through the session today, the preview session, we definitely want to use the playbooks.

For me, room for improvement is the upgrade process. Whenever we have to do an upgrade to the next version, we're a little nervous and apprehensive about that.

Stability, it's very stable within our organization. What we're at is 7.25 right now, we do wanna go up to 7.4. we're a little nervous about that at the point because it's so new but eventually we will make that jump.

Scalability is very good for us. We are able to use it in different areas within the organization. Different groups and stuff like that.

I have used tech support in the past and it is great. I definitely recommend tech support, we do go to the LogRhythm Community first but with me, when I was first introduced to the SIEM LogRhythm, I was new to the environment and so I leaned on tech support to help me understand the environment, and as I was making those calls with them I was like "Okay, teach me like I'm a two year old. Walk me through this so I can do this on my own."

On a scale of one to ten, I rate LogRhythm as a nine because it is a wonderful tool that definitely helps with identifying different threats within the organization. I would definitely recommend this tool. It's a very, I would say beasty application, you always will be on top of things when it comes to LogRhythm because it's always changing, but that's a good thing because the environment, the threat environment is always changing. So I'd definitely highly recommend it.

The target I would give to an individual that's looking for the best SIEM tools to put in their environment would be definitely look at one that's growing, that's not stagnant and LogRhythm is definitely one of those too that look for ways to improve it, user friendly and the different things that's out there in the environment to be able to catch the types of the bad guys or the different threats. They always try to stay on top of things. So I definitely recommend LogRhythm in that case.

Our primary use case for using the LogRhythm SIEM product is reviewing alarms, events, and managing our cases for forensic investigation.

The LogRhythm platform has helped my organization by being able to have 24 analyses on logs and events from all the various systems that feed into the LogRhythm platform. It gives our analysts the capability to assess rapidly and be able to respond to events in almost real time.

We currently have over 500 log sources inside the platform. Managing those is relatively easy. The main feature that we do take advantage of with our log sources is setting up silent log source alarms, so that way we can identify if a log source is not feeding logs as it should be.

Currently, our messages processing rate is around 2,000 messages per second.

Our mean time to detect threats has been going down, which is a good thing. Lately, our main focus has been on handling and reducing the mean time to resolve phishing incidences within the company.

Our security maturity program has been overall positively influenced, mainly in the HIPAA healthcare spectrum, by meeting third-party auditing requirements and having those tested, too, and confirmed by our third-party auditors.

The capabilities that we mostly take advantage of in the LogRhythm platform is the wide array of log formats that we can bring in from various systems, and the capability to create custom role processing capabilities for log sources that may not already be a part of the platform.

Currently, LogRhythm, the playbook's functionality is not in my version, so we're looking forward to utilizing playbooks. That's part of the main draw for me to come here, was to learn more about the playbook functionality and how we can incorporate that into our platform. But right now, the functionality is not there.

The largest room for improvement would be inside the web platform, being able to have a longer log live time. Currently, we manage about five days of live log data inside the web console. Ideally, that should be 30 days-plus.

Stability is very good, so stability for the LogRhythm platform has been very positive. We do have pain points around upgrades, but we have been able to engage with support and get rapid response to how those issues resolved.

Scalability for the LogRhythm platform for my company has been very positive. We've been able to ingest logs from very high-traffic log sources without any type of issue, congestion, so very positive.

I was not initially involved in the setup. I came in to manage the SIEM solution three years after its deployment.

I would rate LogRhythm a nine out of 10, primarily because of the current functionality within the system and the direction that the company is going. I feel it's appropriately aligned with security today and being prepared for tomorrow.

We use it for centralized log management and for alerting. It's been working pretty well. We're on the beta program so what we're on right now has not been working quite as well lately. We're helping them find the bugs, but before this we didn't have any really major issues with it.

It makes everything quicker when it's all centralized. Anything we need to find, it brings to our attention. Even other products we have that feed into it, instead of having to watch all of them we only have to watch one. For example, we have CrowdStrike, so instead of having to pay attention that solution - because its dashboard doesn't really pop when an alarm comes up - we can see issues with the red on the LogRhythm alarm. That is very nice.

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

Being able to find everything in one place is really nice when you're doing your searches.

One thing we have mentioned to them before is that we'd like to be able to do searches, or drill-downs, directly from an alarm. When you click it and the Inspector tab slides out, that might be a good place to be able to click the host to search for the last 24 hours. I know the search is right there but it would be even nicer to just click that and then have an option to search something there.

Going into the beta, stability was very good, but in the beta its not been as great for us lately.

There was a known bug where, after about five minutes it would duplicate alarms, up to about 10,000. After 10,000 alarms in five minutes, everything is shutting down. Also, some of the maintenance jobs get deleted when upgrading, so our database was filling up without deleting the old backups. Those are the two major issues so far.

I just took it over recently but we got it built to last. It's been the same since we put it up.

I open tickets frequently, especially in the beta program. To get the first response is usually a little slow, but once they're talking to you it's very good.

Figure out what you need it for before just getting everything you can into it. That's probably the main thing. We recently brought in an external firewall and it has everything enabled. So make sure it can do what you want and don't try to do more than what you need.

We have made a few playbooks, but we haven't done too much with them yet. For deployment and maintenance of the solution, it's just me doing the administration.

We're at 60 or 70 log sources right now. With some of the newer ones, we've had to open up tickets for them, like the newer Cisco Wireless. We've had issues with Windows Firewall and AdBlocker. We've had to get those fixed. We process about 600 messages per second.

In terms of the maturity of our security program, we got this solution right after we started up, so it has been growing with us. We're now at a point where we're happy with it and getting good value out of it.

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.

It is for security monitoring.

It has helped us centralize and have better visibility into devices on our network. We are better able to respond to threats in a timely manner.

• Out-of-the-box features, like widgets and dashboards.
• The content in the LogRhythm Community is very helpful and useful for new users.

I would like to have threat indexing and a cloud version.

When we had version 7.2.6, there were a lot of issues deploying that version and with the indexing. The indexer was unstable. So, we were not able to use the platform when we were on that version until we were able to upgrade to 7.3.4. That is when it became more useful to us.

Now, the stability is good. Right now, it is more a matter of fine tuning the alerts and rules that we have, then we can reduce the hit on the XM performance.

In terms of capacity, we have the same XM appliance. We still haven't touched it (going beyond having that appliance), deployed another indexer, or moved to a distributed architecture.

Tech support has been good. They have fixed whatever has been bothering me when I contact them.

I do the deployment and maintenance for the solution.

We have seen a measurable decrease in the mean time when detecting and responding to threats.

Definitely consider LogRhythm. There are a lot of players in the market, but LogRhythm is a solid solution.

We don't have the playbooks. They are on version 7.4. We just upgraded to version 7.3.4. We are going to wait before we upgrade again due to performance issues.

We have around 22,000 log sources and average 5000 messages per second.

We use it for all of our log correlations and event management. We try to do some external troubleshooting for other groups, like WebOps, but it's primarily our security and event manager.

For the same price, we have been able to go from a SIEM that could only manage about 20 percent of our environment to a full 100 percent coverage of all the devices on our network. Thus, we have seen a massive increase in the amount of data that we can collect, the type of things that we can see, the way we can look at logs, the way we can get alerts, and the way can create our own customer roles, which has allowed us to customize the work in our environment.

We find the user interface and the ability to pivot near search from one particular item to the next part item to be highly valuable. 

Its ability to work with all different sorts of log sources has been extremely valuable. 

The reporting could be improved. 

There are other security technologies outside of this SIEM that should be inside of this SIEM. I can see in their roadmap that they're trying to address a lot of these things, and have these technologies built into the solution, because there is no point in going to another vendor or opening up a second window to obtain the data that you need.

It is stable. We haven't had any major problems. We had a slight hiccup when we went through our upgrade procedure, but it wasn't anything overly complex, and support was there to help us. Therefore, we had it back up and running very quickly.

It should meet our needs going forward. The way we have it designed right now, we should be able to bring in single boxes and multi boxes to increase storage capacity performance whenever we need it. It's well-designed in that sense, allowing us to grow as needed.

Everything experience I have had with them has been awesome. I have had no issues going to them. They are willing to get on the phone with you. They will get on Webex with you and control the system to see what's going on, getting their hands deep in to it, then resolving the issue.

In previous and other support departments, they will just email you some suggestions and then leave you to take care of it yourself. That is not really what LogRhythm is about.

It is more intuitive than the previous solution (IBM QRadar) that we had in the environment.

We definitely had to get some assistance, because we didn't have the expertise. Once we got the product in place, it's good at maintaining itself, along with the support. 

If you're going anything more than the single box solution, I would not try to set it up by yourself. I would get the expertise to help you get it right.

In comparison to the competition, they are more affordable. This allows us to do more with less.

We didn't have a main logging system, so it's really nice to have that now, and in place. We are collecting all our logs from all the servers, routers, and its really helpful, and it's a great product to have.

Right now I really like the dashboard, and being able to view it easily, and to just have all the data right there available for me.

I think the dashboard could definitely have more features. I've seen some of their roadmaps that they're going towards. I really like it.

One of the features that I actually put in a request for was, they have the ability to build this great case and have it all ready. But you can't export it, right now on my specific 7.2 product, you can't export it from there. So, I can't have a nice PDF to give to a CEO, or give to legal, or wherever it needs to go to further their investigation. That's definitely a product that their actually going to come out really soon with.

The stability is pretty good. We haven't really had any problems with it. I think in our deployments, we had about 25 monitoring agents. One of the agents did start acting kind of funky, so I just called up support. I said, "Hey, we can't get this agent to work properly." They helped us out right there that same day. We actually updated that specific agent, and its been working ever since.

We're a fairly new customer to the product so we haven't had to meet problems like that with it. But we do plan to scale it fairly soon, so we'll see.

It's been pretty good. After the deployment, I really haven't had to call them. They have a pretty nice knowledge base, and their user guide pretty much explains everything you really need to get done. 

There are some issues that I had with Forcepoint, and getting it to work properly with LogRhythm, but that was more on the Forcepoint side of the problem than LogRhythm.

It was due to compliance that they decided to get a product.

I actually was hired within the last five months. I showed up, and they said, "Hey, you're going to get to deploy this." I said, "Sounds great."

Deployment was fairly easy. They gave us some prerequisites that they needed us to have ready for them, so we went ahead and got those all ready, went through change management, got everything approved. 

They needed to have - if you want it to collect logs remotely - a service account created, you needed to have specific ports already open, to make sure that everything communicates properly.

We went ahead and had everything set up. We got the support call because we got the DMX appliance. The day came, we got it all set up, it was fairly simple. The support agent walked us through everything we needed to do. He showed us tips, and tricks, and best practices for specific situations. He did training at the same time as we were deploying. It was a fairly simple, easy process.

It's one of the top 10 SIEM solutions. What I really like about LogRhythm is that they're always innovating, new ideas. They're consistently trying to improve. I think that's really great about them.