Devo Reviews

We're primarily using it to correlate WAN and endpoint activity for our clients. We work with vendors that have endpoint solutions or that control the networks for our clients. We are receiving their feeds, along with some of our other custom deployed equipment, to not only collect endpoint data, but to monitor network activity and correlate it to identify threats, vulnerabilities, attacks, and provide incident response.

We've integrated Devo with a SOAR solution. We have prioritized the severity of our alerting in Devo and that corresponds directly to automated playbooks that are kicked off in the SOAR. With that SIEM-SOAR solution, we have drastically reduced the number of incidents that our analysts have to work through, and we have improved our time to respond as well as the time to remediate, through that integration.

Devo absolutely saves us time. We brief our project manager and client weekly on the number of man-hours saved just by having this SIEM-SOAR integration. Considering the quantity of data feeds and events and endpoints that we have, we can actually present a funnel chart that shows how many "events" we start with and how many become actual incidents. We then have that calculated into the number of dollars saved. It's phenomenal when you look at it. When we show the people who are in charge of getting funding that we saved this number of man-hours, which correlates to this number of dollars, they're more willing to fight to get that funding for the next fiscal year.

The strength of Devo is not only in that it is pretty intuitive, but it gives you the flexibility and creativity to merge feeds. The prime examples would be using the synthesis or union tables that give you phenomenal capabilities. There is such a disparity in how, say, a network feed or an endpoint feed comes in. They're all over the range, not only in the information they present, but in how that information is categorized. The ability to use a synthesis or union table to combine all those feeds and make heads or tails of what's going on, and link it to go down a thread, is functionality that I hadn't seen before.

It also provides high-speed search capabilities and near real-time analytics. I haven't had any problem with it in those contexts. The high-speed search and near real-time analytics are important to us because when it comes to incident response, we have a certain amount of time to turn these events and incidents around. That's how we're graded. That responsiveness, where it's not waiting on any results, is critical to how we do our jobs and how we stay alive in this game.

And because of the ease of integrating Devo with the SOAR solution, we've created an API for a visualization capability, and that works pretty easily. I'm usually an incident response, content development, threat hunting guy. But I was able to do all this stuff on the back end myself. The way it's set up makes it easy for someone who is not a back-end engineer to go in and set up that kind of integration.

We look for historical patterns and analyze trends with that data. That historical data is critical when putting separate events together and trying to detect a pattern or when looking for a low-and-slow, advanced, persistent threat. Without that reach-back capability, you would just see these one-offs and you would never put that information together. What makes a SIEM work is not only seeing the real-time event feed but being able to reach back and put things together. That's at the core of any SIEM solution.

We have a list of things that we'd like to see. I have had all my analysts put in suggestions. I've tested a number of solutions through the years, and I've found that companies appreciate that analyst perspective and anything that makes future releases more user-friendly.

The biggest thing we've found, when trying to integrate Devo with the SOAR solution, is the priority or severity rankings. If they could make those a little bit more intuitive that would help. It seems that when we set the priority of an alert, it doesn't always translate, in the back end, the way you would expect. The severities include "very low," "low," "medium," "high," and "very high." Those correlate to numerical value ranges one to three, four to five, six to seven. It's a little confusing. It would help if they made that priority/severity labeling and numerical system match up a little better.

Also, it would help if some of the error messaging could be a little bit more descriptive when you run a query and an error pops up. It would be good to have a log where you could find those, as well. 

Another issue is that an admin who is trying to audit user activity usually cannot go beyond a day in the UI. I would like to have access to pages and pages of that data, going back as far as the storage we have, so I could look at every command or search or deletion or anything that a user has run. As an admin, that would really help. Going back just a day in the UI is not going to help, and that means I have to find a different way to do that. That's a big one.

I started looking into it and training on it in August of 2020, so I have been using it for about 16 months.

I can count on one hand the number of times it has gone out. It's very stable. A few times we've needed to reboot the stack and that has usually resolved the issue. We're pleased with the solution when it comes to incident response.

It's highly scalable.

I have all the personal numbers of my Devo support guys. I can text them and they usually respond within the hour. It's excellent customer support. I've been in this game for 20 years and you can generally expect someone to get back to you within a business day or two. But if I'm in a pinch, these guys usually respond within an hour.

In terms of being an ally to our business and providing a customer-first approach. They are a highly trusted ally and partner. The success of our solution relies directly on their delivery. We include them in all of our success stories. We consider Devo on par with our company.

Positive

Setting up the solution was pretty complex. Working with the number of external vendors that we had, the way that they would send the information to us, and the fact that they were constantly changing the way that data was being sent, meant we were constantly having to go in and tweak the relay rules. To know what you're doing with the relays, and putting in those rules, takes some homework. Devo was very responsive and worked with us hand in hand, troubleshooting and putting in the parsers and the relay rules to help us get things integrated.

It took six to eight months of that type of work just to get it to work. For our project, the setup was very complex. We had two environments, a lab environment and a live environment and it took that long to get both running. That seems like a lot of time. But we were working with a number of different vendors, and this was the first time any of us had ever done this.

I'm a long-time ArcSight and Splunk user. I see Devo as the evolution of both of them. If the capabilities of those two got together and had a baby, it would probably be Devo.

Devo is a definite upgrade from both ArcSight and Splunk, in my experience. It combines some of the best of each and it takes it to another level when it comes to ease of use and how you can expand the capabilities.

Another benefit of Devo is that it enables us to ingest more data compared to other solutions. This project has such a widespread ingestion of so many endpoints and networks.

The ease of use of Devo really depends on whether you've had experience with a SIEM before. If you have, you should be okay. If this is your first time walking into a SIEM, it may be a little bit overwhelming, which is natural for any SIEM.

But it's very easy to pick up and has great documentation. The tutorials that Devo has provided, the upfront user training, and their lab environment are all very helpful. I just sat through a monthly tutorial where they had one of their commercial users come in and speak for 35 minutes on their best-case uses. The support element, combined with the training that they provide upfront, creates a customer experience where you're not flying solo. You have a lot of people to lean on. We use Devo as a service, but I've found that there is so much documentation at my fingertips that I really don't need to reach out to them that often.

Where they have exceeded my expectations is the training element. They're constantly putting out training tidbits and interactive sessions. They don't have to do that but they're holding sessions where they bring in analysts who do straight run-throughs. That's stuff you don't get anywhere else, other than with someone in a SOC environment. Those sessions are invaluable for picking up tips on how to better use the solution.

In terms of Devo providing a multi-tenant cloud-native architecture, if you can switch domains, it does. At this point in the evolution of our architecture, that is not important because we only have one client at this point. But I do see the usefulness of it to separate your domains and your traffic while, at the same time, potentially filing some of that activity or using it for correlation. We're just not at that stage right now.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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. 

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.

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.

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.

We use it for visibility and alerting in a cybersecurity security use case. 

It is a very specific deployment in the sense that it's not general. We integrated it with our own technology. We are a SaaS vendor. The way we integrated Devo was to put it into our platform as an alerting layer. Because you will be doing executables at your computer all the time, such as opening an email, a browser, or Word, all these things are tracked via telemetry. We take all that raw data for events, essentially enriching it with the classification service that we have as a unique part of our own service. So, if you're opening Word or sending an email, we enrich that with our classification, e.g., malware, then we send it to Devo. We build dashboards and alerts based on that. 

Before, you would have a tool just for cybersecurity. Now you have an impressive tool that takes no effort at all. Suddenly, because of the Devo layer, you have an intelligence tool with no extra deployment effort on the side of the customer to see visibility.

Devo is a powerful interface and platform which will ingest our data coming from an endpoint protection solution, putting it in a format and dashboard, then connecting tools where you extract them into an intelligence platform, oversight, or security. That's essentially what we do.

The solution manages 400 days of hot data for us, which is amazing. We just send it to the Devo platform, then it is there for our customers. It is quite a unique feature because other cybersecurity players typically have a lot of limitations. They normally offer two weeks of historic data with a pain offering of a month. We are sort of unique in the industry because we can offer a year due to Devo. When you're looking at cybersecurity breaches, you will notice that normally attackers have been in your network for more than 300 days. This is the average time that you've been breached and you didn't know, and it's actually close to what we have with Devo. A shorter period of time would be less useful to us.

Because of the module, our customers now have immediate access to telemetry in a way that they didn't have before. The way that we integrate it with a click of a button, activating the Devo module, suddenly they will have immediate access to it. Therefore, the automation and value for customers is quite impressive. 

Ease of use: Even if it's a relatively technical tool or platform, it's very intuitive and graphical. It's very appealing in terms of the user interface. The UI has a graphical interface with the raw data in a table. The table can be as big as you want it, depending on your use case. You can easily get a report combining your data, along with calculations and graphical dashboards. You don't need a lot of training, because the UI is relatively very intuitive.

We find the solution’s Activeboards and widgets to be understandable and flexible. Before the summer, we are looking to expand the ability for people to do their own dashboards and variations off-the-shelf.

It performs well. There is a lot of telemetry in our case, and it is cybersecurity. The telemetry is integrated with a lot of data. You need to look at it in real-time because if you are under attack, then you need to see that immediately: What's going on, where it's coming from, where is the zero patient, etc. This is all the while that you're conducting threat detection. The performance is amazing.

The solution’s real-time analytics of security-related data works well for us. It's a module that we buy from the Devo platform and have as a vertical for the customization of our sessions and alerting. It's great for us to know that they will be taking care of our customers. We don't touch it and are very satisfied.

There's always room to reduce the learning curve over how to deal with events and machine data. They could make the machine data simpler. 

Lookup tables could be used to minimize the performance impact in bringing together two different sources of data together and correlating them. This could be something that they could improve, but maybe this has already been fixed.

Five to six years, going back to 2014.

Maybe two to three times over six years we have found some issues in the system, but normally it is immediately sorted out.

We don't have to worry about how it is maintain and managed over time. That is in their hands, and it is working great.

We have a product manager who maintains the Devo modules part-time (50 percent). There are also five to seven people from our development team who ensure everything is properly integrated. Once every two years, we do a professional services project from them.

We've never found any limitations or drawback included in the data to ingest, map, and integrate into the platform. There have been no issues with scalability.

From a machine data and ingestion perspective, it would be probably be something around a million devices. People actually using the platform is probably several tens of thousands because that's the number of our partners who have sold a Devo module at some point.

Devo is part of our performance, so the more we grow, the more we will need it as part of that blend of growth.

The technical support is very good. Devo is a typical vendor with very capable, technical people who can get to the root cause quickly.

We implemented Devo into our platform from scratch. McAfee and other solutions don't have this offering yet. This was a new thing in 2014 when we implemented it.

The initial setup was quite straightforward. The deployment was a few months, then we were up and running.

The only thing we needed to do for implementation was to choose what part of the event information that we would send to Devo, who would need to map that, parse it, and put it into their platform in a way that was understood in order to give the information back to users in a way that it would make sense. For dashboards, prepackaged, and off-the-shelf cybersecurity intelligence, we needed to choose the information that we would send them. They needed to ingest it and make sense of the dashboards that we needed to show our customers. It was a relatively simple, straightforward project on both sides. We saw very huge volumes immediately.

We first launched the product in 2014, then did a major lifting in 2015. On a continuous basis, we are adding new features that Devo releases. 

We have a big development team as we are a vendor. 

It took two people from our company a few months to deploy the solution with seven people (max) from Devo.

The solution has decreased our mean time to remediation (MTTR) because of the immediate visibility, the prepackage dashboards, and the alerting that we built. With Devo, even if you didn't have any patch solution in place, you could just click in the platform and it could tell you when, where, and what endpoints were seen by Devo in the last year. Then, you can print a list of those computers and the IT people can just go to those to upgrade the patches. In a situation like WannaCry, as long as you know what you're looking for, the fix is immediate. For example, we have one customer who had a situation where they were waiting months for remediation. With Devo, it is immediate because it is available with a report.

The way that we charge our customers is not the same way we are charged by Devo. We need to keep it under control so it makes economical sense for us to sell our model based off of Devo. That's why we don't expand in an infinite way what we send to the Devo platform. We charge on an endpoint basis per license, subscription, or input annually. That's our business model. Devo charges based on ingestion and the time you store, which can be different one month to three months to a year. Therefore, it was difficult to build a model in the beginning that would work for us. That's why we limit the amount of ingestion that we do in the customers' platforms.

The ROI been great. The fact that we could launch it in a few months instead of a couple of years, that's a return on investment. Also, when you put all the costs together, it is less to have done it than with the open source approach.

We have an OEM agreement with Devo. It is very similar to the standard licensing agreement because we are charged in the same way as any other customer, e.g., we use the backroom. However, we built this vertical model extending our portfolio, which is actually a Devo based model.

We have a very simple invoice every month based on ingestion and the seniority of the data stored, which I think is the standard way they charge. Then, every other year we make a charge on a specific professional services project based on our module integration, which is probably unique for us compared to a standard customer.

We were thinking of going with Elasticsearch or an open source solution, but it would have been one to two years of development internally.

We went with Devo which represented more of our core: scalability, stability, and ingestion. All these things are where Devo really excels. We were looking for something focused on enterprise environments.

For patching, the MTTR is immediate compared to a typical Microsoft tool. 

Internal development is underrated. It is a good choice not to invent it all yourself. You should focus on your core business. It made sense to choose Devo to focus on the machine data issues while we focused on cybersecurity and the intelligence that we could build with the platform.

Open source is a good option in some cases, but not for us and our needs.

I would rate the solution as a nine (out of 10).

The most valuable feature of the solution is the log retention time. The dashboarding, what Devo calls Activeboards, is a very useful feature enabling rendering a range of insights from data and related detections. Devo enables collaborative working across security teams within the platform.

Devo continues to invest in their analytic capability and the platform's durability. Regarding the service management side, Devo are maturing their service management, ensuring they are absolutely on it when they have service incidents or problems with the service. I think the tool offers a great and promising future because the platform's fundamentals are good.

In general, over time Devo should look to provide more customization options and support wraps.

We have been using Devo for two years. We use the solution's latest version.

The solution is stable, there have been rare instances where Devo has lost some accessibility and other issues, which they resolved rapidly. Devo are improving on their service management side to ensure fast recovery from issues. High stability in a cloud native platform is key.

Scalability is one of Devo's strengths. Its ability to scale is good, and for a customer, the scalability works out of the box, they can accommodate all customers from small and up to enterprise-sized customers.

Customer service management is prompt and improving enabling faster recovery from issues.

Neutral

The setup phase required technical input and that increases with the scale of the project, but Devo are willing to assist.

The solution is deployed in Devo’s cloud. It is possible to get Devo on-premises, but that is not the main offering.

Deploying Devo you can get the right security outcomes within a few weeks to a month. Its heavily dependent on the scope of the solution.

Devo is taking on the market leaders, and their pricing is commensurate with that strategy.

Core and additional features Devo provide guidance around and help in making value-based pricing discussions.

It is important with any SIEM deployment cloud-based or otherwise to have an experienced implementation team. The implementation team should be prepared to engage closely with the SIEM vendor to get the best from the scope of the deployment.

Overall, I rate the product an eight out of ten.

During the pandemic, small and medium companies didn't buy big servers. Latin American countries only used Devo in industries, maybe banks or security government projects. We create server appliances, such as servers plus switches.

I am a sales and technical support engineer, and Devo has a really good website for creating custom configurations. I can easily create a customized server with their website, so it's a great product for sales engineers.

The price is one problem with Devo. Huawei, Lenovo, and Gigabyte are all cheaper than Devo. I rate Devo's price an eight out of ten because it is expensive.

I've used Devo since the start of the pandemic about three years ago.

We have had some issues, but everything was fine after we updated the firmware. We need to update it every six months. The solution's stability is good otherwise. I have also had issues with the power supply, but I found the problem was with the integrator because they installed it with no UPS at the beginning of the project.

There's not a high level needed to scale the solution. We have great management software that allows you to manage and get alerts on events that could create a problem in the future.

I like their technical support. They respond in one business day, and they are always available. I always do the first level of technical support, but if I need to solve something quickly, and if the problem is hardware, Devo might send, for example, a power supply or a technician to change something.

Positive

We have two options with the initial setup. One is we buy the chassis from the OEM and customize the server. I prefer the OEM server because we have a customized image-focused VLAN, so it is easier for the integrator or customer to set it up. You just need to open the box, turn the server on, and they are ready to install the DNS software.

We have another option where we resell only the Devo server. We are just starting to do this, and it is not easy to assemble because we need a lot of skill.

The time taken to deploy Devo depends. If the final customer has everything done, or if everything is correctly installed, the rack, the air conditioner, or the UPS, it takes two to three hours at most to customize the server and the network card. We need two or three people for labor when the integrator installs the server. We need just one person to configure the server.

We sometimes choose integrators to set up the solution. I have training on the solution and sometimes help customers deploy Devo.

We considered other products because Devo is expensive. Huawei and Lenovo are cheaper, and they say there are no complaints or issues.

I rate Devo a nine out of ten.

We're mostly using it for log retention and investigations into events or security issues within our environment. We're pumping a lot of the logs from our SaaS tools into it, from tools like Google Workspace (G Suite) and OneLogin and the like. When we have questions or investigations from a security perspective, we go into Devo to help answer them.

With Devo, we now have a method to investigate things across our platforms. Before Devo, we had to go to individual platforms. For example, if we suspected something was happening, we'd have to go to tool A's logs, and tool B's logs, and tool C's logs. Now all those logs are in one place and we can use one pane of glass to query all of that data. Especially when it comes to security investigations, Devo has made things more efficient.

Previously, an investigation across various logs might have taken an hour for one individual to put together. Now, in Devo, we can do it in minutes, because it's all in one place and we have access to it right away.

And as a result of some of the alerting we've put in, Devo has certainly helped improve visibility into threats. For example, we only have employees in certain parts of the world, and not in that many countries. We put in alerting so that we know if an employee seems to log in from a country we're not based in. That's a red flag. We have other kinds of alerts as well, and that has definitely helped give us more visibility into the overall risk profile for our organization.

The querying and the log-retention capabilities are pretty powerful. Those provide some of the biggest value-add for us.

We also find their Activeboards, which are their dashboards, useful for just displaying data and seeing historical trends.

We also use their alerting capability to a limited degree, although we don't really have too much invested in alerting yet.

Where Devo has room for improvement is the data ingestion and parsing. We tend to have to work with the Devo support team to bring on and ingest new sources of data. 

I know the Devo Exchange is supposed to make some of that easier, but we've had situations in the past where our data collectors, which are hosted by Devo, have gone down and we've not seen data ingested until we've opened a support ticket with them. 

In general, their data intake process, whether it's how to get new sources in or keep them continuously ingesting, is the biggest area for improvement.

I have been using Devo for about a year and a half.

It's stable but it's not extremely stable. There have been cases where the ingestion of our log data has stopped, which affects the platform. We've also seen issues where the UI becomes unresponsive, or some of the queries have become really slow. Devo itself is not down a whole lot, but sometimes performance can be a problem. Overall, the stability is okay. It's not the best, but it has not been horrible either.

From a customer's perspective, I just scale in terms of what data tier I want, but everything else is hidden from me.

Their tech support has been great, once we've raised issues with them. They've been pretty responsive and I'm pretty happy with that part.

Whenever we've opened a ticket, especially when it's been high-priority, they've responded fairly quickly. They're certainly friendly and they try to be helpful, within the limits of whatever they can do. They also escalate quickly if it looks like it's not getting to a solution within the purview that they have.

Positive

Devo is the first SIEM for us. We didn't have anything before this. We're growing as an organization, and SIEM in general, and Devo in particular, let us scale up our capabilities without having to scale up our manpower.

The complexity comes from getting the data sources ingested. There are some easy ones for common tools like Google or OneLogin or AWS. Getting the logs of those big SaaS tools into Devo was not too difficult. But there are a lot of SaaS tools out there and, especially in the beginning, Devo had to create custom collectors and parsers for us for some of the smaller ones, and that took a while to do.

In terms of getting our staff up to speed on using the solution, on a scale of easy to difficult, it was in the middle. The basic functionality, especially the dashboards and where the data is, is not that difficult. Where the complexity comes in is when it comes to getting value out of that data. There's a query language, called LINQ, which is SQL-like but has quirks that are Devo-specific. That takes some time to learn, but that would probably take time on any platform. Overall, the learning curve is not really easy, but it's not really that difficult either.

Devo certainly helped us deploy it initially.

More than anything, we have seen ROI in the amount of time saved during investigations. From that perspective, it has paid for itself. 

Within the first quarter after we started using it, there were incidents that Devo was able to help us quickly assess and investigate. As a tool, it showed its value pretty quickly.

The way Devo prices things is based on the amount of data, and I wish the tiers had more granularity. Maybe at this point they do, but when we first negotiated with them, there were only three or four tiers.

We definitely looked at competitors, the standard players in this space: Splunk, LogRhythm, and others. We ended up choosing Devo because of two or three things.

First, as an organization, they were very responsive. The support, even during our PoC and evaluation process, and afterward, was and continues to be phenomenal. We know that they're a smaller company like us, and it felt like they were more attentive to us as customers.

The second factor was the price point. If we had to stand up similarly sized solutions from some of the other vendors, it would be much more expensive.

And one of the biggest reasons we went with Devo was that we're a small security team, and we didn't want to have to manage SIEM infrastructure. Devo meets that requirement for us because it's SaaS. There are other SaaS SIEMs, but Devo seemed like the best. All we had to do was pump logs. With other platforms there are infrastructure aspects, like storage and indexers that you have to worry about. We don't have to do any of that. We just put in the logs that we want, up to a limit, and that's it. It allows us to focus on getting the actual value-add out of the logs, rather than spending a lot of bandwidth managing the infrastructure.

We plan on using the Devo Exchange. It's a pretty new feature. Part of the constraints, for us, has been manpower. Our organization is growing pretty rapidly, and we're working on hiring to keep Devo up to date. We just haven't had the bandwidth to invest more into exploring all the features yet.