LogRhythm SIEM Reviews

I found it very useful in our day-to-day operations with monitoring user activity and looking at system analytics and system performance. I found it very useful when investigating threats like IPs, and seeing what's going on with our endpoints, like certain lateral movements that we've noticed. 

I definitely found it very useful when looking at, for example, a compromised host, or a suspicious IP that has been scanning us. I've definitely found it very useful when I look at a log, it'll give me a detailed drill-down of all the information that's needed, including what the rating is, the rating of the threat, and what actions should be taken. 

It gives my team a better idea of what we should do to improve our security posture.

It's improved our organization. For example, if we have a user who's traveling overseas, or we get a suspicious login from the VPN, from a country that we're unfamiliar with, it gives us the ingest logs. The SIEM gives us a better comprehension of what type of threat activity it is and helps us decide if it's benign or legitimate.

Looking at the logs and how much detail each log has when it is ingested into our dashboards is quite useful. I found it very useful when looking at, for example, what emails are inbound and outbound of our networks. 

I like how detail-oriented the logs are in terms of what the origin is and what network it's coming from. 

I also like how the detailed logs give us what host or user it's coming from. On sight, I have a pretty cohesive understanding of what threat intelligence looks like in terms of reviewing what we have to deal with.

I use the Event Log Filtering feature daily. Every day when I look at event logs, I use the filters on certain time ranges and AIU engine rules. Overall, it's had a very positive impact. It helps us expedite certain security incidences very quickly, thanks to how detail-oriented the logs are. It really helps me report threats to my supervisor. For example, if someone's trying to scan us, my boss will ask me, "Can you look into this further?" I'll go ahead, and use the searches and the lists that the LogRhythm console has to offer, and I will get back to him in a timely fashion, with more details on the threat. 

The Event Log Filtering feature has definitely helped reduce administrative overhead. On a scale of one to ten, I would rate it a seven.

It helps us manage workflows and cybersecurity exposure. In terms of managing workflows, it definitely has given us leverage on what our overall security posture is, and gives us a better understanding of what we need to focus on more in terms of what threats are persisting. Our workflows have been pretty seamless so far. I would say our workflow is pretty seamless in terms of static manual investigations.

In terms of blind spots and our ability to shut down attacks, while we don't see all the blind spots, it gives us enough understanding and information about where we can classify a threat. 

Overall, it's had a very positive impact on our security posture. It gives us good visibility of what we need to see right now. It definitely gives us a better understanding of what we deal with, and what we should focus on in terms of what threats are more critical than others. In terms of our daily operations, it's very helpful.

It's positively affected our overall rate of efficiency. It's given us what we need for now. We're looking to improve our efficiency by looking into what LogRhythm offers in its newer products. Still, it's pretty efficient. On a scale of one to ten, I would rate it around eight or nine in terms of efficiency. My immediate coworkers in my department could use what we have right now for looking at critical alerts, user analytics, and overall IT operations since we usually have daily operations where we look at all user activity throughout our organization.

So far, it's pretty robust, and yet, we look for more improvements.

On a day-to-day basis, maybe we could look for more improvements with automation, however, so far, it's good.

In terms of blind spots, we are looking for more improvements since we don't have visibility over everything. Right now, we just use LogRhythm for our on-prem solution, not our cloud solution. We could definitely use more improvements with that in the next product.

Ingesting logs into the web console user interface and probably updating the threat intelligence database are the two places where we'd like to see improvement. We get a lot of noise. Oftentimes, we see a lot of false positives, so possibly using AI or machine learning would be ideal. Implementing that more into the next product would help us actually determine whether it's a false positive or legitimate threat.

I've used the solution for about a year and three months.

In terms of using it on-premises, it is very stable. Granted, we have some hiccups here and there. However, that's what we reach out to tech support for. They're able to provide us with immediate support, and they're willing to really put in the effort to figure out what the cause of the problem is and will work until it's fixed in a timely fashion. 

The scalability is, so far, very robust. I look forward to hearing more about the latest LogRhythm products and what they can do in terms of on-premises and cloud.

The product offers excellent service and technical sport. They're very prompt with getting back to our team regardless of the severity of the incident. Overall, I've had a great experience with this so far.

Positive

I'd rate the solution ten out of ten. 

Those that say SIEM is an outdated security system, don't understand cyber security. SIEM is what allows analysts like myself to be successful. Without a SIEM, how can we see everything? We can't.

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.

I am a security architect, so I don't develop the use cases with the customers if they deliver a team who is in charge of these activities. Depending on the case of the customer, we define something with the customers, according to the technical sessions that we have with them. I prepare all the documentation for the delivery team and present the project.

LogRhythm is deployed on-prem. There are about 60 people using this solution in my organization.

SOAR is integrated with the dashboard that we use for threat management. Because it's all integrated, it is useful for us when we deploy something on-prem.

I don't think the cloud model in LogRhythm is developed enough. This is one of the reasons they changed the position in a negative way in the Magic Quadrant Gartner for SIEM in the recent report. The cost of UBA is also high when you compare it with Securonix.

I would like to have a different cost model for cloud. If that happens, I think LogRhythm could be competitive in other cases with the customers.

The virtual machines require a high computer power, and sometimes customers say it's expensive. There are specific requirements from this solution. LogRhythm has a specific requirement when implementing in virtual machines, which is a very complicated issue. The best solution is in the cloud, most of the time.

I've been using this solution for more than five years.

It's stable.

When we are using LogRhythm in the cloud, it is scalable, but it's more expensive than other solutions. When we are on-prem, it's a little complicated and has a lot of challenges that the customer doesn't want.

It is scalable in the cloud, but not on-prem. It is not easy. It takes more time and money. I would rate it 3 out of 5.

I would rate the presale support 3 out of 5. They could be in contact more and give more information. It's average. I have heard that post-sale support is good.

It's simple because you only need to consider one component and that's it. But if you have a customer with different companies and each company has different subsidiaries and all of them want one only service, all of them will be sending the logs into one single SIEM, so you need a distributed architecture. You need to think about how to include new components and how that will be impacting the architecture in the near future, because we don't know the cost. In some cases, it's complicated if we don't know the new versions or the changes that the vendor will be publishing.

Deployment commonly takes three months but can take up to six months.

We use about six people for maintenance.

We deploy the solutions on our own.

I would rate the pricing 4 out of 5. There are no additional costs to the standard licensing fees.

The customers commonly want to know what is the price for the service in different bands. So we work on a banded price model, and it is something that is complicated. We include the UEBA, which is sized and quoted in terms of the number of users and entities. So we need to make a price banded model for the SIEM and a price banded model for the UEBA. We need two of them and they are related. 

If you increase the number of users, you are increasing the cost of the service of the SIEM. Sometimes we don't know the exact relationship between these two components. In the case of other solutions in the cloud, like Securonix, you just need to say to the customer, "This is the price of the different bands."

I've evaluated solutions that can be deployed in the cloud and have other features or components, like the UEBA. In the case of Securonix, it is included. We need to decide if we are going to propose something that is on-prem or in the cloud, depending on the requirements of the customer. The architecture is more complicated when you deploy something on-prem, so you want to increase the number of EPS, the events per second. You need to consider the architecture.

With Securonix or Splunk, we just need to go to the partner and say, we need an increase in the number of EPS. We also don't have to provide maintenance to the solution because it is in the cloud. Our specialist is more focused on the security aspects instead of providing maintenance to the components.

I would rate this solution 8 out of 10.

My advice is that if the requirement is to have someone on-prem, for example, someone that is working in a financial entity, it is a requirement to have all the information in their own data centers and using specific connections. If you have that case, you can use it. It is convenient. And you can use it if you have a case where the evolution of the environment is not going to change for the next three years. Otherwise, if you have a lot of changes during the time that you are going to be using this solution, you need to include different components that will probably be complicated to architect.

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.

The benefits are almost innumerable. You can't know anything unless you are capturing the data. Once you are capturing the data, you can then make intelligent decisions around what is and is not appropriate, and what is and is not dangerous. It improves the security posture, because you can then know when things are happening that are bad.

Before the LogRhythm solution, if someone was trying to login to a server with a local admin account, I would have no way of knowing that. Nothing would log it, audit it, and it would never show up. Now, I get an AIE alarm every time that happens, because it is considered a pass the hash attack.

If we know when these things are going on in our environments, we can identify rogue admins doing things that they should not be doing, and the questions can be asked, "Why are you using this process? What's failing you that you have to go around the normal procedure to do this?"

Another big one we found was just the ridiculous amount of PSExec running around the environment by non-admins to touch other things, which we have tried to curb. Then, we were able to ingest some custom log sources that have helped us become more proactive in alarming. Some of the stuff that we are using does not do good alerting, or it does not do role-based alerting. So I do not need an IT admin in Georgia to know about a potential issue in China. He does not care.

I need that alarm to go to China, and not to Georgia, but some of our solutions will only send their alarms to one source. So, you either send it to the entire IT organization, every time it happens, or you do not send them at all. It has helped us pair down the noise to our site level admins, and give them more actionable intelligence quicker.

We are a global company. We have 37 locations. China is one big country in Asia. We are on Australia, North and South America, and in Europe, with about 5,000 full-time employees. For the technology stack, we are running a single LogRhythm LR 6403. 2500 NPS license which we are currently hitting the lid on every day, and running a combination of Trend Micro and Malwarebytes. For endpoint, doing Cisco, Firesight for IPS. We are a Cisco shop, a 100% on the network, and we are a VMware shop, 100% for the servers.

Right now, my biggest challenge is distilling the technical data that I am getting out of the LogRhythm appliance, in my reports, and translating that to business value statements to the business units to justify that I need more NPS or I need a bump to NPS, or I need another VX, which is a lot of money to spend. I have to now, instead of making the fear argument of, "Oh my god, the world's on fire." Instead, it is more of, "Here is this device, here is how this solution partners with the business to enable them to make better decisions about risk." Also, they can feel safer in making somewhat more risky decisions, because they know that this solution is behind the scenes, watching, keeping an eye on things, and our team will tell them if something is going wrong.

The ability for me to go into the Web UI, and just learn what's going on in my environment. Being able to go in and show our company's management, "Look, this is what we can see. This is what we can now know about our environment."

Then, using the past several months to baseline what's normal, it has been invaluable, and we have also been able to stop things that were bad, at the same time. We were able to actually show value, while we were still building out the solution.

My biggest challenge always come back to log sources. We are a manufacturing company, so we have a lot of old stuff, and it has been a challenge to get some of our old stuff to light up within LogRhythm in a way that makes sense. I have probably submitted half a dozen log parser requests, and I keep finding more stuff that we need to keep an eye on that doesn't have a definition in LogRhythm. I keep pressing through, and I know they are working hard on it, but that is our biggest challenge.

It has been incredibly stable. I had one minor hardware problem, where it did not reboot at all. It just sat there, but it was just a minor hardware thing, other than that, the software itself has been incredibly stable.

It is near infinite. We are running a single appliance, but I can, even with my current license, break the Web UI off and put it on a VM if I need to, just to relieve some of the pressure. If I need to bring in another appliance, I can bring in another VX, and cluster those, or I can move AIE off onto another machine, it goes vertical and it goes east-west.

Customer Service:

I can't say enough about LogRhythm's tech teams, the staff, the SEs, and even my CRM. They have all been fantastic.

Technical Support:

We are on a first name basis with most of the technical support.

My company did not get me professional services, so I deployed LogRhythm by myself, with no knowledge. So I probably opened 50 tickets in the first three or four months.

They are amazing. They have an incredible depth of knowledge, even the Level 1 person that answers the phone, and their Level 3 support has been invaluable.

LogRhythm is the first SIEM that my company has ever owned. They never owned one before, and it took a lot of convincing to get them to buy it in the first place.

Definitely do a PoC.

• Get an appliance in your system and your company.
• Get your PoC guys to sign their CTU.
• Then, truly think through the business case for this device.

What is it that the business finds important, and how can this appliance/device enable the business to know more about the solution, and to protect that solution from anything.

Because if you start with what we like in the tech industry and what we want to do, you are going to be talking about red team exercises and hacking attempts, and those are all good things to have, but they just do not translate on that initial ask for $100,000s.

You really need to target the business, find out what is important to them, then focus that stuff in, and try to answer their questions with the PoC. Then, they will sign any check you hand them.

We were actually dead set on using Splunk. I came from a Splunk shop at my previous job, and I am a big fan, but I had never seen the Web UI before. So, it is a combination of a few things: The web UI, price pressure from the business, and dedicated hardware, which made LogRhythm the overriding choice for us.

I have seen the features that are coming in 7.3, and they look incredible.

It has far exceeded what I thought it was going to do for me in my job role. With the Web UI, over like a Splunk solution, it has actually become a tool that is used outside of security. I do not have to have people who have Lucene SQL Query Syntax memorized in order to get a value out of the system. They can jump in, log in as themselves, point and click, build themselves a query, and everything's great, then they love it.

It is an SIEM tool. It gathers logs, parses and normalizes them, and correlates the logs with the rules we write. For example, if an account tries to log in multiple times with the same username, I can write a rule for it. The SIEM tool would analyze the logs and generate alerts based on the rule.

The user interface is pretty good compared to other SIEM tools. The log search capabilities are good. It gives results pretty fast.

The correlation can be improved. If an alert is generated, we want to know the related events. We often have to search for the drill-down option. Sometimes, it is not available. Sometimes, the tool fails to get the correlated events that triggered the alerts. Searching logs is a bit difficult compared to other tools.

I have been using the solution for one year.

I rate the tool’s stability a seven out of ten. The tool fails if we run big queries. The search breaks down even if we put a limit on the number of events.

I rate the tool’s scalability a seven out of ten. It generates alerts but doesn’t give us the related events that generated them. Sometimes, we need to mess with the configuration to get it back up. The security team uses the tool to analyze the logs.

I used QRadar before. I prefer QRadar over LogRhythm.

The initial setup is easy. It is not that difficult.

People who want to use the solution must not do any big searches. Overall, I rate the product a six out of ten.

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.