What is our primary use case?
We create solutions around the Devo platform and sell those solutions to our customers.
I use it as a managed SOC, or "SOC as a Service" for customers. I also use it as our managed detection and response platform, where everything goes back into the data lake for analysis and alerting.
How has it helped my organization?
Devo is very easy for our analysts to use. They have the LINQ language, which is easy, and it's like an Excel on steroids.
Devo provides high-speed search capabilities and real-time analytics, which is important to us because we have built 30-minute SLAs. In reality, our detections are within seconds and we allow for 30 minutes as a buffer to ensure that we are successful for our clients. To this point, we haven't found any type of dataset or any data ingestions that has prohibited us from meeting our SLAs.
In the world of cyber, you have to detect things right away. You can't wait hours, days, or weeks. It needs to be detected in an immediate, automatic fashion. Then, with their capabilities to integrate with a SOAR solution, it provides detection and response capability all within seconds, instead of days.
We use Devo more as part of our consultant-based service and the true multi-tenant flexibility, combined with the scalability of AWS, means that we can reach a wide range of customers. For example, we can go outside the United States into the European Union or into the AsiaPac region very seamlessly and very fast, as we're growing our business for managed detection and response in those areas. Just this week alone, we were able to quickly spin up a client in the India region, and we were able to address their concerns and get that spun up very quickly because Devo has that capability already built within AWS. It was approximately a one-day turnaround for us. It's important to us that the product is this nimble, which is in turn because of the AWS architecture.
Devo provides us with 400 days of hot data that we can use to look for historical patterns, which is a key element for us. It means that we can offer our clients different periods for different compliance reasons, such as HIPAA. For the most part, our clients use the 30-day capability but if they are a biotech company then they want to keep data for 180 days. We've had a couple of companies that wanted it for 400 days. The flexibility to keep that hot online is key because they can scale up and scale down at any time they want, and although there is an additional cost to the client, there is no additional infrastructure required. That said, probably 75% of our clients are utilizing the 30-day storage.
This solution gives us better cloud visibility because we're able to ingest any of the cloud logs. We push an EDR agent that then brings all of that telemetry back, and we have correlations with any proxy logs, firewall logs, or authentication logs that we need to have. This gives interoperability between the different log sources. For example, if we see something in an EDR that we want to ensure is connected outbound to something, we can check that through the proxy log and DNS logs that we get from the EDR agent.
This gives us more confidence when it comes to taking action because we'll get that running process, and we are also able to collect the DNS information, which then goes into Devo and we're able to search for it. We can see whether it reached out to this particular URL. What we can do is then go to that proxy server or the firewall log, and just see the outbound traffic and validate it is the same session size or same connection time. This acts as a dual authentication to show that what we saw in the EDR was what we saw on the network as well.
Devo helps us to unlock the full power of our data because they have more than 450 parsers, which means that we can ingest pretty much any type of log data. If we need to, we can go to the Devo professional services and have a log parser created within 48 hours. Any log that we need to ingest or want to ingest or the customer has compliance reasons to ingest, we can. This gives us the flexibility to bring in the core logs that we really need to do our detections or to manage the SOC, together with any other logs that we need to bring in for either correlation purposes or compliance purposes. There's really no type of log that we can't bring in.
This solution saves us a lot of time, although I don't have a before and after to compare because this is the first solution of this type that we implemented. I know of similar solutions in use at other companies that have problems doing what we do, but I don't have a baseline that I can use to calculate time savings.
What is most valuable?
We really use the core feature, which is log management. We bring in and ingest all of the different log sources for our customers and then run our TTPs (Tactics, Techniques, and Procedures) against these for threat detection.
I find the true multi-tenancy to be very valuable. We are able to put all of our detection rules onto our master tenant, and then run those to our sub-tenants when we're looking for all of the detections and alerts. It's essentially the core capability with the kind of vertical app for all of our TTPs that run across our different subdomains.
A big selling point to me is the multi-tenancy. First, we give permission to our clients to log into their domain, and second, we can run different analysis detection rules on different domains, depending on their business vertical. Some of our clients are in the aerospace industry and some are in biotech. They have different concerns than other domains do, so we can write TTPs or detection rules specifically for them because of the multi-tenancy. It doesn't conflict with everybody else. It's not a one size fits all approach, so the multi-tenancy feature is a very key attribute of why we went forward with Devo.
What needs improvement?
We only use the core functionality and one of the reasons for this is that their security operation center needs improvement. It's great for folks that don't really understand advanced detections but for people like us, and other businesses out there that have advanced detections, that becomes problematic and we don't use it.
The detection capabilities and their vertical app capability should be enhanced.
For how long have I used the solution?
I have been working with Devo for two years.
What do I think about the stability of the solution?
This is a very stable solution. We have an uptime of 99.85% from an SLA perspective, and they've never gone below that.
What do I think about the scalability of the solution?
As scalability is tied to AWS, this is a very scalable product. This means that we are able to quickly and easily offer our service in other regions, outside of the United States.
The scalability is a positive point when we're talking to the larger customers. It helps that Devo does not index everything but a lot of it has to do with AWS.
We have a couple of hundred customers and each customer has a few users that access it. At each client site, there are between two and five users that have access to it.
Our plan is to increase our usage. In fact, my company is doubling down on our MDR solution, and the main core of it is Devo. Even at this point, Devo is well-utilized. I expect that in 2022, everyone in the company will be focused on it.
We have 15,000 employees and 300 product lines, and we're looking to make sense of anything that is an opportunity for cross-selling.
How are customer service and support?
Technical support is very good.
We're somewhat like partners of Devo, meaning they'll refer customers to us to manage their environment. They are definitely an ally to our business. We have pretty advanced knowledge of the product, so whenever we really need something, we file a ticket just like everybody else does, but it's usually pretty advanced. This means that we're usually dealing with the professional services folks and we have a really good relationship with them.
Overall, support is very responsive and they take care of any problem that we have pretty quickly.
Which solution did I use previously and why did I switch?
This is the first solution of this type that we implemented.
At other companies, where my teams have come from, it has been very challenging to do the same tasks that we're able to do inside of Devo with other platforms. This is either because they have to index everything, whereas Devo doesn't, or because they don't have a true multi-tenancy. Perhaps they have to bounce between different systems, or because they don't have certain capabilities when it gets above 10 terabytes of data. For instance, at that point, it becomes very problematic to run searches because they'll fail or they'll time out.
The products that my teams were familiar with were Splunk, Sumo Logic, and LogRhythm.
How was the initial setup?
The initial setup was pretty straightforward. Their documentation is really good and we send it to our customers. It is very precise on exactly what you need to do and how you need to deploy the relay.
We deploy this solution on almost a weekly basis, and it can be done within hours.
Our implementation strategy maximizes ease of use for our customers. We have everything come into one or two forwarding points, then create the certification and push it out to the client. We created an executable that makes it seamless for the client and once that connects, the data flows right into the SIEM. It's the same thing with the relay, which is the other way to get data into the SIEM. The relay is very lightweight, running on VMware Ubuntu.
What about the implementation team?
Our in-house team is responsible for deployment.
Each customer is assigned a project manager, and usually, each project manager has 35 customers. My other staff includes a technical project manager, a SOC analyst, and a threat hunter.
What was our ROI?
I have seen a return on investment, and without disclosing figures, I can put it in terms of capabilities. This product allows us to scale up the way we need to, without any additional costs, or there's already a fixed cost with that. This is key for us.
We can bring in any size of customer, from the smallest client to the largest company. Also, I have been able to bake in the pricing model to adjust to the margin that I need for a specific customer.
What's my experience with pricing, setup cost, and licensing?
The pricing is very straightforward and they charge per gigabyte. There are no "gotchas" when it comes to pricing. There's no re-ingestion or exfiltration of it.
With respect to retention, it's what you need it to be. They can scale up and scale down and everything is pretty straightforward. Pricewise, I can't think of any things that I wish I would've known ahead of time.
Pricing is based on the number of gigabytes of ingestion by volume, and it's on a 30-day average. If you go over one day, that's not a big deal as long as the average is what you expected it to be.
The fact that the vendor only charges for ingestion is something that I have been able to use in my practice, and I've built pricing models around that. I think that's probably one of the only ways that they can do it from a SIEM perspective. But, from an MSP perspective, because everyone's looking for per-endpoint pricing, it becomes challenging. It means that we have to use some fuzzy math to come up with something the makes sense such that data ingestion equals endpoint pricing.
Which other solutions did I evaluate?
We evaluated Splunk and LogRhythm. Splunk had great analytics but at that time, two or three years ago, their cloud wasn't as developed as it is now. Also, pricing was another major issue.
I do know that Splunk is a lot more challenging when it comes to threat hunting. You have to know the queries to be able to write in the Splunk query language, and it's a little bit more challenging, whereas Devo seemed to be a little bit easier.
Devo is very much like Excel, where you open up a window and hit data search. So, the workflow for threat hunting was very good and it was seamless. They had a lot of good breadcrumbs and it had a good workflow as it related to threat hunting or threat detection.
From a log parser perspective, Devo is able to ingest more data when compared to other solutions. By default, we can ingest any log source that we need to with Devo. With Splunk, at least when we did our evaluation, that was a little bit less on the scalability, and then LogRhythm, we really had a challenge with.
What other advice do I have?
The vendor has exceeded our expectations in terms of being responsive to some of the things that we want to do. We're always trying to push the envelope and try to be creative with vertical apps. They've gone out of their way to help us in this regard. Whenever I call them, they definitely respond to me, and this is outside of the regular ticketing system. The good thing is that I very rarely need to call them.
My advice for anybody who is implementing Devo is to have an understanding of the log sources that you want to ingest and make sure that they comply with your budget. This is true for any SIEM. It is important to recognize that you're getting charged based on ingestion volume because a lot of people don't realize that. If you have logs that aren't necessary to your business, I would not ingest them because it's just going to increase your budget.
The biggest lesson that I have learned from using Devo is that the benefit of having different log sources is that we can get to the truth faster. It allows us to validate our findings in a shorter period of time, which has been invaluable.
I would rate this solution a nine out of ten.
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.