One of the challenges of the SIEM for the LogRhythm 7 platform is the amount of time it takes to bring new log sources into the MDI. We've waited a couple of years on some sources before they were incorporated. Writing our own custom MDIs is very challenging because it requires expert-level regex in order to write those rules and to make them efficient. Bringing in sources that aren't natively understood is where we've struggled the most.

When we originally got LogRhythm, their tech support was fantastic, and I loved them. Now, we don't quite get as quick of a response. I've been disappointed in the more recent tech support. When you call in, they'll say that they will get you somebody, and you'll finally get someone who will contact you back a day or so later. Whereas before, I would get help right away.

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.

There used to be the ability to create alarms based on message text that was included in LR Version 6.x that has been removed in LogRhythm 7.x, and on that, I would like to see it added back. I was told that this was due to processor overhead but with the amount of CPU and memory suggested, I don't see why this would be an issue.

I would like to suggest that they should improve their usage of third party tools for making dashboards and reports. If they would create their own tools for dashboard and report, it would be much better in terms of security purposes.

It's not easy for someone new to the solution. There are some complexities involved with the initial onboarding. It needs to have more user-friendly dashboards and onboarding processes. 

It is a premium solution which means it is quite expensive. 

The cloud version must be scaled better. The EPS values shown are sometimes not reflective of how we see them. Log ingestion takes a couple of days. When we have errors, the turnaround time is two to three days. It should be organized for better turnaround time. The cloud infrastructure is taken care of by the cloud team. The responses provided by the cloud team are inefficient. The response time must be improved.

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

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

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

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

The biggest complaint I have is about their support. There is no free instructional advice available on their website. An example is with their field names inside log messages, where they have one named "Common event". That is something that LogRhythm has created, and you can't figure out what it means unless you pay a large sum of money for LogRhythm training. Compare this to Splunk, where I can go to their website and download twenty articles on field names right now. There is no documentation that we can afford to buy for this product, so we just have to wing it.

Their product has issues when it comes to hard drive management. Again, their support is not one hundred percent. We are using their hardware, and one time the product just spontaneously stopped collecting logs for about a month and nobody knew it. We called them, and it took a week or two of troubleshooting before they found the issue. To make it worse, the issue was not a misconfiguration. Rather, it was related to how they were storing temporary logs on the hard drive. The drive was shutting down and the logs were not being accepted. It took them weeks to figure this out and it shouldn't have happened in the first place, which suggests a bad design.

It is a product that is very hard to use. You have to set a wide variety of parameters before you can even start to search. The highly structured nature of it does provide some guidance, but with a lack of documentation for things like field names, I don't know what I'm looking for. 

We don't get much use out of this product because people around here consider it to be unreliable, and it's hard to do searches. The main reason for it being here is that there are audit requirements for collecting logs and maintaining them. We have been able to solve problems with it, but searching is kind of clunky.

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

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

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

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.

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.

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.

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.

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.

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

Only area I can think of to improve on is the proof reading and using the guides before releasing them. Out the the 20+ guides I used one had issues with wrong information in it.

Better integration with different services is needed, as there are quite a few platforms that we use that don't integrate very smoothly with LogRhythm. We would like to plug in an API key for another system and have that vendor's information readily available. 

We use Windows Event Forwarding to collect the logs from our Windows clients, and the logs get aggregated as one data source on that collector. Therefore, finding logs specific to one particular Windows system requires some creativity in how we search the SIEM. 

I've heard that in a future release, it may come to a point where the Windows systems would be dedicated log sources, so you can choose just that log source. That would greatly improve our ability to threat hunt with our SIEM.

The biggest one in my mind that I want to implement is some of the AD controls. Reacting to a threat where an account password needs to be changed, or an account should be disabled, to react to that threat. Moving into first a phase where an analyst is gonna see that, review that action and then once we get comfortable, make that an automated action.

The big two big areas for improvement is TTL. Making sure that the data that we're collecting is available for a longer amount of time. So I know with some of the new releases coming in LogRhythm, that's gonna be improved which I'm really excited about. The other one that's kind of getting back to the fundamentals of why LogRhythm was chosen as a solution, being able to take your machine data, understand it, index it, classify it and give you that visibility.

I'd like to see them focus on that because there's so many different security tools being spun up these days that being able to keep up with that and having more partnerships with security vendors to make sure that security tools have new releases in their environment, they're able to keep up with those logging changes.

I would like to see APIs well-documented and public facing, so we can get to them all.

The biggest thing is when you are looking at the client console:A lot of the data, the reports that you can generate, then you are given just a pie chart, a list of data, or both. I would really love to be able to take some of that and not have to export it to a CSV file, so I can pull it into Excel to turn it into some other kind of graph. I know some of that's being handed off to the web console, but that would be the one thing that would be really helpful.

It is a little hard to get integrated.

The one thing that would help me the most, because I am sort of isolated from things, and the guides that LogRhythm puts out are really good. However, a lot of times, it is, "Do this, do this, and this works because of this, this works because you do this." I would love to see something where they show or explain why doing something would break something or wouldn't work for you. That is the one thing, because I have done some things, like created a GLPR, just done them a couple of times, and I had two of work really well, and one that seems like it should be perfect, it is just a simple exclusion, but it does not work at all.

I would like to see additional features around alarm management. We are producing alarms right now, and we are able to change statuses on them. But, I would like to see more details around having timers on those alarms. So, if I have a new alarm that has been sitting there for 15 minutes and no one has gotten to it, I would want some sort of alert to tell me that or a threshold I can set.

The log storage capacity should be increased.

It should be improved for automated setup and auto-configuration. There should be ease of integration and ease of setup.

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

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

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

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

Maybe it's just my lack of understanding of it, but I would like to see the web UI expanded further.

I would also like to see - and there might be some documentation around it - building your own smart response plug-ins.

I think those would be pretty nice.

One area for improvement in LogRhythm NextGen SIEM is that it's a Windows-based tool, and I feel it should be on the Linux operating system instead.

Another area for improvement in the tool is the UI. There should be minor changes in the UI to make it better, though I like the dashboards in LogRhythm NextGen SIEM.

There aren't really any missing features. It's quite a complete solution.

Most of the clients using the on-prem are using customized applications. In the customized applications, we are facing parsing issues and a minimum of two days is required by the LogRhythm team for parsing logs. 

Parsing is totally controlled by LogRhythm and they do not allow any partner or any third-party to handle this part and this is a key challenge on my end. This is a huge cost impact -at least on the Pakistani market. It needs to be addressed.

The solution should be less expensive.

It would be very helpful if there was Kashif a package to help users migrate from QRadar to LogRhythm.

In Pakistan, the government is in the process of developing its final recommendation of cybersecurity and data protection process. We hope this solution will prove to be compliant and will meet the requirements in the future.

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

The built-in functionality of the solution for NDR, SOAR, SIEM, and EDS has room for improvement.

The price of the solution has room for improvement.

The web and on-premise console interface should be the same instead of having a separate engine for each. 

I hope that they remove the console and have only one GUI. There should be one engine for both the web and the console. They shouldn't have two different engines for each one of them.

There should be easier deployment status, and like Splunk, there should be a more professional way to write the search. There shouldn't be only a drop-down menu. It'll be a good thing to add.

We'd like to receive alerts for zero-day attacks in the future. We'd like alerts that offer us better security. For example, if there are abnormal occurrences, we'd like to know right away. 

We've had issues with scaling and local support.

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

Hearing the roadmap items, it's pretty good. I especially like the fact that the playbook is coming with the ability to integrate the smart responses into the playbooks. That way, we can not only have the playbooks, take those steps, but start to automate those steps as well. I think that is really powerful.

We played around with the CloudAI portion during the beta. We're not currently using it. But I think more in that area is going to be really important, where we can look at machine-based patterns, as opposed to just, "I saw two of these and three of these things, so set an alarm." I'm really excited about that.

Functionality, ease of use.

There are a few "gotchas" in the applications. One of the issues that we're having right now is on the AI Engine, when you do the drill-down. There are no events that are being populated for the drill-down. The recent upgrade and release fixed some of that.

And some of the other parsing rules. Parsing isn't done correctly.

The user interface needs improvement. The more the user can slide around and know what's going on, the better it will be.

More features that I would like to see more development in are the automation and the smart response. A lot of the attendees here at the LogRhythm User conference are working towards that, and most of us are not even developers. But we're trying to figure what are the skill sets and how do we make sure that LogRhythm gets more intuitive in automating and responding to alarms and notifications that we get.

CloudAI is amazing from what I've heard about it so far, and I'm looking forward to it.

There is always room for improvement. Everybody continues to integrate. They've been a great company to work with so far. I'm one of those who is optimistic, there's always room for improvements.

For me right now, I have not used it long enough to give an evaluation of what the product is lacking. As far as room for improvement, I would like to see the solution be a more hardened operating system other than Windows. I’d prefer that they didn’t use the Microsoft Windows platform. I think that they lose a lot of efficiency and performance that way.

We are still implementing and have not yet completed the LogRhythm implementation for one particular customer. We haven't faced any issues right now. Once we've completed and we are doing the log analysis and the correlation and audits, at that point in time, if we find challenges, I can update you. Right now, it's okay.

Let us see once we finish the website we are working on. Then we'll understand better more of what we need. We'll probably need an improved user experience in terms of reporting and analytics. If the reports are very easy to configure and generate what we require, that will be the best thing. At the end of the day, it is just logging, correlating and reporting.

I really can't think of a particular one, I've been very satisfied with what's happening. 

I know they're going to get another spike in customer base, hopefully they'll have the ability to ramp up people in support along with the customer ramp up. That's a hard game to play.

I've been part of a number of beta tests, so when CloudAI came out - which is phenomenal: The ability for something to give you information in a SIEM environment, you're often gathering data, writing rules to monitor the data, so you can see what you think you should see. But they're doing inference engine work, where they're looking at what a threat implies, and then presenting it to you.

In our field, false positives versus true positives are a big deal, but they've kind of taken it a step forward. I've come to call it - they may offer me information that I look at, that I didn't know about but I should know about - it's not a false positive because it didn't show a threat. It's a true insight because it showed me something that I wouldn't ever infer myself. 

So features like that, the work that they're doing moving forward in that space, especially with machine learning. The sky's the limit in that, I'm looking forward to them doing it. 

Probably the biggest improvement and I've talked to several of the management here at the LogRhythm User conference on it, is their thin piece, which is their file integrity monitor, that we use on some of our security servers. The data sets are extremely large, tons of files are being modified, deleted, created. That product could use some more enhancing.

We've been working with them to enhance that product for future releases. It's been a good experience. 

Any issues that we've had, they've actually fixed the majority of the issues that we had with the initial product, by even giving us customized installation packages to adapt to our environment.

It's not necessarily bad against LogRhythm, but I think an area that always can be improved is the parsing rules. The more information that we can get out of the logs, as far as specific metadata in the logs, whether it's an IP address, or something like that. Sometimes, LogRhythm will parse the rule but perhaps it won't get every little detail out of the rule.

Any advancement in those, could be very helpful to be able to correlate those logs against other items. Especially for items that are a little less - "mainstream" may not be the right word - that are not necessarily a top-tier vendor. Perhaps, instead of Cisco, it's a different firewall vendor. Those sorts of things, that sometimes we run into an issue where the log parsing is suboptimal. It could be a little bit better, could be some improvements there.

Our key challenge is working with disparate IT groups. We are a brand new security team within our organization. It's a pretty small company. They have grown their infrastructure by acquisitions, so they have a lot of separate naming conventions at each location, different staff, different log sources, and firewalls, which are different at each location.

It is has been a challenge. This has been one of the first applications that we've had. This and a couple others that security teams brought in recently that works across the enterprise. So, we've had a lot of challenges just getting AD or DNS to work, real basic stuff.

Then, also the log sources for the servers, we didn't have a lot of the logging enabled, so we had to kind of go back and then we had to enable a lot of logs using GPOs, working with our IT, and actually doing a lot of the work ourselves, because challenges are resources. There is so much work to do and not enough staff.

I did see a lot of the web console features coming up. I think those dead on, exactly what's needed. A lot of them had to do with better case management and more sorting, going through your alarms, and drilling down in different ways. I think that is really important.

In terms of improvements, I would probably look for more things to go into the web console that is currently on the fat client. I think that is the trend. I think that is what LogRhythm is doing. I find myself going back and forth between the web console and the client console and I probably spend more time in the thick client and it'd be nice to just be in one.

LogRhythm is really on track and they're doing a lot of things very well. In some other areas, particularly with the UI, how things are done administration-wise and a little bit on LogRhythm University, some improvements are needed. There are some challenges with registering for classes and taking them.

I was not completely satisfied. I wasn't really sure what classes to take. I did not feel like I had the direction initially to understand how to deploy LogRhythm. When you get LogRhythm out-of-the-box, there are so many knobs to turn and so many things to configure and set up, that it's almost impossible to do it on your own, as an enterprise senior engineer. I have a lot of experience with a lot of advanced tools and I find LogRhythm very challenging. I do not think we really could have gotten where we are without Optiv coming out for a week and spending time setting up the appliance and optimizing it the way it should.

There are some improvements that could be made to make it easier to use.

What I would like to see is improvement on the analytics, especially on the cloud and intelligence workspace.

The customer support system is time-consuming and needs to be improved because it is not very good. For other solutions, you can deliver whenever you have a customer problem. All you need to do is open a ticket, log into the system, and the issue is resolved. However, for LogRhytm, we have to flag the problem and then send the log, and we never know if we will receive a response in one hour or one week.

In addition, LogRhythm NextGen SIEM has one of the best analysis features, but it can still be improved. However, I believe they plan to make improvements since they're only selling the product for two systems currently.

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 would like it to do a lot of the automation (which I still need to learn more about), because I am essentially a one man shop doing all the jobs. I'd like for it to be able to do more for me, so I can focus my attention on my other job responsibilities, because there are a lot of them.

The Web Dashboard UI: Maybe it can improve more to indicate some of what Splunk is doing, because I also compare with other SIEM products. Maybe LogRhythm can have some sort of dashboard similar to what Splunk is giving to their customers.

The product is good, but maybe they can further improve what they are doing in the roadmap, such as cloud AI and some of the web dashboard enhancements.

Just integration into our ticketing system, which we're using service now. Just being able to integrate LogRhythm with that so we can track incidents.

Continued support to help us understand the solution better.

The product's stability needs improvement.

LogRhythm NextGen SIEM could improve by adding more applications for the banking sector. There are not any custom applications at this time.

For me it would be the efficiency and signing up and standing up systems, as well as a little bit cleaner on case management. That can be a little bit complicated to go through and actually be able to analyze it and compile the information that I have. At least that's what I've found so far. Those would be the two biggest things.

For me, room for improvement is the upgrade process. Whenever we have to do an upgrade to the next version, we're a little nervous and apprehensive about that.

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.

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.

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

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

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

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

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

I would like to have threat indexing and a cloud version.

The reporting could be improved. 

There are other security technologies outside of this SIEM that should be inside of this SIEM. I can see in their roadmap that they're trying to address a lot of these things, and have these technologies built into the solution, because there is no point in going to another vendor or opening up a second window to obtain the data that you need.

I think the dashboard could definitely have more features. I've seen some of their roadmaps that they're going towards. I really like it.

One of the features that I actually put in a request for was, they have the ability to build this great case and have it all ready. But you can't export it, right now on my specific 7.2 product, you can't export it from there. So, I can't have a nice PDF to give to a CEO, or give to legal, or wherever it needs to go to further their investigation. That's definitely a product that their actually going to come out really soon with.

Global management for registry integrity monitoring. Right now you have to apply what they call RIM policies, Registry Integrity Monitoring policies, one agent at a time. If you have thousands of endpoint agents, you have to touch each one of those one at a time. That is a pain in the rear, so I would really like to see some type of group or global management for RIM policies, like they have already for FIM, the File Integrity Monitoring. You can grab hundreds of agents at one time, and apply them across the board. I don't know why you can't do that with the registry piece.

I do think there is room for improvement because the system is still running on the Windows Server platform. The problem with running on Windows is that it is not that good for scaling and providing for big deployment environments.

With that said, I think it's good enough. For the most part, I just want to have a consolidated platform for the NDR, i.e. the new MistNet NDR that they have acquired, with the current XDR. At this time, it is still two separate controls.

Their ticketing system for managing cases can be improved. They can either do that or adopt some of the open-source ticket systems into theirs. The current system works and gets the job done, but it is very bare-bones and basic. There are some things that could be improved there. 

They should also bring in more threat intelligence into the product and also probably start to look into the integration of more cloud or SAS products for ingesting logs. They're doing the work, but with the explosion of COVID, a lot of businesses have started to move towards more cloud applications or SAS applications. There is a whole diverse suite of SAS products out there, which is a challenge for them and I get it. They seem to be focusing on the big ones, but it'll be nice to be able to, for example, pull in Microsoft logs from Office 365. They are working towards a better way of doing that, and they have a product in the pipeline to pull logs in from other SAS applications.

The biggest thing for them is going to be moving away from a Windows Server infrastructure into a straight-up Linux, which is more stable in my eyes. For the backend, they can maybe move into more of an up-to-date Elastic search engine and use less of Microsoft products.

I would like to see more integration with more products that are out there within the same security field.

There has to be some improvement with SecondLook Wizard. It's one of the functionalities on LogRhythm where you can restore inactive logs. For instance, it's a forensic analysis point of view if something happened around a year ago that you have to look into. I wish there was a smoother, more seamless feature.

I think condensing and consolidating what a user accesses over and over again and just having CloudAI understand that that's all of the user's, and you can consider it as one thing rather than multiple things, and alarming on it, and alerting me on it, having me have a mini heart attack every time it tells me that this user is authenticating from a new place.

I would say the thing that I'd like to see the LogRhythm do a better job of is staying ahead of the curve as it relates to like things like cloud. It seems like from that standpoint that maybe the cloud stuff was a little bit of an afterthought or wasn't done kind of as people started to move to cloud quicker. It's one of those things of where we kind of are doing it now, but it seems like some of the cloud connections are still buying, kind of being created as we go. So I think that's one area I think they could improve in.

In terms of the product, what really needs to improve are the metrics that you can get from it. We're all about mean time to detection, mean time to response, pulling those metrics out so I can put them into my KPI packs to present to the board. Everyone in a CISO role is having the same challenge. We've got multiple spreadsheets. Being able to leverage the SIEM to give us the information would be invaluable.

The other area is Office 365. We're cloud-first as far as our enterprise goes, and what we lack at the moment is being able to pull that information into the SIEM. I understand that that's coming, so we're looking forward to that.

I would like to see case management become more independent from LogRhythm itself. Right now, it is very oriented to LogRhythm based events, but not manual events, such as user reported things and incidents where we might have large volumes of data that we have to store as part of the case. It works real well as a workflow device, but not real well for overall case management for an organization.

The reporting engine is poor in comparison to other areas. It should be moved to the web interface to improve its functionality and usability.

Adding an entity (should be able to create a template and/or eliminate locations) could be much faster/streamlined. The wizard could be improved to specify OU/Groups to search for new entities.

The coordination and load bussing has room for improvement. 

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

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

LogRhythm NextGen SIEM is currently based only on the Windows platform. This means that some of our customers have to purchase a Windows license elsewhere. If LogRhythm can move to a Linux platform or a proprietary platform, it would be very helpful.

The biggest thing that I think needs improvement is reporting in the Web Console. Most of our reporting is done in the thick client console. The only people that have access to that, really, are the people that work for me, the administrators of the system. So the end-users, the people whose logs we consume, we give them views to their logs but they aren't able to run reports. By moving reporting to the Web Console, that would enable all of the regular, non-administrative users to run reports as well.

What I'm looking for was actually in a session, here at the LogRhythm User conference, about the PIE phishing analytics. That was real interesting because right now we've got a guy that walks through that process attempting to see if the email came in, who got it, and whether or not it was exploited. That's all manual at this point. 

I think they're limited now with this to Office 365. We've got on-prem Exchange and it would be interesting to act like they're going to evolve that into that, to have that ability to look at that information a lot quicker.

It’s very easy to overwhelm the system. I have some of the beefiest data that they provide, and I can still overrun the system.

The native ability to identify the correct time of logs and data also needs work, e.g. if I bring in a system log data stream, LogRhythm's ability to natively say it's a Cisco firewall or a Palo Alto firewall -- sometimes it struggles to identify the device.

My installation has some unique problems, apparently, because of our network architecture, and that's why we're looking at other solutions, and possibly a replacement. 

We're looking at user-based analysis. Granted, we haven't enabled the UEBA module, but we're forwarding all our proxy logs to LogRhythm and we have a really hard time pulling those proxy logs back out of LogRhythm. However, when we take LogRhythm and forward the same logs into somebody else's user-based analytics software, we get the majority of what we were missing. So we know the logs are making it to LogRhythm, but we still can't pull them out. If we've got all our proxy logs and I go out to Google or Facebook or the like, we should be able to go in and pull that information out ten minutes later, but it's a big challenge to do that.

The biggest thing I want is, right now you have thick console and the web console. Most of the reporting has to be done in the thick console. I'd love more reporting in the web console. A lot of our users don't have access to the thick console, only administrators do, so a lot of users can't run their own reports.

The security playbook could be pre-defined and available to other analysts with similar security issues. Currently, playbooks are individually written for various actions and threats. 

It would be faster and easier to react to issues if pre-defined playbooks were accessible to all analysts. 

I think a must-have feature would be better reporting. Today, as you can imagine, the organization would like to see what is happening in our environment, and the reporting feature within LogRhythm, I would say, is very limited.

The reports do not provide information such as, who are your top ten end users generating the most activity within the environment, or appliances, per se, so that's very limited.

Report-building is in Crystal Reports and has a limitation. A non-editable template must be created, then the report is created against the template. OFI is this. The template needs a preview option, as well as an edit option.

The software needs to work on its pricing. 

LogRhythm's SOAR and NDR features don't stack up well against competitors. 
maybe integrating theme functionality as the other do. But in general, it's okay.

What I would suggest is for the product to make the consoles more user-friendly. The integration module should be simpler. That way, that the end-customer himself can do the integration and they are not always dependent on our site. The integration with other vendors should be easy.

The solution is likely not the best option for a smaller organization.

One of the features I like to recommend is a LogRhythm queuing ticket for a level-one tier system so that clients are not dependent on a third party.

• Move it to Linux. I would like to see it get off the SQL Server.
• I would like it to be containerized. 

We run across the odd vendor which we are using that we think are large players in their environment, but there is not necessarily a native support for their log ingestion per se, where it requires customization in order to be able to parse and accept their logs. I would also like to see them expand on some of the ability to interact with other technologies in real time via the programming platforms.

I work in a highly regulated industry. I know the product has compliance mechanisms, but being able to get more governance surrounding some of the compliance. Merging things that we have to be on top of would be helpful.

I can't think of any features they should add because we haven't used everything they've already released. They have Office 365 logs integration. They've got this new phishing engine that we haven't used. They've got dashboards we haven't used, so we're basically right at the very bottom, we need to start building with what they're already doing.

In terms of improvement, their community boards, where to go find things, as a customer. As they're growing and they're moving stuff around, and it would be nice if we knew exactly where to find what. They're constantly reinventing how they do things and where they put stuff, that's the one challenge I've run into. I've always found the answer when I got to the right person: "Yeah. That's over here now," but I know other customers have shared that same issue.

There are enough features that we are not using, and not to their fullest extent, at the moment.

Retrieving logs that have been archived can be a difficult and time consuming process. The module which performs this, called the Second Look Wizard is not very well integrated into the rest of the product. It would be nice if you had the ability to right click on a log and search the archives for more data like it (you can do this with non-archived logs) and then after restoring archived logs, easily pivot to an investigation for that data. Currently, those 3 steps all have to be run separately.

I would like to see our vulnerabilities counter. We will be using Tenable to fill that void right now.

What still needs improvement is automation. The SmartResponse obviously does not use open APIs at the moment, so we're having a lot of problems connecting it with things like Palo Alto Traps and some other systems, things like Cisco. I know that it's on the roadmap, but at the moment that is where the weakness lies.

For myself, I would like a HIPAA configuration out of the box where I can switch on various HIPAA rules. Obviously, HIPAA has 18 very exact identifiers and I'd like those to be already in the box ready to be switched on.

From what I saw yesterday here at the conference, they seem to be right on track with making the Web Console much easier, case management much easier.

When you're searching on something, you see something that you think may be a threat, you have to keep threat-hunting, deep diving, and from what I saw yesterday, it looks like it's going to get a lot easier and more helpful.

I would like to see support added for Exchange 2016, and Check Point OPSec Lea.

Adding the capability to identify and perform an auto import of new log sources (especially Windows-based systems), based on specified criteria, would be a useful feature. 

Enhancing the creation of report packages would also improve this solution.

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.

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.

There is, of course, always, improved automation. Because, as we are continually needing more and more people from an analyst perspective, the more we can automate, the fewer people we need. If we can automate some of the lower-level things, that can allow our SOC to be trained on the higher-level more technical things that really give the true value. I don't want my analyst to be stuck underneath sending emails, and "alert fatigue" is the buzz word. 

But, on top of that, there has been a market that has grown from SIEM for security orchestration, where it's another tool you have to bolt on top of SIEM to make SIEM as effective as it should be from day one.

I was in a session earlier today here at the LogRhythm User conference where they're mentioning that the web UI, and through the case management, they're actually getting an incident playbook that you can utilize. That's a big step that I'm intrigued by. Hopefully it goes the way that it's planned because that is one that saves me from having to go out and purchase a separate security orchestration tool, which is just another screen I need to look at.

That feature is one that I'm very excited about, and hopefully it follows the roadmap according to what LogRhythm is projecting. That's definitely a feature that I and my managers have identified as a need. I was excited to hear about that at this conference. 

That's probably the only feature request that would be of drastic improvement to our SOC.

I'm not really sure I can pinpoint any particular area that I see LogRhythm needing improvement in. 

I think they probably need to, because a lot of companies are having this cloud-first strategy, where anything that's new has to go into the cloud for some reason. So I think with CloudAI coming out, that's really good. But maybe having more of LogRhythm in the cloud. Educating people about how we get LogRhythm more into the Cloud.

Part of the care and feeding of LogRhythm is staying on top of what's coming out in LogRhythm. I know that their community site has been improved and that they're wanting people to be more involved with the community. But I think making people aware of parts of LogRhythm that are new is very important. 

It's hard to say what should be improved because we're still trying to get an understanding of what the tool does.

I think in all the sessions we have at the LogRhythm User Conference, we'll find out more what the tool does. Then, from there, we'll probably decide if we really wish it would do this or that.

• Better correlation of all events: We seem to get a lot of misinterpreted data coming from multiple sources. It would be nice to have an easier way to interpret the data and correlate it.
• The challenge of maintaining it: Maintaining compatibility with all of our log sources is still a challenge for us.

We have implemented it as a necessary feature, but we need to be able to mature that.

Easier creation of rules and parsing, and more user-friendly. A more user-friendly basis of using the tool to create rules and alarms to be able to report off of, and quickly stop any attacks and the like.

Also, more in-depth training on how the security platform works with other pieces of software like Sequel, firewalls, or PowerShell.

• The greater AI
• API support

Increased total costs of ownership (TCO): We have had to staff up our SOC. This has required analysts, which has required salary and staffing requirements.

In the next release, I would certainly like to see more HIPAA compliance. I would also like to see more integration with Palo Alto Networks, particularly their Traps, which is their endpoint solution.

In addition, I'd like to see more automation coming in. Whilst they have SmartResponse, it does not yet configure with OpenAPI support. That is something that I feel they need to look at in their next edition.

Better knowledge transfer during implementation.

We definitely thought it was complex when we initially set it up, but that is usually just a single pain problem. It could definitely be more straightforward.

This product is in general for medium-sized companies. For bigger companies with millions of logs coming in, it just cannot support them. The solution is not robust. It depends on the size of the companies and the size of the firewalls you have which will determine if it will work for you. Thus product is really good and easy to use for medium sized companies.

Definitely expansion on log parsing. There are some obscure log sources that we don't currently have parses for. We needed a new solution when our previous solution, the licensing expired on it. Hardware was out of life, as well as it wasn't scaling very well. Didn't provide a lot of the features that we needed.

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.

We still have a lot of noise, so this is a problem. We are having a hard time visually sifting through it. We need help dialing it in. We don't have the in-house expertise. Do we hire someone just for this purpose and have them sit there all day, every day doing that? It is almost at that point. We are looking at Optiv as solution right now.

It is so robust. There are so many moving pieces that you can't dabble in them. This is the problem that we are struggling with. You have to have somebody who works with it, and that is their job. Maybe a bigger company could have a whole team which could do this, but we don't have the capability right now.

I would like to see the client and the web client merged, so all the administrative functions are in the same web interface. It is just clunky right now. If you leave it running, it slows down your machine. However, we are still on version 7.3.

In the canned reports, I would like to see, rather than a blank report come out, for it to say something like, "No logs found," or "No log sources available." I don’t like blank reports.

My main thing I'd like to see is, when you're using canned reports, that they're not blank. If there's no log source say, "No log source", or if it didn't find anything say, "It didn't find anything". I hate blank reports.

I'd like to see a real-time dashboard of events. I know it's available, but it needs work. I haven't been able to put in the 20 or 30 hours that it would take to really become an expert with it. I rely on the PDF reports which guide my day, but having the information in real time in the dashboard would be nice.

To me, the best additional feature would be, much like you see with a firewall or with an antivirus scan or intrusion prevention, a real-time console for activity and almost sort of automatic updates for certain features. That would be helpful.

The reporting aspect is difficult to use and very difficult to get your own reports. So far this is it; they have a web UI and we had a recent update which fixed a lot of bugs and added a lot of great features. But the reporting is lackluster.

No current suggestions.

I see room for improvement in the log ingestion. Customizing a log source is very technical, probably more technical than it has to be.

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. 

One of the things I find that would be helpful is the GLPR information, to be able to understand what is actually being processed. I've got, say, 20 different rules, but I don't know which one is getting more of the data, which is getting none of the data, because there's not really a good interface for that.

I'm really excited about the CloudAI stuff. One thing I've asked, and I don't know if it's in the works or not, is for a better way to test our AI rules, to make sure they're working correctly, instead of having to manually go in to each one and doing an invalid login to see if the rule fires. Some better way to test all those rules that we have turned on and enabled would help.

The biggest thing that we need - in one of the presentations today here at the LogRhythm User conference they were talking about it - is automating your SOC and trying to get your systems to do as much as they can do without human intervention. Which is great. 

I provided feedback afterwards to say, "We need to be able to ingest all data. And we need to be able to parse all data." What that means is, my Checkpoints that I have today, which is my unified-threat management system, I'm only able to ingest firewall logs and events from the blade. I own all the other blades from Checkpoint: IPS, Threat Emulation, threat detection, Data Loss Prevention. All of those blades have data that I need to be able to feed down into LogRhythm. From there, we also need to be able to truly parse the data. I've had to have a couple of custom collectors built specifically for SQL Server-type events, for database analysis, to ensure that the data that's being brought in, the events are parsed, we can be actionable on that.

It's pretty effective. In some cases we have run into some issues: The way that the rules work, and the alarms trigger. We get a good number of false positives.

I wish that there were more instructional videos on how to do different things and more walk-throughs.

Also, easier generation of AIE rules, or custom ones.

I would like to be able to use the Web Console, but because of our volume I can't.

Also, it needs to stay healthy. A lot of the problems seem to pop up out of nowhere, and a lot of them seem to be somewhat debilitating. We were fine for a long time, and then eventually one day our processing just dropped. I ended up talking to support for something like a month, and eventually I got to someone who said, "You should check the BIOS settings on your data processors and your indexers." Turned out there was some read-head caching setting that wasn't enabled by Dell. We were fine for over a year, and then all of a sudden, problems.

It's a great tool, just random dragons seem to cause problems.

Sometimes our rules don't fire correctly, events don't get created correctly, but that's mostly just because we have to write custom regex.

Also, moving from away from the fat console, more into the web console for log sources and tuning and things like that, would be helpful.

At times It gets a little clunky, or resource-intensive, but it works.

There are a lot of pieces of it that are very complex and time consuming. If we can try somehow to just make it more simple, that would be better.

I would like to see more pre-integrated SmartResponses. Right now, I'm on 7.1.10, so I'm not even to the current version. If there were more pre-integrated SmartResponses, that would be really cool.

One of the features that we'd definitely like to see is the user inference, entity inference, where one entity would have a unique ID and then with that unique identity you could pull out the information or log associated with that. It helps a lot in the investigation, because currently what happens when we get an alert from LogRhythm it's just the tip of the iceberg. Then we need to do lot of investigation. But having this entity inference kind of tool would help us. We could tie all the logs with that unique entity, and we would be able to collect the information, I think it would be really cool to have something like that.

Also, with automation, like identifying new log sources and the environment, or automation of log sources that have not been reported from last month or a week. You can put up some kind of alerting system there so you can retire or look into it.

The reporting on the dashboard should be improved from a management perspective. It would be helpful if they adjusted the colors and the presentation to make things clearer and easier to read. 

I'm not a fan of the system's user interface.

For our market, the solution is quite expensive. It would be ideal if they could work on and improve their existing pricing plans to help make it more affordable in our country.

We'd like it if the solution could be more customizable in future releases.

I would definitely like to see more things in the Web Console, in terms of the ability to run reports and generate reports out of it, and schedule those. Instead of having to go to the FAT client, you would just do it out of the Web Console.

Right now there are two brains, there are the Web Console and the FAT console so that hinders a little bit of flexibility or innovation that they can do. It is a tough spot to be in, but otherwise it is a pretty good product.

We were having some challenges initially, especially ingesting those standard log sources. We ran into issues where it was not parsing correctly. That wasn't our expectation, because we considered them standard log sources, but there was some issue with parsing our logs.

As far as adding log sources, it is not as straightforward. At the same time, granting access we have noticed it's not using AD groups. It's more of the organizational unit in AD.

It will definitely help if the parsing side would be much easier, meaning it would be better if we could easily make adjustments on the parser, both on standard and non-standard log sources. The way it works right now, it looks like we have to engage LogRhythm in order for us to make adjustments on the parser.

Focus on open source, long sources like Linux and Docker, and those kind of things. More help and assistance with some of the open source products, everything seems to be focused on Windows versus giving some guidance and some documentation on how to use it. This seems to be lacking.

It would be a huge help if there were some guidelines or some new technologies that were developed specifically for that.

I would like to see more focus on it being a data lake. We have around 100 terabytes of data stored in LogRhythm, machine data, sensor data. That all could be used for operations tasks as well. It would really be awful to have to stand up another Splunk instance at 100 terabytes alongside of it.

Also, seeing more analytics features, and more flexibility around that, and their schema.

Bringing it out completely horizontally scalable, and also continued focus on supporting lots of different vendors, for a lot of data sources.

There is room for improvement in the area of File Integrity Monitoring.

• More seminars.
• Reporting: A reporting tool would be good for us, especially if we have better knowledge of them.

Adding more integration for security products would be an improvement.

Dashboards, reports. Right now I know there's a big issue with reporting. It's challenging, at least for us, to do some of the reporting within the system itself. Hopefully that's something that gets improved.

Also, when you're reaching out to any other solution out there, any third party, most of them have integrations with Splunk; that's something that it's lacking on the LogRythm side. They're lagging behind when it comes to integration to main platforms.

So hopefully, with the help of the entire community, we can build something a little bit more flexible when it comes to integrations.

I would like to the log management database perform more efficiently.

The CloudAI obviously, that's going to be big for us. Hopefully that matures. I saw the problem statement video they did today at this conference, which is great. But I haven't seen anything tangible out of that yet, so looking forward to that.

I wouldn't give them a 10 out of 10 because there is definitely some room for improvement as far as in the GUI. Some of the things don't make sense. I think they need to better understand how a SOC would use that platform.

I don't think they understand that every morning we do a case review and we need a quick dashboard to go review open cases for our SOC. And that's not built into the dashboard, so we have to create that. There are some use cases that I think they should sit down a little bit more with the customer and understand how we use it.

If they continue to do innovation, and listen to their customers, then they'll move forward, and I think that will be the best thing for all parties involved.

There is a Group-By field that they're breaking out, which stopped me from being able to have certain events. They're breaking it out in 7.3, so they've already got it. That was the one thing that bothered me, so I'm happy about that.

Logging improvements. I think that the template to reporting is just difficult, it's hard to go back. You can't modify the templates. So more customization. That would be key.

We could also use more information on how to integrate with specific vendors.

Threat intelligence is a big thing. LogRhythm actually has a pretty good threat intelligence deal, but we happen to use a vendor that is not built-in. It'd be great if LogRhythm could expand more on the user forum on how to integrate more with the more non-mainstream vendors.

A cleaner interface. I keep getting confused and forgetting where everything is. A more intuitive interface would be helpful.

It does seem to be good at gathering data. Like I said, it's hard for me to get that data. I would just like it to be more intuitive. When I go to look for stuff I frequently can't find it. Either it's not there or I just don't know the program.

Lots of concern these days regarding vulnerability, and being able to interface with other tuypes of applications when creating event log. We have lots of other applications to monitor. Logrhythm can extract that info, but some require converting before LogRythem. Windows logs don't need converting, but SQL, & XML do require conversion and monitoring.

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

We need to get better training for things like creating code and playlists. The way it's done now takes a long time. 

I'm sure there are always areas, in stability and scaling, that need improvement. I don't have anything right off that I can say I know needs improvement right at this point.

I did hear about the new playbook edition coming up and I am excited about it.

I don’t have a lot of confidence in their support. The support is not first class. I am still working with them with follow ups with the numerous issues we have had. The appliance itself seems to be doing what it’s supposed to, but the support is lacking.

The main area of improvement is that the client must be installed on the computer for all of the functions to work. So if the client doesn't have a customer in their system, they can’t use it.

NextGen SIEM's integration with other software is good but could be improved.

NextGen SIEM has separate rules for AI, advanced intelligence, and MP rules - it would be better to have a centralized way to write the rules and create alarms. In the next release, I would like to see the network hierarchy diagram that QRadar offers.

Mostly they should just expand on the features that are already there. More pre-built parsers, more pre-built AI rules, more dashboard widgets that we can put to use.

The ability to customize certain features of the product.

More detail in the alerts given to avoid additional searches, as often the source or destination associated with the alert is not evidenced.

We would like to see a better base templates for reporting.

It seems with all of the advanced features that we haven't quite figured them out.

It is very complex. More training maybe, in addition to the LogRhythm training on the community website, which is a lot. Better adoption starting out, so we are more comfortable when we start and when we go live.