Devo Reviews

Our initial use case is to use Devo as a SIEM. We're using it for security and event logging, aggregation and correlation for security incidents, triage and response. That's our goal out of the gate.

Their solution is cloud-based and we're deploying some relays on-premise to handle anything that can't send it up there directly. But it's pretty straightforward. We're in a hybrid ecosystem, meaning we're running in both public and private cloud.

We're very early in the process so it's hard to say what the improvements are. The main reason that we bought this tool is that we were a conglomeration of several different companies. We were the original Qualcomm company way back in the day. After they made billions in IP and wireless, they spun us off to Vista Equity, and we rapidly and in succession bought three or four companies in the 2014/2015 timeframe. Since then, we've acquired three or four more. Unfortunately, we haven't done a very good job of integrating those companies, from a security and business services standpoint.

This tool is going to be our global SIEM and log-aggregation and management solution. We're going to be able to really shore up our visibility across all of our business areas, across international boundaries. We have businesses in Canada and Mexico, so our entire North American operations should benefit from this. We should have a global view into what's going on in our infrastructure for the first time ever.

The solution is enabling us to bring all our data sources into a central hub. That's the goal. If we can have all of our data sources in one hub and are then able to pull them back and analyze that data as fast as possible, and then archive it, that will be helpful. We have a lot of regulatory and compliance requirements as well, because we do business in the EU. Obviously, data privacy is a big concern and this is really going to help us out from that standpoint.

We have a varied array of threat vectors in our environment. We OEM and provide a SaaS service that runs on people's mobiles, plus we provide an in-cab mobile in truck fleets and tractor trailers that are both short- and long-haul. That means our threat surface is quite large, not only from the web services and web-native applications that we expose to our customers, but also from our in-cab and mobile application products that we sell. Being able to pull all that information into one central location is going to be huge for us. Securing that type of landscape is challenging because we have a lot of different moving parts. But it will at least give us some insight into where we need to focus our efforts and get the most bang for the buck.

We've found some insights fairly early in the process but I don't think we've gotten to the point where we can determine that our mean time to resolution has improved. We do expect it to help to reduce our MTTR, absolutely, especially for security incidents. It's critical to be able to find a threat and do something about it sooner. Devo's relationship with Palo Alto is very interesting in that regard because there's a possibility that we will be pushing this as a direct integration with our Layer 4 through Layer 7 security infrastructure, to be able to push real-time actions. Once we get the baseline stuff done, we'll start to evolve our maturity and our capabilities on the platform and use a lot more of the advanced features of Devo. We'll get it hooked up across all of our infrastructure in a more significant way so that we can use the platform to not only help us see what's going on, but to do something about it.

So far, the most valuable features are the ease of use and the ease of deployment. We're very early in the process. They've got some nice ways to customize the tool and some nice, out-of-the-box dashboards that are helpful and provide insight, particularly related to security operations.

The UI is 

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

Devo has a lot of cloud connectors, but they need to do a little bit of work there. They've got good integrations with the public cloud, but there are a lot of cloud SaaS systems that they still need to work with on integrations, such as Salesforce and other SaaS providers where we need to get access logs.

We'll find more areas for improvement, I'm sure, as we move forward. But we've got a tight relationship with them. I'm sure we can get anything worked out.

This is our first foray with Devo. We started looking at the product this year and we're launching an effort to replace our other technology. We've been using Devo for one month.

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

The scalability is unlimited, as far as I can tell. It's just a matter of how much money you have in your back pocket that you're willing to spend. The cost is based on log ingestion rate and how much retention. They're running in public cloud meaning it's unlimited capacity. And scaling is instantaneous.

Right now, we've got about 22 people in the platform. It will end up being anywhere between 200 and 400 when we're done, including software engineers, systems engineers, security engineers, and network operations teams for all of our mobile and telecommunications platforms. We'll have a wide variety of roles that are already defined. And on a limited basis, our customer support teams can go in and see what's going on.

Their technical support has been good. We haven't had to use their operations support too much. We have a dedicated team that's working with us. But they've been excellent. We haven't had any issues with them. They've been very quick and responsive and they know their platform.

We were using Splunk but we're phasing it out due to cost.

Our old Splunk rep went to Devo and he gave me a shout and asked me if I was looking to make a change, because he knew of some of the problems that we were having. That's how we got hooked up with Devo. It needed to have a Splunk-like feel, because I didn't want to have a long road or a huge cultural transformation and shock for our engineering teams and our security teams that use Splunk today. 

We liked the PoC. Everything it did was super-simple to use and was very cost-effective. That's really why we went down this path.

Once we got through the PoC and once we got people to take a look at it and give us a thumbs-up on what they'd seen, we moved ahead. From a price standpoint, it made a lot of sense and it does everything we needed to do, as far as we can tell.

We were pulling in all of our firewall logs, throughout the entire company, in less than 60 minutes. We deployed some relay instances out there and it took us longer to go through the bureaucracy and the workflow of getting those instances deployed than it did to actually configure the platform to pull the relevant logs.

In the PoC we had a strategy. We had a set of infrastructure that we were focusing on, infrastructure that we really needed to make sure was going to integrate and that its logs could be pulled effectively into Devo. We hit all of those use cases in the PoC.

We did the PoC with three people internally: a network engineer, a systems engineer, and a security engineer.

Our strategy going forward is getting our core infrastructure in there first—our network, compute, and storage stuff. That is critical. Our network layer for security is critical. Our edge security, our identity and access stuff, including our Active Directory and our directory services—those critical, core security and foundational infrastructure areas—are what we're focusing on first.

We've got quite a few servers for a small to mid-sized company. We're trying to automate the deployment process to hit our Linux and Windows platforms as much as possible. It's relatively straightforward. There is no Linux agent so it's essentially a configuration change in all of our Linux platforms. We're going through that process right now across all our servers. It's a lift because of the sheer volume.

As for maintenance of the Devo platform we literally don't require anybody to do that.

We have a huge plan. We're in the process of spinning up all of our training and trying to get our folks trained as a day-zero priority. Then, as we pull infrastructure in, I want those guys to be trained. Training is a key thing we're working on right now. We're building the e-learning regimen. And Devo provides live, multi-day workshops for our teams. We go in and focus the agenda on what they need to see. Our focus will be on moving dashboards from Splunk and the critical things that we do on a day-to-day basis.

We worked straight with Devo on pretty much everything. We have a third-party VAR that may provide some value here, but we're working straight with Devo.

We expect to see ROI from security intelligence and network layer security analysis. Probably the biggest thing will be turning off things that are talking out there that don't need to be talking. We found three of those types of things early in the process, things that were turned on that didn't need to be turned on. That's going to help us rationalize and modify our services to make sure that things are shut down and turned off the way they're supposed to be, and effectively hardened.

And the cost savings over Splunk is about 50 percent.

Pricing is pretty straightforward. It's based on daily log ingestion and retention rate. They keep it simple. They have breakpoints, depending on what your volume is. But I like that they keep it simple and easy to understand.

There were no costs in addition to their standard licensing fees. I don't know if they're still doing this, but we got in early enough that all of the various modules were part of our entitlement. I think they're in the process changing that model a little bit so you can pick your modules. They're going to split it up and charge by the module. But everything was part of the package that we needed, day-one.

We were looking at ELK Stack and Datadog. Datadog has a security option, but it wasn't doing what we needed it to do. It wasn't hitting a couple of the use cases that we have Splunk doing, from a logging and reporting standpoint. We also looked at Logstash, some of the "roll-your-own" stuff. But when you do the comparison for our use case, having a cloud SaaS that's managed by somebody else, where we're just pushing up our logs, something that we can use and customize, made the most sense for us. 

And from a capability standpoint, Devo was the one that most aligned with our Splunk solution.

Take a look at it. They're really going after Splunk hard. Splunk has a very diverse deployment base, but Splunk really missed the mark with its licensing model, especially when it relates to the cloud. There are options out there, effective alternatives to Splunk and some of the other big tools. But from a SaaS standpoint, if not best-in-breed, Devo is certainly in the top-two or top-three. It's definitely a strong up-and-comer. Devo is already taking market share away from Splunk and I think that's going to continue over the next 24 to 36 months.

Devo's speed when querying across our data is very good. We haven't fully loaded it yet. We'll see when the rubber really hits the road. But based on the demos and the things that we've seen in Devo, I think it's going to be extremely good. The architecture and the way that they built it are for speed, but it's also built for security. Between our DevOps, our SecOps, and our traditional operations, we'll be able to quickly use the tool, provide valuable insights into what we're doing, and bring our teams up to speed very quickly on how to use it and how to get value out of it quickly.

The fact that it manages 400 days of hot data falls a little bit outside of our use case. It's great to have 400 days of hot data, from security, compliance, and regulatory retention standpoints. It makes it really fast to rehydrate logs and go back and get trends from way back in the day and do some long-term trend analysis. Our use case is a little bit different. We just need to keep 90 days hot and we'll be archiving the rest of that information to object-based long-term storage, based on our retention policies. We may or may not need to rehydrate and reanalyze those, depending on what's going on in our ecosystem. Having the ability to be able to reach back and pull logs out of long-term storage is very beneficial, not only from a cost standpoint, but from the standpoint of being able to do some deeper analysis on trends and reach back into different log events if we have an incident where we need to do so.

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.

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.

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.

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. 

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

I've had no stability issues. 

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.

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. 

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.

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.

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.

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.

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.

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.

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.

We create solutions around the Devo platform and sell those solutions to our customers.

I use it as a managed SOC, or "SOC as a Service" for customers. I also use it as our managed detection and response platform, where everything goes back into the data lake for analysis and alerting.

Devo is very easy for our analysts to use. They have the LINQ language, which is easy, and it's like an Excel on steroids.

Devo provides high-speed search capabilities and real-time analytics, which is important to us because we have built 30-minute SLAs. In reality, our detections are within seconds and we allow for 30 minutes as a buffer to ensure that we are successful for our clients. To this point, we haven't found any type of dataset or any data ingestions that has prohibited us from meeting our SLAs.

In the world of cyber, you have to detect things right away. You can't wait hours, days, or weeks. It needs to be detected in an immediate, automatic fashion. Then, with their capabilities to integrate with a SOAR solution, it provides detection and response capability all within seconds, instead of days.

We use Devo more as part of our consultant-based service and the true multi-tenant flexibility, combined with the scalability of AWS, means that we can reach a wide range of customers. For example, we can go outside the United States into the European Union or into the AsiaPac region very seamlessly and very fast, as we're growing our business for managed detection and response in those areas. Just this week alone, we were able to quickly spin up a client in the India region, and we were able to address their concerns and get that spun up very quickly because Devo has that capability already built within AWS. It was approximately a one-day turnaround for us. It's important to us that the product is this nimble, which is in turn because of the AWS architecture.

Devo provides us with 400 days of hot data that we can use to look for historical patterns, which is a key element for us. It means that we can offer our clients different periods for different compliance reasons, such as HIPAA. For the most part, our clients use the 30-day capability but if they are a biotech company then they want to keep data for 180 days. We've had a couple of companies that wanted it for 400 days. The flexibility to keep that hot online is key because they can scale up and scale down at any time they want, and although there is an additional cost to the client, there is no additional infrastructure required. That said, probably 75% of our clients are utilizing the 30-day storage.

This solution gives us better cloud visibility because we're able to ingest any of the cloud logs. We push an EDR agent that then brings all of that telemetry back, and we have correlations with any proxy logs, firewall logs, or authentication logs that we need to have. This gives interoperability between the different log sources. For example, if we see something in an EDR that we want to ensure is connected outbound to something, we can check that through the proxy log and DNS logs that we get from the EDR agent.

This gives us more confidence when it comes to taking action because we'll get that running process, and we are also able to collect the DNS information, which then goes into Devo and we're able to search for it. We can see whether it reached out to this particular URL. What we can do is then go to that proxy server or the firewall log, and just see the outbound traffic and validate it is the same session size or same connection time. This acts as a dual authentication to show that what we saw in the EDR was what we saw on the network as well.

Devo helps us to unlock the full power of our data because they have more than 450 parsers, which means that we can ingest pretty much any type of log data. If we need to, we can go to the Devo professional services and have a log parser created within 48 hours. Any log that we need to ingest or want to ingest or the customer has compliance reasons to ingest, we can. This gives us the flexibility to bring in the core logs that we really need to do our detections or to manage the SOC, together with any other logs that we need to bring in for either correlation purposes or compliance purposes. There's really no type of log that we can't bring in.

This solution saves us a lot of time, although I don't have a before and after to compare because this is the first solution of this type that we implemented. I know of similar solutions in use at other companies that have problems doing what we do, but I don't have a baseline that I can use to calculate time savings.

We really use the core feature, which is log management. We bring in and ingest all of the different log sources for our customers and then run our TTPs (Tactics, Techniques, and Procedures) against these for threat detection.

I find the true multi-tenancy to be very valuable. We are able to put all of our detection rules onto our master tenant, and then run those to our sub-tenants when we're looking for all of the detections and alerts. It's essentially the core capability with the kind of vertical app for all of our TTPs that run across our different subdomains.

A big selling point to me is the multi-tenancy. First, we give permission to our clients to log into their domain, and second, we can run different analysis detection rules on different domains, depending on their business vertical. Some of our clients are in the aerospace industry and some are in biotech. They have different concerns than other domains do, so we can write TTPs or detection rules specifically for them because of the multi-tenancy. It doesn't conflict with everybody else. It's not a one size fits all approach, so the multi-tenancy feature is a very key attribute of why we went forward with Devo.

We only use the core functionality and one of the reasons for this is that their security operation center needs improvement. It's great for folks that don't really understand advanced detections but for people like us, and other businesses out there that have advanced detections, that becomes problematic and we don't use it.

The detection capabilities and their vertical app capability should be enhanced.

I have been working with Devo for two years.

This is a very stable solution. We have an uptime of 99.85% from an SLA perspective, and they've never gone below that.

As scalability is tied to AWS, this is a very scalable product. This means that we are able to quickly and easily offer our service in other regions, outside of the United States.

The scalability is a positive point when we're talking to the larger customers. It helps that Devo does not index everything but a lot of it has to do with AWS.

We have a couple of hundred customers and each customer has a few users that access it. At each client site, there are between two and five users that have access to it.

Our plan is to increase our usage. In fact, my company is doubling down on our MDR solution, and the main core of it is Devo. Even at this point, Devo is well-utilized. I expect that in 2022, everyone in the company will be focused on it.

We have 15,000 employees and 300 product lines, and we're looking to make sense of anything that is an opportunity for cross-selling.

Technical support is very good.

We're somewhat like partners of Devo, meaning they'll refer customers to us to manage their environment. They are definitely an ally to our business. We have pretty advanced knowledge of the product, so whenever we really need something, we file a ticket just like everybody else does, but it's usually pretty advanced. This means that we're usually dealing with the professional services folks and we have a really good relationship with them.

Overall, support is very responsive and they take care of any problem that we have pretty quickly.

This is the first solution of this type that we implemented.

At other companies, where my teams have come from, it has been very challenging to do the same tasks that we're able to do inside of Devo with other platforms. This is either because they have to index everything, whereas Devo doesn't, or because they don't have a true multi-tenancy. Perhaps they have to bounce between different systems, or because they don't have certain capabilities when it gets above 10 terabytes of data. For instance, at that point, it becomes very problematic to run searches because they'll fail or they'll time out.

The products that my teams were familiar with were Splunk, Sumo Logic, and LogRhythm. 

The initial setup was pretty straightforward. Their documentation is really good and we send it to our customers. It is very precise on exactly what you need to do and how you need to deploy the relay.

We deploy this solution on almost a weekly basis, and it can be done within hours.

Our implementation strategy maximizes ease of use for our customers. We have everything come into one or two forwarding points, then create the certification and push it out to the client. We created an executable that makes it seamless for the client and once that connects, the data flows right into the SIEM. It's the same thing with the relay, which is the other way to get data into the SIEM. The relay is very lightweight, running on VMware Ubuntu. 

Our in-house team is responsible for deployment.

Each customer is assigned a project manager, and usually, each project manager has 35 customers. My other staff includes a technical project manager, a SOC analyst, and a threat hunter.

I have seen a return on investment, and without disclosing figures, I can put it in terms of capabilities. This product allows us to scale up the way we need to, without any additional costs, or there's already a fixed cost with that. This is key for us.

We can bring in any size of customer, from the smallest client to the largest company. Also, I have been able to bake in the pricing model to adjust to the margin that I need for a specific customer.

The pricing is very straightforward and they charge per gigabyte. There are no "gotchas" when it comes to pricing. There's no re-ingestion or exfiltration of it.

With respect to retention, it's what you need it to be. They can scale up and scale down and everything is pretty straightforward. Pricewise, I can't think of any things that I wish I would've known ahead of time.

Pricing is based on the number of gigabytes of ingestion by volume, and it's on a 30-day average. If you go over one day, that's not a big deal as long as the average is what you expected it to be.

The fact that the vendor only charges for ingestion is something that I have been able to use in my practice, and I've built pricing models around that. I think that's probably one of the only ways that they can do it from a SIEM perspective. But, from an MSP perspective, because everyone's looking for per-endpoint pricing, it becomes challenging. It means that we have to use some fuzzy math to come up with something the makes sense such that data ingestion equals endpoint pricing.

We evaluated Splunk and LogRhythm. Splunk had great analytics but at that time, two or three years ago, their cloud wasn't as developed as it is now. Also, pricing was another major issue.

I do know that Splunk is a lot more challenging when it comes to threat hunting. You have to know the queries to be able to write in the Splunk query language, and it's a little bit more challenging, whereas Devo seemed to be a little bit easier.

Devo is very much like Excel, where you open up a window and hit data search. So, the workflow for threat hunting was very good and it was seamless. They had a lot of good breadcrumbs and it had a good workflow as it related to threat hunting or threat detection.

From a log parser perspective, Devo is able to ingest more data when compared to other solutions. By default, we can ingest any log source that we need to with Devo. With Splunk, at least when we did our evaluation, that was a little bit less on the scalability, and then LogRhythm, we really had a challenge with.

The vendor has exceeded our expectations in terms of being responsive to some of the things that we want to do. We're always trying to push the envelope and try to be creative with vertical apps. They've gone out of their way to help us in this regard. Whenever I call them, they definitely respond to me, and this is outside of the regular ticketing system. The good thing is that I very rarely need to call them.

My advice for anybody who is implementing Devo is to have an understanding of the log sources that you want to ingest and make sure that they comply with your budget. This is true for any SIEM. It is important to recognize that you're getting charged based on ingestion volume because a lot of people don't realize that. If you have logs that aren't necessary to your business, I would not ingest them because it's just going to increase your budget.

The biggest lesson that I have learned from using Devo is that the benefit of having different log sources is that we can get to the truth faster. It allows us to validate our findings in a shorter period of time, which has been invaluable.

I would rate this solution a nine out of ten.

We are an MSSP and we provide security monitoring services for our customers. We also treat ourselves as a customer. That means we use Devo internally for our own services in addition to using it to monitor our customers. The use case varies by customer, but they are all security-related as well as dealing with a little bit of storage retention, depending on the customer's needs.

Because of the way Devo works, our onboarding time has shrunk by 50 percent at least.

Also, at a high level, Devo's cloud-native SIEM has helped improve visibility into threats with its data analytics. That's very important because, as an MSSP, we need to be able to analyze the data for our customers and spot anomalies. This feature is still relatively new even to Devo, so I cannot say how happy we are with it at the moment; we still haven't taken full advantage of it. But the Big-Data analytics features included with Devo are allowing us to write some advanced alerting mechanisms that were not available to us in the past.

We are also able to ingest data that, in the past, would have been difficult to ingest.

The most powerful feature is the way the data is stored and extracted. The data is always stored in its original format and you can normalize the data after it has been stored.

By way of an analogy, if you have ever taken a text file and inserted it into a spreadsheet, the individual fields within that text file now belong in individual cells in the spreadsheet. If a particular set of data should have been in a single cell but was split into two cells, searching for it as a whole becomes difficult. The way Devo stores its data, it never gets separated. It's always stored as original data. The only time it gets split up is on extraction, when I actually need to look at my data. That gives me control over how the data is parsed or normalized. I don't have to worry about data being mangled as it's being collected and that gives me confidence that I always have 100 percent fidelity in my data.

The second most valuable feature is the way the alerting mechanism works. It is a code-based approach. You write your queries like code, with a lot of flexibility and access to internal libraries. Those aspects are not available in Boolean or natural language alerting mechanisms that are used by Devo's competitors.

For example, IBM's QRadar uses natural language and you construct a sentence out of predefined options to create your alerting mechanism. With ArcSight and McAfee you use Boolean logic statements. That restricts what you can actually do with the alerting mechanism. You cannot do sub-selections or complicated math problems. Those approaches are less data-centric and more just simple logic. Devo takes a Big-Data approach, rather than simple logic, when it comes to alerting. That makes it super-duper powerful.

Another important feature for us, as an MSSP, is that it allows us to carve up the data from each individual customer that fits into each individual tenant, and that data funnels up into a single master tenant through which we control everything. It becomes invaluable for customers who still want access to their data and we don't have to worry about them potentially accessing another customer's data.

In addition, Devo has an extremely powerful API that is now allowing us to create third-party integrations with forensic tools. That allows us to use Devo as a Big-Data storage facility. As a result, when Devo fires off an initial alert, our third-party forensic analytics tools can pull up the alert and use Devo's extremely powerful query engine to pull in all the secondary and tertiary metadata right into them. That allows us to track the incident with even more powerful tools.

The overall performance of extraction could be a lot faster, but that's a common problem in this space in general. 

Also, the stock or default alerting and detecting options could definitely be broader and more all-encompassing. The fact that they're not is why we had to write all our own alerts.

They could also provide more visual dashboards, what they call Activeboards, within their environment. Activeboards enable you to create custom or pre-defined dashboards. In that context, there are a couple of very useful features for us that are not available when I compare them to some of their competitors. They are features that help you quickly analyze data in a visual way. What they have is still pretty decent but they could beef it up a little bit.

We onboarded it a little bit over a year ago. 

In general, any stability issues have not been very impactful. There have been frequent small outages that make things difficult, but we're giving them a little bit of leeway because they're still a growing platform.

It scales really well, at least from our perspective. We don't know if there are any performance issues in the back-end. As I said earlier, it could be faster. But overall, because it's a cloud-based solution, we really don't worry about scaling. We simply onboard a new customer. They go into their own tenant and their data flows up to the management MSSP tenant. We simply size the licensing accordingly, so it's super easy to scale.

Support is pretty good. They're responsive and they usually solve problems relatively well. And if they mess something up, they will actually put professional services people in to solve the problems, if a wide range of issues is involved.

Both our technical and channel-partner relationships have been very good. We meet with them for status calls at least twice a month. They're very good about staying in contact to provide both satisfaction and technical assistance.

Positive

We used McAfee ESM on-prem. We switched because it  

• was getting old and not evolving
• was not cloud-based or cloud-centric
• had limited correlation engine capabilities compared to Devo
• was hard to segment customer data
• required us to host all the hardware in-house.

The list goes on and on and on.

The switch to Devo helped reduce blind spots and had a very good effect on our ability to protect our organization.  With the limitations removed on how data is inserted and extracted, we were able to alert on things we were never able to alert on before.

It was not an easy deployment because we're an MSSP. Devo's core content, its alerting and security content, is limited. We have a very wide variety of requirements with a lot of our customers. Unfortunately, most of the content that came with Devo couldn't be used. We had to write a lot of our content from scratch. 

We're still learning to crawl with the product because it's insanely powerful, but we were able to see value from it almost instantly. The value became instant because of the granularity with which we could write our content and how powerful the writing of that content was. Because the content that it came with was somewhat limited, we're pretty much writing our own content.

McAfee and Devo co-existed for quite a lot of time in our environment because we needed to make sure Devo was stable before we could cut McAfee off. In fact, some customers are still on it.

There is a bit of a learning curve with Devo because its search language is based on Microsoft LINQ. If you're used to graphic-interface types of SIEMs, like McAfee or LogRhythm or QRadar, where you point-click-drag-drop rather than write your own queries, or you haven't worked with Microsoft LINQ before, there's a learning curve. In addition, Devo has its own "flavors" on top of everything, like its own powerful libraries. If you don't know them there is a bit of a learning curve there as well. All of us are still learning it a year later.

But they do offer both basic and advanced training, and that helps you get started. They also have a pretty advanced Knowledge Base library to help.

Devo's team was involved in the migration and they assisted us quite a bit.

Our experience with them was decent. It wasn't bad. They put in quite a few man-hours helping us create the content and setting up the initial cloud environment. But they misunderstood our overall use case, early on. In the beginning, we were going in the wrong direction for a little bit. Once that was figured out, we were able to get back on track but time was already spent moving in that direction.

But they were very closely involved and helped us scope it out and prep everything. They were instrumental in the migration process.

We did a competitive bake-off between Devo, Elastic, and Google.

Google dropped out very early on. They didn't seem to be very forthcoming in the whole process. It turned out their product no longer exists, so that explains why they weren't being very good about the onboarding process. They didn't want to waste anybody's time.

Early on, Elastic was ahead of Devo in our PoC but when it came time to create very advanced security alerting use cases, Elastic was failing to create the advanced alerts we needed. Devo's proof of concept team was able to help us create those advanced use cases. Devo won there. And, price-wise, Devo was the cheapest out of the three in the bake-off.

Between Devo's advanced features, the price, and the longer default retention period of 400 days, compared to Elastic at 90 days, they ticked enough boxes that they won. The retention days were an important aspect because about 90 percent of our customers fall within a 400-day retention range, and that means we don't have to come up with alternative storage solutions and pay extra for them.

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.

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.

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.

I'm a SOC director for a Fortune 500 company, and we use it as our primary SIEM for our leverage SOC service.

Devo has streamlined a lot of our processes. We now have the ability to generate content and create alerting, and we can view all of that across a larger plane than we could with our previous tool.

Devo uniquely provides a direct view into the raw data, as opposed to a lot of tools that give you an ingested, parsed, and normalized view. Normalization is great for some things, but there are other things that it's not so great for. Devo allows you to have both simultaneously. You can parse the data and do some normalization but still have all the raw data the way it came from whatever it came from. That allows you to do deeper dives and look directly at what's coming in, versus a representation of what came in.

It also dramatically shortens the amount of time that we spend doing research in the tool. It has taken the average time that one of our analysts spends on an alert from 10 minutes down to roughly five. They're spending half the amount of time doing research because of the way that we are able to set up the data within Devo. And they can use things like Activeboards to provide a lot more context than our previous toolset could.

We're able to find things quicker and more efficiently, and with broader visibility than we had in our previous toolset.

We're also able to take a look at the data a bit more holistically, and that provides us with a better top-down view so that we can better see where there might be gaps in our coverage.

In terms of ingesting data, Devo literally takes anything we throw at it and as much as we're throwing at it. Our ingestion of events has increased by a full one-third compared to ingestion with our previous SIEM. That increase is a result of our increased customer base as well as the increasing number of things that we're ingesting from our customers.

The most valuable feature is that it has native MSSP capabilities and maintains perfect data separation. It does all of that in a very easy-to-manage cloud-based solution.

And when the Devo Exchange came out, for access to community-driven content, I was one of the first folks who used it. I was part of the advisory board that really pushed to get that product created for them. I'm all about the Devo Exchange. When compared to Devo's peers in the SIEM market, that was the area that they were lacking in: the ability to share types of content. Other platforms have definitive user bases and large external communities that look at how to do different types of alerting, configuring, and threat hunting within their platforms. Because it was relatively new to the market, Devo just didn't have that built up yet. The fact that they have not only built it but have integrated it directly into their product is absolutely fabulous.

The Devo Exchange is literally point-and-click. If you see something you like, you click on it. It tells you whether you have the applicable tables to make that content work. If you do, you can click a button and it automatically installs for you. All you have to do is go in and create any alerting rules that you want associated with it. It's absolutely amazing.

The Exchange has made it much easier for us to deploy new content. We don't have to spend a whole lot of hours cycling through and creating the content ourselves when someone has created similar or exactly the same content that we would be creating. It has shaved 15 to 20 percent off of our deployment times for new alerts, saving us the time that we would have put into building those things.

In addition, there are things in the Exchange that we weren't sure how to do. Once we saw them in the marketplace we pulled them down and they have given us deeper insights into the data that we have.

The biggest area with room for improvement in Devo is the Security Operations module that just isn't there yet. That goes back to building out how they're going to do content and larger correlation and aggregation of data across multiple things, as well as natively ingesting CTI to create rule sets. Exchange has gone a long way to fix some of those gaps, but there's still room for improvement in that area.

I've been using Devo since December of 2020.

Very early on it had some stability issues, but for the last eight months or so, it's been rock-solid. Even when they have put out notices that there has been an issue, rarely have I ever actually seen that impact our operations. Compared to when we onboarded and where we are now, it is a night-and-day difference.

The solution has been able to scale to whatever we have thrown at. There have been zero problems scaling.

It is the primary toolset that we have settled on for our leverage service. The core of our service offering is around the solution. It is absolutely important.

The tech support has been absolutely amazing. We have a technical account manager and I can email him anytime and I generally get an answer back within a few hours. Either that or he'll escalate to the appropriate team to get it taken care of for us.

The only drawback is that we have asked for capabilities and, because of where they are in their growth and funding, getting them has been a little slower than what we would have liked.

Positive

Our previous solution just wasn't as robust in both processing power and the ability to analyze data.

Migrating to Devo was super simple. Their professional services gave us a lot of assistance, making sure that we had the right parsers in Devo at the platform level. Getting stuff pointed to it was relatively simple.

We essentially dual-fed both our SIEM products for a few months and it was fairly seamless. We did the switch from our previous SIEM into Devo about three months earlier than we had planned, based on how robust we were in Devo at that point.

That ease of migration was definitely important to us. Anytime you migrate from one tool to another, there are significant costs in personnel training and rewriting all of your processes and procedures, because it's a new tool. Devo had a very smooth process with their training platform and the professional services when we first onboarded it. That made it a relatively smooth transition.

We started our proof of concept in December and were live by the beginning of March. That's a really short timeline to get into production with them. We saw return of value almost immediately.

It was relatively simple to get our staff up to speed on the solution. Devo provides an amazing training platform to get them set up on the solution itself, as well as some of the modules within it. Typically folks can go through that and get going in the platform, working as analysts, within a week. And that's for someone with no SIEM background at all. If they have a SIEM background it's even faster.

The learning curve is fairly shallow, especially if you've done SIEM tasks before. It's very much like what you'd expect. It involves a slightly different language than what some other SIEMs use. Azure Sentinel uses "KQL," Devo uses "link," which is very SQL-like. If you have a background in anything remotely related to databases or SIEM, the learning curve is fairly negligible once you understand how Devo works. The training platform does a great job of bringing you up to speed on why Devo is different.

We analyzed a bunch of options. Devo was not even one that we had on the map. They put in a response to our request for proposal and, bar none, they outperformed their peers across all of our key requirements. In addition, they had roadmaps for all the things that we wanted to do.

Among the things that were important to us that Devo could provide were its ability to 

• do true MSSP in the cloud with actual data separation per client
• give individual clients access to their data, and only their data, based on the way the data is separated
• give us the ability to do analytics, rule sets, and alerting across all of those environments at one time, which doesn't sound like a huge ask but it's actually monumental.

The ability to have data segregated but still do analytics across multiple data sets is something that's just not really used in a lot of other products. Either everything is mashed into one set of data, and you don't have true separation of that data so you can't, in turn, give customers view sets into that; or it's all separated and you have to do all the work against each silo rather than having a unified view, which is something we have within the Devo platform.

Definitely take a good, hard look and considerate it. It's the fast-growing leader in the SIEM field.

Overall, Devo is awesome, but it's got some room to grow. I would like to see better native ingestion of cyber threat intelligence and building out of deeper correlation capabilities. They have some work that they're doing in Flows to do some of that stuff, but it still has room for some additional maturity.