Devo Reviews

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

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

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

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

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

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

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

Neutral

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I've been using Devo since December of 2020.

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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 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 it for monitoring our core set of network devices, our key systems. We're collecting all the log traffic and using it as a platform to correlate and set up alerts to monitor, and looking for any suspicious behavior.

One of our early use cases is for compliance and we've set up dashboards that pull in the logs that we need. We have formatted it the way we need it to look and when we meet with internal audit we just show them the dashboard and they have all the information that they need. That's one of the early wins that we've had with it.

When it comes to network, endpoint, and cloud visibility, Devo makes it easy to see all of that. It's all on one dashboard, it's all visible. Instead of having to jump from system to system to system, we can see all of our web traffic and we can see endpoint stats, and whether we need to investigate anything. It's very useful. It definitely raises the level of confidence when we need to take action, compared to our last tool. When a forensic investigation moves forward and we have to do a deeper dive, all that data is there. And the integration team that we're working at Devo is very good at tuning it and showing us what we need. They show us how to extract the relevant pieces and not worry about the less relevant pieces of information.

The solution has saved us time, although we're still in the learning stage. We've only had it in place for three months. I would venture that it's probably saving a few hours a week per analyst, but I expect that to grow as we get better at using it.

It's very intuitive. The interface is extremely useful. You can perform many functions from one page. In other tools that we looked at, you'd have to toggle back and forth between screens and you'd have to exit one menu and copy and paste things into another section. With Devo you can do everything using drop-downs. It's very user-friendly when creating queries and dynamic lists. You can modify the interface to look the way you want with columns and sorting. It's very well thought out.

It provides high-speed search capabilities and near real-time analytics. These things are extremely important. 

It's also very easy to pull data into it from various log sources, even if they're custom homegrown apps. The parsers are also very easy to use.

If all of the connectors for the third-parties were there, it would be a solid 10. Everything else about it is right there. It's a newer product, so we knew going in that there would be some growing pains and that some things might not be available because not all third-parties would be included.

I've been using Devo for about three months.

So far, it's been rock-solid. There have been no issues at all.

It should be able to grow as we need it to. It is a SaaS solution, so if we need more data we just purchase more bandwidth.

The size of our environment is about 14,000 users, globally, and about 20,000 endpoints.

We haven't had to use their technical support yet. We've only been working with the integration team.

They've been great through the deployment. Obviously, there are going to be little bumps in the road and their team has been very helpful. I've worked with other integration teams that wouldn't even look at the possibility of an issue being at their end until you exhaustively proved that it wasn't at your end. Devo, on the other hand, was very willing to help. They would jump on a call, review the config with us and look through it. They're very willing to spend time and investigate with you; not just push it back on you to double-check everything. They have also pulled in other resources. If the integration engineer didn't know an answer, he would very quickly, usually on the same call or later that day, get another engineer on the phone who was knowledgeable, and we would work through the issue. They're very responsive and it's a very good customer experience. Customer service is very important to them.

Their willingness to go the extra mile and just jump on a call anytime, without having to schedule a call, is an example of where they have exceeded expectations. The project lead would just jump on a call and answer questions anytime.

It was fairly easy to deploy. We had a good deal of on-premises devices where we installed a relay that forwards the log information to the cloud. We also use a large number of SaaS tools. With those it was just a matter of an API connector. Things went very smoothly.

Getting logged in to it and getting logs identified took a week and a half to two weeks.

There were three members of my team involved. One was more focused on getting the collector built and connected, and getting all of our internal log sources forwarding to that. I had two other engineers working on the deployment side, working on rules and carving out the data to send it to specific buckets. Those three are also the ones who take care of maintenance of the solution. We're still in the early stages so we're tweaking things and constantly modifying and figuring out our internal processes.

We used Devo's integration professional services. They worked alongside with my team and they have been excellent.

So far we've seen ROI from the fact that when the auditor comes in quarterly and looks at it, as happened the other day, they are extremely impressed. The return value is going to be there. It's already starting, where we're creating custom dashboards for various groups to look at their own data. We don't have to provide reports anymore. We just give them the data and they can log in and look at whatever they want in real time.

It's going to be huge as we move further down the road and we learn to better utilize the tool. We have some big plans for it.

Regarding pricing they were in the ballpark with most of the others we looked at, but one of the things that put them above and beyond is the 400 days of storage. That's big. 

They're a newer company so they may have cut better deals, but they were in the ballpark with at least a couple of the other front-runners that we were looking at. Devo is a good value and, given the quality of the product, I would expect to pay more.

The fact that Devo only charges for ingestion works great for us. In some of the other solutions we looked at, depending on what you were doing with the data, extra charges were assessed. If you wanted to pull playbooks in, that was an extra charge. If you wanted to ingest certain types of logs from certain systems, that was an upcharge. In our environment and our business model, the month-to-month fluctuating charges just weren't an option, and many of the other solutions are going down that road. Devo provides good value: "Hey, here's your ingest, here's what you're licensed for, and here's what your annual bill is going to be. And if you go over that, then you true-up the next year." So it is a beneficial model for us.

Overall, with the pricing model, Devo enables us to ingest more data compared to other solutions we evaluated. We don't have to worry about being billed more if we use any additional functionality or that we may have to set a cap on the ingest for the month or the week.

The fact that the solution keeps 400 days of hot data to look for historical patterns was extremely important because many of the competitors kept 90 days or maybe six months. We looked at the big choices that most other companies use. And with those competitors, if you wanted the extra data, it would be put into warm or cold storage and to utilize it you'd have to pull it back in.

Another one of Devo's advantages is, as I've mentioned, the user experience. It's well thought out and the workflows are logical. The dashboards are intuitive and highly customizable.

There are a few drawbacks to it. Some third-parties don't have specific API connectors built, so we had to work with Devo to get the logs and parse the data using custom parsers, rather than an out-of-the-box solution. Most of our third-parties are working on them because it seems that Devo is making some waves in the industry and more and more people are using them. But that has been what we've had to do with three of our third-parties that didn't have a connector. Devo had to create one, and, once again, their customer service was great. They just built it for us and it worked.

When it comes to analyst threat-hunting and incident response, because there are so many options, and Devo has the ability to do many things from one screen, the workflow is a lot more organic and natural. That means you can drill down to the level you need to and pull in the data you need from one screen. You don't have to keep moving around in Devo. It's much more configurable and the options are there to pretty much dig as deep as you need, from one screen.

Overall, Devo approached things a little differently and that's why we ended up going with them.

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.

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

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

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

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

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

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

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

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

The UI is 

• clean
• easy to use
• intuitive. 

They've put a lot of work into the UI. There are a few areas they could probably improve, but they've done a really good job of making it easy to use. For us to get engagement from our engineering teams, it needs to be an easy tool to use and I think they've gone a long way to doing that.

The real-time analytics of security-related data are super. There are a lot of data feeds going into it and it's very quick at pulling up and correlating the data and showing you what's going on in your infrastructure. It's fast. The way that their architecture and technology works, they've really focused on the speed of query results and making sure that we can do what we need to do quickly. Devo is pulling back information in a fast fashion, based on real-time events.

The fact that the real-time analytics are immediately available for query after ingest is super-critical in what we do. We're a transportation management company and we provide a SaaS. We need to be able to analyze logs and understand what's going on in our ecosystem in a very close to real-time way, if not in real time, because we're considered critical infrastructure. And that's not only from a security standpoint, but even from an engineering standpoint. There are things going on in our vehicles, inside of our trucks, and inside of our platform. We need to understand what's going on, very quickly, and to respond to it very rapidly.

Also, the integration of threat intelligence data provides context to an investigation. We've got a lot of data feeds that come in and Devo has its own. They have a partnership with Palo Alto, which is our primary security provider. All of that threat information and intel is very good. We know it's very good. We have a lot of confidence that that information is going to be timely and it's going to be relevant. We're very confident that the threat and intel pieces are right on the money. And it's definitely providing insights. We've already used it to shore up a couple of things in our ecosystem, just based on the proof of concept.

The solution’s multi-tenant, cloud-native architecture doesn't really affect our operations, but it gives us a lot of options for splitting things up by business area or different functional groups, as needed. It's pretty simple and straightforward to do so. You can implement those types of things after the fact. It doesn't really impact us too much. We're trying to do everything inside of one tenant, and we don't expose anything to our customers.

We haven't used the solution's Activeboards too much yet. We're in the process of building some of those out. We'll be building dashboards and customized dashboards and Activeboards based on what those tools are doing in Splunk. Devo's going to help us out with our ProServe to make sure that we do that right, and do it quickly.

Based on what I've seen, its Activeboards align nicely with what we need to see. The visual analytics are nice. There's a lot of customization that you can do inside the tool. It really gives you a clean view of what's going on from both interfaces and topology standpoints. We were able to get network topology on some log events, right out of the gate. The visualization and analytics are insightful, to say the least, and they're accurate, which is really good. It's not only the visualization, but it's also the ability to use the API to pull information out. We do a lot of customization in our backend operations and service management platforms, and being able to pull those logs back in and do something with them quickly is also very beneficial.

The customization helps because you can map it into your business requirements. Everybody's business requirements are different when it comes to security and the risks they're willing to take and what they need to do as a result. From a security analyst standpoint, Devo's workflow allows you to customize, in a granular way, what is relevant for your business. Once you get to that point where you've customized it to what you really need to see, that's where there's a lot of value-add for our analysts and our manager of security.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

And the cost savings over Splunk is about 50 percent.

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

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

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

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

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

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

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