LogRhythm SIEM Reviews

My primary use case is to alert to any anomalies that may have security relevance as far as some of the industry regulations that apply to our health care, as well as payment card industry.

We have a product that is a security orchestration and response tool Demisto and I think that from the standpoint of automation and response perhaps the first version of the playbooks is not going to compare to the product that we have that's a stand alone for that purpose. However from a price point it's very attractive and I think that as it matures we'll look at probably moving over onto the LogRhythm playbooks if it can support the kind of things that we're leveraging out of this other product and it looks like that's their plan.

It was the same that was brought up in one of the talking sessions. Our users will tend to forward every email they don't like just to be safe. It's a spam review and it takes our analysts then a ton of time to go through. So we have leveraged this to go and read from the mailbox that those spam emails all get forwarded to and then to look and analyze the hashes of any files. They'll hash them or the links in the file or the sender or anything that looks funny and it'll do all the things an analyst will do and make its determinations and then we'll see from there if we have anything to follow up on.

Our ability to respond quickly or the time to detect has dropped significantly. There's some things that we see now that we would have never seen. For example, maybe a domain administrator adding an account to a server's admin group that goes against process and policy but they're doing it to troubleshoot something or whatever. We have never seen that before because of the amount of logs that come out of those Microsoft security logs and the fact that we've got 6,000 servers in our environment. But the other things that we would have seen we still see them faster. When we see something that from the power firewalls that verdict change did pass something through, but now it says it's malicious an attachment on an email or something. We can take action now far faster whereas before we might have got the indication out of our antivirus tool when somebody tried to double click the attachment.

Most valuable features for our organization are the centralized painted glass for us to go through and triage and see everything going on in our environment. We're a mature organization. We have a lot of tools and a lot of different implementations and to go through all those dashboards monitoring everything is just not possible. So we centralize everything and then we get it, come into the web console and we're able to triage and respond quickly to anything that is important.

We do use many other capabilities with LogRhythm. We of course collect from our printer devices and our servers as well as some of our security specific systems. We'll drink from API's. We'll also implement file integrity monitoring in our data environment. So we use a lot of different features available within LogRhythm.

It makes is possible to stay aware of much more of what's going on. We get an overview, a macro view that we can zoom in on as opposed to prior to that we had individual panes of glass. You might be stuck in the firewall interface for half a day whereas something goin on is not getting addressed that we really should probably investigate. So that's our biggest benefit.

We're not using any of the built in playbooks. We are about to go up to version 7.4 once it becomes available. We were not an early adopter because of our size.

There's two that I can think about off the top of my head. One is service protection. So for example to compare it to the antivirus product, if I'm an admin on a server I can't uninstall the antivirus product unless I have the administrator password for the antivirus not the domain administrator passwords. In the same way these guys that are out there doing upgrades in the middle of the night and stuff they don't know why anything isn't working. But the first thing they do is they want to peel off all the security products 'cause they think that's interfering. Then all of a sudden I'll have a server that is no longer even has the LogRhythm agent on it. I'm trying to figure out who uninstalled this and whatever. It gets into a situation where I just go well why is that possible? Product like Symantec antivirus or trapps or something. I couldn't uninstall it from my work station even if I'm a domain admin. I got to have that admin password for the product and I think that should be baked into the LogRhythm agent so we have more stability over our deployment.

The second thing that I would like is, like I said our login level is about 750 million logs a day, but sometimes we'll go 850 or 1.2 billion logs a day. Sometimes maybe 680. So what in my environment changed? I don't have the ability really with the tools they give me to profile the systems very well and the log sources except for running supports which I can look at and kind of the crystal reports interface or I can export it to a big giant PDF or spreadsheet. But then I'm looking, well last month the exchange service kicked out this many logs and it's a little bit more but where did the rest of it go? If I go from 750 million logs average in a day to 850 it might not just be a delta of 100,000 logs increase, it could be 150 because something else might not have generated the same amount of logs.

So for the ability for me to be able to profile a system and say what's behaving normally and abnormally you can do some of that with the AI rules and we've played a little bit with that in the past, but it would be better if it was something like what they're doing with UEBA where I can say this server kicked out 80 million logs yesterday and that's not normal for it. I'd like to see what was going on with that box. That would in some ways where my mean time to detect which servers went through a significant variance in what they typically do would be very helpful for me on a lot of days.

LogRhythm gives us the ability to automate. We do have some smart response plugins that we're using. Unfortunately with healthcare you end up using more contextual smart response plugins then you do actionable ones. I can't go and shut down a system 'cause unless I have absolute 100 percent confidence in the fact that it's not actually touching a person because a biomed is a computerized medical device that connects to a person. So in our environment with a half dozen hospitals, 130 clinics. We can't just go around shutting things down or even necessarily quarantining them because it might be a client server type of situation where we can't interrupt this if maybe they're giving a radiation treatment to someone. We have a lot of different enclaves and things. But LogRhythm allows me to see things that I may want to take action on via a human resource. I can send a desktop tech out there to make sure that whatever it is I'm concerned about is not in fact taking place.

In LogRhythm the stability is very good. We're pleased with it. However we have a high rate of logs for at least I think it is. We approach 750 million logs on a daily basis is about our average and if anything stops working or service needs to be restarted it will rapidly vary itself. We don't have too many problems with anything like that it's just from time to time if something's not available, resource it needs, things will begin to back up and then it's exciting trying to recover.

Scalability is good. We had 23 systems not counting the collectors that are big LogRhythm servers, data processors, indexers. That monitors web consoles, pm's. We have in two different data centers we find that scaling for volume is very good. Scaling for the flip over for any disaster recovery situation we don't use Microsoft DNS we use Infoblox and the DR utility up to this point did not incorporate that product line and what was necessary. But they did take it back and that's what I like about how responsive they were. They didn't charge us the PSR's for all the time that we spent when it didn't work. They went back, they worked with Infoblox they handed off a technical document that I can work with my DNS guys back there and then reschedule the hours with PS. So it's really, I liked the way that they addressed it. They made it like we were important. I know we're one of many, but they took that back and they expanded their disaster recovery capability based on the fact that that's what we wanted.

Oh, tech support's good. We generate a lot of tickets. Anything from log, sometimes the vendors will enrich their logging but then that changes the ability of the tool to parse it and so then we'll notice that a log is not parsing and everything's going to the catch all rule. We'll open up a ticket, they'll take care of that pretty timely as well as anytime that we have a high issue, something that's affecting our availability and visibility and our network, they're very responsive.

I was back in 2014, so I was assisting someone else who's primary function was to implement it and it was several full versions back. I think it was version six or five or something like that. I don't know what it was. I think your awareness of LogRhythm grows over time. There's certainly ways to do things that are advisable that you can get away with. Rules that are not two and two well when you're on a certain scale once you get big, no technology is going to really handle any efficient rules and log processing policies that are beyond what you need, right? So I think that we probably had a normal growth path and knowledge curve compared to others where we first got it and we tried to do too much, turned on a bunch of rules. Didn't know how to tune them. But I think that right now we have a solid implementation. We have 130, 150 alarm rules running. We're not maxing out resources. Everything is running really well from a reliability standpoint, availability from the product. We do wish that the web console would go back a little bit further with its look in time. However, it is fortunate that they've embraced some of the other stand alongside technology like Cabana and ELK stack where we can take a look at the parsed data and trend back over time.

LogRhythm gives us the ability to automate. We do have some smart response plugins that we're using. Unfortunately with healthcare you end up using more contextual smart response plugins then you do actionable ones. I can't go and shut down a system 'cause unless I have absolute 100 percent confidence in the fact that it's not actually touching a person because a biomed is a computerized medical device that connects to a person. So in our environment with a half dozen hospitals, 130 clinics. We can't just go around shutting things down or even necessarily quarantining them because it might be a client server type of situation where we can't interrupt this if maybe they're giving a radiation treatment to someone. We have a lot of different enclaves and things. But LogRhythm allows me to see things that I may want to take action on via a human resource. I can send a desktop tech out there to make sure that whatever it is I'm concerned about is not in fact taking place.

If I had to rate LogRhythm I would say I give it an eight out of ten. I think that I like the direction that they're going as a company. I like their philosophy and their milestones that they lay out at these conferences. I do like them also from a product standpoint because some of the competitors are just not, they're price prohibitive as far as volume especially when you look at SIEM tools like Splunk. Small shops can afford Splunk, but big shops you got to really need Splunk to really afford it. The same with Qradar that's what we had previously where we were at and they just became price prohibitive. So I like LogRhythm, they have the full package. I like where they're going with network monitor. I like the UEBA stuff. We're not currently using that. I like the playbook integration. It seems like they're really thoughtfully maturing their product line and I think that gives me confidence for even if I have a pain point now they're going to address that going forward.

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

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

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

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

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

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

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

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

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

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

More than five years.

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

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

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

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

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

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

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

My advice:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Our primary use case would be for compliance. We needed a check in the box for compliance. Right now, it's performing and doing its job, allowing us to say that we are compliant with HIPAA, PCI, etc.

It has improved the way our organization functions. It has allowed us to dive deeper into our network and figure out what is going on by parsing logs properly and being able to reduce the time it takes to work cases down from seven days to approximately two days.

LogRhythm has increased productivity because all the tools that we need are in the web UI, allowing us to find threats on our network fast and efficiently.

Our security program is still in its infancy. There is a lot of work that needs to be done. We finally were able to get our SIEM. A few things that we need to do are data loss protection, user behavior analytics, and another feature that LogRhythm offers that we're probably going to invest in the future. The program could use some work, but it is pretty solid now.

The most valuable feature is the Threat Intelligence Services (TIS).

We would like to see more things out of the console into the web UI. I guess this is what they are doing in 7.4.

In the three weeks that we have had it, we have had 99 percent uptime. It is a very stable platform.

It is scalable. They don't charge for going over your messages per second. It does scale with the business. 

Technical support could use a little work in the terms of responding back. The feedback that we received is they do need a little more staff, but every issue that we've opened a ticket up for has been resolved.

We did not have a previous solution that we were using.

The initial setup is straightforward and complex as it requires a lot of work. It's very straightforward and very organized. Our consultant guided us as to what we needed to do, but the entire thing is complex. One misstep or incorrect character can bring the whole thing down.

I do all the deployment and maintenance.

The sales engineers and salespeople who come in and scope out what you need are very knowledgeable. They are not there to upsell you. They get you what you need for what you have, so everything runs perfectly. The consultants are extremely knowledgeable. Getting LogRhythm up took less than a week. It's a very solid solution.

When it comes time to renew, they say, "This is what you are using. This is what we can do for you." So, they work with you on pricing.

There were multiple competitors. We almost went with Splunk, but LogRhythm ended up being the best for the price. It ended up being everything we needed in one solution.

Everyone needs a SIEM. Go with LogRhythm.

We are not using the full-spectrum analytic capabilities yet, as we are brand new.

We have not used any of the playbooks. We do have them. We find them to be very detailed and organized. We just need to find a way to implement them.

I run in about 45 log sources with 12 of them being domain controllers, aka DNS.

Messages per second are fluctuating between 3000 and 9000. We are still trying to figure out why. We think it is our very chatty domain controllers, as we do deal with the Hard Rock and Seminole tribe, but I would say that we average about 5000.

Most important criteria when selecting a vendor: customer service. Do they care about our business as much as we care about our business? Also know as, do they care about our data as much as we care about our data?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Once you get stuff up tuned, it just runs.

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

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

Check it out.

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

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

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

We have about 1800 log sources. 

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

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

The log correlation is the most valuable feature.

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

The coordination and load bussing has room for improvement. 

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

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

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

The solution is stable.

The solution is scalable.

The technical support is responsive and always resolves our issues.

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

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

I give the solution an eight out of ten.

The solution is for medium and large organizations.

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

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

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

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

I have been using this solution for about two years.

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

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

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

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

I didn't use any other solution previously.

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

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

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

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

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

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