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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. 

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.

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.

Initial setup with Devo is very straightforward.

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

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

The initial setup was relatively straightforward. 

In terms of maintenance, I go through every quarter to ensure that each of our log sources is still sending logs to Devo. We were a little disappointed that they didn't have a good way of informing us if a log source stopped sending logs. I appreciate that each source sends on a different frequency, but we should be able to define that frequency and receive a notification of any issues.

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.

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

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

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. 

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.

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.

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.

We have two options with the initial setup. One is we buy the chassis from the OEM and customize the server. I prefer the OEM server because we have a customized image-focused VLAN, so it is easier for the integrator or customer to set it up. You just need to open the box, turn the server on, and they are ready to install the DNS software.

We have another option where we resell only the Devo server. We are just starting to do this, and it is not easy to assemble because we need a lot of skill.

The time taken to deploy Devo depends. If the final customer has everything done, or if everything is correctly installed, the rack, the air conditioner, or the UPS, it takes two to three hours at most to customize the server and the network card. We need two or three people for labor when the integrator installs the server. We need just one person to configure the server.

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.

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

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

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

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

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

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

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

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

The initial setup is straightforward. It took approximately one week to deploy.

The Devo implementation team came to our building and installed everything. After that, we moved all of our information, which included creating a copy of all of the logs that we had in the other solutions. Once that was complete, we were able to start working with Devo.

Our implementation strategy was originally part of a four-year plan. However, we finished the full implementation early and the four years were reduced to six months.

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

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

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

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

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

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

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

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

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

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