LogRhythm SIEM Reviews

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

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

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

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

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

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

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

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

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

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

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

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

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

The primary use case is to provide security analytics for the SOC and empowering all of our SOC operations for day to day business.

LogRhythm's improved our organization by allowing all sorts of members of the organization to be able to access this data in a much easier way than they have been able to in the past. So instead of more obscure SIEMs, or things out there like Splunk, where you might have to learn an entire language for how to interact with your data, it's all very visual based.

I'd say that's a big difference right there, but also just the ease of use of getting it into and getting it indexed by the SIEM. The other piece of it that I think is pretty huge for us is just how fast it executes on that data. So in previous SIEMs, I've seen where we've had to take up to three or four minutes for a simple query. I have that back in seconds. That's definitely a huge performance improvement for us.

I would say that the maturity of the organization that I'm with now is it kind of straddles a couple of different zones. On the one hand, we have a security team, and members on the security team that have been doing what they're doing for a very long time, and a couple of them even doing that a very long time at that organization. However, the security landscape has changed just dramatically in the last few years. And that definitely sounds like totally hackneyed, but it's true, especially when it comes to cloud integrations, AI, data science, all of this stuff has changed the game so much. So I would say that we're very much behind the curve in terms of we're a team of six or seven people trying to keep up with the industry. And we really look to these next gen tools like LogRhythm's SIEM to bring us there.

New functionality like playbooks are exactly how we're going to raise the maturity level of our team through automation and playbooks. That's absolutely the direct path that we see getting us to a more mature place. We've got the experience on our team, but we don't have 100 people working for us either. And so, we're really kind of looking for LogRhythm to fill that gap there.

Specific to LogRhythm SIEM, I would say the dash boarding capability is pretty spectacular, so having the advanced UI available to just instantly drag and drop widgets into the browser and get top 'X' whatever field you're looking for just in real time is incredibly powerful. It's very fast. That's one of the things that I love about it is that we can get trending information at a moment's notice for just about anything that we have packed into the SIEM. So it's incredibly quick to get very easy high level information on any field we're looking for in the SIEM, and then be able to drill down into that through the log feature at the bottom.

We are using their AI engine, we're using the actual web console itself. We're using lists in some of their automated list for generating content of blacklisted hosts or known malware sites and things like that.

Most of those features are turned on at this point in time. We're actually pretty new, I think that says a lot to the amount of use we've been able to get out of it. We've only installed it maybe three or four months ago. And the amount of data that we have going into the SIEM at this point in time, which amounts to nearly 20,000 events per second, plus all the different features we have turned on is pretty impressive. So I think that that speaks a lot to the ease of getting it stood up and running, which is something that I've seen be way more difficult in other SIEMs in the past.

We will be using the playbooks immediately, on day one, as soon as they're available. I've attended some of the playbook sessions here already and we're looking at which ones are already out there for use and how we're going to integrate them into our environment. So, playbooks are going to be a huge point of focus for the next year for sure for us.

I think LogRhythm definitely has some opportunity to grow in its documentation space, particularly like if I just use Splunk as an example. Splunk has amazing documentation. It's great. It's almost second to none in terms of the quality of its documentation. I would almost use that as an industry standard and say, "If you can do this ..."

There's no reason someone can't copy that pretty much exactly and say, "Let's do the same thing, but for LogRhythm." That way, when I have a new engineer or even an analyst come on board, I can point them to the documentation and say, "Get to work." That's not really possible today. We definitely need a little bit more hand holding when it comes to administrative features that aren't nearly as obvious when we're using the thick client or something like that. 

We've got a lot of work to do in terms of training people up there. But the documentation, I would say, is probably the biggest, one of the biggest things that I've come across to say, "This definitely needs some improvement here in terms of its clarity and availability."

Even just finding the right documentation that you're looking for can be tricky sometimes. My best bet is usually just to do a search of the forums and hope that I can find something and get lucky on the first try, as opposed to having every part of the system thoroughly documented out in an almost open source like way, in the way that open source projects have often gone about documenting and Wiki-izing, if you will, their content. I would love to see LogRhythm do something like that.

I would say that stability for us, overall, considering we're a brand new customer of LogRhythm, it's been very stable. We've had a couple of things come up, and I'd say those are more than anything just a "Oh, we didn't know that this should be tuned to a particular way or that the database wouldn't auto grow on its own". And there've been a couple of things like that, but there's been no major issue of, "Oh no, we threw too much data at it and the whole thing just died."

That's one thing that I'm pretty grateful for is that the whole thing hasn't come crumbling down upon us. And that can happen with a SIEM, particularly when you've got multiple data streams feeding in. As one piece of the puzzle breaks down, there's a downstream effect of killing every other part of the SIEM further on down the line. That hasn't happened yet. So, we haven't had any cascading failures or anything like that. It's actually been really stable so far and we've enjoyed that.

Scalability has been good. We have general guidelines on how far we can take it with with the hardware that we've purchased and installed. And we can sustain even above a little bit, we've found, a little bit above what we're even scoped out for our hardware. So, we've been able to really expand the scope of logging to the endpoint level, so we can take logs from every end point in the company and throw that at LogRhythm for the installation that we've set up. And it can keep up with that and we haven't had any issues of it just starting to drop stuff or anything like that. And so I would say it's definitely a top tier vendor in terms of being able to handle scale in my experience.

I've personally used a bunch of them and we've also, in just our QA process, we've interviewed several before settling on LogRhythm. Splunk would be the big one. And I think in that case the, the licensing mechanism kind of disqualified them. And it's a good system with a large community around it. But the ease of use for the end users wasn't quite there as it was with LogRhythm. Plus the licensing scheme felt a little bit out of date and cumbersome in comparison to LogRhythm.

I have only needed support a couple of times so far, we've opened a few cases with tech support. I can't sing too many praises of tech support so far. And they definitely have a tendency to want to try to lead you towards professional services, which isn't completely unusual in these cases, especially for new users.

I would say that the information is out there somewhere, but they don't have the best support site. They just don't. A lot of the information is just kind of in a forum somewhere buried somewhere in that forum probably, or in somebody's head. The documentation isn't quite as greater or spectacular as Splunk for example. But LogRhythm Community does have a passionate community. And if you find the right person, chances are you're going to be able to get your question answered.

I was hired just after they did the initial setup. But I immediately, because I'd missed that, set up a dev environment for us using all of the same components, so the differentiated data indexers and the platform manager and all that. So I set up a whole version of that on my own in virtual environment after the fact. And I did it by myself without too much help. So, that really did go pretty smoothly. I only needed to contact support once for that whole process. So it wasn't too bad.

A couple of others that we've considered, IBM QRadar that's actually one that we had in house previously, and we'd had stability issues with that platform. And so it was one that we were kind of looking at the market to see what we could replace that with. And I would say again that the ease of use of LogRhythm, for new analysts as well as management people, and the licensing scheme were two things that made it pretty attractive for us

We do have quite a few log sources. Currently we've got around 30 or 40 completely different kinds of log sources and roughly six or 7,000 different devices currently reporting in. We set it around 20,000 events per second sustained for our new infrastructure. That's kind of a lot for us. We've gotten that up relatively quick, up and running. So the stability for that has been great. And as far as parsing goes, we have generally stuck to platforms that we know would parse out of the box. And now, we're just starting to get our feet wet with, okay, what are some platforms where maybe it doesn't have out of the box support for the parsing messages" Or we might want to write our own parser or something along those lines.

We know that it supports things like common event format. And so generally, I'm pretty confident that we'll be able to get everything in there that we want. I wish we had that information. Unfortunately we don't have mean time to detect or any of those soft things. Prior to LogRhythm, it wasn't even an option for us to get those sorts of things. Now with playbooks coming out and some of the new tagging features and case management features that are going to be in seven point four for LogRhythm, that's our first target is to start actually putting numbers around that. And we just haven't had LogRhythm in house long enough to stand up a program around getting those metrics.

As far as the rest of 2018 and 2019 goes, that's one of our number one goals is to get those metrics in place. And certainly, the case management features and seven four are what we're looking to get us there. 

I can tell you for sure that that saves at least an hour of analyst time every single time that occurs and that might happen three or four times a day even for just potentially unwanted software and things like that. So we know that we're saving a lot of time. I have no idea how much exactly we're saving just yet, but I know it's going to be a lot more in the future because we're really starting to get sped up with smart response options and automation, especially when it comes to playbooks. So we'll see a lot of that in the future and that's another one of the big reasons that we've looked to LogRhythm to say, "Okay, we know that we still have yet to see some of what we've invested in here, but we're confident that we're seeing it already."

I give it a nine out of ten right now. The only only minus being for documentation, that's it. But I think that they can get there. So I have faith in them. The advice I would give to somebody looking for a new SIEM or to invest in SIEM technology would be obviously they have to keep in mind the price. We always have to work within that constraint. As a technology person, I hate to think from that perspective, but it's our reality and so things like Splunk really work against that in terms of being able to have to pay for ingestion of data. LogRhythm is great in that area. And that's one of the reasons why we've definitely looked towards LogRhythm for that. A couple of the other things that I look at for them is automation capabilities and API's. 

Everything these days has to have an API. So how good is your SIEMs API? And LogRhythm definitely seems committed to continuing developing their API out, particularly with playbooks and automation. And so, generally, I'm going to say that's where you should be looking for SIEM right now is automation. Most of the SIEM software solutions can do 99 percent of what's out there. Can It parse a message? Can it store it? Can it index it? All of those things, they all generally check that box somewhere along the lines. But how closes is that ecosystem? How available is the API? How good is the support gonna be and things like that, that not necessarily every SIEM does equally? I would say that's where they need to look to find their value.

Our primary use case for bringing on a SIEM in general was the need to correlate our data across dozens of different solutions that were spitting out logs. We got to a level of complexity where it became mandatory.

This solution has been almost like a transformative change in how we detect and then respond to incidence. Quite honestly before, we didn't know what was going on and we couldn't detect anything other than  a random virus that sent an email from our AV solution. For us, it really took off when I was a little onboard the Office 365 logs and then we were able to start monitoring locations of login and we actually detected multiple accounts that were logging in from countries that had no business being there.

That led to some investigatory work and actually led to some password resets. It was really positive and we continued to detect that type of activity and enhanced the rules, changing here and there. That was a big one for us because we had never even looked at the Office 365 audits because we didn't have a way to do it. LogRhythm brought that in and within a day or two, we're like, "These three accounts are popped and we need to get these guys off the network now." It was amazing.

We're currently processing about 3,500 messages per second. We have experienced a massive decrease in our mean-time to detect. It's actually hard to improve on nothing. It's hard to get worse than no detection, so we went from being able to like, "Oh, a virus happened," to, "This user went to a weird website. We got that from your DNS logs and then 10 minutes later, their antivirus fired on something." And now we know that we can go over there and triage that system quickly as opposed to maybe not getting the virus log for a day. The other thing is detecting when we think breaches are happening, which is something we just didn't have the capability to do before we brought in LogRhythm.

When it comes to our security maturity, I was the first person at my company to do security, and the company had been around for 30 years. I bet that started from scratch, and I started where we were bleeding which was our endpoint detection for malware and ransomware. And then be added on more layers. We added on like IPS and we added on a lot of perimeter type stuff.

While LogRhythm was probably the last component that I have onboarded in like first two-year time frame, it's now the center of the program. Everything feeds into it and that's where I go for just about everything. There are a few solutions that I still have to go out to those solutions to look at stuff but even like from a purchasing perspective, even my IT operations team, my IT applications team, my company asks vendors two questions right out of the gate. Do you have a cloud offering, and do you natively support LogRhythm? And those two are heavy, heavy hitters when it comes to whether or not we're going to put you in the running to buy your software.

The most valuable features in LogRhythm, honestly for me, the single most valuable feature is the web console. That is actually the primary reason we chose LogRhythm over some of these other solutions because I was able to leverage web console usage across multiple layers of IT, and I didn't have to sit back and teach everybody complex SQL queries. Just that point-and-click interface, it's nice and bouncy and it's beautiful to look at has really driven the adoption of the use of the software. Secondarily, I think another really great feature is the LogRhythm community. And the content that that provides has enhanced our adoption over the years.

We don't use the full-spectrum analytics capabilities of the SIEM mainly because I'm a lone wolf in running it. It's just a matter of timing and focus. We do a lot of analytics around user behavior although we're not a cloud AI customer yet. We're doing a lot of what they call the AI engine to do user behavioral modeling and we're starting to onboard some network behavior modeling analytics as well.

It honestly comes back to me for log sources. The time to get support to onboard a log source runs about 18 months, and that's just too long. Like I said, I'm a lone wolf running the system. I don't have a lot of free time to write ReGex and build out my own policies, and I tend to write bad ones that are very inefficient. It is tough when I get a critical source or when a part of the business went out and just bought something, never consulted IT, and now we have to audit it and it doesn't support LogRhythm or it doesn't even like have a function that gets us the logs. We have a cloud solution where we can't even get the logs out of it. It's crazy bad. But when we do get those logs in, it would be really helpful if we could get a supported log source policy from LogRhythm in a shorter amount of time

I have had a lot of trouble with stability, perfect timing. We onboarded way too many log sources on the get-go and overran our appliance's capabilities. And I've spent probably the last 12 months working to stabilize the damage that I caused the system when I did that. It's been a rough year for stability. Even just before I came to this conference, I think I got it finally stabilized. I'm cautiously optimistic that I can take a deep breath and start focusing more on the logs instead of the appliance itself.

We've scaled the solution twice. I haven't done a whole lot of like large-scale build-outs. We're still a single appliance. What we did scale was we scaled the memory and we scaled our NPS license and then I added in some external storage. And all of those things went great. We're to a point now where they're recommending that we buy what they call a data indexer separately. My leadership is more interested in moving it to the cloud than buying more hardware, so I'm working to get a POC started up to get it up into Azure and see if we can scale horizontally in Azure as opposed to buying more hardware. I might have a lot more to say about scalability next year.

Tech support LogRhythm is one of my favorites. Of all the solutions I deal with, those guys and girls are insanely good at their jobs. And so when we bought the solution, my leadership did not buy professional services to help me deploy it. I did it blind, basically, with the user guide. And I think in the first year, the number was about 75 tickets that I opened in the first year. And they still answer me when I call them, so that's great. And they're very willing to stick with you as long as you need.

The only challenge I do have with their tech support is the time shift because their tech support is all based here and I'm on the East Coast. They want to meet it like 5:00 p.m. Denver time, it's like, "Oh, no. I'm at 7 o'clock, dude. I'm done for the day." One little annoyance but it's well worth it in the end to get the support that we get.

The support for log sources is fantastic. It is challenging because you're always going to come up stuff that you need that is not recognized, and writing my own policies has been very challenging. As far as log sources, the last time I checked on Friday, I think we were at 2,900 log sources. It's a lot for this little appliance.

When we went shopping for a SIEM, I had come from a Splunk shop. I was very familiar with Splunk the interface. I like the software, so Splunk was number one on my list. And who was number two? SolarWinds had a SIEM solution that we had played with a little bit at my company, so they were also in the running. And then actually one of my partners talked to me about LogRhythm because I'd never even heard with LogRhythm before and so we did a demo.

And ultimately, it was two big factors. From a Splunk perspective, cost. Cost to build it out and then cost of licensing, it's just unattainable for us. And number two, LogRhythm's WebUI and the speed with which you can run searches in it was hands down my primary reason for going with LogRhythm.

I'm going to give them an eight. It's a fantastic solution and I totally support what they're doing and I like where it's going. But there is room for improvement, and there are some pain points and honestly I've had a rough year. That kind of influences it too. It's been a lot of time on the phone with support this year.

I will tell them what I wished I have known the day I started onboarding logs, and that is when you're looking for a SIEM, put all the features and everything to the side. Go talk to your business people and find out what's important to them because that's how you're going to know what to bring on initially. And once you know those things that are critical and the things you have to do, then you can evaluate the different solutions to see who has the native support because we didn't do that.

We bought it simply because it was awesome and fast and less expensive than Splunk. And then I onboarded 1,500 log sources in a week and brought the system to its knees. And I'm even now today still cleaning up and removing log sources that just bring no value. It's just noise.

Take the time and plan that out before you even go talk to vendors. Figure out what logs are out there, which ones are meaningful to you and the business and then find the solution that fits best with that.

Our primary use case is for fraud detection and infrastructure, so we use the SIEM to detect frauds in the banking side of the house as well as infrastructure. I use it for security and UEBA purposes. 

We have seen a lot of improvement. When I first got into LogRhythm, we were just doing the fraud side of the house. Afterwards, we started doing the infrastructure side, where we're seeing a lot of events coming in. We were getting a lot of ransomware attacks that are happening or a lot of malicious actors coming in, trying to hack ours, which we can see in the SIEM right away and use the SmartResponses to block it at the firewall level.We stop them at the edge level, and we don't have to worry about them coming in.

We do have an MSSP that does our 24 hours ops, when we're not there during normal business hours.

The playbooks will come in handy for them to go through and meet our expectations, so I can design the playbooks of what I expect and what the organization expects during certain events triggering and the process that they need to take place for them to call us up at night and say, "Hey, this is something that needs your attention."

I have plenty of log sources. Roughly, I have about 500 plus different types of log sources coming into my LogRhythm, and the support's been great. The out of the box solutions with their log message processing has majority of what I need. There are some that I had to create, because obviously the products are new, and I made LogRhythm aware of it, and they're creating custom parsers for it.

We are rated for 10,000 MPSs because we have two data processors and data indexers, but I'm only using about 3,5000 combined.

The solutions have been great for us. We use the SmartResponse to do most of our automation work for us, to block attacks, and to kick off users if they're doing anything malicious. It's saved us a lot of man hours. Based on MTT and MTRs for us, we've saved a lot of considerable time.

I did see it decrease in time to detect and response by a day, because there is myself during work hours and MSSP, which we combined, and we've reduced it to about 24 hours, mean time to detect.

Some of the valuable features, I find it's very easy for me to integrate new log source types within the SIEM. The MPEs, there's plenty out of the box solutions that we can integrate new appliances with. We're constantly buying and upgrading our appliances, so it makes it easy for me to ingest logs and run correlations in the AI Engines. 

Currently, we don't have full spectrum capabilities. We're using AI Engine mostly to run correlations, and then we obviously have our dashboards and stuff, but apart from that, we're working on the UEBA implementation for users to run more correlations. We do have our net monitors that we use to run packet monitors, packet captures, and even traces.

I think where I see room for improvement for LogRhythm is probably granularization of log source types. So, if that were to happen, I think it'd be a lot more better for the product. So, we are in the current five-year security maturity program.

I've never had any issues with my SIEM. We just upgraded from physical to virtual, and it was a seamless process. Everything worked well.

LogRhythm is very scalabe. We increased our MPEs from 2,500 to 10,000 right now, and we're very happy. We have room for plenty of growth. We're only using less than half of what we have.

Tech support's always been great. Every time I had an issue, I'd go in, open up a support ticket. I usually get an engineer calling me back within the first half an hour, and they'll help me troubleshoot within a day.

The product was already set up when I first jumped on with the organization. My only process is the movement from physical to virtual and then the upgradation to 7.3 and 7.4.

So, we are in the current five-year security maturity program. We're on year one, and LogRhythm is gonna be the center point for the first two years in terms of aggregating all the different log source types within the organization. We still find that there are log source types that are not coming in, which we plan to integrate within LogRhythm and use its analytics tools to help us get more mature and establish us forward in maturity of our security for the industry.

I rate LogRhythm 10. It's very easy to use. It's very user friendly. The product is very innovative with SmartResponse and AI Engine, so it takes half the work from myself and my analysts, so I love that product for that reason.

The primary use case for this solution is to monitor our environment and ensure that we are not having any breaches. In addition, this solution allows us to maintain compliance with HIPAA .

The SIEM and the CloudAI has improved our organization by helping us track down errors in our network. It has helped out our IT services team, and it's also helped out our database team in trying to track down errors inside of our network. It's also opened our eyes to a lot of the attacks that have been coming in to our network from outside threat actors. It's helped us stop a lot of those attacks as they're happening, and it's also helped us identify some policy violations inside of our network as well. 

I haven't used the playbooks yet, but from what I've learned here at RhythmWorld, I will be integrating the playbooks as part of our incident response policy.

The most valuable features for me are the customization features. I can build it out to do whatever I want. I've created rules in there for Crypto mining and Crypto jacking. 

The compliance aspect is phenomenal. The reporting in there is fantastic. It helps our internal audit team. It also helps us with our compliance, as well, for our audit. So it's a lot of good options in there.

CloudAI gives us analytics into our user's behavior and whether or not they are acting outside of their norms. It has helped me to identify a lot of policy violations inside of our networks. A lot of bad habits. Just for a specific use case, I've identified where an account that should have been disabled was being used by another user inside of our network. A lot of policy violations. A lot of geographical location identification inside of the networks.

CloudAI-UEBA has enhanced my security operations because I've been able to track down users with anonymous behavior. To be more specific about that, I've been able to track down users that were using accounts that they shouldn't have. So for example, we had a user that left the company and another user was using that account to access servers inside of our network that they didn't have access to. So it's very powerful. It just takes some learning to get used to.

I have over 3,300 log sources. The support for log sources is pretty good, unless you want to go to the cloud where I've had some rough spots with that. I had a hard time integrating with Office 365 because my antivirus wasn't supported. I had to get some custom parsers in order to get that integrated.

I would say that better API support for cloud log sources would be a definite improvement. 

Ease and setup would be a major improvement because it took over a week to get it all up and running, and that didn't even count tweaking it and getting it all set up for my environment. There's some room for growth there.

The stability is decent. During the day it works just fine. We do a lot of reporting at night and it hits the system pretty hard, but other than that, everything works perfectly. During the day, searching is perfect. It runs perfectly. The stability is fine except for those heavy hours.

Stability for CloudAI has been great. I haven't seen any issues with it dropping. I haven't had any issues with that at all.

The scalability for the most part is OK. The product has some hard stop limits on what your processor can handle.  I have an XM appliance, which means it's an all in one.

I have some hard limits on how far I can go with the processing rate. So if I go above that I'll have to spec out a whole new system and then renew my license. I don't see that happening anytime soon in my environment.

I have used tech support a few times when getting things set up. For the most part, they are pretty quick to get back to you and very helpful. They've also showed me a lot of tips and tricks to make things either run better or to get better results for my SIEM. The customer support is fantastic.

I knew that we needed a SIEM solution because we had no visibility

We didn't have any SIEM monitoring tools up until I showed up at the company. We didn't have any visibility into what was going on on our networks or on our systems. So that was one of the first steps that I took when I came on with the company.

My shortlist was Rapid7 InsightIDR, LogRhythm, and Splunk

I had a live demo of InsightIDR running in my environment and I liked LogRhythm a whole lot more, a whole lot better than their solution.

On average, I process around 1200 messages per second.

So measurable results for mean time to detect and mean time to respond. I don't have measurable results because there wasn't anything there beforehand. But now, we've responded within hours to events that could have been breach incidents, or in some cases within minutes and stopping attacks in their tracks.

My security program's maturity is still in its infancy. I'm basically starting it from scratch. LogRhythm has been a major step with giving me file integrity monitoring, the SIEM capabilities, log collection, a lot of things that we didn't have before. User behavior has been amazing for helping me keep track of what's going on in my network. So it's been a major stepping stone. It's the first in many.

I would rate LogRhythm as an eight out of ten because of the compliance factor. The modules for compliance are fantastic. The UEBA and CloudAI are solid for user behavior, and the SIEM itself is very powerful. I work very heavily in the customization aspect of it. Writing my own alarms, my own rules to try and track down events and alarms, stuff going on inside of my network. My only complaint really is just the lack of API support and how much work it takes to bring in cloud. That definitely needs some work. And just the time to set up is very time-intensive.

If I had a friend or a colleague that was looking to implement a SIEM, I would definitely recommend LogRhythm, and I would pretty much give them the same answers that I gave here where cloud support is still growing, but the tools that it has are very powerful. The behavior analytics are fantastic. It definitely would have to be on their list at least to look at.

The primary use case is to monitor for compliance and the behavioral analytics of our users, tracking for potential threats to the company's infrastructure.

We are using both products. We are using NetMon integrated with the LogRhythm platform.

It has centralized monitoring for our security operations. Therefore, it improves our analysts' work. 

Our security program's maturity has been transformational for my staff. First from an educational standpoint, all the staff has started to go through either admin or analyst tracks and education. This definitely organizes my security operations to the point that it makes it easy for me to do security operations. It facilitates it throughout the organization.

Out-of-the-box, it already has a knowledge base solution. Therefore, if you do a little bit of work, such as configure the lists and log sources, you can have use cases implemented quickly.

Their current roadmap is what I want to see implemented. I want to be able to upgrade to 7.4 and have the playbooks implemented as fast as possible. 

Stability has probably been one area where Health Checks have not been great with the product. We have been told that they are going to improve Health Checks on product, though we do struggle with them on a daily basis.

Scalability misses the mark sometimes, especially when you have an integrated disaster recovery built into the solution. 

LogRhythm is looking at elasticity and trying to make the product more scalable.

We use the tech support on a daily basis. They are very easy to reach. There is always a person whom you can talk to and is focused on my issue at hand. They really pay attention to me, and that's worth it in my book.

I maintain the solution. Right now, I have two dedicated engineers and two analysts. However, we need more staff and are looking to hire more because we want to grow this solution to suit our needs.

It improves our mean time to be able to respond and remediate issues that we come across.

There is a different reason why you pick LogRhythm over its competitors. It is a security SIEM, where others are SIEMs but not focused on just security.

The capabilities of playbooks is in 7.4, which we are not able to utilize yet. Therefore, we have built outside of the solution playbooks. However, we are looking forward to the integration of playbooks in 7.4, or even version 8. 

We were shown today a couple of things where playbooks will be enhanced, even having SMARTResponse coming right out of the playbooks, so hopefully advanced SOAR capabilities.

We run two independent LogRhythms. On one, we have about 33,000 different log sources, which include endpoints and now IoT devices. On the other, we have a very small footprint. It somewhere around 3000 log sources.

On one of my LogRhythms, I have a message per second around 2400 to 2500. That spikes depending on the time of day. Sometimes, it goes up to 17,000. On average, it comes back down to about 2300. On the other LogRhythm, there are very few messages per second. It is around 600. 

Do your homework first. See what pie in the sky solution is supposed to be for your SIEM. Do not just check a box. LogRhythm will more than likely suit your needs.

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 primary use case is compliance requirements. 

It is performing at the moment, but we are still in the process of implementing it.

We haven't fully integrated it or stood up the platform, so the benefits are realized yet.

The most valuable features would be the automation, reporting, and the support.

I do plan to use the full extent of the correlation and AI Engine to streamline our processes.

My big thing is the easability. I don't like to go to two different systems. The fat client that you have to install to configure it, then the web console which is just for reporting and analysis. These features need to collapse, and it needs to be in a single solution. Going through the web solution in the future is the way to do it, because right now, it is a bit cumbersome. 

If I remember correctly, there are some compatibility issues with different browsers. The user system work only on Chrome. In order to use something like this solution, we would have to have that extra browser. It would be nice if LogRhythm had a full support compatibility across all browsers, regardless of what platform they're using and whether they are on desktop or mobile devices.

I'm a little on the fence about stability, because the platform runs on Windows at the moment. There has been some finicky administration stuff, especially if we are going to try to integrate it with our own domain's policies which need to be correctly reflected. In the instance that we have, it is not necessarily a good idea to have an endpoint security, but when you have to meet compliance and follow rules, these are some of the exceptions. There needs to be a way to allow organizations to utilize these platforms and still be in compliant.

I don't what the demand is. I know the number of systems that we have. We try to forecast the demand ahead of time by coming up and listing the services that we need in the environment, but there are still things which are probably still yet to be seen.

As we run into systems which we were not aware of and need custom integration, I don't know what the pain points will look like or if things will be overlooked: Is the system scalable enough to where it will allow me to continue to log certain things without any restrictions? I don't know at this time, and I will find out once it happens.

So far, the technical support has been good.

I was hired in because I have the skill set to implement it. The original acquisition of the product was done by other people. Now, they have somebody who has the skill set and understands the technology deploying and configuring it, then going forward maintaining it.

For the development and maintenance, it will be just me. However, for the day-to-day log analysis, there will be a second person providing that function.

While we are aware of the playbooks, we still need to look into them.

We are close to a gig of messages a second, so quite a bit of data.

To capture your use cases, understand exactly what you are looking at ingesting. Do the research as far as what the company has done. For example:

• What have they provided at organizations of similar size?
• At peer organizations, how have they implemented the solution and what are some of their pain points?

Understand what everybody else has done previously with the solution.

I'm an admin and analyst, so use cases cover a lot of log sources for applications, mostly.

Being able to see when one of our assets is down and being able to restart it really quickly has been a definite benefit. It has been really helpful in the general maintenance of our whole environment.

We're able to look at our environment and see how it's being affected, according to the log sources. We can immediately see how the system responds to things that our development team does.

The Web Console is my favorite. It enables me, at a glance, to see the health of the environments. That is really important to me and to us.

I would like to see more widgets. I just love the widgets on the Web Console, I love to play with them, so more would be better.

The stability has been great since the upgrade.

We just upgraded to 7.35 and, although I wasn't involved in that, it seems like since then everything has been working really well. It scaled really well and we are taking in new network monitors. That has been really easy.

We usually do end up having to remind technical support about our issues, get back in touch with them to see what the status is on our tickets. That has been frustrating in the past, but they do find solutions. Sometimes it takes a while. And sometimes that communication gets lost. Some of our tickets had to be escalated to engineers. They get a little bit lost, at times, when that happens to a ticket.

Overall, I would rate tech support at three out of five.

I would definitely recommend LogRhythm. Work with the LogRhythm team to help learn how your environment works. Use as much help as LogRhythm can provide in your initial setup, so you can understand your environment best.

We have more than 20 log sources. We average around 3,000 messages per second. We have hit 8,000 in the past, but not since the new upgrade in which we got more room. In terms of staff for deployment and maintenance, there are just two of us who share it. But when we're on-call, all of us use it. There are nine of us who use it every day when on-call.

I rate the solution at seven out of ten. I'm very happy with it. I love how powerful it is. However, the customer service is where the points come off. I know they're working on it.

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

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

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

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

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

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

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

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

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

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

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

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

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