We have most of our major log sources going to it, and we have both an internal NOC as well as an external MSSP that does 24/7 monitoring. We use it for writing all of our alerting use cases for different correlations between all of our different logging apps.

In terms of our environment, we have several departments. We're a staffing company, and we have a lot of different contractual obligations with other companies. So, it's a fairly complex environment. We have multiple domains. We have several DMZ environments, and we have three active data centers.

We look at this solution for both security monitoring and operational monitoring use cases. It helps us to understand any kinds of security incidents, typical-scene use cases, and IT operations, including DevOps and DevSecOps use cases.

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

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

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.

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.

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.

We are a value-added reseller focused on cybersecurity and big data analytics. Devo is a premier partner of ours. We not only resell Devo but we provide deployment services, content development, and analytic services for Devo customers.

Our primary use case is so we have historical logs in case of an event or if we need to do any troubleshooting.

Our secondary use of Devo is for incident detection; certain logs trigger alerts, so we now have a 24/7 monitoring service that detects and alerts us to incidents. 

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.

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

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

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

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

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

We are using their latest version.

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.

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.

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.

During the pandemic, small and medium companies didn't buy big servers. Latin American countries only used Devo in industries, maybe banks or security government projects. We create server appliances, such as servers plus switches.

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

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

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

We have several use cases for Devo. The first is related to the security center (SOC) operations, and they do the log correlation for Devo security.

We now have fraud use cases and application monitoring use cases, and we're starting to work on some use cases related to business analytics.

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

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

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

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

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

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