What needs improvement with LogRhythm NextGen SIEM?

LogRhythm SIEM could learn from Wazuh, as Wazuh has a built-in mechanism that allows you to write custom scripting and scripts through languages that Wazuh can then trigger, which is somewhat better and more matured in Wazuh compared to LogRhythm SIEM. Additionally, the parsers that I write for LogRhythm SIEM tend to get quite complex for log parsing, while with Wazuh, I can achieve a similar parser with much less complexity. Those are some of the pain points that some of our customers have been expressing. If LogRhythm SIEM could make a lightweight version of their solution, that would be quite competitive because some of my customers have a very large need but refuse to go with LogRhythm SIEM due to its complexity and high resource intensity. Therefore, they have been moved to Wazuh, which I am deploying for them. Even though LogRhythm SIEM has extremely good capabilities, their resource utilization is too heavy for certain customers, so if they could make a separate, lightweight version, that would be quite beneficial.

One major area for improvement in LogRhythm SIEM is the lack of volume measurement capability in terms of storage. There is currently no way to determine how much data is being consumed in terms of gigabytes, terabytes, or petabytes from particular devices or environments. This information is crucial for planning future storage needs and scalability. The system monitor (collector) agent has issues with resource consumption. Even when not actively collecting data, the agent continues to consume significant CPU and memory resources, which can be particularly problematic for small business environments with limited resources. LogRhythm SIEM could improve by adding more default device support. While they have good default settings for devices such as Palo Alto firewalls, custom log sources often require extensive work. Increasing the number of supported devices with built-in policies and functionality would reduce the need for custom work. Competitive SIEM tools often provide more comprehensive coverage for various devices and vendors.

I cannot think of any specific features that LogRhythm SIEM can improve upon since it supports a wide variety of major vendors. However, they need to improve their parsing techniques; the tool should understand various devices and present data in a human-readable format. For example, if a personal Android mobile needs to be integrated, LogRhythm SIEM should be able to parse that data effectively. They also need to improve their database of supported devices to cover smaller vendors alongside the major players, allowing for better global reach and usability. I have noticed some problems with parsing errors, event mismatches, and data mismatching, so ensuring accurate parsing and continuous improvement according to device updates are my basic expectations as a detection engineer.

The SOAR capabilities need improvements as they currently require programming knowledge. A more user-friendly user interface with drag-and-drop features, similar to key competitors like Splunk, would be beneficial.

The integration is slightly difficult with other assets, like EDR technologies or firewalls. Also, the back end is not as user-friendly as other solutions like IBM QRadar. The technical support is also not as good compared to some other products.

LogRhythm SIEM works well, but the biggest pain point is retrieving logs using multiple filters. Even though they use Logstash from the ELK stack, it becomes very slow. LogRhythm's system uses Logstash, and while it's very fast in Elastic, it's not as quick in LogRhythm.

The price could be improved. In future releases, I suppose if they can give us some training related to LogRhythm, that would be very beneficial. I suppose the training is not enough. And the product might be a little bit complex for non-experienced people

The tool needs to improve the implementation part and have a virtual list of files for a virtual appliance or something like that because it is a very complicated area when it comes to implementation. There are a lot of pieces that need to be installed and prepared, and, of course, there is a need for virtual resources. The tool must offer better virtual resources and prepare some virtual appliances with some ISO or VMDK files. I don't care, but the solution must do something to improve the product. There are too many things that are complicated during the implementation phase.

LogRhythm SIEM can improve its user interface. The current interface is quite complex and can be challenging to navigate. While it offers many valuable features, understanding how to access and utilize them efficiently takes time. Simplifying the client console's user interface would significantly enhance the user experience and make it more user-friendly.

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.

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.

The product's stability needs improvement.

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.

The software needs to work on its pricing.

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.

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.

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 user interface needs improvement. The more the user can slide around and know what's going on, the better it will be.

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.

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.

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.

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

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

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.

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.

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

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.

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

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.

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

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.

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

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

The biggest complaint I have is about their support. There is no free instructional advice available on their website. An example is with their field names inside log messages, where they have one named "Common event". That is something that LogRhythm has created, and you can't figure out what it means unless you pay a large sum of money for training. Compare this to Splunk, where I can go to their website and download twenty articles on field names right now. There is no documentation that we can afford to buy for this product, so we just have to wing it. Their product has issues when it comes to hard drive management. Again, their support is not one hundred percent. We are using their hardware, and one time the product just spontaneously stopped collecting logs for about a month and nobody knew it. We called them, and it took a week or two of troubleshooting before they found the issue. To make it worse, the issue was not a misconfiguration. Rather, it was related to how they were storing temporary logs on the hard drive. The drive was shutting down and the logs were not being accepted. It took them weeks to figure this out and it shouldn't have happened in the first place, which suggests a bad design. It is a product that is very hard to use. You have to set a wide variety of parameters before you can even start to search. The highly structured nature of it does provide some guidance, but with a lack of documentation for things like field names, I don't know what I'm looking for. We don't get much use out of this product because people around here consider it to be unreliable, and it's hard to do searches. The main reason for it being here is that there are audit requirements for collecting logs and maintaining them. We have been able to solve problems with it, but searching is kind of clunky.

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 see room for improvement in the log ingestion. Customizing a log source is very technical, probably more technical than it has to be.

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.

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.

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.

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

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.

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.

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

I have over 3,300 log sources. The support for log sources is pretty good, unless you want to go to the cloud where I've had some rough spots with that. I had a hard time integrating with Office 365 because my antivirus wasn't supported. I had to get some custom parsers in order to get that integrated. I would say that better API support for cloud log sources would be a definite improvement. Ease and setup would be a major improvement because it took over a week to get it all up and running, and that didn't even count tweaking it and getting it all set up for my environment. There's some room for growth there.

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

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

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.

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.

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 would like to see APIs well-documented and public facing, so we can get to them all.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

My biggest complaint is documentation. Everyone tells me, "We have documentation on the 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.

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

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

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.