Devo Reviews

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Prior to Devo, we used the LogRhythm SIEM.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I have been using the solution for about a year.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 look at this solution for both security monitoring and operational monitoring use cases. It helps us to understand any kinds of security incidents, typical-scene use cases, and IT operations, including DevOps and DevSecOps use cases.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We have been using it for about two years.

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

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

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

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

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

Positive

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

Initial setup with Devo is very straightforward.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I would rate Devo as 8.5 out of 10.

We have most of our major log sources going to it, and we have both an internal NOC as well as an external MSSP that does 24/7 monitoring. We use it for writing all of our alerting use cases for different correlations between all of our different logging apps.

In terms of our environment, we have several departments. We're a staffing company, and we have a lot of different contractual obligations with other companies. So, it's a fairly complex environment. We have multiple domains. We have several DMZ environments, and we have three active data centers.

We now spend a lot less time supporting different pieces of the SIEM. Log integration is super easy and super fast, and it handles all the data we can throw at it. That was a big deal because we send quite a bit of data to it.

We started using Devo Exchange within the last few months. We've used it to install some active boards and to get some help with different log sources. We used it to access community-driven content. That's how we got some of the active boards. This community-driven content for protecting our organization is very important. One of the problems we had with our previous SIEM was getting adequate support and information about the things we needed, and that hasn't been an issue since the community has been helping us.

It's very easy to use Devo Exchange. There is a bit of a learning curve to learn how they classify and use the data, but once you understand it, it's a very simple platform. This ease of use has improved our incident response capabilities. We've got a much more robust alert stack now. We've been able to build out use cases for things we couldn't in the past. It has been very helpful.

Devo Exchange has saved us weeks. The community gets back really quickly, whereas, for some of the support tickets that we opened previously, it would take so long.

Devo Exchange has been great. With our previous SIEM, there were log sources where we couldn't get any help, and we couldn't get much support because even the company we were working with didn't understand them. With Exchange, because people all over the place have had experience with it, and they are able to give us some ideas.

Devo has absolutely improved our visibility. We had a lot of visibility gaps, especially in our cloud solutions, and integrating cloud solutions with Devo has been great. It increased visibility into our organization.

Devo has allowed us to ingest quite a bit more data. Our data ingestion has almost doubled.

Devo saves us hours in every investigation. Previously, just getting the data to return with searches and things like that was cumbersome. A lot of the interfaces were very slow. We haven't had any issues like that with Devo. It has been very quick.

The most useful feature for us, because of some of the issues we had previously, was the simplicity of log integrations. It's much easier with this platform to integrate log sources that might not have standard logging and things like that. 

Alerting is very easy to set up and use, and it's pretty robust. It takes a lot of ingests. We had some issues previously where we were overwhelming our old SIEM. We were setting too many logs, and it couldn't handle the load. That's why we looked for something that could have much higher rates of ingestion.

The fact that the solution manages 400 days of hot data was a huge selling point. In our organization, we have to have 365 days of hot data all the time, and licensing that with other solutions was extremely expensive.

Some of the documentation could be improved a little bit. A lot of times it doesn't go as deep into some of the critical issues you might run into. They've been really good to shore us up with support, but some of the documentation could be a little bit better.

The other thing is the interface. It's super easy to use, but it takes a little time to get used to. Definitely, the training helped a lot, but it's not like most other SIEMs. That's because of the way they ingest the data. So, it's totally understandable.

We've been using it for seven months.

So far, it has been really good. They have an alert console for any time they're having some slowdowns or anything like that. They're very proactive in alerting us, but there have been very few occasions where we experienced too much lag or slow down. It has been pretty robust.

It's great. That's the reason we like it. It offers us so many tools that we're building out even more in our toolset. It gives us things we didn't have in the past, such as some of the SOAR capabilities and things like SecOps.

I have contacted them a couple of times. They were great. They were quick to assist us. Two different times, we were hitting some issues that were rather complex, and they jumped on calls with us, and we were able to resolve them.

Positive

We used McAfee Nitro. We switched because the technology was very slow and outdated. It wasn't keeping up with the times. Keeping the 365 days of hot data was getting extremely expensive and cumbersome because of the number of disk resources we had to throw at it. The support and updates to the platform were manual because it was an on-prem solution. So, anytime we had to do a major rollout of a SIEM upgrade, it took hours, and it was always problematic, whereas, with a SaaS solution, it's just done in the backend for us.

Implementing Devo has helped reduce blind spots versus our previous SIEM solution especially when it comes to cloud products. McAfee Nitro SIEM had pretty much zero cloud connectivity. We're pretty heavy with Azure and M365 stack, and they had no connectors to get any of those logs into our SIEM. So, we were completely blind to our cloud products.

The biggest impact is that we're able to proactively recognize issues that we're having in those cloud environments. Previously, they were either discovered by somebody accidentally, or an issue arose or an incident happened and we had no alerting around it. We had to triage afterward, whereas now, we have alerting. So, we get those alerts ahead of time.

I led the deployment project. Any project is complex to a degree, but it was as straightforward as they could make it.

In terms of the implementation strategy, we mapped out everything. We had a corporate-wide project around it. The Devo team was completely a part of the deployment project along with our third-party MSSP. The three teams worked together through the entire project. From Devo's side, Rory gave us a hand. Yailin Perez was great. William Wilde was really good. He's a great engineer over there.

The migration piece wasn't bad at all. The initial build-out was a little bit cumbersome, but that goes with any system. For standing up the relays, endpoint managers, and things like that, there was some lead time. It took us about three months just to get everything built and in place for our on-prem pieces to send the information to Devo, but once we were up and rolling, we moved all of our log sources and all of our alerting in just over 90 days.

The ease of migration was extremely important because we were very close to the end of our licensing with our previous SIEM, and we didn't want to relicense and pay for support if we didn't have to. We were able to migrate quickly and avoid that expense.

Devo's team was with us every step of the way. We had weekly stand-ups three times a week, and anytime we reached out to them, they jumped on a call with us immediately. They gave us really good first-line support, and their professional services team was great. They were very knowledgeable, and they assisted us a lot. Our experience was great.

It wasn't difficult at all to get our staff up to speed on using the solution. They provided us with some free training and most of our teams took the free training. So, we were able to hit the ground running as soon as we had the solution in place.

For deployment, internally, we had four resources from four different teams. We had representatives of the Linux team, the Windows team, the security team, and then our procurement team. We also had members from our MSSP as well as from Devo.

In terms of maintenance, it requires very little maintenance. There are just the log sources themselves and other day-to-day things. The solution itself has been no problem. We don't have anybody dedicated to its maintenance. I own the product from a team perspective. So, I'm 100% engaged with it, but everybody in our team uses it, and we all manage it to some degree. We don't have anybody dedicated to just it. It doesn't need it.

We have absolutely seen an ROI. We've been able to hire one more analyst with the money we saved on our licensing.

We extracted value within the first two weeks because we were able to ingest our cloud solutions, but at the 60 to 90 day point, we 100% realized our investment, and we were completely satisfied.

It's very competitive. That was also a primary draw for us. Some of the licensing models with solutions like Splunk and Sentinel were attractive upfront, but there were so many micro-charges and services we would've had to add on to make them what we wanted. We had to include things like SOAR and extended capabilities, whereas all those capabilities are completely included with the Devo platform.

I haven't seen any additional fee. 

We looked at seven different competitors. We looked at Splunk. We looked at Sentinel. We looked at LogRhythm, and we reviewed the newer McAfee SIEM. We did our due diligence. We looked at a lot of them. We did a POC on LogRhythm as well as Sentinel and Devo. We did a bake-off, and Devo was the clear leader.

The biggest thing that we were very careful about was figuring out what our ingest level is ahead of time. It can be very difficult to reach that conclusion, especially when native SIEMs or legacy SIEMs do more ingest on logs per second or events per second, whereas Devo ingests using gigs per day. So, spending some time to figure out that calculation so that you don't over-license or under-license is critical. We were very lucky, and we hit those numbers, but a primary concern of ours at the beginning was making sure we didn't under-license. You don't want to have to expand your licensing and go back to ask for more money.

The biggest lesson that I've learned from using this solution is the way they do the ingest. You don't have to categorize the data ahead of time before ingestion. You can throw all the logs you want at it and then go back and do a correlation afterward. That's the biggest thing we learned. It's a great solution and most other SIEMs don't do that.

Overall, I'd rate it a nine 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.

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.