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 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.
It is our sole cross-correlation logging backend for some IBM services. We have a combination of LogDNA and Sysdig for root cause analysis and customer events.
LogDNA is related to the operations of the service. Sysdig is somewhat nice in the sense that it also gives us some backdrop when there are any issues with respect to resources and other types of metrics-based constraints.
LogDNA consolidates all logs into one place, which is super valuable.
Every once in a while, our IBM cloud operational implementation gets behind. Sometimes, when we have a customer event, we do not get access to the latest logs for about 30 minutes, particularly for the sites that are heavily utilized. This is clearly not good. It is impossible to do RCA when you can't look at the logs that pertain to the time period in which the event occurred. It could be more of an operational problem than a feature problem. I don't have visibility about whether it is a LogDNA issue or just an operational issue.
We have been using this solution for about a year.
It has decent stability. We're heavily dependent on it. All RCA, customer support issues, and site reliability studies go to LogDNA. It is something we depend on ten times a day.
It has much better stability than Elastic.
Its scalability is fine. We are running significant throughputs on it.
It is significantly better than Elastic in scalability.
We do not directly interact with them. We tend to go through the customer support of the services team that manages LogDNA.
We were using Elastic. The reason for going with LogDNA was that Elastic was just not able to keep up with the throughput of what our services go through. LogDNA is more stable and scalable than Elastic.
Elastic also could not give us the performance for looking at 30 days in arrears. That was another reason for moving away from Elastic.
We haven't had anything yet that we couldn't do through LogDNA. Feature-wise, it is solid for us. From a functionality point of view, that is, finding stuff and doing RCA and other things, we're able to find what we're looking for. We don't have any constraints at this point.
I would rate LogDNA an eight out of ten.
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.
We have a POC environment but have not onboard it to any of our clients.
The most valuable feature is the correlation function, which is flexible.
It is a bit easier to use than other products, such as Splunk or ELK Elasticsearch.
The technical support can be improved a little bit, and the price could be cheaper.
I have been using IMB QRadar for one year.
IBM QRadar is a stable solution.
Technical support needs improvement.
I know a little bit about Splunk and ELK Elasticsearch. We did not have a PoC with Splunk so it was just theoretical, but I did learn about it.
The initial setup is very easy.
IBM QRadar is a little bit expensive compared to other products.
I would recommend this solution to others who are looking for an on-premises solution. For a SIEM solution, it is the best one to go with. If they are interested in using the cloud, I would not recommend it. The cloud version of QRadar is QRoC and it is a bit complicated.
I would rate this solution an eight out of ten.
