LogRhythm NextGen SIEM Review

Useful to maintain logs for auditing purposes, but too complicated to use with insufficient support


What is our primary use case?

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

What is most valuable?

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.

What needs improvement?

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

For how long have I used the solution?

Three years.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

What about the implementation team?

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

What's my experience with pricing, setup cost, and licensing?

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.

Which other solutions did I evaluate?

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

What other advice do I have?

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.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Add a Comment
Guest
Sign Up with Email