LogRhythm SIEM Reviews

We typically consult with our clients and help them with necessary services.

The UEBA flow is the most useful aspect of the solution.

The initial setup is pretty easy.

While the cost is high, the security provided is quite good, and for those who can afford it, they will pay for the peace of mind.

I'm not a fan of the system's user interface.

For our market, the solution is quite expensive. It would be ideal if they could work on and improve their existing pricing plans to help make it more affordable in our country.

We'd like it if the solution could be more customizable in future releases.

We've been dealing with the solution for about a year.

The solution is quite stable. There aren't issues related to bugs or glitches. It doesn't crash. It's reliable.

The solution can scale if a client needs it to.

We have clients that have 10-15 users on the solution. They are mostly security analysts. In terms of those that can actually view and escalate cases, there may only be five with such access.

At this point, there aren't any plans to increase usage.

We typically are the ones that handle technical support for our clients if they run into issues.

The initial setup is not complicated. It's quite easy and very straightforward if you follow the guides provided. I followed the guides and found it to be rather simple. It's not difficult to get everything up and running.  

The deployment doesn't take too long. You can have it ready to go in one working day. That includes installation and configuration.

We have a minimum of five people who handle maintenance and deployments.

Our company handles the installation for our clients. We can handle the implementation ourselves. We don't need a separate consultant or integrator.

In our market, for the price it costs, our clients aren't using this solution so much. It seems to be quite expensive in Nepal. That said, even with the fees and a rather high cost, it is the best product among other competitors. 

We're partners with LogRhythm.

We don't technically use the solution typically. We consult with clients and advise on products. We also provide services on the solutions we offer. In this case, we do use the product as we log issues.

We use the latest version of the solution.

For our customers, the pricing will scare off many. However, if users are concerned more with the security of their account, they'll find this is a good option.

I would recommend the product. On a scale from one to ten, I'd rate it at an eight.

We use this solution to examine disparate log sources and provide a cohesive method to search for anomalous behavior. 

In our compliance environments (NERC and SOX), we are able to provide evidence of compliance.

The most valuable feature is scheduling the KB update, which reduces administrative effort.

I would like to see support added for Exchange 2016, and Check Point OPSec Lea.

Adding the capability to identify and perform an auto import of new log sources (especially Windows-based systems), based on specified criteria, would be a useful feature. 

Enhancing the creation of report packages would also improve this solution.

Our primary use case is for general log monitoring. We do not use it as a SIEM.

The feature that makes it usable is the web interface.

One nice feature about the product is the log message field extraction, where they try to fit every field into a field name. A log message is a string of ASCII text and its value depends on how the vendor formats it. Fields within log messages, such as a time stamp or source IP address, are delimited by spaces. Depending on the type of device, the information varies because if it's a temperature sensor you'll get temperature, or if it's a pressure sensor you'll get pressure, but if it's an active directory server you'll get an active directory message. The problem comes about because in some cases, the fields are not labeled.

Rather than an identifier for a source IP address (e.g. "SRCIP="), it will just have the address, and you have to determine what it is based on its location within the message. Of course, even though the field name is not in the log message itself, the field will still have a name. Extracting it correctly requires that you understand how the vendor formatted it. With LogRhythm, it does a better job than some products at slotting every field into a field name.

The biggest complaint I have is about their support. There is no free instructional advice available on their website. An example is with their field names inside log messages, where they have one named "Common event". That is something that LogRhythm has created, and you can't figure out what it means unless you pay a large sum of money for LogRhythm training. Compare this to Splunk, where I can go to their website and download twenty articles on field names right now. There is no documentation that we can afford to buy for this product, so we just have to wing it.

Their product has issues when it comes to hard drive management. Again, their support is not one hundred percent. We are using their hardware, and one time the product just spontaneously stopped collecting logs for about a month and nobody knew it. We called them, and it took a week or two of troubleshooting before they found the issue. To make it worse, the issue was not a misconfiguration. Rather, it was related to how they were storing temporary logs on the hard drive. The drive was shutting down and the logs were not being accepted. It took them weeks to figure this out and it shouldn't have happened in the first place, which suggests a bad design.

It is a product that is very hard to use. You have to set a wide variety of parameters before you can even start to search. The highly structured nature of it does provide some guidance, but with a lack of documentation for things like field names, I don't know what I'm looking for. 

We don't get much use out of this product because people around here consider it to be unreliable, and it's hard to do searches. The main reason for it being here is that there are audit requirements for collecting logs and maintaining them. We have been able to solve problems with it, but searching is kind of clunky.

Three years.

With respect to stability, I can only speak to our environment, but we have had issues with the hardware. It's a Windows product. We have seen the system spontaneously seizing, and we have experienced complete failure.

When an incoming log message is processed there are a lot of operations that have to take place. These include analyzing the time, identifying fields to see which are present, naming the fields, and indexing the information. We have seen this process fail quite a few times. With the recent purchase of new hardware, however, I don't think that we have had this problem lately. It may be related to an older version of the hardware, but I don't know.

I think scalability would be more difficult. Unlike Splunk, where the licensing is based on the volume of incoming gigabytes, you have to buy additional hardware to handle an increase in data. These boxes are then added to a cluster, and it is expensive.

We have four or five people who use this product, and we're all network engineers.

I don't like their support.

If you go on their website and you want to get a training video for how to do X then forget about it. They're not going to give it to you until you pay. They don't give you any information unless you pay for it. I think that stinks about the product.

Let's say that I am using Splunk, and I need to know how to write a regex (regular expression), or if I need to know how to configure an index or something, then I go on to the website, find an instructional article, read it, and finish what I'm doing. With LogRhythm it's "Where's the money?"

I understand that you have to pay for training courses, and I understand that you have to pay for certification, but it is the same with Splunk. With LogRhythm, it doesn't give you anything without paying first.

LogRhythm came in and deployed the product, and there is no maintenance required that I know of.

This is a solution for people who have cash to spend. Everything is expensive with LogRhythm, and you don't get anything for free.

I suggest that everybody who uses this product receive the full training and certification, and can also afford to pay for the high-level engineering support. If you don't have the money for the training, then it's not for you. It costs approximately $5,000, but if you don't get it then you won't be an efficient user. It is a very complicated product, so the training has to be a commitment that you're willing to make. The training cannot be for a single person, but everybody who will be using the product.

LogRhythm sells you a box that has a certain capacity for incoming log messages. Once you exceed that capacity, you have to buy another box and cluster it. It's expensive. It is for environments where the money is not a barrier.

The solution was already in place when I arrived, so I was not involved in the decision.

Honestly, I don't like this solution so much. I'm actually a Splunk Certified Architect and so I know Splunk pretty well, and when I compare them, I really don't like this product. The best advice that I can give is not to install this product unless you have a use case that matches its capabilities.

The use case for this product, the LogRhythm SIEM, is in a regulatory environment such as HIPAA, SOC, PCI, or banking. These are heavily audited environments where you have precise requirements for reporting. They have pre-configured lots of different types of inputs but it's a very rigid environment. You can only collect information from certain types of sources and it's very complex as to how to instruct the product to obtain a certain type of log message.

Once you configure a new log message source, you'll have to go on to the LogRhythm platform and conduct a variety of clicks and actions to vet or verify that log source and allow LogRhythm to start collecting logs. Not only that, but there's one more annoying thing. I'd say for these highly audited environments, regulatory environments that I mentioned, they have many, many pre-configured reports.

So, it's designed very rigidly. In other words, they have done a lot of work in pre-identifying what the fields are in every type of log message. If you're getting log messages from Active Directory or the firewall then they know exactly what every field is. But, they have their own particular naming convention for fields and with the rigidity, you can't change that so easily.

I'm in the networking team and we're using it to monitor log messages from our networking equipment. For that, it's not such a good product. For example, consider a jet engine with a lot of sensors such as temperature, pressure, rotational speed, wind speed, fuel flow, etc, they have lots and lots of sensors in them that are all connected by ethernet. If you want to use Splunk to monitor a jet engine you can do it, easily. Forget about doing with LogRhythm, that's not happening.

The bottom line is that for highly regulated industries it may work well, but you cannot use LogRhythm to monitor equipment. You also have to make sure that everybody who uses the product has full training and certification. If you're not willing to commit to the full training then don't even consider it.

I would rate this solution a five out of ten.

Our primary use case is for looking at daily logs, drawing conclusions, and making relationships and correlations to investigate particular event IDs, investigate particular alarms that we have, and just viewing normal data use. I'm new to the system so I'm still getting used to it. 

From a security standpoint, it's the solution to have, in regards to LogRhythm. Just having a SIEM solution in your environment is definitely key. It's a very highly rated solution, but we may be moving away from it in the future. We're looking to see what else is out there. 

The ability to investigate a particular period of time where you can analyze logs is its most valuable feature. 

I would like to see more integration with more products that are out there within the same security field.

There has to be some improvement with SecondLook Wizard. It's one of the functionalities on LogRhythm where you can restore inactive logs. For instance, it's a forensic analysis point of view if something happened around a year ago that you have to look into. I wish there was a smoother, more seamless feature.

We have a lot of issues with stability. Sometimes it crashes and we have to rerun a scan. It also freezes. It hasn't been the best.

Scalability is fine. 

We've submitted some tickets with their technical support. My manager has had some poor experiences with them in the past. 

Quality, support, preciseness, and accuracy are the criteria we consider when we evaluate solutions to proceed with. 

I would rate it a six and a half out of ten. Sometimes I have to rerun scans and look into why the scan didn't complete and why it crashed. All of that stuff has to do with the initial set up. For the most part, it does what we want, but there can definitely be improvement. 

I would advise someone considering this solution to look beyond LogRhythm. LogRhythm is one of the top solutions. I would say Splunk is overrated. Look into IBM QRadar and then McAfee as well.

We utilize the LogRhythm solution to monitor most of our servers and our users to make sure that nothing anomalous is happening. What I really love about the LogRhythm platform is the fact that when something anomalous happens, I can see it almost immediately through the ability to collect a massive amount of logs in a very small footprint as far as hardware goes.

We do utilize everything. I think one of the most recent things that I've really enjoyed about LogRhythm is the ability to utilize smart responses published by LogRhythm. For example, one of our use cases is that when we have a termed users group, that when someone is placed in there, we want to monitor to see if their account is ever activated again. So we have a smart response set up that when a termed user is enabled, the smart response immediately activates and says bam, that user is getting disabled again. We don't want anyone to have access to that at all.

We've seen mean time to detect and to respond go down pretty significantly. We actually recently implemented the CloudAI solution, which allowed us to look into our users' anomalous behavior. Recently, we actually had some user who's a remote user, he traveled to somewhere else in the US, and CloudAI flagged it and was like, hey, this user is authenticating from somewhere new. This isn't somewhere we've seen before. I jumped right in, and I'm saying, "Hey, what's this user doing?" We emailed their manager who emailed them, and they said, "Oh, no, I'm just on vacation in California. It's okay." We had CloudAI learn about it, and now, it's really easy to see when a user does something anomalous.

CloudAI has been something in our environment that I have enjoyed immensely. It takes really a lot of the guesswork out of what our users are doing. Right when we implemented it, our CEO was actually out of the state, and we were having a hard time getting a lot of his user data because he was out of the state on vacation. When he came back, immediately CloudAI flagged him in the 80s with a threat score being from 0 to 100. Immediately, I was like, oh crap, our CEO's account has been compromised. But no, CloudAI was still learning our environment. It took it about a month or two to learn what was happening in our environment, what was going on, and then all of our threat scores, they kind of hover around the 20s now.

When something does something anomalous, when they work out-of-state, even when they authenticate to a different Microsoft server, it lets us know immediately what's going on, and it lets us know, and it lets us understand what our users are doing. CloudAI has definitely enhanced our security operations. It helps me understand what the users are doing almost instantaneously. It helps me understand what these users are doing in a daily report, and it helps me really feel why our users are doing certain things, why they're authenticating to certain servers. It helps me understand what their job would really want them to access or what their job has them access.

When they do something different from that, I really want to know why they're doing that. CloudAI helps me know what our users are doing. Rather than what hosts are doing or what servers are doing, it helps me know what the users are doing with their accounts. I think somewhere CloudAI would have room for improvement is maybe correlating hosts with IPs because often, I'll have a user, it'll come up with an anomaly score saying it's been authenticating from different hosts, but really what it is is it'll have the user's computer, then the user's IP that they're coming from, and sometimes their hostname with our domain name afterwards. Sometimes, CloudAI will usually be alerting us on some things that are really just the user's computer IP coming up multiple times.

LogRhythm has really improved, I think, my personal sense of security as far as our organization. I feel that I can trust the data that it's pulling in. Through its metrics, I can see when something isn't reporting so I know immediately if, maybe say one of our core servers isn't feeding its logs to us, I can remediate that almost immediately, and then feel secure again knowing that that data is coming to LogRhythm, and LogRhythm is correctly dealing with it. I can know that our security is in place.

We haven't used any of the LogRhythm built-in playbooks yet. Stability has been really good. The LogRhythm platform in our environment actually sat for three years with no one really using it. I came in about six months ago. I was able to pull it from generating about a thousand alarms a day that were just heartbeat errors, or critical components going down, to it actually only generating about 100 alarms a day, some of those being diagnostic alarms, but most of them being very helpful alarms that rarely ever point to having a component being down. With some short maintenance daily, LogRhythm has been a very stable platform.

I think condensing and consolidating what a user accesses over and over again and just having CloudAI understand that that's all of the user's, and you can consider it as one thing rather than multiple things, and alarming on it, and alerting me on it, having me have a mini heart attack every time it tells me that this user is authenticating from a new place.

Scalability with the LogRhythm platform has been immensely easy. We went from about five system monitors to over 200 in a week. We implemented that through our system management thing, but rolling out 200 system monitors in a week was incredibly easy through the client console, which LogRhythm has documented immensely well.

Tech support with LogRhythm has been great. I've only ever had one bad case out of about the 15 or 20 tickets I've put in. They usually immediately get back to me, and even if it's something outside of their scope, there always willing to help refer me to the person that I need to talk to, and my issue is always resolved within the week. LogRhythm's support for log sources is great. We have about 3,000 log sources right now that we're taking in. Most of that is coming into our main data collector, but anytime we've had any new log sources that we need to onboard, it's been pretty seamless, and we haven't seen any performance hit on our main box.

With our LogRhythm solution, we're processing anywhere from 800 to 1,500 messages per second. With the LogRhythm platform, we're processing anywhere from 800 to 1,500 messages per second, and we don't see a performance hit at all.

We've had CloudAI implemented into our deployment for about three months so far, and out of that three months, we've only had one day of downtime. That was with a scheduled transfer from how they were hosting it before to where they're hosting it now. Stability and uptime has been 99% plus. It's been something that I can count on every day to come in and see this report and rely on it. We really haven't had the chance to scale CloudAI. We're a growing organization, but we're not ballooning, and we're not adding on new users. CloudAI is a great option to sync with AD to pull all your users and, and you can just set up the identities and run with it on day one. The reason why we went with CloudAI and decided that it was something we needed in our environment was because we had the log data for a lot of our servers, a lot of our hosts.

We had the authentication data from our domain controller on the users, but we really wanted to understand what the users were doing and why they were doing it. So we looked into other artificial intelligence programs that would do some of the similar things, but we realized that CloudAI would do what we wanted but then feed the data right back into the LogRhythm platform. With that, we were able to see what the users were doing along with what our servers were doing, what the hosts were doing, and we would have all that data correlated, and we could understand it in one big picture right in the web console.

The implementation of CloudAI was incredibly easy. We just ran a script, added a certificate, and all of the sudden, we were sending the data to them, and we had a report the next day. When we choose a vendor to work with, the number-one thing that we want to understand is that they understand the product. We aren't just going to go to a vendor and say, "Here's our money, please go learn about this product and then implement it in our environment," because I'll just implement it, I'll just learn about it myself and do it. But if I go to a vendor and learn that they know about this product, they've implemented something before, I'm going to go with them nine times out of 10 because they will do something that I can't do myself because I don't understand what's going on.

If I had to rate LogRhythm and CloudAI out of 10, I think I'd give it an eight. There's still room for LogRhythm to improve, and they've laid out a pretty great roadmap for what they want to do in the future. I think if they continued to innovate and continue to implement the things that they've talked about, that they'll continue to grow in my eyes. There is some room for improvement, but overall, if you want a very solid platform with stability and scalability, LogRhythm is definitely the way to go.

The primary use case is tying all of our log sources together between all of our Windows servers, network devices, and we've recently added all of our cloud infrastructure as well. So it's really tying all those together, correlating all those logs and getting us one central pane of glass really as it relates to all of our logging activities.

I think the biggest way that it's improved us from an organizational standpoint is giving us a single view into all of our log sources and all of our infrastructure devices. Whereas before we didn't ever have that. It was always a hodgepodge of stuff put together, so I think it's the best thing is that it brings everything together so that we can all one view of it.

The playbooks are definitely something I see a lot of value and so look forward to when we do get upgraded to be able to using those playbooks. I think that's a way of automating and making sure that we're standardized in the way that me and my team or are utilizing the LogRhythm. I think playbooks are very valuable.

We really aren't tracking our mean time to respond or mean time to detect as of now, that's kind of something that I want to get better at, to kind of formalize that process. So as of now, it's hard to say how much it has, but I know just from an anecdotal standpoint, I can guarantee that we're doing a lot better in responding now than we did before, before we had the SIEM in place.

I think the biggest thing is tying all of our log sources together, whereas there was a lot of manual work before of reviewing Windows logs or you know, firewall logs. Bringing it all together so that way my team, the information security team, as well as the infrastructure team can kind of view all of that from a single pane of glass and see everything that's going on in the environment.

As of now, we're not using all of the full analytics capabilities that we know the logarithm SIM can do. So it's one of the things, areas of that we need to improve on. We have all of our log sources in there, now making sure that we're getting the value of all that together is something we still need work on, so.

I would say the thing that I'd like to see the LogRhythm do a better job of is staying ahead of the curve as it relates to like things like cloud. It seems like from that standpoint that maybe the cloud stuff was a little bit of an afterthought or wasn't done kind of as people started to move to cloud quicker. It's one of those things of where we kind of are doing it now, but it seems like some of the cloud connections are still buying, kind of being created as we go. So I think that's one area I think they could improve in.

Stability has been great. We have not had any unplanned outages, all the upgrades that we have done have gone as expected. So from that standpoint, stability's been great.

Scalability's been great as well. We've got a very disparate environment and the original servers that we have are from three years ago, are still in place. We haven't had any performance issues at all, so it scales to our solution, understanding that as we bring on additional devices, we know that it will scale up to be even bigger than where we're at right now.

Tech support's been great. Every time we work with them on any upgrades or any questions about any of the anything we want to add a new log source or whatever, they've been excellent on that and they're always right on top of it and always get us to where we need to go.

I was involved, actually one of the first. It was one of the first products involved when I started with the company. We didn't have a SIEM, didn't have any really from a monitoring standpoint, didn't have anything. So LogRhythm was really the first major product that we bought and the installation was awesome. I mean it went as expected, moved it along quickly, and it provided value as soon as we were done with the installation. So the install was amazing.

We're about 20 different log source types. I mean all total log sources, we're probably in the 400-500 range, so I mean it has a log source, there are log source types for everything that we have right now. One of the challenges we have had is adding all of our cloud infrastructure in there as well. So I know that's something that logarithm was working on.

We're doing about 2000 messages per second.

When we looked at putting a SIEM in place, we kind of realized that we wanted somebody that was a neutral vendor, where they're not tied to specific vendors that, you know, we wanted to make sure that with the SIM we were buying would monitor all the devices that we had in place. So finding somebody that's kind of an independent, not tied to specific hardware manufacturers, really important to us to make sure that, you know, the SIEM could monitor everything that we had in place.

So I think from a security program, maturity level, logarithm really got us started in that direction. As I mentioned, you know, it was one of the first products we bought and when we first started I really started the information security program myself. So it was kind of the first product we bought that we built everything around. So it really is the kind of the central repository for everything we're doing from an information security program standpoint.

I would say LogRhythm, on a scale of 1 to 10, it'd be a nine. I think it's a really solid solution. I think one of the things that they could probably improve on, as I mentioned, was being kind of a little more proactive when it comes to things like cloud and things like that, so I think that they are getting better, but I'd say a nine right now.

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.

The primary use case for our LogRhythm product is to maintain PCI compliance across all of our environment. We also use it to monitor authentication and monitor our perimeter for security threats.

The product is improving our organization, giving us a lot more visibility. It also gives a lot of our smaller different IT organizations that we partner with better understanding of their environment and also a way to kind of structure the access to that data.

We are using a lot of the analytical capabilities. One of my favorite features is the AI engine that allows us to take multiple data events, tie them together in different patterns and different baselines in order to identify more complex threats in our environment.

Our security program is still pretty immature. It's a pretty immature company, we've existed for less than a year. We're growing very rapidly, we're trying to start with the foundational policy and compliance requirements that we have and trying to tie those and map those into LogRhythm. So that's gonna be our main tool to tie all that requirements into.

The most valuable feature I get out of the LogRhythm platform is being able to take machine data and present it in a format that's easy to understand, easy to analyze, easy to pivot through to get answers to the questions that I had that I'm investigating, whether they're security related or operationally related.

At this time, we're not using any of the playbooks in LogRhythm because it's currently not available in our version. However we are very excited about that feature coming out in the near future and we're definitely looking at using playbooks to do phishing, unauthorized access and our other use cases we're gonna identify in the future to make sure that our analysts are responding to the threats in similar ways and that the correct actions are being taken.

We have around 75 different types of log sources coming into the environment right now. The log source support is good, there's always room for improvement. One of the areas that LogRhythm's kind of pushing really hard right now is to integrate more cloud solutions, so your Office 365, your Azure, your AWS, making sure that those SaaS and other cloud platforms are getting the data you need into that platform. It's getting better but there's definitely still work to be done.

We currently have 3000 messages per second in our environment but we still have a number of different resorts to onboard in our tenant. So we're definitely looking to push above, probably the 7, 8000 range.

The biggest one in my mind that I want to implement is some of the AD controls. Reacting to a threat where an account password needs to be changed, or an account should be disabled, to react to that threat. Moving into first a phase where an analyst is gonna see that, review that action and then once we get comfortable, make that an automated action.

The big two big areas for improvement is TTL. Making sure that the data that we're collecting is available for a longer amount of time. So I know with some of the new releases coming in LogRhythm, that's gonna be improved which I'm really excited about. The other one that's kind of getting back to the fundamentals of why LogRhythm was chosen as a solution, being able to take your machine data, understand it, index it, classify it and give you that visibility.

I'd like to see them focus on that because there's so many different security tools being spun up these days that being able to keep up with that and having more partnerships with security vendors to make sure that security tools have new releases in their environment, they're able to keep up with those logging changes.

Stability in the LogRhythm product has been very solid for me. I'm a very experienced user, I've used the product for about five to six years now. I have a lot of administration and analyst experience with the tool. The other great feature is that LogRhythm support is really excellent, they're easy to get a hold of, they're very talented and if they aren't able to answer your question right away, they have a very good internal escalation process to get an answer to resolve your issue.

Scalability is pretty solid with LogRhythm, I know that's one of their biggest issues, is if you have a huge enterprise environment, there might be scalability issues, but for a small, medium, pretty large sized businesses, I think LogRhythm's gonna be a great tool to match that environment.

I wasn't part of the evaluation at this location, I actually took the job because I knew they had selected LogRhythm and I had the experience there. I know they did some SIEM tools comparisons with Rapid7, Splunk and QRadar which was the incumbent when evaluating LogRhythm as a replacement SIEM solution.

I was involved in the setup at our organization replacing QRadar, our previous SIEM. It was a very straightforward implementation, the TMF team at LogRhythm helped make sure we got everything deployed, gave us some examples of how to onboard the log sources and then kind of gave us a playbook to move forward and gather the rest of the data from our environment.

I'd give LogRhythm a nine out of ten because of the ease of use, especially as an analyst, being able to twist and turn all that data, drill down on it, really get an easy understand of what's going on in the environment.

From the administration side as well, it's a lot easier to use than other products that I've had and it has all the built in knowledge, whereas with some tools you dump all your data into it and it's up to you to do that classification and indexing and understanding of that data, where the value that LogRhythm's gonna provide for you is that prebuilt classification for all the data sources in your environment.

If I had a friend that was looking to implement a new SIEM solution, I would have them understand what log sources they're trying to bring into their SIEM solution and make sure that the one they chose supported those log sources. On top of that, understand your use cases that you're gonna use this SIEM for, have those ready in hand and be ready to start billing those out as you get that data in the environment.