Our initial use case is to use Devo as a SIEM. We're using it for security and event logging, aggregation and correlation for security incidents, triage and response. That's our goal out of the gate.
Their solution is cloud-based and we're deploying some relays on-premise to handle anything that can't send it up there directly. But it's pretty straightforward. We're in a hybrid ecosystem, meaning we're running in both public and private cloud.
We're very early in the process so it's hard to say what the improvements are. The main reason that we bought this tool is that we were a conglomeration of several different companies. We were the original Qualcomm company way back in the day. After they made billions in IP and wireless, they spun us off to Vista Equity, and we rapidly and in succession bought three or four companies in the 2014/2015 timeframe. Since then, we've acquired three or four more. Unfortunately, we haven't done a very good job of integrating those companies, from a security and business services standpoint.
This tool is going to be our global SIEM and log-aggregation and management solution. We're going to be able to really shore up our visibility across all of our business areas, across international boundaries. We have businesses in Canada and Mexico, so our entire North American operations should benefit from this. We should have a global view into what's going on in our infrastructure for the first time ever.
The solution is enabling us to bring all our data sources into a central hub. That's the goal. If we can have all of our data sources in one hub and are then able to pull them back and analyze that data as fast as possible, and then archive it, that will be helpful. We have a lot of regulatory and compliance requirements as well, because we do business in the EU. Obviously, data privacy is a big concern and this is really going to help us out from that standpoint.
We have a varied array of threat vectors in our environment. We OEM and provide a SaaS service that runs on people's mobiles, plus we provide an in-cab mobile in truck fleets and tractor trailers that are both short- and long-haul. That means our threat surface is quite large, not only from the web services and web-native applications that we expose to our customers, but also from our in-cab and mobile application products that we sell. Being able to pull all that information into one central location is going to be huge for us. Securing that type of landscape is challenging because we have a lot of different moving parts. But it will at least give us some insight into where we need to focus our efforts and get the most bang for the buck.
We've found some insights fairly early in the process but I don't think we've gotten to the point where we can determine that our mean time to resolution has improved. We do expect it to help to reduce our MTTR, absolutely, especially for security incidents. It's critical to be able to find a threat and do something about it sooner. Devo's relationship with Palo Alto is very interesting in that regard because there's a possibility that we will be pushing this as a direct integration with our Layer 4 through Layer 7 security infrastructure, to be able to push real-time actions. Once we get the baseline stuff done, we'll start to evolve our maturity and our capabilities on the platform and use a lot more of the advanced features of Devo. We'll get it hooked up across all of our infrastructure in a more significant way so that we can use the platform to not only help us see what's going on, but to do something about it.
So far, the most valuable features are the ease of use and the ease of deployment. We're very early in the process. They've got some nice ways to customize the tool and some nice, out-of-the-box dashboards that are helpful and provide insight, particularly related to security operations.
The UI is
They've put a lot of work into the UI. There are a few areas they could probably improve, but they've done a really good job of making it easy to use. For us to get engagement from our engineering teams, it needs to be an easy tool to use and I think they've gone a long way to doing that.
The real-time analytics of security-related data are super. There are a lot of data feeds going into it and it's very quick at pulling up and correlating the data and showing you what's going on in your infrastructure. It's fast. The way that their architecture and technology works, they've really focused on the speed of query results and making sure that we can do what we need to do quickly. Devo is pulling back information in a fast fashion, based on real-time events.
The fact that the real-time analytics are immediately available for query after ingest is super-critical in what we do. We're a transportation management company and we provide a SaaS. We need to be able to analyze logs and understand what's going on in our ecosystem in a very close to real-time way, if not in real time, because we're considered critical infrastructure. And that's not only from a security standpoint, but even from an engineering standpoint. There are things going on in our vehicles, inside of our trucks, and inside of our platform. We need to understand what's going on, very quickly, and to respond to it very rapidly.
Also, the integration of threat intelligence data provides context to an investigation. We've got a lot of data feeds that come in and Devo has its own. They have a partnership with Palo Alto, which is our primary security provider. All of that threat information and intel is very good. We know it's very good. We have a lot of confidence that that information is going to be timely and it's going to be relevant. We're very confident that the threat and intel pieces are right on the money. And it's definitely providing insights. We've already used it to shore up a couple of things in our ecosystem, just based on the proof of concept.
The solution’s multi-tenant, cloud-native architecture doesn't really affect our operations, but it gives us a lot of options for splitting things up by business area or different functional groups, as needed. It's pretty simple and straightforward to do so. You can implement those types of things after the fact. It doesn't really impact us too much. We're trying to do everything inside of one tenant, and we don't expose anything to our customers.
We haven't used the solution's Activeboards too much yet. We're in the process of building some of those out. We'll be building dashboards and customized dashboards and Activeboards based on what those tools are doing in Splunk. Devo's going to help us out with our ProServe to make sure that we do that right, and do it quickly.
Based on what I've seen, its Activeboards align nicely with what we need to see. The visual analytics are nice. There's a lot of customization that you can do inside the tool. It really gives you a clean view of what's going on from both interfaces and topology standpoints. We were able to get network topology on some log events, right out of the gate. The visualization and analytics are insightful, to say the least, and they're accurate, which is really good. It's not only the visualization, but it's also the ability to use the API to pull information out. We do a lot of customization in our backend operations and service management platforms, and being able to pull those logs back in and do something with them quickly is also very beneficial.
The customization helps because you can map it into your business requirements. Everybody's business requirements are different when it comes to security and the risks they're willing to take and what they need to do as a result. From a security analyst standpoint, Devo's workflow allows you to customize, in a granular way, what is relevant for your business. Once you get to that point where you've customized it to what you really need to see, that's where there's a lot of value-add for our analysts and our manager of security.
Devo has a lot of cloud connectors, but they need to do a little bit of work there. They've got good integrations with the public cloud, but there are a lot of cloud SaaS systems that they still need to work with on integrations, such as Salesforce and other SaaS providers where we need to get access logs.
We'll find more areas for improvement, I'm sure, as we move forward. But we've got a tight relationship with them. I'm sure we can get anything worked out.
This is our first foray with Devo. We started looking at the product this year and we're launching an effort to replace our other technology. We've been using Devo for one month.
The stability is good. It hasn't been down yet.
The scalability is unlimited, as far as I can tell. It's just a matter of how much money you have in your back pocket that you're willing to spend. The cost is based on log ingestion rate and how much retention. They're running in public cloud meaning it's unlimited capacity. And scaling is instantaneous.
Right now, we've got about 22 people in the platform. It will end up being anywhere between 200 and 400 when we're done, including software engineers, systems engineers, security engineers, and network operations teams for all of our mobile and telecommunications platforms. We'll have a wide variety of roles that are already defined. And on a limited basis, our customer support teams can go in and see what's going on.
Their technical support has been good. We haven't had to use their operations support too much. We have a dedicated team that's working with us. But they've been excellent. We haven't had any issues with them. They've been very quick and responsive and they know their platform.
We were using Splunk but we're phasing it out due to cost.
Our old Splunk rep went to Devo and he gave me a shout and asked me if I was looking to make a change, because he knew of some of the problems that we were having. That's how we got hooked up with Devo. It needed to have a Splunk-like feel, because I didn't want to have a long road or a huge cultural transformation and shock for our engineering teams and our security teams that use Splunk today.
We liked the PoC. Everything it did was super-simple to use and was very cost-effective. That's really why we went down this path.
Once we got through the PoC and once we got people to take a look at it and give us a thumbs-up on what they'd seen, we moved ahead. From a price standpoint, it made a lot of sense and it does everything we needed to do, as far as we can tell.
We were pulling in all of our firewall logs, throughout the entire company, in less than 60 minutes. We deployed some relay instances out there and it took us longer to go through the bureaucracy and the workflow of getting those instances deployed than it did to actually configure the platform to pull the relevant logs.
In the PoC we had a strategy. We had a set of infrastructure that we were focusing on, infrastructure that we really needed to make sure was going to integrate and that its logs could be pulled effectively into Devo. We hit all of those use cases in the PoC.
We did the PoC with three people internally: a network engineer, a systems engineer, and a security engineer.
Our strategy going forward is getting our core infrastructure in there first—our network, compute, and storage stuff. That is critical. Our network layer for security is critical. Our edge security, our identity and access stuff, including our Active Directory and our directory services—those critical, core security and foundational infrastructure areas—are what we're focusing on first.
We've got quite a few servers for a small to mid-sized company. We're trying to automate the deployment process to hit our Linux and Windows platforms as much as possible. It's relatively straightforward. There is no Linux agent so it's essentially a configuration change in all of our Linux platforms. We're going through that process right now across all our servers. It's a lift because of the sheer volume.
As for maintenance of the Devo platform we literally don't require anybody to do that.
We have a huge plan. We're in the process of spinning up all of our training and trying to get our folks trained as a day-zero priority. Then, as we pull infrastructure in, I want those guys to be trained. Training is a key thing we're working on right now. We're building the e-learning regimen. And Devo provides live, multi-day workshops for our teams. We go in and focus the agenda on what they need to see. Our focus will be on moving dashboards from Splunk and the critical things that we do on a day-to-day basis.
We worked straight with Devo on pretty much everything. We have a third-party VAR that may provide some value here, but we're working straight with Devo.
We expect to see ROI from security intelligence and network layer security analysis. Probably the biggest thing will be turning off things that are talking out there that don't need to be talking. We found three of those types of things early in the process, things that were turned on that didn't need to be turned on. That's going to help us rationalize and modify our services to make sure that things are shut down and turned off the way they're supposed to be, and effectively hardened.
And the cost savings over Splunk is about 50 percent.
Pricing is pretty straightforward. It's based on daily log ingestion and retention rate. They keep it simple. They have breakpoints, depending on what your volume is. But I like that they keep it simple and easy to understand.
There were no costs in addition to their standard licensing fees. I don't know if they're still doing this, but we got in early enough that all of the various modules were part of our entitlement. I think they're in the process changing that model a little bit so you can pick your modules. They're going to split it up and charge by the module. But everything was part of the package that we needed, day-one.
We were looking at ELK Stack and Datadog. Datadog has a security option, but it wasn't doing what we needed it to do. It wasn't hitting a couple of the use cases that we have Splunk doing, from a logging and reporting standpoint. We also looked at Logstash, some of the "roll-your-own" stuff. But when you do the comparison for our use case, having a cloud SaaS that's managed by somebody else, where we're just pushing up our logs, something that we can use and customize, made the most sense for us.
And from a capability standpoint, Devo was the one that most aligned with our Splunk solution.
Take a look at it. They're really going after Splunk hard. Splunk has a very diverse deployment base, but Splunk really missed the mark with its licensing model, especially when it relates to the cloud. There are options out there, effective alternatives to Splunk and some of the other big tools. But from a SaaS standpoint, if not best-in-breed, Devo is certainly in the top-two or top-three. It's definitely a strong up-and-comer. Devo is already taking market share away from Splunk and I think that's going to continue over the next 24 to 36 months.
Devo's speed when querying across our data is very good. We haven't fully loaded it yet. We'll see when the rubber really hits the road. But based on the demos and the things that we've seen in Devo, I think it's going to be extremely good. The architecture and the way that they built it are for speed, but it's also built for security. Between our DevOps, our SecOps, and our traditional operations, we'll be able to quickly use the tool, provide valuable insights into what we're doing, and bring our teams up to speed very quickly on how to use it and how to get value out of it quickly.
The fact that it manages 400 days of hot data falls a little bit outside of our use case. It's great to have 400 days of hot data, from security, compliance, and regulatory retention standpoints. It makes it really fast to rehydrate logs and go back and get trends from way back in the day and do some long-term trend analysis. Our use case is a little bit different. We just need to keep 90 days hot and we'll be archiving the rest of that information to object-based long-term storage, based on our retention policies. We may or may not need to rehydrate and reanalyze those, depending on what's going on in our ecosystem. Having the ability to be able to reach back and pull logs out of long-term storage is very beneficial, not only from a cost standpoint, but from the standpoint of being able to do some deeper analysis on trends and reach back into different log events if we have an incident where we need to do so.
We are using it for monitoring firewalls, Windows operating systems, some Linux operating systems, active directories, and some of the solutions in the cloud such as Office.
In terms of deployment, everything is in the cloud. Our licenses are on the cloud. We don't deploy anything on premises except the RIN.
We are a managed service provider, and we offer this service to third-party clients. Most of our clients are very happy with the solution. We can detect a lot of threats, which are not false positives, and we can describe the threats very well. A lot of information can be obtained from this SIEM, and we can provide very good incident reports to our clients.
We were using another solution previously. The other solution couldn't compete with the features and functionality that we were looking for as a managed service provider. Some clients ask for specific features, and we couldn't complete those needs with other products. They were more about calculations, such as events per second (EPS). With Securonix, it is easier to sell the product and make quotes for our clients. It has helped us a lot at the administration, commercial, and operation levels.
It provides actionable intelligence on threats related to our use cases. It can detect violations and reduce false positives. This actionable intelligence is one of the most important parts because we have suffered with some of the other solutions in terms of receiving a lot of events and alarms where most of them were false positives, which made it a bit difficult for us to investigate and generate incident reports. Securonix is handy for engineers and the security operations center.
Its analytics-driven approach is pretty good at finding sophisticated threats and reducing false positives. When it comes to monitoring network devices, such as firewalls, it can detect behaviors that would be difficult for other solutions to detect or for normal engineers to detect manually. It has a lot of violation policies, and it is very handy and helpful at this level.
It adds contextual information to security events, which is one of the most important points. We can fill a lot of information into our reports for our clients.
Everything is saved for us and indexed. We can review any event we need within three or six months. We can review even when the data is in the cold phase. We never faced any case where we lost any event data. When clients asked about some events in the past, we could find them very easily and without any issues by using the queries.
It improves analysts' efficiency to do more with less time. Spotter is one of the best tools for me for searching and visualizing various things such as policies. With the Spotter language, you can search for whatever you need. You can search for any endpoint, any IP, any hostname, or any violation name. Even though it is not very fast, it is fine for us. Splunk or Elasticsearch is faster than Securonix because this is their job. Even though Spotter is not as fast, it has been helpful for us.
The detection of threats and reduction of false positive alarms as compared to other solutions are valuable features. It has improved threat detection response and reduced a lot of noise from false positives as compared to our previous SIEM solutions. This was one of the reasons we decided to try or move to Securonix. Other products generated thousands of events, and a lot of them were false positives, which made it difficult for us to handle all the events. For example, we were monitoring a firewall internally, and that firewall generated about five million events per month. The previous product detected almost 1,000 to 1,500 events as positive events, whereas Securonix generates less than 200 events, and most of them are not false positives.
It can integrate with a lot of solutions. Being able to ingest all our log sources when investigating threats is one of the good points of Securonix. After we started to use Securonix, we could integrate a lot of solutions, which we couldn’t do previously. It works with many devices, platforms, and cloud solutions. It is pretty good in terms of integration.
The incident response area should be improved.
It is more difficult than other products, but overall, it is good. The platform has a lot of options and functionality. So, you need to check almost everything. For new engineers or people who don’t have much experience with this kind of platform, it is a bit difficult, but for experienced engineers, it is not that difficult.
When you have been doing a lot of work for about one or two hours, and you have a lot of tabs open, it slows down or gets stuck. There is a delay of 10 to 15 seconds in opening tabs or dashboards. I don't know why this happens, but for me, it is not a big issue. I just wait, and that's all.
I have been using this solution for one year.
It is stable, but it slows down or gets stuck when you have a lot of tabs open.
Overall, it is scalable, but when you are investigating a lot and you have a lot of tabs open and are involved in big work, it sometimes becomes slow or gets stuck.
In terms of its users, our SOC team has three engineers, and I am the fourth one. We have three clients for now for Securonix. We use it internally to monitor our company. Overall, there are five or six users using the interface, investigating, and reporting to the clients.
Most of the time, their support is very good, but sometimes, we had to escalate the issues. Sometimes, we opened a ticket, and we immediately received an answer for fixing the issue, but at other times, we got a response after one, two, three, or even seven days. I guess it is based on the impact or severity, but when we have an urgent issue or problem, Securonix solves it very fast. I would rate them an 8 out of 10.
Positive
We were previously using Splunk, and we wanted to continue, but when we did the evaluation, we found Splunk to be more difficult to implement than others. It is fine to operate it, but its implementation is more difficult. It also had fewer features than Securonix. Securonix is dedicated to security information event management, but this is not the main functionality of Splunk. Even though Splunk is very strong in security, and we have been using it, when it comes to, for example, machine learning, Securonix has pre-configured policies. So, we don't have to spend that much time, whereas when it comes to Splunk, we have to configure everything. We have to install the applications and configure the dashboards. Considering the functionalities, features, and pricing, we felt that Securonix would be the best option.
It is better than previous solutions in terms of threat investigations and onboarding. That's because most of the other solutions are based on rules. Sometimes, there is no intelligence when it comes to detection, whereas Securonix has policies that are a collection of rules. Securonix doesn't only extract the log and tells us that it is a low-impact event or informative event. It also tries to correlate most of the events according to the policies and takes us to the main point. This is how Securonix has helped us to reduce a lot of false positives. Other solutions only worked with rules, and they only sent us events. We had to review most of those events, which is not the case with Securonix. It has a lot of policies for all types of detections. There are almost 1,000 policies, and Securonix can correlate various types of behaviors and pieces of evidence to detect advanced threats. It is good at this level.
We have the cloud license of Securonix. Everything is on the cloud. We only implement RIN on-premises, which is straightforward. You just download the executable, give it permission, and execute it. You provide the information it asks. There are a few packages that you need to install previously, but overall, it is very handy and straightforward.
I implemented it on my own.
Its price is fine. We found it to be cheaper than LogRhythm, Exabeam, Splunk, as well as Elastic Security. A few months ago, when we were comparing Securonix with Elastic Security, we found Securonix to be cheaper than Elasticsearch. We were pretty surprised that Elastic Security is more expensive than Securonix because Elasticsearch is just starting, and it cannot compete with Securonix at this time. So, the pricing of Securonix is pretty good for now.
We tried to evaluate some of the other products, but we decided to go with Securonix for the business part. It was easier for us to meet the needs of our clients related to calculations.
We evaluated LogRhythm. The first problem that we faced with LogRhythm was that it would have been pretty difficult for engineers to handle in terms of the user interface. As compared to Securonix, it was also very expensive. Securonix had most of the features or functionalities that we were looking for. We also evaluated Exabeam, and we had the same problem with the price and features.
It has somewhat reduced the amount of time we require for investigation. It hasn't probably helped in detecting advanced threats faster along with lower response times because there is this gap between the RIN receiving the information and then sending this information to the cloud. This gap makes it a little bit late as compared to other solutions. Other than that, it is good.
I would rate it a 9 out of 10.
We use Splunk to monitor our private cloud, data center, and other applications.
I don't like Splunk very much and find that it does not have many useful features.
Splunk works based on parsing log files.
I don't like the pipeline-organized programming interface.
I find the graphical options really limited and you don't have enough control over how to display the data that you want to see.
I find that the performance really varies. Sometimes, the platform doesn't respond in time. It takes a really long time to produce any results. For example, if you want to display a graph and put information out, it can become unresponsive. Perhaps you have a website and you want to show the data, there's a template for that, or it has a configuration to display your graphics, and sometimes it just doesn't show any data. This is because the system is unresponsive. There may be too much data that it has to look through. Sometimes, it responds with the fact that there is too much data to parse, and then it just doesn't give you anything. The basic problem is that every time you do a refresh, it tries to redo all of the queries for the full dataset.
Fixing Splunk would require a redesign. The basic way the present the graphs is pipeline-based parsing of log files, and it's more of a problem than it is helpful. Sometimes, you have to perform a lot of tricks to get the data in a format that you can parse.
You cannot really use global variables and you can't easily define a constant to use later. These things make it not as easy to use.
I have been using Splunk for approximately one year.
I use Splunk at least a couple of times a week.
I'm not sure about scalability but to my thinking, it's not very scalable. I know that it's probably expensive because it relies a lot on importing log files from all of the systems. One of the issues with respect to scalability is that there's never enough storage. Also, the more storage you have, the more systems you need to manage all the log files.
Splunk is open for all of the users in the company. We might have 1,000 IT personnel that could access it, although I'm not sure how many people actually use it. I estimate that there are perhaps 200 active users.
I have not been in contact with technical support from Splunk.
In this company, we did not previously use a different monitoring solution.
I was not involved in the initial setup.
We have a DevOps team that is implementing Splunk and they are responsible for it. For example, they take care of the licensing of the product.
We have a team at the company that completed the setup and deployment.
The other product that I've seen is Elastic, and I think that it would be a better choice than Splunk. This is something that I'm basing on performance, as well as the other features.
My understanding is that as a company, we are migrating to Azure. When this happens, Splunk will be decommissioned.
Overall, I don't think that this is a very good product and I don't recommend it.
I would rate this solution a five out of ten.
Our primary use case for Wazuh is monitoring endpoints. The second is incident management. Logging is essential for us because of Indian IT compliance rules require us to store logs for 180 days. We need to monitor and maintain logs also.
Wazuh is monitoring around 1,200 inputs, but there are only about four or five members of the IT team directly using the solution.
The configuration assessment and pile integrity monitoring features are decent.
Log data analysis could be improved. My IT team has been looking for an alternative because they want better log data for malware detection. We are also doing more container implementation also, so we need better container security, log data analysis, auditing and compliance, malware detection, etc.
Overall, the implementation part of Azure is tricky. It can be simplified and automated more to shorten the deployment timeline, so we can immediately onboard the application. The entire implementation process should be user-friendly.
We implemented Wazuh in 2019.
I rate Wazuh six out of 10 for stability. While we haven't seen any incidents lately, it used to crash a few years back. The dashboard would be inaccessible due to some service failure or something.
I rate Wazuh eight out of 10 for scalability.
We use community forums like Stack Overflow to find answers. Most debugging and troubleshooting processes are readily available online.
Setting up Wazuh is complex. The deployment involved two IT engineers and took about two months
We deployed Wazuh.
Wazuh is a free solution.
We tried to replace Wazuh with a CrowdStrike real-time security solution. We also tried some solutions from one of our vendors We want to move to either Elastic or CrowdStrike.
I rate Wazuh six out of 10. It's a solid open-source. Stability-wise, Wazuh seems to have fixed all the past issues, and the latest version is possibly the most stable. However, they need to add more features to keep up with the competition. Compared to products like Elastic, Wazuh still lacks a lot of in-depth information. It's still not possible to do a dive, and the configuration could be easier.
LogRhythm NextGen SIEM is customizable, simple to manage, and there are many features. The solution does not require an expert to be able to use it, anyone can use it.
LogRhythm NextGen SIEM could improve by adding more applications for the banking sector. There are not any custom applications at this time.
I used LogRhythm NextGen SIEM within the last 12 months.
The stability of LogRhythm NextGen SIEM is good.
LogRhythm NextGen SIEM is scalable.
The solution has good technical support.
I would rate the technical support from LogRhythm NextGen SIEM a four out of five.
I have used previously ELK Logstash. In my country, LogRhythm NextGen SIEM is used more than ELK Logstash.
The installation is straightforward.
I rate the installation of LogRhythm NextGen SIEM a four out of five.
The support which allows more customized to the environment when we are deploying new systems is called Professional Service and is very expensive. The technical annual support and there is an annual fee.
The price of LogRhythm NextGen SIEM engineers is expensive, but when comparing them to ELK, ELK engineers are more expensive.
My advice to others is for the initial deployment it should be done by certified engineers or the authorized vendor.
I rate LogRhythm NextGen SIEM a nine out of ten.
