Devo Reviews

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

Devo certainly helped us deploy it initially.

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

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

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

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

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

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

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

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

We are primarily using the solution as a cloud observability platform.

Most use cases are related to service operations, not security operations. This is due to the fact that in security operations our company uses Splunk and other platforms. In this case, in my team, we are using Devo for service operations requirements. We correlate across metrics and trace on that data to understand root causes. For example, we'll look at metrics in jobs, time processes, root cause investigations where we have fails, job performance, deals, payments, et cetera. 

With Devo, you integrate and run as a fully managed service. We are very interested in the total of severability for IT and the organization all in a one user interface. With Devo, all analysis is done in a graphical user interface. That gives our analysts the confidence to investigate a problem and fix it.

For example, we can have a lot of matrices and trace data in a single user interface. We can eliminate swivel chair analysis among tools for a streamlined workflow that gives us the most direct path to the root course. 

Devo provides great structural data. Its business-rich data set means better, smarter machine learning and this leads to a smarter analysis of anomalies and a stronger predictive analysis.

Devo, unlike other vendors, doesn't charge extra for playbooks and automation. 

It's very, very versatile. 

Service Operations is a tool inside the product. It offers a constant standard with advanced machine learning. The Devo machine learning workbench also enables you to bring in your own custom-built machine learning models. This is very interesting for us.

I need more empowerment in reporting. For example, when I'm using Qlik or Power BI in terms of reporting for the operations teams they also need analytics. They also need to report to the senior management or other teams. The reporting needs to be customized. You can build some widgets in terms of analytics and representations, however, I want to export these dashboards or these widgets in a PDF file. While you can explore everything as a PDF, it's not very complete. I am missing some customization capabilities in order to build a robust, meaningful report.

The initial setup is a little complex.

Technical support could be better.

There do seem to be quite a few bugs within the version we are using.

In the next update, I'd like it if they explain more about the Devo framework. The Devo framework is a tool inside the product. It's a prototype. It is a tool that provides to the customer a map of processes or a workflow, for example, with an HTML application with a front end. My understanding is that each component of this front attaches data with the queries. It might be customized. I'd like to generally understand this better.

I'd like to understand DevoFlow. Up to now, usage could send data to the platform, retrieve it and enrich it by generating graphs and analytics. However, it's my understanding that Flow provides users the ability to process the data in real-time by defining complex workflows as soon as data arrives in the platform so that you can make analytics in a sequence. I'd like to better understand these new capabilities.

I've been working with the solution for one and a half to two years or so. 

At this moment I consider the solution to be stable. However, I find that I perform any little fixes throughout a project. There are bugs here and there that I do contend with. I'd prefer to have these fixed as opposed to having to install a whole new version.

In the beginning, there were not more than 20 to 25 users. However, our objective remains to get 100 people on the product. We add them little by little due to the nature of our projects.

In terms of scalability, it's a product well-focused on expansion. As a SaaS, they provide you more architecture, more machines in terms of performance, et cetera. We're quite happy with its capability to expand.

Technical support needs to be more direct. For example, when we submit a ticket, the support team will delegate a task to the operations team, for example, or various other teams. This muddles the transparency. We're unsure as to who is in charge of fixing the problem. I simply want an answer to my problem and I want them to fix it and tell me what is wrong. I don't need to know it was sent here, there, or there. We are not 100% satisfied with the level of service provided to us.

The initial setup was a little bit complex, however, we had great support from the Devo team. We are using the public cloud - not on-premise. They provided us the infrastructure. The complexity was mostly around how to build the VPN securitization, the tunnel, as this tunnel was built by us, not by Devo. We, therefore, had to build a lot of technical tests of communications. This was complex.

With Devo, we have to connect by LLDP protocol. For example, Devo at the beginning shows the users as an email and a password. In our company, we needed to connect this mechanism of access to our own mechanism of the corporation. We had to deal with the protocol of connectivity of users, FSAA, for example. Sometimes this was difficult and we had to make a lot of test connections, et cetera.

There isn't too much maintenance required. Devo provides the product. I have to ensure that the mechanism of communication is stable and in continuous service. Our VPN with the tunnel is the responsibility of us while the persistence of data and the performance of searching data representation is the responsibility of Devo.

Devo assisted us with the implementation process.

Devo, like other vendors, doesn't charge extra for playbooks and automation. That way, you are only paying for the side on the data ingestion. If you sign a contract, you are able to process as much as 500 gigabytes per day. With this price, you can connect 10 people, 20 people, 18 people, 80 people - it's very good. It's very efficient in terms of the cost of the license. 

Depending on if you are ingesting more than you sign up for, you have to pay more. There is potential for extra costs only in this one aspect, and not in the other services, or in other people who connect to the product. 

Devo provides you professional services. Professional services is a manner to give service to the clients in terms of consultants. Expert consultants help the customer to design the business case and can show them how to build it. This is an extra option, for people who want to take advantage of their insights.

I have done a lot of assessments with Devo against other products such as Elasticsearch, Kibana, Splunk, and Datadog, among others.

We're just customers and end-users.

We are using the most recent version of the product.

We are using Devo in a public cloud with some other web service we have secured with a VPN built in the company so that it's tunnel secured.

I would rate the solution at an eight out of ten. If the solution required fewer fixes and was a bit more flexible, I would rate it higher.

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

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

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

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

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

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

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

I like their query language and I like their speed. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Support was included in our licensing.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We are using their latest version.

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

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

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

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

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

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

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

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

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

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

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

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

I've had no stability issues. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Five to six years, going back to 2014.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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