LogRhythm SIEM Reviews

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

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

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

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

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

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

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

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

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

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

More than five years.

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

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

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

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

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

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

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

My advice:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Customer Service:

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

Technical Support:

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

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

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

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

Definitely do a PoC.

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

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

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

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

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

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

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

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

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

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

I have been using the solution for one year.

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

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

I used QRadar before. I prefer QRadar over LogRhythm.

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

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

In my company, we use LogRhythm SIEM for integrations. We use the product for SOC use cases. If we have SOC implementations, LogRhythm is the SIEM solution we use since it can also offer a SOAR solution.

The most valuable features of the solution are network monitoring, user behavior analytics, and log collection. Our company uses almost all the features offered by the solution.

The console installation is an area with a shortcoming in the solution that needs improvement. If LogRhythm SIEM can offer a web console, it would be great. Since the product does not offer a web console, my company must rely heavily on the client console. There need to be some improvements in design. I want LogRhythm SIEM to be more user-friendly.

The File integrity monitoring (FIM) features offered by LogRhythm are great, but it is not competitive with the other solution offering the same feature.

I have experience with LogRhythm SIEM for two years. My company is a reseller of cybersecurity solutions. I use the solution's latest version.

It is a pretty stable solution. Stability-wise, I rate the solution an eight out of ten.

It is a very scalable solution. Scalability-wise, I rate the solution a nine out of ten.

My company caters to three customers who use the solution. Mostly our customers are enterprise-sized businesses with a few hundred or thousands of people.

I rate the technical support as an eight out of ten.

Positive

The initial setup was easy. I rate the setup phase an eight on a scale of one to ten, where one is difficult, and ten is easy.

The solution is deployed on-premises.

For deployments, it can take about two to three weeks. It could take more time when it comes to tuning or fine tuning needed in the solution, and it is not the case for LogRhythm alone but the same for all SIEM solutions. The deployments and the initial configuration can take around a month.

There are two aspects when it comes to the steps involved in the deployment phase, which are organizational and technical. Our company starts the deployment with the organizational aspects first, where we have to understand the company's context, to understand the company's use cases, and where we have to implement. Then, we start with the technical stuff, like installing solutions and configuring the use cases we have already discussed with the customers.

On a scale of one to ten, where one is low, and ten is high, I rate the pricing between six and seven. Price-wise, it is not a solution for small businesses. My company works in the African market, and in African markets, LogRhythm SIEM could be very expensive for small enterprises. There are annual charges to be paid for using LogRhythm SIEM. There are no extra charges in addition to the licensing costs of the solution.

To those planning to use the solution, I suggest they get trained before starting the use and deployment of the solution.

I rate the overall solution a nine out of ten.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Once you get stuff up tuned, it just runs.

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

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

Check it out.

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

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

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

We have about 1800 log sources. 

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

I'm a user, administrator, and analyst. We are using version 7.4.

The solution is deployed on-premise. Three people are working with this product in our company.

Currently, we are in the implementation phase. LogRhythm is better than QRadar from the point of view of collecting Windows events. It has a much higher view. You can enable monitoring by default.

Sometimes the Platform Manager crashes because it's built around Windows.

Every component is on a separate device. Right now we are just integrating log sources. We didn't do any threat intel or use cases until now. I did this with another customer, but with QRadar.

They have to think like IBM. IBM did X-Force public cloud, which is a beautiful tool that gives us threat intel feeds. LogRhythm doesn't have this solution, but maybe they want to integrate this. The Client Console is very bad.

The console is for administrators to add log sources or do some basic investigation. It is a very bad GUI. I think it's very old and built upon an old OS. They have to get rid of it or use a web-based application or develop it in the Client Console application.

I have been using LogRhythm for one year.

It's very scalable. We can scale up or have vertical or horizontal. If you want to add more indexers or connectors, it's easy to implement.

We haven't opened any cases until now. I used to work with QRadar, and sometimes it takes very long to receive a reply from IBM. We didn't experience any use cases until now, but with LogRhythm, we have some delays from the implementation view.

LogRhythm is expanding in my country, Egypt. Multiple customers have moved to LogRhythm. So, they don't have many people for support. We have to schedule a session, and then in implementation engage with engineers.

Initial setup was complex.

We have multiple data indexers, and each component is on a separate device. I think QRadar has many tools from the point of view of applications integrated within the SIEM solution, like threat intel or use case manager. In LogRhythm, I don't see this.

Maybe we haven't gotten so far in the implementation, but in QRadar I can feel it's easier from the initial setup. We have only these components placed on one site. We don't have another recovery site.

I didn't see the RFP, but I heard that it is more expensive than QRadar. I remember one customer implemented only one QRadar in two sites. It cost them $2 million, I think. Maybe LogRhythm is much higher.

QRadar is built around Red Hat, so it's more stable. I think LogRhythm is more complicated than QRadar.

I would rate this solution 7 out of 10.

When you integrate a log source by default, you have to know what the customer needs or the process that is wanted, because we did the reconfiguration multiple times for log sources.

So, they have to also follow the MITRE ATT&CK Framework, because by default LogRhythm collects the common logs, so you have to enable this.

To estimate it in the licensing sizing exercise, it must be done correctly. Sometimes I see customers sizing away from the current situation. Customers sometimes buy a license that is not enough for their implementation, because they didn't expect what they would be adding in the future during the implementation.

Sometimes the implementation takes one year, and the customer adds more devices, so it exceeds their license. I think it's the presales' job to do the sizing correctly. And the customer must be aware of how or what to implement during, so that implementation doesn't take long.

It took some customers two years to implement a SIEM solution. I don't remember the solution, but it was a waste of two years' time.

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.