We just raised a $30M Series A: Read our story

Devo OverviewUNIXBusinessApplication

What is Devo?

Devo is the only cloud-native logging and security analytics platform that releases the full potential of all your data to empower bold, confident action when it matters most. Only the Devo platform delivers the powerful combination of real-time visibility, high-performance analytics, scalability, multitenancy, and low TCO crucial for monitoring and securing business operations as enterprises accelerate their shift to the cloud.

Devo Buyer's Guide

Download the Devo Buyer's Guide including reviews and more. Updated: November 2021

Devo Customers

United States Air Force, Rubrik, SentinelOne, Critical Start, NHL, Panda Security, Telefonica, CaixaBank, OpenText, IGT, OneMain Financial, SurveyMonkey, FanDuel, H&R Block, Ulta Beauty, Manulife, Moneylion, Chime Bank, Magna International, American Express Global Business Travel

Devo Video

Pricing Advice

What users are saying about Devo pricing:
  • "[Devo was] in the ballpark with at least a couple of the other front-runners that we were looking at. Devo is a good value and, given the quality of the product, I would expect to pay more."
  • "I'm not involved in the financial aspect, but I think the licensing costs are similar to other solutions. If all the solutions have a similar cost, Devo provides more for the money."
  • "Devo is definitely cheaper than Splunk. There's no doubt about that. The value from Devo is good. It's definitely more valuable to me than QRadar or LogRhythm or any of the old, traditional SIEMs."
  • "Be cautious of metadata inclusion for log types in pricing, as there are some "gotchas" with that."
  • "Devo was very cost-competitive... Devo did come with that 400 days of hot data, and that was not the case with other products."
  • "It's a per gigabyte cost for ingestion of data. For every gigabyte that you ingest, it's whatever you negotiated your price for. Compared to other contracts that we've had for cloud providers, it's significantly less."
  • "I like the pricing very much. They keep it simple. It is a single price based on data ingested, and they do it on an average. If you get a spike of data that flows in, they will not stick it to you or charge you for that. They are very fair about that."

Devo Reviews

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
Art Faccio
Director Cyber Threat Intelligence at IGT
Featured Review
Real User
Top 5
Makes it easy to see all our network, endpoint, and cloud on one dashboard, instead of having to jump from system to system

Pros and Cons

  • "The user experience [is] well thought out and the workflows are logical. The dashboards are intuitive and highly customizable."
  • "Some third-parties don't have specific API connectors built, so we had to work with Devo to get the logs and parse the data using custom parsers, rather than an out-of-the-box solution."

What is our primary use case?

We use it for monitoring our core set of network devices, our key systems. We're collecting all the log traffic and using it as a platform to correlate and set up alerts to monitor, and looking for any suspicious behavior.

How has it helped my organization?

One of our early use cases is for compliance and we've set up dashboards that pull in the logs that we need. We have formatted it the way we need it to look and when we meet with internal audit we just show them the dashboard and they have all the information that they need. That's one of the early wins that we've had with it.

When it comes to network, endpoint, and cloud visibility, Devo makes it easy to see all of that. It's all on one dashboard, it's all visible. Instead of having to jump from system to system to system, we can see all of our web traffic and we can see endpoint stats, and whether we need to investigate anything. It's very useful. It definitely raises the level of confidence when we need to take action, compared to our last tool. When a forensic investigation moves forward and we have to do a deeper dive, all that data is there. And the integration team that we're working at Devo is very good at tuning it and showing us what we need. They show us how to extract the relevant pieces and not worry about the less relevant pieces of information.

The solution has saved us time, although we're still in the learning stage. We've only had it in place for three months. I would venture that it's probably saving a few hours a week per analyst, but I expect that to grow as we get better at using it.

What is most valuable?

It's very intuitive. The interface is extremely useful. You can perform many functions from one page. In other tools that we looked at, you'd have to toggle back and forth between screens and you'd have to exit one menu and copy and paste things into another section. With Devo you can do everything using drop-downs. It's very user-friendly when creating queries and dynamic lists. You can modify the interface to look the way you want with columns and sorting. It's very well thought out.

It provides high-speed search capabilities and near real-time analytics. These things are extremely important. 

It's also very easy to pull data into it from various log sources, even if they're custom homegrown apps. The parsers are also very easy to use.

What needs improvement?

If all of the connectors for the third-parties were there, it would be a solid 10. Everything else about it is right there. It's a newer product, so we knew going in that there would be some growing pains and that some things might not be available because not all third-parties would be included.

For how long have I used the solution?

I've been using Devo for about three months.

What do I think about the stability of the solution?

So far, it's been rock-solid. There have been no issues at all.

What do I think about the scalability of the solution?

It should be able to grow as we need it to. It is a SaaS solution, so if we need more data we just purchase more bandwidth.

The size of our environment is about 14,000 users, globally, and about 20,000 endpoints.

How are customer service and technical support?

We haven't had to use their technical support yet. We've only been working with the integration team.

They've been great through the deployment. Obviously, there are going to be little bumps in the road and their team has been very helpful. I've worked with other integration teams that wouldn't even look at the possibility of an issue being at their end until you exhaustively proved that it wasn't at your end. Devo, on the other hand, was very willing to help. They would jump on a call, review the config with us and look through it. They're very willing to spend time and investigate with you; not just push it back on you to double-check everything. They have also pulled in other resources. If the integration engineer didn't know an answer, he would very quickly, usually on the same call or later that day, get another engineer on the phone who was knowledgeable, and we would work through the issue. They're very responsive and it's a very good customer experience. Customer service is very important to them.

Their willingness to go the extra mile and just jump on a call anytime, without having to schedule a call, is an example of where they have exceeded expectations. The project lead would just jump on a call and answer questions anytime.

How was the initial setup?

It was fairly easy to deploy. We had a good deal of on-premises devices where we installed a relay that forwards the log information to the cloud. We also use a large number of SaaS tools. With those it was just a matter of an API connector. Things went very smoothly.

Getting logged in to it and getting logs identified took a week and a half to two weeks.

There were three members of my team involved. One was more focused on getting the collector built and connected, and getting all of our internal log sources forwarding to that. I had two other engineers working on the deployment side, working on rules and carving out the data to send it to specific buckets. Those three are also the ones who take care of maintenance of the solution. We're still in the early stages so we're tweaking things and constantly modifying and figuring out our internal processes.

What about the implementation team?

We used Devo's integration professional services. They worked alongside with my team and they have been excellent.

What was our ROI?

So far we've seen ROI from the fact that when the auditor comes in quarterly and looks at it, as happened the other day, they are extremely impressed. The return value is going to be there. It's already starting, where we're creating custom dashboards for various groups to look at their own data. We don't have to provide reports anymore. We just give them the data and they can log in and look at whatever they want in real time.

It's going to be huge as we move further down the road and we learn to better utilize the tool. We have some big plans for it.

What's my experience with pricing, setup cost, and licensing?

Regarding pricing they were in the ballpark with most of the others we looked at, but one of the things that put them above and beyond is the 400 days of storage. That's big. 

They're a newer company so they may have cut better deals, but they were in the ballpark with at least a couple of the other front-runners that we were looking at. Devo is a good value and, given the quality of the product, I would expect to pay more.

The fact that Devo only charges for ingestion works great for us. In some of the other solutions we looked at, depending on what you were doing with the data, extra charges were assessed. If you wanted to pull playbooks in, that was an extra charge. If you wanted to ingest certain types of logs from certain systems, that was an upcharge. In our environment and our business model, the month-to-month fluctuating charges just weren't an option, and many of the other solutions are going down that road. Devo provides good value: "Hey, here's your ingest, here's what you're licensed for, and here's what your annual bill is going to be. And if you go over that, then you true-up the next year." So it is a beneficial model for us.

Overall, with the pricing model, Devo enables us to ingest more data compared to other solutions we evaluated. We don't have to worry about being billed more if we use any additional functionality or that we may have to set a cap on the ingest for the month or the week.

Which other solutions did I evaluate?

The fact that the solution keeps 400 days of hot data to look for historical patterns was extremely important because many of the competitors kept 90 days or maybe six months. We looked at the big choices that most other companies use. And with those competitors, if you wanted the extra data, it would be put into warm or cold storage and to utilize it you'd have to pull it back in.

Another one of Devo's advantages is, as I've mentioned, the user experience. It's well thought out and the workflows are logical. The dashboards are intuitive and highly customizable.

There are a few drawbacks to it. Some third-parties don't have specific API connectors built, so we had to work with Devo to get the logs and parse the data using custom parsers, rather than an out-of-the-box solution. Most of our third-parties are working on them because it seems that Devo is making some waves in the industry and more and more people are using them. But that has been what we've had to do with three of our third-parties that didn't have a connector. Devo had to create one, and, once again, their customer service was great. They just built it for us and it worked.

When it comes to analyst threat-hunting and incident response, because there are so many options, and Devo has the ability to do many things from one screen, the workflow is a lot more organic and natural. That means you can drill down to the level you need to and pull in the data you need from one screen. You don't have to keep moving around in Devo. It's much more configurable and the options are there to pretty much dig as deep as you need, from one screen.

Overall, Devo approached things a little differently and that's why we ended up going with them.

What other advice do I have?

We did a pretty good job of this, but with hindsight it is always something that we could have done better: the planning of the project. So have a good idea of what logs you want to ingest, right out of the gate, and have the necessary internal teams ready to get you what you need. The pre-planning is the most important thing. We had the relay built and functional for getting the data from site to cloud, literally in 20 minutes. If we had been a little better organized on our end, the implementation would have taken one week instead of a week and a half to two weeks.

So the most important piece of advice in a deployment like this is to know your data. Know what you want and make sure your teams, including the IT teams that need to build the virtual machines, are ready to get the hardware in place quickly.

From my point of view, and from what my team has told me, everything is intuitive and user-friendly. From a logistics point of view, everything is well laid out and well thought out.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Flag as inappropriate
Elizabeth Manemann
Cyber Security Engineer at H&R Block, Inc.
Real User
Top 20
Accepts data in raw format but does not offer their own agent

Pros and Cons

  • "The most valuable feature is definitely the ability that Devo has to ingest data. From the previous SIEM that I came from and helped my company administer, it really was the type of system where data was parsed on ingest. This meant that if you didn't build the parser efficiently or correctly, sometimes that would bring the system to its knees. You'd have a backlog of processing the logs as it was ingesting them."
  • "From our experience, the Devo agent needs some work. They built it on top of OS Query's open-source framework. It seems like it wasn't tuned properly to handle a large volume of Windows event logs. In our experience, there would definitely be some room for improvement. A lot of SIEMs on the market have their own agent infrastructure. I think Devo's working towards that, but I think that it needs some improvement as far as keeping up with high-volume environments."

What is our primary use case?

We have a couple of servers on-premises to gather the logs from our devices. We have a lot of devices including vendor-agnostic collectors that will, for example, collect syslogs from our Linux host. The logs are then sent to the Devo Relay, which encrypts the data and sends it to the Devo Cloud.

What we send to Devo includes all of our Unix-based logs. These are the host logs, as well as logs from a lot of the network devices such as Cisco switches. Currently, we are working with Devo to set up a new agent infrastructure, and the agents will collect Windows event logs.

We were using a beta product that Devo provided for us, which was based on an open-source platform called Osquery. That did not quite work for the volume of logs that we have. It didn't seem to be able to keep up with a large number of servers, or the large amount of Windows event log volume that we have in our environment. We're currently working with them to transition to an Xlog and use their agents, which work really well to forward the logs to Devo.

We also send cloud logs to Devo, and they have their own collector that handles a lot of that. It basically pulls the logs out of our cloud environment. We are sending Office365 management logs, as well as a lot of Azure PaaS service logs. We're sending those through an event hub to Devo. We are currently working on onboarding some AWS logs as well.

We have several corporate locations, with the main location in the US. That is where the majority of our resources are, but we do also have Devo relays stood up in Canadian, Australia, and India. These locations operate in a way that is similar to what is described above, although on a smaller scale. They're sending all of their Unix devices and syslogs to the relay, and then I believe only Australia at the moment is using agents to pull from Windows logs. Canada is using a different SIEM at the moment, although that contract is about to expire, so then we'll onboard their Windows event logs as well. India does not have any Windows servers that need to have an agent for collecting logs, so just send the Linux and Unix logs over the relay to Devo.

Our main use case and customer base are our security operations center analysts. A lot of our process was built up and carried over from our previous SIEM, LogRhythm. We have an alerting structure built out that initiates a standard analyst workflow.

It starts when you get an alert. You drill down in the logs and investigate to see if it's a false positive or not.

We are in the process of onboarding our internal networking team into Devo, and we are gathering a lot of network logs. This means that they can monitor the health of our networking infrastructure, and at some point, maybe set up health alerts for whatever they are looking for.

We have another team that is using Devo, which is our internal fraud team. They're very similar to stock analysts, where they just look for suspicious events. They are especially interested in tax filing and e-filing. We gather logs for that, and they go through a really deep investigative workflow.

How has it helped my organization?

One of the immediate improvements that come to mind is the amount of hot, searchable data. In the SIEM we had before, we were only able to search back 90 days of hot, searchable data, whereas here we have 400 days worth. That definitely has improved our threat hunting capabilities. 

We're also able to ingest quite a bit more data than we were before. We're able to ingest a lot of our net flow data, which if we had sent that to our previous SIEM would have brought it to its knees. So the amount of data that the analysts are able to see and investigate has been a really big beneficial use case. I'd say that's the biggest benefit that it's provided.

I myself do not leverage the fact that Devo keeps 400 days of hot data to look at historical patterns or analyze trends. A lot of times I will look at that to see the log volumes, the traffic, make sure there are no bottlenecks as far as how log sources are sending to Devo. I would say that the analysts definitely for certain cases will go back and try to retroactively view where a user was logging in, for example. At the moment, we haven't really had a use case to push the limit of that 400 days so to speak, and really go really far back. We definitely use the past couple of months of data for a lot of the analyst cases.

This is an important feature for our company especially with the recent SolarWinds attack, which was a big deal. We did not have Devo available, but because that happened so far in the past, it was a struggle to pull that data for it to look for those IOCs. That was definitely a really big selling point for this platform with our company.

Devo definitely provides us with more clarity when it comes to network endpoint or cloud visibility. We're able to onboard a lot of our net flow logs. We are able to drill down on what the network traffic looks like in our environment. For the cloud visibility, we're still working on trying to conceptualize that data and really get a grasp around it to make sure that we understand what those logs mean and what resources they're looking at. Also, there's a company push to make sure that everything in the cloud is actually logging to Devo. As far as cloud visibility, we as a company need to analyze it and conceptualize it a little bit more. For network visibility, I would say that Devo's definitely helped with that.

The fact that Devo stores the data raw and doesn't perform any transformation on it really gives us confidence when we know that what we are looking at is accurate. It hasn't been transformed in any way. I'd definitely say that the ability to send a bunch of data to Devo without worrying about if the infrastructure can handle it definitely allows us to have a bigger and better view of our environment, so when we make decisions, we can really address all the different tendencies. We're collecting a lot more types of log sources than we were before. So we can really see all sides of the issue; the vast amount of data and the ability to really take our decision and back it up with the data, and not just random data but we can use a query and display the data in a way that backs up the decision that we're making.

Devo helps to release the full potential of all our data. The active boards like the interactive dashboards that Devo provides really help us to filter our data, to have a workflow. There are a lot of different widgets that are available for us to visualize the data in different ways. The active boards can be a little slow at times, a little bit difficult to load, and a little bit heavy on the browser. So sometimes the speed of that visualization is not quite as fast as I would like but it's balanced by the vast amount of options that we have.

That's one of the big things that like all security companies, security departments really purported having that single pane of glass. The Devo active boards really allow us to have that single pane of glass. That part is really important to us as a company to be able to really visualize the data. I haven't found the loading speeds have become a significant roadblock for any of our workflows or anything, it's an enhancement and a nice to have.

We all want everything faster, so it's definitely not a roadblock but the ability to represent the data in that visualized format is very important to us. It's been really helpful, especially because we have a couple of IT managers, non-technical people that I am onboarding into the platform because they just want to see an overall high-level view, like how many users are added to a specific group, or how many users have logged in X amount of days. The ability to provide them not only with that high-level view, but allow them to drill down and be interactive with it has really been super helpful for us as a company.

Devo has definitely saved us time. The SIEM that we were on before was completely on-prem, so there were a lot of admin activities that I would have to do as an engineer that would take away from my time of contextualizing the data, parsing out the data, or fulfilling analysts requests and making enhancements. The fact that it is a stock platform has saved me a ton of time, taking away all those SIF admin activities. 

I wouldn't say that it really increased the speed of investigations, but it definitely didn't slow it down either. They can do a lot more analysis on their own, so that really takes away from the time that it takes to reach out to other people. If you went back 90 days, you had to go through a time-consuming process of restoring some archives. The analysts don't have to do that anymore, so that also cuts off several days' worth of waiting. We had to wait for that archive restoration process to complete. Now it's just you pull it back and it's searchable. It's right there. Overall, I would say Devo has definitely saved us a lot of time. For the engineering space, I would say it saves on average about one business day worth of time every two weeks because a lot of times with on-prem infrastructure, there would be some instances where it would go down where I'd have to stay up half the night, the whole night to get it back up. I haven't had to do that with the Devo platform because I'm not managing that infrastructure. 

What is most valuable?

We are using some of the other components, such as Relay, which is used to help us ship logs to Devo.

The most valuable feature is definitely the ability that Devo has to ingest data. From the previous SIEM that I came from and helped my company administer, it really was the type of system where data was parsed on ingest. This meant that if you didn't build the parser efficiently or correctly, sometimes that would bring the system to its knees. You'd have a backlog of processing the logs as it was ingesting them.

One thing that I love about Devo is that you can accept the data in a raw format. It's not going to try to parse it until you query it. This makes it really flexible for us because if the analysts come to us and explain that they need a specific log source, we can just work on the whole transportation system, insofar as how to get it to Devo. We don't have to worry about parsing it out until later. We can actually see the data in the platform and then we can use the queries to perform contextualization on it, parsing out whatever metadata we need.

I really like the flexibility that the queries offer to parse out the data. Parsing out JSON logs, for example, is very easy. You don't have to mess with regex. It's literally just a point-and-click interface. So that has been incredible. I would say overall in a nutshell, one of my favorite parts is that they really have captured the essence of sending us all your data. You don't have to worry about how to parse it. You can get the data onboard and then you can perform transformations on it later. And the transformations that you can perform on it are super flexible.

Devo definitely provides high-speed search capabilities and real-time analytics. The search can be a little bit slow at times. But for the amount of data that we're pulling back relatively speaking, I would say that the speed is very nice. The ability to pull back large amounts of data, also the amount of data that they keep hot and searchable for us is incredible. I would definitely say that they provide real-time analytics and searching.

I have heard from other customers that the multi-tenancy capabilities are pretty good, but I don't have much experience with that in the HR Block though.

What needs improvement?

When it comes to the ease of use for analysts, that's an area that they may need to work on a little bit. Devo offers its version of a case management platform called Devo SecOps. They did offer it to us. It's part of our contract with them. The analysts have found that the workflow isn't very intuitive. There are a couple of bugs within the platform, and so we are actually sticking with our old case management platform right now and trying to work with Devo to help iron out the roadblocks that the analysts are facing. Mostly it seems like they have trouble figuring out where the actual case is. A lot of the search features that are in the main Devo UI don't translate over into their SecOps module. They seem separate and disjointed. So the core of the platform where we have all of the data isn't integrated as well as we would like with their case management system. There's a lot of pivoting back and forth and the analysts can't really stay in the SecOps platform which adds some bumps to their workflow.

The SecOps module also needs improvement. It should be more closely integrated with the original platform that they had. The data search abilities in the SecOps platform should be made more like the data search abilities in the administrator's side of the platform. 

From our experience, the Devo agent needs some work. They built it on top of OS Query's open-source framework. It seems like it wasn't tuned properly to handle a large volume of Windows event logs. In our experience, there would definitely be some room for improvement. A lot of SIEMs on the market have their own agent infrastructure. I think Devo's working towards that, but I think that it needs some improvement as far as keeping up with high-volume environments.

For how long have I used the solution?

We implemented Devo as a PoC last year but have only just started using it officially a few months ago.

What do I think about the stability of the solution?

It's a Devo-managed SaaS cloud platform. It does seem like lately that they've been having trouble keeping up with the large volume of events. It's maybe due to other customers besides H&R Block. I have shared in their cloud infrastructure and we have noticed some slowness and some downtime. I would say it's definitely not more than a maximum of three hours every two weeks. It's usually not a lot of downtime or slowness, at least not to the point where we cannot work within the platform, but it does seem to have been picking up a little bit more lately. That's why I average out around three hours every two weeks. But I would say as far as overall stability, the uptime has been really great. If it's "down", it's really more just that search is run really slow, but you can still get into the platform. It's not really that everything is down where you can't look at alerts. That rarely ever happens. I would say overall, it's pretty stable and it allows our analysts to stay on the platform.

What do I think about the scalability of the solution?

In terms of scalability, we are able to ingest as much or as little data as we want, so that is really awesome. I've been pretty amazed at how much we're able to throw at it. We can expand as much as we want to suit our needs, obviously within the confines of the subscription agreement. There is a data cap, but within that limit, we can really go crazy. The scalability is awesome. It's very scalable.

There are about 50 or so users on the platform right now. We have our SOC analysts at different levels that just perform investigative activities. The majority of our clients on the platform are our security operations center analysts. They have different privileges based on their roles. We give them the ability to create test alerts if they're trying something out.

We have various other team members throughout our corporation using it, only two or three here and there. We have three individuals from our networking team, a couple of individuals from IT support that often utilize the platform to investigate user lockout and stuff like that. Of course, we have the engineers in the platform which have been five or six individuals. The main user base is our SOC analysts.

We do maintenance for our servers and such. We don't really have them on the platform at the moment. They have their own kind of tools. They utilize their graphs to monitor the health of our infrastructure, but that may be something at some point in the future that we may be pursuing. The more teams that we get into our SIEM, the better because it really justifies the usage of the tool. Right now, as far as from a maintenance perspective, the only IT staff that would be using it for that sort of thing would be our networking team. And we have about three individuals that we just recently onboarded, so they're just getting used to the platform.

Devo is mostly being used for security logs. There's a push to start using this not only for security monitoring but for infrastructure health monitoring as well. So we're starting with the networking team. We really are still in phase one of really fleshing Devo out, adding more enhancements and alerts. My primary role is to support the security operations center, to support the security aspect of things but I haven't heard if it's set in stone yet. I would say that we are definitely going to try to push to utilize Devo more throughout our organization for health monitoring and for the networking team to use. Perhaps at some point in the future, we would expand our usage. It's not set in stone yet, but I could definitely see that happening.

How are customer service and technical support?

We have a couple of tickets open with support but mostly for platform health monitoring questions. We do have some in regards to alert logic, but nothing that was super important that we actually had to call Devo tech support.

Their professional services team works really hard on building out active boards for us and helping us make sure that we are monitoring the health of our platform. Overall, I'd say they're definitely really collaborative. They want to hear what's going well for us and what's not. 

Sometimes they're not quite as responsive as I would like, but I think that is also due to the transition process because that was recent. We are giving them some time to get adjusted to our account and get things all set. I would say from a support standpoint, they have definitely been very responsive to our cases that we have open, so that's been really helpful. I've had instances in the past with vendors where it takes several weeks to hear anything back on a case.

Which solution did I use previously and why did I switch?

Prior to Devo, we used the LogRhythm SIEM.

We switched mainly because of the ability to ingest more data. In certain instances, we had to say no to onboarding certain log sources because of the amount of value it offered, the cost-benefit didn't weigh out. LogRhythm put the point where if you added too much data, if you had too much volume being ingested, it would start breaking. It would start complaining and things would just go bad. The amount of downtime we had with LogRhythm was really the main metric driver to get us to transition to Devo. Then what really appealed to us about Devo versus other SIEMs was their "give us all your data" model. That was something we were really struggling with and that was something that we really wanted from a SIEM. We wanted to correlate between as many data sources as possible. They offered us that capability that LogRhythm really did not. 

How was the initial setup?

The initial setup was fairly straightforward. I don't know if this falls into the whole analysis of the Devo UI itself. I'm not sure if Devo considers their agent infrastructure as part of this offering because it was beta, but that was rather complex. We didn't get a lot of details as to the specs needed for when we set up the agent manager infrastructure in our environment, so that was pretty complicated. But as far as just onboarding the data, really offloading all of the alerts that we had out of our old SIEM, it was pretty straightforward.

I would definitely say one thing that may have made it easier would be for Devo to have some more out-of-box alerts. The previous SIEM that we had, had a lot of alerts that they offered us from their research and from their labs and we really built on top of those. We had to build a lot of our alerts from scratch to transition them from our old SIEM to Devo. If Devo had their own alert library or a more fully fleshed-out alert library, that would have made that aspect of it a little less time-consuming. Otherwise, as far as the data onboarding and the data ingestion, that was very straightforward as far as SIEM transitions go. The relay they provided us gave us a single point to send everything to. 

We really shifted completely from our old SIEM to Devo in about three to four months, which by industry standards was very quick. It was a combination of a lot of hard work and teamwork on our side, but again, the data ingestion, the ease of getting that data into Devo took off a lot of that time. We had a single point to send it to which helped with the transition.

In terms of our implementation strategy, our initial goal was to get everything out of our old SIEM. So first we made sure that all of the log sources that were there would be redirected to Devo. And so we set up the appropriate components to forward it to Devo, and then once all the data was in there we started working on transitioning the alert and building out the alert logic, and making sure that the alert logic matched what we had in our old SIEM. After that was onboarding all the users, making sure that the RBAC controls were in place. 

What about the implementation team?

We did use a consultant. We worked with Novacoast. We had a relationship with them in the past. They're an MSSP. They really helped us with building the alert logic mainly.

What's my experience with pricing, setup cost, and licensing?

You definitely get what you pay for. Devo has offered a lot of extra features to justify the price. Devo worries about managing the infrastructure and how it's going to handle that volume, how it's going to store it, and all those things. It allows us to not require as many engineers and not require as many engineering hours. We can devote that time to other things. That's the biggest benefit for the cost. 

I have seen in the Devo documentation that for certain aggregation tasks that you have running in the background, you could be charged extra for those. I've been meaning to get clarification on that. 

Which other solutions did I evaluate?

We were considering Azure Sentinel, mainly because we're an Azure shop. That was mainly the only other solution we looked at. We chose which SIEM we wanted to have a POC with. Azure Sentinel didn't seem to offer as many features as Devo did, which is why we chose them for our POC. I think that was it. We sent it out to a couple of vendors but none of them fulfilled our needs as much as those two and then it was really just between Azure Sentinel and Devo. And Devo gave us a lot more features than Azure Sentinel did.

As far as from an analyst perspective, something that was unique about Devo versus other SIEMs was the immense contextualization capabilities they have because the platform is really based on that you query the data and you perform all these contextualizations in the query. 

Another thing that we were thinking about was the learning curve with querying and using the UI. Devo's response in that learning curve was they definitely provided a lot of training for us. That really helped the analysts.

As far as our previous solution, it definitely allows us to ingest more data than we were able to with LogRhythm. I don't think that the others had 400 days of hot, searchable data. They did not have that much time available as hot and searchable. We definitely have the ability to ingest and store for longer periods of time and to ingest more data. That's really the big thing that is the next-gen capability of Devo that we were looking for was really unlike other SIEMs that I've seen or administered where you don't parse on ingest, you parse after you get the raw data in the platform. That really removes that roadblock.

What other advice do I have?

I have been with the company for approximately three years and in the engineering space for about two.

If the more data the better is the goal for your organization, then Devo is really the way to go for that. But if you're looking more for a super robust analyst interface, next-gen analyst workflow, I don't think Devo is at that point yet. They're more at the point where you can ingest a lot of data and perform visualizations on it really well. 

One of the things that I really like about Devo is the ability to parse the data, and not just the ability to parse the data after you ingest it. There are so many different ways to do it. 

I would definitely explore trying to parse that out yourself because, for me, the first couple of times it was a little bit difficult to get used to the query language and everything. But now, when someone asks for something to be parsed out in a certain way, it's super easy. Explore the ability to use the queries to parse out data to give you that independence and ability to represent data however you want to represent it.

Devo definitely has all the next-gen concepts that I haven't really seen in any other SIEM, but I do think that they definitely have some more room for improvement. A lot of SIEMs offer their own agent and Devo does not at the moment. I would rate Devo a seven out of ten.

Most of the stuff that we saw in our POC with them was the "wow" moment. This platform can address anything. All of the features met my expectations from the POC. As far as the onboarding and integration, it's definitely improved our workflow but the "wow" moment was when we had our proof of concept with them and saw what the platform initially could do, and then it really lived up to that.

Which deployment model are you using for this solution?

Hybrid Cloud
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Flag as inappropriate
JerryH
Director at a computer software company with 1,001-5,000 employees
Real User
Top 5
Enables us to bring all our data sources into a central hub for quick analysis, helping us focus on priorities in our threat landscape

Pros and Cons

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

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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 

  • clean
  • easy to use
  • intuitive. 

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.

What needs improvement?

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.

For how long have I used the solution?

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.

What do I think about the stability of the solution?

The stability is good. It hasn't been down yet.

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

Which solution did I use previously and why did I switch?

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.

How was the initial setup?

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.

What about the implementation team?

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.

What was our ROI?

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.

What's my experience with pricing, setup cost, and licensing?

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.

Which other solutions did I evaluate?

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.

What other advice do I have?

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.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Learn what your peers think about Devo. Get advice and tips from experienced pros sharing their opinions. Updated: November 2021.
554,148 professionals have used our research since 2012.
MV
Security Analyst at a comms service provider with 10,001+ employees
Real User
Top 10
Centralizes all our data, enabling us to correlate it and see issues we had never seen before

Pros and Cons

  • "The user interface is really modern. As an end-user, there are a lot of possibilities to tailor the platform to your needs, and that can be done without needing much support from Devo. It's really flexible and modular. The UI is very clean."
  • "One of the biggest features of the UI is that you see the actual code of what you're doing in the graphical user interface, in a little window on the side. Whatever you're doing, you see the code, what's happening. And you can really quickly switch between using the GUI and using the code. That's really useful."
  • "The Activeboards feature is not as mature regarding the look and feel. Its functionality is mature, but the look and feel is not there. For example, if you have some data sets and are trying to get some graphics, you cannot change anything. There's just one format for the graphics. You cannot change the size of the font, the font itself, etc."

What is our primary use case?

Our primary use of Devo is as a SIEM, and then as a big-data platform. We do store a lot of data centrally, using the solution, and then we analyze it. The main purpose of the analysis is for security, to detect attacks, abnormalities, and to get an overall view of the health of the network.

We deploy it on-premise. Devo mainly deploys in the cloud, but that's just not possible with our security policy.

How has it helped my organization?

We didn't have a proper SIEM platform before, so just having Devo is really a big improvement. We are in the initial phase, but it does make us look at the data differently because we can access it really fast and with ease. The benefit is going to come with more time with the platform. We'll be able to do things we haven't done before, and think outside the box with the platform, because the solution can do things fast. We can experiment. We're now thinking more about more experimentation. Instead of thinking of all the limitations to what you can do with the platform and where you cannot go, it's now open. What would we want to do? We don't have that fear that we will hit the wall.

We have retention policies set globally. We used to have access to the same amount of data before we started with Devo, but that data was not centralized. So the ability to access the old data hasn't really changed. We always had the data. But what has changed is the ease with which we can access this data, the speed, and the ability to be able to correlate this data.

The main result of the centralization is the correlation we can now do. We had a lot of sources with logs, but nobody was centralizing them. Now we have the visibility. By making Devo the central platform and the only platform, we're trying to standardize how the sources and logs work. That means we only have one interface to configure on the sources. We can make instructions that are quite easy to follow for everybody, and which will probably not change over time. Doing this, we break the barrier of logging being difficult to configure and we reduce the issue of destinations changing all the time or of having to change how the data is structured. Even during the deployment process, this really brought way more visibility than we had before. Every day that we're working with the platform, we see problems that nobody ever thought about. It has definitely created a lot of visibility for us.

And with the Devo platform, we can also create long-term use cases. We were not able to do that before because we didn't have the correlation and the data in the same place.

Also, we can now get quite detailed data about communication between different nodes. Sometimes you don't see security incidents right away, and sometimes you have to go back. Now, we can go back three months to a specific date and do a really detailed analysis of what happened. Before, we would have to go to five, 10, or 15 different sources, extract the data and then put it together in a different platform. 

In addition, if we're looking for abnormalities, the longer we have data, the richer and more detailed our model is for what normal behavior is. We can then detect the anomalies more precisely.

Finally, our MTTR has already gone from days to hours. Before we might have had to go to three or four departments and talk to three or four different people to get the logs and manually analyze them. Now, it's a matter of minutes or an hour and we can get a clear picture of what's going on and what to do next. It is a huge change compared to what we had before.

What is most valuable?

The speed of the platform is one of its most valuable features. The solution is designed differently so it doesn't really matter how far back you go, the speed's going to be the same.

We use its real-time analytics, which are very good. It sends alerts; we have some alerts that update every five minutes, or whenever the data comes in. It's really fast. We can work on really large data sets and have a resolution in minutes for these alerts. It's great. It's not actual, real-time because there is some delay before the logs come from the data collectors. But that's not a problem with the Devo platform. It's just how logs travel around here.

The user interface is really modern. As an end-user, there are a lot of possibilities to tailor the platform to your needs, and that can be done without needing much support from Devo. It's really flexible and modular. The UI is very clean. It makes sense for me, personally, the way it's set up.

The UI also has these little perks. For example, if you do queries and you set a certain time range which you need to reuse in different queries, instead of having to type it in every time there is quick access to all the time ranges you have been using. You can just pick the one you need, instead of typing in, say, January 22nd, 2020, from 15:35 to 15:45. You have quick access to whatever ranges you have already put in. I reuse these a lot and it saves a lot of time.

Another UI feature is that it does a type of pre-aggregation and pre-processing for you. Whenever you hover over certain parameters that can be filtered or adjusted, you get an overview of the top 10 values, with the percentages as well. Sometimes you just want to know what the ratio is between different sources. You don't have to do anything to get that. You just hover your mouse over where you would start setting it up and you can actually see the values right away.

It's full of these little surprises. It has something called CyberChef which is a really rich tool for manipulating IT-related data, IP addresses, encoding, and the like. CyberChef is an open-source tool that I sometimes use through its web interface. But you can actually use it directly in the Devo tool, so that's another big bonus. It looks like Devo thought, "Okay, people who use our platform may use this tool as well. It's open-source, so we'll just include it." It's integrated, creating an interface between them.

And one of the biggest features of the UI is that you see the actual code of what you're doing in the graphical user interface, in a little window on the side. Whatever you're doing, you see the code, what's happening. And you can really quickly switch between using the GUI and using the code. That's really useful too.

Activeboards is another really good feature. With them, you can actually see the code as well. It's really powerful. Sometimes with this type of software, there is a similar dashboard feature, but you're very limited in what you can do with it in the graphical user interface. And if you reach its limits, you have to call the vendor and let the vendor do it. But here, you can see the code. So if you want to go deeper, or if there's some feature that is not reachable with the GUI, you can write it yourself. The documentation is really good, so it's quite easy to do.

Activeboards' ability to build and modify dashboards on the fly is also powerful. We came to Devo from a different solution and, obviously, the users didn't want to change the way they use the platform. They required a certain workflow that is not in Devo. With Activeboards, we can recreate the exact workflow they are used to, without any difficulty. That makes it very easy for the user to switch to Devo. That's the power of the Activeboards. You can really change a lot of things. It's very modular.

What needs improvement?

I don't use the Activeboards' visual analytics that much. I just look at the data, most of the time. The Activeboards feature is not as mature regarding the look and feel. Its functionality is mature, but the look and feel is not there. For example, if you have some data sets and are trying to get some graphics, you cannot change anything. There's just one format for the graphics. You cannot change the size of the font, the font itself, etc. You get a graphic that works well in some cases, but in other cases, the numbers are too small and you cannot do anything about it. Overall, the graphic presentation of data is okay, but I miss the basic functionality of being able to change how things look.

For how long have I used the solution?

We've been using Devo for about two months. (as of 02/2020)

What do I think about the stability of the solution?

I don't remember a single issue with the platform in the two months we've used it. There has been no downtime or data missing, at least during my work hours, eight hours a day, Monday to Friday. Even though it's a new product, I feel it's very mature. There are very few bugs in the platform, even if it's evolving all the time.

What do I think about the scalability of the solution?

The scalability is very good. We had some assessments from Devo and they said, "Oh, for this amount of data at the moment you will need this and this." We were kind of skeptical because the amount of hardware they asked for was way less than the old platform that was running some of the data. But I've seen some performance reports and we're very far from reaching any limits on the platform at the moment.

In our office we're not using that much data, but our colleagues in sister company are using way more than we od and they are happy. Having gone through the implementation I know a little bit about how the architecture works and I think it's built to be scalable.

In the future, over the next 12 months, we'll be using it more in terms of volume of data and how much we're using the platform. We are not utilizing very much of what it can do. We use it a lot in daily workflows, but we are not using it to the full potential yet. 

How are customer service and technical support?

The tech support is excellent. We used some Agile methodology to install the platform and we had some non-standard channels in our organization, like Slack or Microsoft Teams, where we used instant messaging communication with the team, and their response times were very fast. 

The support was very professional but very flexible. We had defined some requirements at the beginning of the project, which were included in the contract, but then we realized that we wanted to change them. We were a little bit afraid that because they weren't in the contract it would not be possible, but that wasn't a problem at all. There were no questions asked.

Which solution did I use previously and why did I switch?

We used Splunk prior to Devo. We switched because we were not happy with Splunk. We felt that the platform wasn't built properly and the support was very problematic and expensive. We had an RFQ process, a tender, and Splunk was in the game since it was our current platform. But we were just not happy with them even during the tender. So we decided that we were going to change.

The differences between Splunk and Devo are performance, ease of use, the functionality, and the approach of the company. The latter includes how they do support and development. Devo, overall, is a better solution for us.

How was the initial setup?

Most of the work was done by the Devo team. The work from our side was to get the hardware and the networking ready and to configure the sources. The configuration of the sources was quite straightforward. The main system is not highly complex.

We're going to be doing our own maintenance, level-one and level-two support. Our people are going to training. Devo uses many standard components and standard interfaces. There is no big, proprietary software barrier. It's quite flexible too, in that we could choose our own operating system. They recommend Ubuntu, but in our corporation we run everything on Red Hat. There was no problem at all in this regard.

The hardware requirements were also very flexible, so we could have chosen whatever we wanted; what works for us. Everything was pretty straightforward. There were no issues. Setting up users and alarms — the configuration of the platform — was very easy too.

There were some bottlenecks on our side, but including planning, it took three to four months. The platform was ready in three to four weeks and deploying all our customizations, all our use cases and alarms, was another month. 

The process required five people, including me. We had a project manager, as well as an OSS engineer who was responsible for the hardware and everything that we had to do in that regard — obtaining the hardware, network connectivity, etc. Two of us from network security were responsible for the goals of the platform, defining the use cases, and testing the platform. We also had support from the networking firewall team.

Maintaining the solution is less than half a full-time position. We have a team doing it, but nobody is directly dedicated to it. There are certain processes that that team follows so if we have an issue, we create a ticket and somebody from that team will sort it out.

Overall, we have 10 to 20 people using Devo across our organization. They are in security roles. Because we have a lot of data, some people use it for performance management, while other use it for fault management in the network for the devices. Management uses it to generate security-posture reports. At the moment, it's very security-oriented. So most of the users are security analysts in our group.

What was our ROI?

We have definitely saved time using Devo, but the greater visibility it gives us is really hard to quantify. Everybody's more effective, obviously. And the hardware costs are down compared to the other solution. Everybody feels it's a good value, especially in mitigating risk or attacks. With the greater visibility and the ability to aggregate and analyze data in a better way, we have better mitigation. We see the threats sooner or more in detail. We can do everything better.

What's my experience with pricing, setup cost, and licensing?

I'm not involved in the financial aspect, but I think the licensing costs are similar to other solutions. If all the solutions have a similar cost, Devo provides more for the money.

Because we are running an in-house solution, there is the extra cost for us, when compared to the cloud, in maintaining our own hardware, and the level-one and -two support we are doing. But we feel we won't need consultants in the future, which we needed with Splunk where we paid extra for a more defined platform and doing the work. Devo is very well-documented and the platform is very open.

Which other solutions did I evaluate?

There was a Splunk solution and Juniper branded product  that we looked at, along with some open-source solutions.

What other advice do I have?

My advice is to go with scrum Agile method for implementing it. It really works. They're did really good at it.

The biggest lesson I've learned from using Devo is that it is good, functioning software. And there's really good support.

I'm so happy with the platform. I've seen it go from pre-production to production. I was very happy with it in pre-production and I thought, "Okay, maybe when we start loading all the data, the complete set, maybe it will be different," but it's not. It does what it says on the tin. It really works for us.

I rate Devo at nine out of 10. They could be a 10. If they pushed us a little bit harder at the beginning so we actually come up with a more detailed plan for the integration of our sources, that could have made them a 10.

It's an upstart company and we really see great potential with them. They're updating the platform and they're adding a lot of features, features that matter to us, without us actually telling them we need them. So I think they really understand the market. They understand how modern software should work and how people work. It's really refreshing. You feel you're not limited by the platform. You're only limited by your imagination.

Which deployment model are you using for this solution?

On-premises
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Chris Bates
CISO at a computer software company with 501-1,000 employees
Real User
Top 5
Enables us to combine data from disparate sources and get real-time context, alerting, and visibility

Pros and Cons

  • "The thing that Devo does better than other solutions is to give me the ability to write queries that look at multiple data sources and run fast. Most SIEMs don't do that. And I can do that by creating entity-based queries. Let's say I have a table which has Okta, a table which has G Suite, a table which has endpoint telemetry, and I have a table which has DNS telemetry. I can write a query that says, 'Join all these things together on IP, and where the IP matches in all these tables, return to me that subset of data, within these time windows.' I can break it down that way."
  • "There's room for improvement within the GUI. There is also some room for improvement within the native parsers they support. But I can say that about pretty much any solution in this space."

What is our primary use case?

We're using Devo as an operations and security event management logging platform. We're shipping all of our log data and telemetry into Devo, including G Suite, Okta, GitHub, Zscaler, Office 365; pretty much all of our logging data is going into Devo. And we're using Devo to do some analytics and alerting and searching on that log data. The analytics are things like average, min/max, and counts on certain types of log data—performance metrics—for monitoring and uptime/downtime health.

How has it helped my organization?

Devo provides high-speed search capabilities and real-time analytics. Nowadays, everything is about the data analytics. Our infrastructure is many disparate things that have to work in unison to make something happen, and our security is various things, working in different ways, to make something happen. Being able to combine that data together and get real-time context and alerting and visibility into it is key. Prior, we'd have to go look in the G Suite log to find an authentication issue, and then we'd have to enrich that authentication issue with something from someplace else. Usually it would even be a separate person doing it. The old way of doing it was very problematic. Having one repository where the data is combined, and you can do the analytics and all the enrichments, saves a tremendous amount of time.

We benefit from the speed at which we can triage and troubleshoot things and get to the bottom of certain security events and issues. What used to take many minutes, and up to hours, to do, things like different API calls and gathering different data sources, is now streamed in real time as it happens, into Devo, and we can look at it.

As an example, I'm building profiles on analytics for GitHub, so that I know what normal access looks like for a GitHub repository and what abnormal access looks like for a GitHub repository. If someone modifies the GitHub repository in a way it shouldn't be changed, I know that right away. 

I also know if someone tries to access some of our internal repos or other SaaS solutions, without being on our Zero Trust networking. Those types of things really start to stand out. It takes a large amount of data to make those work from disparate systems, and troubleshooting them can be very problematic unless you have that data in a centralized location. So the speed at which we can operate our security stack is something we've gained.

It saves us hours a day. It really depends on what we're troubleshooting, but it has saved me hours on just the stuff I need to do. There's definitely a cost savings.

It provides more clarity for network, endpoint, and cloud visibility because we're pumping all our data into it. We're pumping DNS traffic data, Zero Trust data from Zscaler, all of the authentication data from Okta, Google, and O365, as well as the endpoint data from our own product. We can query all that data in a centralized manner, and correlate it in a certain manner. But that's because we're putting the data into it. Confidence in the actions needed is about context. Being able to get the most context, before you do something or make a decision, is better. The context we can get from having everything centralized, by combining all those data sources together, gives us an understanding of the complete picture of the issue and how long the issue has persisted. Then we can make a better decision on how we're going to solve things.

What is most valuable?

I like their query language and I like their speed. 

Ultimately what it comes down to for us is, "Can we write advanced queries that bind the different data sets together?" and that is what we're doing. We're able to do things like see an event, this IP or its DNS name here, and then search all our other log streams to also find it there, and then take data from there and search throughout other types of things.

What needs improvement?

There's room for improvement within the GUI. There is also some room for improvement within the native parsers they support. But I can say that about pretty much any solution in this space. Those are the standards where they need to improve because that's usually where they lag.

For how long have I used the solution?

We've been using Devo now for about six months.

What do I think about the stability of the solution?

There haven't been any major issues or hiccups since we deployed it.

What do I think about the scalability of the solution?

We bought a certain scale, a certain data-ingest-rate, and it's had no problem with that data-ingest-rate. From the PoC and the deep-dive we did, we know the system scales horizontally. We tested it. I'm quite confident that it can scale.

We're going to keep on throwing more and more data into it. After all the security data is in there, the next layer of data is going to be telemetry data from performance data. We'll monitor for things like network lag and system performance. The more operational data will be the next layer of data that goes in there, when we get there. That will probably be in the next three to six months. Right now we run on Elastic for the majority of that and we'll be looking at swapping over. It's just a matter of getting it planned out so there isn't an impact.

How are customer service and technical support?

Our experience with their technical support has been good, for the few times we've had to use it. We haven't had to use it very often, which is a good thing. Ben, who is my lead engineer, has contacted them and he has had no complaints. They've been responsive and answered. We also have them on Slack.

When talking about a customer-first approach, they're pretty good. They worked with us for the things we needed them to work with us on. They were understanding of timelines. They've been very forthcoming.

I have pretty high expectations, so I wouldn't say they have exceeded them, but they haven't disappointed me either. That's good. There are very few vendors about which I can say that.

Which solution did I use previously and why did I switch?

Prior to using Devo, we were using QRadar. We switched because when we looked at the data we wanted to throw at QRadar, it was going to fall over and blow up. The amount of money IBM wanted for that amount of data was absurd. It's a legacy system that operates and scales in a legacy way. It just can't really handle what we planned to throw at it, as we ramp up towards IPO, in our infrastructure.

How was the initial setup?

The initial setup was actually pretty easy. They give you something in a SaaS. You have instructions on how you start pointing data to it and the data starts going in there. Devo has the ability to auto-parse it in some way. It works well.

We were shipping production data into it, as part of our PoC, within a couple of days of starting. It didn't take very long.

Our implementation strategy was to identify the areas that had the most critical data that we wanted. We then went one-by-one through those areas and figured out how to get them into Devo, whether we were shipping them natively, API-to-API—like AWS—or whether we had to deploy the Devo collector, which was easy. The collector is just a VM, or an image. We deployed those images and started shipping the data in. Once the data was in, we started writing and tuning our own rule sets.

For the deployment, we had one SIEM engineer who was working on QRadar and I redeployed him on Devo. He had all of the data sources that were going into QRadar redirected into Devo within three or four days. He could have done it quicker if it wasn't for change management. It was really not an administrative burden at all to deploy.

As for maintenance, it's SaaS service. We're just running the SIEM as operators. We have a full-time guy who is a SIEM engineer, but a lot of his job isn't maintaining the tool. His job is more one of continuing to drive additional value out of the tool. That means writing more and more advanced rule sets, correlations, and analytics, more than anything else.

There are about 10 to 15 people who have access to Devo in our company, including security research people who are looking for trending there. Our IR and threat-hunting and security teams have access to it and our SRE team has access because we're also shipping some of our SRE telemetry into it.

What was our ROI?

We've seen ROI, just from the time savings alone. I can't say we have recovered what we spent on it, but our staff is absolutely spending less time doing certain things, and getting more things done within the time they have, using the tool. 

What's my experience with pricing, setup cost, and licensing?

Devo's licensing model, given that they only charge for ingestion, is fine. It's risky to them, but I'm assuming they're going to manage that. If I'm ingesting a little bit of data, but I'm running a ton of queries on said data, it's going to be much more expensive for them. Whereas, if I ingest a ton of data and query every Nth period of time, then they will make more money off of it.

Support was included in our licensing.

Which other solutions did I evaluate?

We looked at Humio and Splunk. Splunk was too expensive, so we ruled them out right away. Devo was the only one we went all the way through the hoops with.

Devo is on par with Splunk. It's definitely farther ahead than Humio was. Splunk has more apps, more integrations, because it's been around longer and it's bigger, but ultimately the querying language is as useful. They're different, but there's nothing I can do in Splunk that I can't do in Devo. Once I learn the language, they're equivalent. There isn't anything necessarily better with Devo, but Splunk is kind of an old standard, when it comes to threat hunting.

Devo is definitely cheaper than Splunk. There's no doubt about that. The value from Devo is good. It's definitely more valuable to me than QRadar or LogRhythm or any of the old, traditional SIEMs. Devo is in the next gen of cloud SIEMs that are coming. I think Devo plans to disrupt Splunk, or at least take a slice of the pie.

I wouldn't say that Devo ingests more data compared to any other solutions. But the thing that Devo does better than other solutions is to give me the ability to write queries that look at multiple data sources and run fast. Most SIEMs don't do that. And I can do that by creating entity-based queries. Let's say I have a table which has Okta, a table which has G Suite, a table which has endpoint telemetry, and I have a table which has DNS telemetry. I can write a query that says, "Join all these things together on IP, and where the IP matches in all these tables, return to me that subset of data, within these time windows." I can break it down that way. That entity-based querying, where you're creating an entity that's complex, is much more powerful than the old legacy vendors. You can do it with Splunk, but with Splunk you have to specify the indexing upfront, so that it's indexed correctly. With Devo, the way it lays it out on disk, as long as you know what you want and you tell them what you want laid out on disk, it tends to work better.

I've been happy with Devo. They're a smaller company, so they're more hungry for your business than, say, a Splunk. They're more willing to work with you and be customer-focused than a Splunk is, for sure. And that's the same with QRadar or any other big ones. That's a plus.

What other advice do I have?

Be very realistic about what you want to send into it and make sure that you have use cases for sending data to it, but that's the same anywhere. One of the problems that a lot of people have is that with the old SIEM you sent all of your data and then figured out a use case for it afterwards. I'm much more of a firm believer in figuring out the use cases and then sending the data.

Make sure you have the data you're going to be shipping into it well documented. Don't, by default, take everything you're shipping in your SIEM and ship it to Devo. That's probably not the best use of your time.

Also, really start thinking about complex use cases, things like "If A and B and C happened, but A, B, and C are on different data sources, then tell me that there's a problem." That's not something you used to be able to do on a traditional SIEM, or at least not very effectively. So start thinking about the more complex data analytics use cases to improve your learning and your logic. That's really the power of Devo.

It's pretty easy to use. My guys have had no problem getting up to speed on it. I wouldn't say it's easier to use than some of the others, but it's as easy to use. Once you learn the language, you can start writing the rule sets, and you can actually have the GUI show you the language it is using. So, we have had no issues in that regard. It's well-documented.

The trending we're interested in is not the 400-day rolling window that Devo provides. We use a six-month rolling window for audit and/or investigative purposes. If we find something, we can go back and look at it very quickly to see how long it has been happening in our environment. We haven't really been historically trending over more than six months. Eventually we may expand into using the 400 days, but right now we're focused more on blocking and tackling, which requires shorter windows.

Overall, I have no issues with it and my guys love it.

Devo is what we thought it would be when we bought it. It's basically a high-speed analytics engine that allows us to query our data at speed and scale, and combine it together. That was the whole purpose, and it is what it is. We had a very mature idea of what we wanted when we went looking.


Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Jordan Mauriello
SVP of Managed Security at CRITICALSTART
MSP
Top 10
Be cautious of metadata inclusion for log types in pricing. Having the ability to do real-time analytics drives down attacker dwell time.

Pros and Cons

  • "The ability to have high performance, high-speed search capability is incredibly important for us. When it comes to doing security analysis, you don't want to be doing is sitting around waiting to get data back while an attacker is sitting on a network, actively attacking it. You need to be able to answer questions quickly. If I see an indicator of attack, I need to be able to rapidly pivot and find data, then analyze it and find more data to answer more questions. You need to be able to do that quickly. If I'm sitting around just waiting to get my first response, then it ends up moving too slow to keep up with the attacker. Devo's speed and performance allows us to query in real-time and keep up with what is actually happening on the network, then respond effectively to events."
  • "There is room for improvement in the ability to parse different log types. I would go as far as to say the product is deficient in its ability to parse multiple, different log types, including logs from major vendors that are supported by competitors. Additionally, the time that it takes to turn around a supported parser for customers and common log source types, which are generally accepted standards in the industry, is not acceptable. This has impacted customer onboarding and customer relationships for us on multiple fronts."

What is our primary use case?

We use Devo as a SIEM solution for our customers to detect and respond to things happening in their environment. We are a service provider who uses Devo to provide services to our customers.

We are integrating from a source solution externally. We don't exclusively work inside of Devo. We kind of work in our source solution, pivoting in and back out.

How has it helped my organization?

With over 400 days of hot data, we can query and look for patterns historically. We can pivot into past data and look for trends and analytics, without needing to have a change in overall performance nor restore data from cold or frozen data archives to get answers about things that may be long-term trends. Having 400 days of live data means that we can do analytics, both short-term and long-term, with high speed.

The integration of threat intelligence data absolutely provides context to an investigation. Threat intelligence integration provides great contextual data, which has been very important for us in our investigation process as well. The way that the data is integrated and accessible to us is very useful for security analysts. The ability to have the integration of large amounts of threat intelligence data and provide that context dynamically with real time correlation means that, as analysts, we are seeing events as they're happening in customer environments. We are getting the context of whether that is related to something that we're also watching from a threat intelligence perspective, which can help shape an investigation.

What is most valuable?

The ability to have high performance, high-speed search capability is incredibly important for us. When it comes to doing security analysis, you don't want to be sitting around waiting to get data back while an attacker is sitting on a network, actively attacking it. You need to be able to answer questions quickly. If I see an indicator of attack, I need to be able to rapidly pivot and find data, then analyze it and find more data to answer more questions. You need to be able to do that quickly. If I'm sitting around just waiting to get my first response, then it ends up moving too slow to keep up with the attacker. Devo's speed and performance allows us to query in real-time and keep up with what is actually happening on the network, then respond effectively to events.

The solution’s real-time analytics of security-related data does incredibly well. I think all the SIEM solutions have struggled to be truly real-time, because there are events that happen out in systems and on a network. However, when I look at its overall performance and correlation capabilities, and its ability to then analyze that data rapidly, it has given us performance, which is exceptional.

It is incredibly important in security that the real-time analytics are immediately available for query after ingest. One of the most important things that we have to worry about is attacker dwell time, e.g., how long is an attacker allowed to sit on a system after it is compromised and discover more data, then compromise more systems on a network or expand what they currently have. For us, having the ability to do real-time analytics essentially drives down attacker dwell time because we're able to move quickly and respond more effectively. Therefore, we are able to stop the attacker sooner during the attack lifecycle and before it becomes a problem.

The solution speed is excellent for us, especially in regards to attacker dwell time and the speed that we're able to both discover and analyze data as well as respond to it. The fact that the solution is high performance from a query perspective is very important for us.

Another valuable feature would be detection capability. The ability to write high quality detection rules to do correlation in an advanced manner that really works effectively for us. Sometimes, the correlation in certain engines can be hampered by performance, but it also can be affected by an inability to do certain types of queries or correlate certain types of data together. The flexibility and power of Devo has given us the ability to do better detection, so we have better detection capabilities overall.

The UI is very good. They have an implementation of CyberChef, which is very good for security analysts. It allows us to manipulate, transform, and enrich data for analytics in a very fast, effective manner. The query UI is something that most people who have worked with SIEM platforms will be very used to utilizing. It is very similar to things that they've seen before. Therefore, it's not going to take them a long time to learn their way around the platform.

The pieces of the Activeboards that are built into SecOps have been very good and helpful for us.

They have high performance and high-speed search as well as the ability to pivot quickly. These are the things that they do well.

What needs improvement?

There is room for improvement in the ability to parse different log types. I would go as far as to say the product is deficient in its ability to parse multiple, different log types, including logs from major vendors that are supported by competitors. Additionally, the time that it takes to turn around a supported parser for customers and common log source types, which are generally accepted standards in the industry, is not acceptable. This has impacted customer onboarding and customer relationships for us on multiple fronts.

I would like to see Devo rely more on the rules engine, seeing more things from the flow, correlation, and rules engine make its way into the standardized product. This would allow a lot of those pieces to be a part of SecOps so we can do advanced JOIN rules and capabilities inside of SecOps without flow. That would be a great functionality to add.

Devo's pricing mechanism, whereby parsed data is charged after metadata is added to the event itself, has led to unexpected price increases for customers based on new parsers being built. Pricing has not been competitive (log source type by log source type) with other vendors in the SEMP space.

Their internal multi-tenant architecture has not mapped directly to ours the way that it was supposed to nor has it worked as advertised. That has created challenges for us. This is something they are still actively working on, but it is not actually released and working, and it was supposed to be released and working. We got early access to it in the very beginning of our relationship. Then, as we went to market with larger customers, they were not able to enable it for those customers because it was still early access. Unfortunately, it is still not generally available for them. As a result, we don't get to use it to help get improvements on multi-tenant architecture for us.

For how long have I used the solution?

I have been using the solution for about a year.

What do I think about the stability of the solution?

Stability has been a little bit of a problem. We have had stability problems. Although we have not experienced any catastrophic outages within the platform, there have been numerous impacts to customers. This has caused a degradation of service over time by impacting customer value and the customer's perception of value, both from the platform and our service as a service provider.

We have full-time security engineers who do maintenance work and upkeep for all our SIEM solutions. However, that may be a little different because we are a service provider. We're looking at multiple, large deployments, so that may not be the same thing that other people experience.

What do I think about the scalability of the solution?

We haven't run into any major scalability problems with the solution. It has continued to scale and perform well for query. The one scalability problem that we have encountered has to do with multi-tenancy at scale for solutions integrating SecOps. Devo is still working to bring to market these features to allow multi-tenancy for us in this area. As a result, we have had to implement our own security, correlation rules, and content. That has been a struggle at scale for us, in comparison to using quality built-in, vendor content for SecOps, which has not yet been delivered for us.

There are somewhere between 45 to 55 security analysts and security engineers who use it daily.

How are customer service and technical support?

Technical support for operational customers has been satisfactory. However, support during onboarding and implementation, including the need for professional services engagements to develop parsers for new log types and troubleshoot problems during onboarding, has been severely lacking. Often, tenant set times and support requests during onboarding have gone weeks and even months without resolution, and sometimes without reply, which has impacted customer relationships.

Which solution did I use previously and why did I switch?

While we continue to use Splunk as a vendor for the SIEM services that we provide, we have also added Devo as an additional vendor to provide services to customers. We have found similar experiences at both vendors from a support perspective. Although professional services skill level and availability might be better at Devo, the overall experience for onboarding and implementing a customer is still very challenging with both.

How was the initial setup?

The deployment was fairly straightforward. For how we did the setup, we were building an integration with our product, which is a little more complicated, but that's not what most people are going to be doing. 

We were building a full integration with our platform. So, we are writing code to integrate with the APIs.

Not including our coding work that we had to do on the integration side, our deployment took about six weeks.

What about the implementation team?

It was just us and Devo's team building the integration. Expertise was provided from Devo to help work through some things, which was absolutely excellent.

What was our ROI?

In incidents where we are using Devo for analysis, our mean time to remediation for SIEM is lower. We're able to query faster, find the data that we need, and access it, then respond quicker. There is some ROI on query speed.

What's my experience with pricing, setup cost, and licensing?

Based on adaptations that they have made, where they are essentially charging for metadata around events that we collect now, that extra charge makes up any difference in price savings between Splunk or Azure Sentinel and them. 

Before, the cost was just the data itself, but they have adjusted it now where they even charge if we parse the data and add in names for a field that comes in. For example, we get a username. If you go to log into Windows, and it says, "That username tried to log in." Then, it labels the username with your name. They will charge us for the space that username takes up when they label it. On top of that, this has caused us to lose all of the price savings that were being found before. In fact, in some cases, it is more expensive than the competitors as a result. The charging for metadata on parsed fields has led to significant, unexpected pricing for customers.

Be cautious of metadata inclusion for log types in pricing, as there are some "gotchas" with that. This would not be charged by other vendors, like Splunk, where you are getting Windows Logs. Windows Logs have a bunch of blank space in them. Essentially, Splunk just compresses that. Then, after they compress and label it, that is the parse that you see, but they don't charge you for the white space. They don't charge you for the metadata. Whereas, Devo is charging you for that. There are some "gotchas" there around that. We want to point, "Pay attention to ingest charges for new data types, as you will be charged for metadata as a part of the overall license usage." 

There are charges for metadata, as Devo counts data after parsing and enrichment. It charges it against license usage, whereas other vendors charge the license before parsing and enrichment, e.g., you are looking at the raw, compressed, data first, then they parse and enrich it, and you don't get charged for that part. That difference is hitting some of our customers in a negative way, especially when there is an unparsed log type. They don't support it. One that is not supported right now is Cisco ASA, which should be supported as it is a major vendor out there. If a customer says, "Well, in Splunk, I'm currently bringing 50 gigabytes of Cisco ASA logs," but then they don't consider the fact that this adds 25% metadata in Splunk. Now, when they shift it over to Devo, it will actually be a 25% increase. They are going to see 62.5 gigs now when they move it over, because they are going to get charged for the metadata that they weren't being charged for in Splunk. Even though the price per gig is lower with Devo, by charging more for the metadata, i.e., by charging more gigs in the end, you are ending up either net neutral or even sometimes saving, if there is not a lot of metadata. Then, sometimes you are actually losing money in events that have a ton of metadata, because you are increasing it sometimes by as much as 50%. 

I have addressed this issue with Devo all the way to the CEO. They are not unaware. I talked to everyone, all the way up the chain of command. Then, our CEO has been having a direct call with their CEO. They have had a biweekly call for the last six weeks trying to get things moving forward in the right direction. Devo's new CEO is trying very hard to move things in the right direction, but customers need to be aware, "It's not there yet." They need to know what they are getting into.

Which other solutions did I evaluate?

We evaluated Graylog as well as QRadar as potential options. Neither of those options met our needs or use cases.

What other advice do I have?

No SIEM deployment is ever going to be easy. You want to attack it in order of priorities for what use cases matter to your business, not just log sources.

The Activeboards are easy to understand and flexible. However, we are not using them quite as much as maybe other people are. However, we are not using them quite as much as other people are. I would suggest investment in developing and working with Activeboards. Wait for a general availability release of SecOps to all your customers for use of this, as a SIEM product, if you lack internal SIEM expertise to develop correlation rules and content for Devo on your own.

I would rate this solution as a five out of 10.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Other
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Flag as inappropriate
SM
Product Director at a insurance company with 10,001+ employees
Real User
Top 20
Gives us a single, integrated tool to simplify support and reduce downtime

Pros and Cons

  • "Those 400 days of hot data mean that people can look for trends and at what happened in the past. And they can not only do so from a security point of view, but even for operational use cases. In the past, our operational norm was to keep live data for only 30 days. Our users were constantly asking us for at least 90 days, and we really couldn't even do that. That's one reason that having 400 days of live data is pretty huge. As our users start to use it and adopt this system, we expect people to be able to do those long-term analytics."
  • "One major area for improvement for Devo... is to provide more capabilities around pre-built monitoring. They're working on integrations with different types of systems, but that integration needs to go beyond just onboarding to the platform. It needs to include applications, out-of-the-box, that immediately help people to start monitoring their systems. Such applications would include dashboards and alerts, and then people could customize them for their own needs so that they aren't starting from a blank slate."

What is our primary use case?

We look at this solution for both security monitoring and operational monitoring use cases. It helps us to understand any kinds of security incidents, typical-scene use cases, and IT operations, including DevOps and DevSecOps use cases.

How has it helped my organization?

We had multiple teams that were managing multiple products. We had a team that was managing ELK and another team that was managing ArcSight. My team was the "data bus" that was aggregating the onboarding of people, and then sending logs through different channels. We had another team that managed the Kafka part of things. There was a little bit of a loss of ownership because there were so many different teams and players. When an issue happened, we had to figure out where the issue was happening. Was it in ELK? Was it in ArcSight? Was it in Kafka? Was it in syslog? Was it on the source? As a company, we have between 25,000 and 40,000 sources, depending on how you count them, and troubleshooting was a pretty difficult exercise. Having one integrated tool helped us by removing the multiple teams, multiple pieces of equipment, and multiple software solutions from the equation. Devo has helped a lot in simplifying the support model for our users and the sources that are onboarding.

We have certainly had fewer incidents, fewer complaints from our users, and less downtime.

Devo has definitely also saved us time. We have reduced the number of teams involved. Even though we were using open-source and vendor products, the number of teams that are involved in building and maintaining the product has been reduced, and that has saved us time for sure. Leveraging Devo's features is much better than building everything.

What is most valuable?

It provides multi-tenant, cloud-native architecture. Both of those were important aspects for us. A cloud-native solution was not something that was negotiable. We wanted a cloud-native solution. The multi-tenant aspect was not a requirement for us, as long as it allowed us to do things the way we want to do them. We are a global company though, and we need to be able to segregate data by segments, by use cases, and by geographical areas, for data residency and the like.

Usability-wise, Devo is much better than what we had before and is well-positioned compared to the other tools that we looked at. Obviously, it's a new UI for our group and there are some things that, upon implementing it, we found were a little bit less usable than we had thought, but they are working to improve on those things with us.

As for the 400 days of hot data, we have not yet had the system for long enough to take advantage of that. We've only had it in production for a few months. But it's certainly a useful feature to have and we plan to use machine learning, long-term trends, and analytics; all the good features that add to the SIEM functionality. If it weren't for the 400 days of data, we would have had to store that data, and in some cases for even longer than 400 days. As a financial institution, we are usually bound by regulatory requirements. Sometimes it's a year's worth of data. Sometimes it's three years or seven years, depending on the kind of data. So having 400 days of retention of data, out-of-the-box, is huge because there is a cost to retention.

Those 400 days of hot data mean that people can look for trends and at what happened in the past. And they can not only do so from a security point of view, but even for operational use cases. In the past, our operational norm was to keep live data for only 30 days. Our users were constantly asking us for at least 90 days, and we really couldn't even do that. That's one reason that having 400 days of live data is pretty huge. As our users start to use it and adopt this system, we expect people to be able to do those long-term analytics.

What needs improvement?

One major area for improvement for Devo, and people know about it, is to provide more capabilities around pre-built monitoring. They're working on integrations with different types of systems, but that integration needs to go beyond just onboarding to the platform. It needs to include applications, out-of-the-box, that immediately help people to start monitoring their systems. Such applications would include dashboards and alerts, and then people could customize them for their own needs so that they aren't starting from a blank slate. That is definitely on their roadmap. They are working with us, for example, on NetFlow logs and NSG logs, and AKF monitoring.

Those kinds of things are where the meat is because we're not just using this product for regulatory requirements. We really want to use it for operational monitoring. In comparison to some of the competitors, that is an area where Devo is a little bit weak.

For how long have I used the solution?

We chose Devo at the end of 2020 and we finished the implementation in June of this year. Technically, we were using it during the implementation, so it has been about a year.

I don't work with the tool on a daily basis. I'm from the product management and strategy side. I led the selection of the product and I was also the product manager for the previous product that we had.

What do I think about the stability of the solution?

Devo has been fairly stable. We have not had any major issues. There has been some down time or slowness, but nothing that has persisted or caused any incidents. One place that we have a little bit of work to do is in measuring how much data is being sent into the product. There are competing dashboards that keep track of just how much data is being ingested and we need to resolve which we are going to use.

What do I think about the scalability of the solution?

We don't see any issues with scalability. It scales by itself. That is one of the reasons we also wanted to move to another product. We needed scalability and something that was auto-scalable.

How are customer service and support?

Their tech support has been excellent. They've worked with us on most of the issues in a timely fashion and they've been great partners for us. We are one of their biggest customers and they are trying really hard to meet our needs, to work with us, and to help us be successful for our segments and users.

They exceeded our expectations by being extremely hands-on during the implementation. They came in with an "all hands on deck" kind of approach. They worked through pretty much every problem we had and, going forward, we expect similar service from them.

Which solution did I use previously and why did I switch?

We were looking to replace our previous solution. We were using ArcSight as our SIEM and ELK for our operational monitoring. We needed something more modern and that could fulfill the roadmap we have. We were also very interested in all the machine learning and AI-type use cases, as forward-facing capabilities to implement. In our assessment of possible products, we were impressed by the features of AI/ML and because the data is available for almost a year. With Devo, we integrated both operational and SIEM functions into one tool.

It took us a long time to build and deploy some of the features we needed in the previous framework that we had. Also, having different tools was leading to data duplication in two different platforms, because sometimes the security data is operational data and vice versa. The new features that we needed were not available in the SIEM and they didn't have a proper plan to get us there. The roadmap that ArcSight had was not consistent with where we wanted to go.

How was the initial setup?

It was a complex setup, not because the system itself is complex but because we already had a system in place. We had already onboarded between 15,000 and 20,000 servers, systems, and applications. Our requirement was to not touch any of our onboarding. Our syslog was the way that they were going to ingest and that made it a little bit easier. And that was also one of our requirements because we always want to stay vendor-agnostic. That way, if we ever need to change to another system, we're not going to have to touch every server and change agents. "No vendor tie-in" is an architectural principle that we work with.

We were able to move everything within six months, which is absolutely amazing. That might be a record. Not only Devo was impressed at how efficiently we did it, but so were people in our company.

We had a very strong team on our end doing this. We went about it very clinically, determining what would be in scope and what would not be in scope for the first implementation. After that, we would continue to tie up any loose ends. We were able to meet all of our deadlines and pivot into Devo. At this point, Devo is the only tool we're using.

We have a syslog team that is the log aggregator and an onboarding team that was involved in onboarding the solution. The syslog team does things like the opening of ports and metrics of things like uptime. We also have four engineers on the security side who are helping to unleash use cases and monitor security. There's also a whole SOC team that does incident management and finding of breaches. And we have three people who are responsible for the operational reliability of Devo. Because it's a SaaS product, we're not the ones running the system. We're just making sure that, if something goes wrong, we have people who are trained and people who can troubleshoot.

We had an implementation project manager who helped track all of the implementation milestones. Our strategy was to set out an architecture to keep all the upstream components intact, with some very minor disruptions. We knew, with respect to some sources, that legacy had been onboarded in certain ways that were not efficient or useful. We put some of those pieces into the scope during the implementation so that we would segregate sources in ways that would allow better monitoring and better assessment, rather than mixing up sources. But our overall vision for the implementation was to keep all of that upstream architecture in place, and to have the least amount of disruption and need for touching agents on existing systems that had already been onboarded. Whatever was onboarded was just pointed at Devo from syslog. We did not use their relays. Instead, we used our syslog as the relays.

What's my experience with pricing, setup cost, and licensing?

Devo was very cost-competitive. We understood that the cost came without the monitoring of content, right out-of-the-box, but we knew they were pointed in that direction.

Devo's pricing model, only charging for ingestion, is how most products are licensed. That wasn't different from other products that we were looking at. But Devo did come with that 400 days of hot data, and that was not the case with other products. While that aspect was not a requirement for us, it was a nice-to-have.

Which other solutions did I evaluate?

We started off with about 10 possibilities and brought it down to three. Devo was one of the three, of course, but I prefer not to mention the names of the others.

But among those we started off with were Elastic, ArcSight, Datadog, Sumo, Splunk, Microsoft systems and solutions, and even some of the Google products. One of our requirements was to have an integrated SIEM and operational monitoring system.

We assessed the solutions at many different levels. We looked at adherence to our upstream architecture for minimal disruption during the onboarding of our existing logs. We wanted minimal changes in our agents. We also assessed various use cases for security monitoring and operational monitoring. During the PoC we assessed their customer support teams. We also looked at things like long-term storage and machine learning. In some of these areas other products were a little bit better, but overall, we felt that in most of these areas Devo was very good. Their customer interface was very nice and our experience with them at the proof-of-value [PoV] level was very strong. 

We also felt that the price point was good. Given that Devo was a newer product in the market, we felt that they would work with us on implementing it and helping us meet our roadmap. All three products that we looked for PoV had good products. This space is fairly mature. They weren't different in major ways, but the price was definitely one of the things that we looked at.

In terms of the threat-hunting and incident response, Devo was definitely on par. I am not a security analyst and I relied on our SIEM engineers to analyze that aspect.

What other advice do I have?

Get your requirements squared and know what you're really looking for and what your mandatory requirements are versus what is optional. Do a proof of value. That was very important for us. Also, don't only look at what your needs are today. Long-term analytics, for example, was not necessarily something we were doing, but we knew that we would want to do that in the coming years. Keep all of those forward-looking use cases in mind as well when you select your product.

Devo provides high-speed search capabilities and real-time analytics, although those are areas where a little performance improvement is needed. For the most part it does well, and they're still optimizing it. In addition, we've just implemented our systems, so there could be some optimizations that need to be done on our end, in the way our data is flowing and in the way we are onboarding sources. I don't think we know where the choke points are, but it could be a little bit faster than we're seeing right now.

In terms of network visibility, we are still onboarding network logs and building network monitoring content. We do hope that, with Devo, we will be able to retire some of our network monitoring tools and consolidate them. The jury is still out on whether that has really happened or not. But we are working actively towards that goal.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Flag as inappropriate
JayGrant
Manager of Security Services at OpenText
MSP
Top 5
We can build Activeboards that can do queries across multiple different types of data sources with one query

Pros and Cons

  • "Being able to build and modify dashboards on the fly with Activeboards streamlines my analyst time because my analysts aren't doing it across spreadsheets or five different tools to try to build a timeline out themselves. They can just ingest it all, build a timeline out across all the logging, and all the different information sources in one dashboard. So, it's a huge time saver. It also has the accuracy of being able to look at all those data sources in one view. The log analysis, which would take 40 hours, we can probably get through it in about five to eight hours using Devo."
  • "Their documentation could be better. They are growing quickly and need to have someone focused on tech writing to ensure that all the different updates, how to use them, and all the new features and functionality are properly documented."

What is our primary use case?

I run an incident response, digital forensics team for OpenText. We do investigations into cyber breaches, insider threats, network exploitation, etc. We leverage Devo as a central repository to bring in customer logging in a multi-tenant environment to conduct analysis and investigations.

We have a continuous monitoring customer for whom we stream all of their logging in on sort of a traditional Devo setup. We build out the active boards, dashboards, and everything else. The customer has the ability to review it, but we review it as well, acting as a security managed service offering for them. 

We use Devo in traditional ways and in some home grown ways.

For example, if there is a current answer response, I need to see what's going on in their environment. Currently, I'll stream logs from the syslog into Devo and review those. For different tools that we use to do analytics and forensics, we'll parse those out and send that up to Devo as well. We can correlate things across multiple forensic tools against log traffic, network traffic, and cloud traffic. We can do it all with Devo.

It's all public cloud, multi-factor authentication, and multi-tenant. We have multiple tenants built in as different customers, labs, etc. Devo has us set up in their cloud, and we leverage their instance.

We are using their latest version.

How has it helped my organization?

Being able to build and modify dashboards on the fly with Activeboards streamlines my analyst time because my analysts aren't doing it across spreadsheets or five different tools to try to build a timeline out themselves. They can just ingest it all, build a timeline out across all the logging, and all the different information sources in one dashboard. So, it's a huge time saver. It also has the accuracy of being able to look at all those data sources in one view. The log analysis, which would take 40 hours, we can probably get through it in about five to eight hours using Devo.

When you deal with logs, a lot of times the log fields from different vendors have partial data. For instance, an endpoint log may have the domain user name as Jay Grant, whereas the network log has it as example.com/jaygrant. Because of the way that you can manipulate the log sources and do the search, you can do a search for Jay Grant across all these log sources, even though the fields are a bit different. That is something very difficult to do in a one-off scenario, where you are able to do it with Devo. Then, once you have things built out on the Activeboards, you can build out alerts and build off automation processes where you can right click and execute other tools to run based on data sets that you found.

As far as reporting to our customers, it gives us time back where traditionally we would have to sit and write out written reports and take snapshots to illustrate things to our customer. It's easy so I can give role based access to my customer directly to the data. I can render it to them, visualizing it in the way that we want them to see it, and they're able to export that out on their own. It sort of takes away the need for my analysts to write reports like they have in the past. We can have the customer's log write and render results in real-time without stopping and writing reports, then picking up analysis again. It's easily saved us 60 percent of time from a log analysis, correlation, and timeline perspective.

I can bring cloud, on-prem, a static security tool, and static forensic tools in it. This has greatly affected our visibility into key business functions. It's a cross correlation of real-time data that's coming in, investigative data findings, being able to overlay it and see it in real-time, and what's going on based on the investigative findings that we've had.

What is most valuable?

The Activeboards are the most valuable feature. Given multiple different types of unstructured and structured data, we can then build Activeboards that can do queries across all those data sources with one query, being able to visualize the data from multiple different sources. That is probably the most useful thing that we find in Devo.

The visual analytics are extremely easy to understand. You have to learn how the queries need to be built and how to do that in an effective manner, but once you have someone trained in how to do the queries and Activeboards, it's very easy for that person to build them and render the data in whatever manner you need. If I bring in forensic memory analysis, forensic hard drive analysis, and network data, I can point it to specific fields in each of those logs and have it correlated altogether.

The solution is very nice because of the Activeboards that we build out. It's multi-tenant and easy for us to pull the code into other tenants and leverage them for other customers. From an attack perspective, Devo also allows us to scan across multiple tenant environments to see if the same attack is occurring towards multiple different customers. Then, it also keeps their data isolated from each other in compliance conformity. This is a huge factor for us, and one of the reasons why we looked at Devo originally. They were the only ones that we saw who offered that multi-tenant environment.

Devo manages 400 days of hot data, which is obviously great because you have the ability to go back in logs and correlate against things that you've seen. If you have a web attack come in on day 300, you can go back across all the logs with Activeboards and look for that same artifact for almost a year's time. So, it's very effective in what it can do. Depending on the logs themselves, it could be even longer than those 400 days. It just depends on how deep and rich those logs are.

I like the UI. It's simple to use. When you get into the advanced features, once you have some training, it's very easy to toggle around. But, even from a novice standpoint, you can definitely get in there, find information and data that you're looking for, and everything else, which is good.

What needs improvement?

The only downfall that I have is it is browser based. So, when you start doing some larger searches, it will cause the browser to lock up or shut down. You have to learn the sweet spot of how much data you can actually search across. The way that we found around that is to build out really good Activeboards, then it doesn't render as much data to the browser. That's the work around that we use. As far as ingestion, recording, and keeping it, I've seen no issues.

It comes down to some feature requests here and there, which is normal stuff with software. As a user, I may want to scroll through the filters, but the filter didn't allow scrolling at first. That's a feature that came in with version 6. 

For how long have I used the solution?

We've been playing around with it since June and had it fully deployed since August.

What do I think about the stability of the solution?

I've had no stability issues. 

What do I think about the scalability of the solution?

Scaling has been easy. It's cloud, so you just keep dumping data at it. I haven't seen any issues.

I have six or seven people who maintain and log into it, using it for analysis and everything else. Everyone is capable of doing the same thing on it. We also have customers who log into it to look at their data. There are about 25 people who have access over all the tenants.

It's definitely being fully utilized. It is a core tool for us in looking at logs, because logs are the starting point in any investigation. So, leveraging Devo from start to finish in any investigation is basically what we do.

How are customer service and technical support?

Their tech support is average. You are going to open up a ticket and wait a while. They need to go through their scripts, like everyone else. If there is an issue, you have to push to have it escalated, then go from there. 

The support is average, but the Professional Services is above average.

Two areas of improvement would be their tech support and documentation. Their documentation could be better. They are growing quickly and need to have someone focused on tech writing to ensure that all the different updates, how to use them, and all the new features and functionality are properly documented. 

Which solution did I use previously and why did I switch?

I've used a ton of other solutions: ELK Stack, Kibana, and Splunk. The cost of Devo, as it relates to Splunk, is significantly less with higher value. Its capabilities of ingesting so many different types of structured and unstructured data beats out the other tools that I've used. The pre-built parsers also beat out what we've used. Overall, it's far more advanced and user-friendly than the other competitive log analysis and SIEM tools. I've used these tools at OpenText and in different roles as well.

We're on the professional services side. This isn't OpenText IT services. This is us providing service to customers who are doing investigations. As investigators, we use whatever tool is out there that's best-of-breed. We came across Devo, then PoC'd and liked it. That's why we brought it into the toolbox.

How was the initial setup?

The initial setup is easy. They just send you your credentials, you log in and go to their user docs, grab the relay, bring it down, and you can point the data to it. Or, you could do direct ingestion of CSV files or other data sources directly to the cloud. Setup-wise, there's very little that you actually have to set up.

Anytime we deploy into an environment, we could have a relay setup in 20 to 30 minutes.

What about the implementation team?

We PoC'd the tool, then I built my own deployment strategy as to how my team leverages it, as we leverage it in a different manner than its intended use. 

I was the one that designed and deployed it. It took me maybe a day or two to come up with the exact way that I wanted it to be done and create a document for my team.

We initially had 40 hours of Professional Services that we leveraged to do some customized things that we wanted done. Every customer gets those Professional Services hours with their purchase just to get through the little nuances that are different in every environment. Their Professional Services team was excellent, very responsive, and for anything that we needed, the turnaround time was minimal. So, it was good.

What was our ROI?

The solution has definitely decreased our MTTR. The faster you can get through data, the faster you can get to the actual root cause and remediation. Identifying a root cause, cuts time down in half by maybe 50 percent. As far as getting to remediation, I'd put it at about the same.

We have seen ROI. It's the fact of having a tool that you can build a repeatable process off of for your analysts. To be able to provide repeatable investigative capabilities is a big return on investment for us.

What's my experience with pricing, setup cost, and licensing?

It's a per gigabyte cost for ingestion of data. For every gigabyte that you ingest, it's whatever you negotiated your price for. Compared to other contracts that we've had for cloud providers, it's significantly less.

Which other solutions did I evaluate?

We have used everything out there. We have used Splunk, ArcSight, and LogRhythm. We've used all those tools. We have leveraged them from customer environments and used them as tools. So, we have exposure to all of those.

Devo is used on every investigation that we do. It's a core tool for us. Without Devo, it would be very difficult for my analysts to do the same investigation from a threat hunt or incident response perspective repeatedly. Because we're consistently using the same tool, we consistently know how it's setup. We've set it up that way. So, it's very easy for us, customer-to-customer, to repeat the process. Whereas, if I had LogRhythm with one customer, then Splunk with another customer, it's not a repeatable process.

What other advice do I have?

Definitely get training and professional services hours with it. It is one of those tools where the more you know, the more you can do. Out-of-the-box, there is a lot of stuff that you can just do with very little training. However, to get to the really cool features and setups, you'll need the training and a bit of front-end assistance to make sure it's customized for your environment the right way.

You need to have a tool of this capability in your environment, whether you're providing service for someone else or if it's your own internal environment that you're working in. It is a core piece of functionality.

I would rate the solution between an eight point five and nine (out of 10). The only two things that stop it from getting a 10 are they need to improve their documentation and customer service. That's just customer service from the standpoint of support. It's just your generic, outsourced, call in support, where they read through a script, and go, "Did you try this? Or, did you try that?" Then, open up a ticket, and you're waiting for a period of time. If they can improve their support process and documentation, they would very easily push towards a 10.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Other
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Gabe Martinez
CEO at Analytica 42
Reseller
Devo helps organizations save money and become more efficient by providing a scalable, cost-effective, cloud-based logging and security analytics platform.

Pros and Cons

  • "Devo provides a multi-tenant, cloud-native architecture. This is critical for managed service provider environments or multinational organizations who may have subsidiaries globally. It gives organizations a way to consolidate their data in a single accessible location, yet keep the data separate. This allows for global views and/or isolated views restricted by access controls by company or business unit."
  • "Some basic reporting mechanisms have room for improvement. Customers can do analysis by building Activeboards, Devo’s name for interactive dashboards. This capability is quite nice, but it is not a reporting engine. Devo does provide mechanisms to allow third-party tools to query data via their API, which is great. However, a lot of folks like or want a reporting engine, per se, and Devo simply doesn't have that. This may or may not be by design."

What is our primary use case?

We are a value-added reseller focused on cybersecurity and big data analytics. Devo is a premier partner of ours. We not only resell Devo but we provide deployment services, content development, and analytic services for Devo customers.

How has it helped my organization?

Devo helps organizations save money and become more efficient by providing a scalable cost-effective data platform. A lot of organizations have the challenge of way too many data stores. This might be the result of company acquisition, different projects in time, etc.  But the result is they end up having one for each SIEM, Hadoop clusters, S3 buckets, custom solutions, etc. Basically, the data is everywhere. Devo provides a cost-effective, scalable way to get all that data into one place and streamline their processes.

Devo also provides a multi-tenant, cloud-native architecture. This is critical for managed service provider environments or multinational organizations who may have subsidiaries globally. It gives organizations a way to consolidate their data in a single accessible location yet keep the data separate. This allows for global views and/or isolated views restricted by access controls by company or business unit.

Devo keeps 400 days of hot data to look for historical patterns or analyze trends. A lot of organizations top out from the limitations of their hardware. Depending on the volume of data, they may be limited to only 30, 60, or 90 days retention for analysis.  After which, they might have to roll out data off to long term storage. They must do this because it is so costly to have the hardware to support long-term real-time analysis. Even if this “saves” some money, this also becomes a configuration and technical logistics challenge. Whereas with Devo, they just give you 400 days of accessible, searchable hot storage. This also helps with better visibility and meet a lot of compliance requirements.

What is most valuable?

Devo’s UI, high-speed search, and analytic capabilities.

The UI ease of use for analysts is very good. We love it. The UI really gives you two ways to work with the data. First, the UI lets junior analysts work through and understand the data. They can interact with the data, perform all kinds of built-in enrichments and/or functions using the intuitive, user-friendly UI.  Second, every UI interaction builds the actual query syntax being used along the way.  Devo’s query code editor gets updated with the query that the user is building via the UI.  Once the user gets comfortable with the query language, which is LINQ, they can continue to use the UI or simply choose to use LINQ directly.   It goes the other way too, you can also start with LINQ and if you get stuck on syntax, you can just leverage the UI and it will update the query you started from. Very nice.

Another nice capability is if some ingested data is nested inside a field that you need for your use case, you can easily parse it out in-line and make the data inside the field usable immediately! You can even go back historically and further process data that has been ingested already.  For Analytica42, the ability to build parsers easily without reliance on Devo Engineers really helps us support all our end customers who might be ingesting that same data source.

On high-speed search capabilities and real-time analytics, it’s one thing to ingest data as quickly as possible, it’s another to query and use that data. We have seen this problem historically in SIEMs where you can ingest data but aren’t really able to query and retrieve that data which makes it kind of pointless. Devo does both quite well.

Finally, you can then take any query you build and easily create alerts and detections that can alert your security team, SOC, and/or drive tools like a SOAR to do response.

What needs improvement?

Some basic reporting mechanisms have room for improvement. Customers can do analysis by building Activeboards, Devo’s name for interactive dashboards. This capability is quite nice, but it is not a reporting engine.  Devo does provide mechanisms to allow 3rd-party tools to query data by their API, which is great. However, a lot of folks like or want a reporting engine, per se, and Devo simply doesn't have that. This may or may not be by design.

I say this because I’ve seen many, many times where a customer states that they absolutely need to have a reporting engine.  But based on my experience with other SIEMs, the vendor ends up building a reporting engine, and the customer acknowledges the effort, but then they don’t actually use it. They end up extracting the data into whatever reporting mechanism/tools they use already.  So, often it seems it is the most requested mandatory/nice-to-have feature. Again, not having full reporting feature may or may not be by design for Devo but it has not been a showstopper because you are able to leverage their API to query the data you need and put it into any tool or format you like.

For how long have I used the solution?

We have been using it for about two years.

What do I think about the stability of the solution?

It is very stable. I can't really think of any hiccups. It has always been available when we need to use it.

All the maintenance is handled by Devo. That takes that headache and burden off the end-user. It lets them focus on their job vs spending time keeping the system up and running. That is the benefit of the SaaS offering that they provide, it allows an organization to focus their analysts on security, or their IT resources on other projects.

What do I think about the scalability of the solution?

It is very scalable. We have worked with Devo to design architectures that can go from a single terabyte to100 terabyte-plus daily ingestion of data. It is purpose built to maximize the advantages of the cloud infrastructure to scale.

How are customer service and support?

We work with their support all the time. From a support perspective, we get relatively quick responses, and they follow up on a regular basis until issue is resolved. They use a ticketing system to help manage the process and also lets us know the status of progress. So far, the team that we work with has been good.

They are customer-friendly and partner-friendly. They are easy to work with from their technology all the way to our relationship. Having a good partnership means a lot, especially for Analytica42 and what we do for a living. We have a good, bidirectional relationship, which is very important. We have been building upon that over the past two years.

How would you rate customer service and support?

Positive

Which solution did I use previously and why did I switch?

We work and support other SIEM and log management solutions for our customers who use Elastic, Sumo Logic, Splunk, and more.

How was the initial setup?

Initial setup with Devo is very straightforward.

If a customer has cloud services like AWS, O365, Gsuite, etc, and they want to ingest the data, you can probably get that up in a day to a day and a half. Everything is ready when you are ready. You just need to provide the respective API information.

The Relay, their local log collector, may take a little bit longer because it tends to be on-premise. But it is very easy to install. The Relay supports direct hardware installation, in Virtual Machines and/or in Docker containers. With motivated customer and available resources, a deployment could take as little as week or two to get all the data sources flowing.

What about the implementation team?

The staff required will depend on the size of the organization implementation team, change control process, the number of unique data sources, access to those data sources, how hands-on the customer wants to be, and finally their availability and timeline. Based on these factors, you could probably have only one or two Devo engineers or partners like Analytica42 assist a customer and their organization.  It is not a heavy lift technically, but the challenges are more centered around coordination.

For a typical deployment, the Devo team provisions the cloud instances, then Analytica42 are given access to the cloud environment. This model makes it easy for us to work with their customers globally. Once provisioning is complete, we typically are hired to assist customers to onboard their data sources, set-up performance analytics, and build content within the environment.  A lot of times, it is about mining the data and creating detections and rules with the data that gets ingested. For example, a customer might be ingesting AWS data into the Devo platform, we will then build searches and detections off that data to cover a wide range of use cases. Once validated, we also walk the customer through the process to get those alerts operationalized with their SOC or MSSP for validation, triage, and remediation.

It is worth mentioning something that is dear to my experience. Devo invests a lot in customer success. Devo assigns a CSM (Customer Success Manager) who walks the customer thru the whole on-boarding process. They assist with project planning, coordinate the efforts of the customer team with the Devo Professional Services Team or with a partner like Analytica42. They are focused on making sure the customer is happy and successful.

What was our ROI?

Devo saves us time. The turn-up time for the cloud is very quick with their SaaS infrastructure. Getting data in is relatively quick, whether it is leveraging relays, collectors or both. They are very modern in the sense that they are very friendly with GCP, AWS, Azure, etc., in terms of just needing plugin API keys, then it will start ingesting data and parsing it.

They have easy to configure Relays that can go on-prem and pretty much collect any type data that you can think of. I have always been very happy with that. It is a joy to partner and be able to work with this kind of system.

If you have acquired different data stores or SIEMs over time, especially if you are a large organization, you find yourself buying one of each. That is kind of wasteful, inefficient, and expensive. Because of the Devo’s scalability and low-cost, you can get the data from all those disparate environments into one place. Additionally, a lot of times in those environments, you have to filter out data so the systems don't get overwhelmed, thus you are partially blind on things you do not collect.  With Devo, their philosophy is you can go ahead and collect all the data. Devo’s ROI is saving on redundant licensing costs, storage/processing costs, collection costs, overhead of maintenance cost, but more importantly the ability to build a more holistic security program because you visibility to all your data for 400 days.  This helps any organization for detection and compliance reasons.

What's my experience with pricing, setup cost, and licensing?

I like the pricing very much. They keep it simple. It is a single price based on data ingest, and they do it on an average. If you get a spike of data that flows in, they will not stick it to you or charge you for that. They are very fair about that.

Additionally, that one price is all-inclusive. As a partner, I appreciate that as I am able to resell that easily. I just need to know your volume per day and I can price it out.  And with that you get 400 days of storage, the management full capability, all the analysis, additional applications, with no additional hidden costs that we have seen. That is very attractive.

Which other solutions did I evaluate?

We work with Elastic, Sumo Logic, Splunk, other SIEMs, and more. These solutions are very comparable to Devo when it comes to threat hunting and incident response. It just depends on the end customer and what solution will work best for them.

Some advantages of Devo are multi-tenancy and scale. It was built to be multi-tenant which uses resources in an intelligent way. This helps being able to manage multiple organizations. Some of the security solutions you need to create a separate instance for every single organization, which can be inefficient.

The other advantage or sweet spot of where Devo shines is price/volume at scale. Some of the other vendors may be a better solution at lower volumes of data ingest. Devo really accelerates once you get above 500 gigs or a terabyte a day. Cost-wise, once you start hitting that terabyte mark or above, some of the other vendors won't necessarily compare in price or scale. We have seen it where others would need a lot more TCO infrastructure to manage the same volumes that Devo can handle.

What other advice do I have?

If you are in need of a new SIEM or Log Management Platform and/or want to leverage the advantages of a cloud-based solution, Devo can offer a Proof of Concept (PoC) so you can see it for yourself.   

More and more organizations are moving away from on-prem and leveraging the cloud. I know a lot of companies still feel like they have to do on-prem but I see this loosening up. In scenarios where there are strict regulations, companies have ended up leveraging Devo for their IT and security infrastructure logs but then kept a small on-prem solution for strict compliance of more regulated sources.  Again, I see this changing as more and more organizations are adopting use of the cloud and is worth considering.

I would rate Devo as 8.5 out of 10.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Amazon Web Services (AWS)
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor. The reviewer's company has a business relationship with this vendor other than being a customer:
Flag as inappropriate