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.

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

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

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

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

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.

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.

I rate the solution seven out of ten.

Devo's cloud-native SIEM increased our threat visibility, though we had hoped for a bit higher. Visibility is critical, as we rely upon knowing about security incidents as soon as possible. We expected the solution would provide additional insight, but we're finding it isn't. Devo gives us the historical logs, a fantastic capability we are very happy with. However, the incident and threat detection is not what we had hoped for. Regarding security operations, the tool is different from what we wanted.

Getting our staff up to speed with the solution was right in the middle in terms of difficulty. It wasn't as easy as we had hoped, but it wasn't insurmountable by any stretch of the imagination. Devo provided us with several training sessions, and I wonder how much that helped because our group is very technical. The tool's interface is intuitive, so our staff can find what they need. With regular use, the learning curve is relatively low, but without that, it can take some getting used to, as with any solution. Devo is broad and encompassing, so it requires familiarity to leverage it fully. We don't have dedicated internal staff to manage the solution, so we outsourced the monitoring to an MSP.  

The migration from QRadar to Devo was relatively straightforward and painless; we essentially cut the cord on QRadar, maintained the logs and moved them over to the new solution. The ease of migration was relatively important, the old solution was antiquated, so we expected any newer tool to be better. 

Migrating the bulk of the initial logs took about three months. We got some aspects up and running during a proof of concept while we were still using the old solution. Once we went live, we migrated the POC environment to a production environment, so it was much less stressful than it could have been. 

The Devo team was intimately involved in the migration. They weren't as responsive as we had hoped, and they seemed new and didn't completely understand the product. We received better support on escalation; overall, they were critical to the migration.

Before going down this path, I advise potential customers to document their log sources and what information they need based on their use cases.

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

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

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

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.

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.

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

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

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.

I rate Devo a nine out of ten.

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

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

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.

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.

Devo provides multi-tenant cloud-native architecture but in our organization, I would rate it a six out of ten in terms of importance. The feature is important, although not so much for our specific use case. I don't expect that this will change in the next few years.

I would rate this solution a nine out of ten.

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.

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