How Arctic Wolf Modernizes Cloud Security and Enhances Threat Detection with Databricks

Summary

• Arctic Wolf security modernization: This video shows how Arctic Wolf eliminated data silos and enhanced their MDR pipeline to investigate suspicious threat actors using the Databricks Data and AI platform.
• Data lake threat detection: Learn how to build scalable data lakes for security operations and create ML models that deliver threat hunting tools to SOC analysts on the Databricks Data and AI platform.
• Gen AI for cybersecurity: Discover how generative AI on the Databricks Data and AI platform enables faster cybersecurity incident response and improved threat detection for modern security operations.

How Arctic Wolf Modernizes Cloud Security and Enhances Threat Detection with Databricks

Talk by Amisha Singh, Sr. Delivery Solutions Engineer, Databricks ; Justin Lai, Distinguished Data Architect, Arctic Wolf
In this video, you’ll gain actionable insights to modernize your security operations and strengthen cyber resilience. Arctic Wolf will highlight how they eliminated data silos & enhanced their MDR pipeline to investigate suspicious threat actors for customers using Databricks.
Here’s more to explore:
Unified and open governance for data and AI: https://www.databricks.com/product/unity-catalog
See all the product announcements from Data + AI Summit: https://www.databricks.com/events/dataaisummit-2025-announcements

FAQs

How can Databricks improve cybersecurity operations?

This video demonstrates how Arctic Wolf used the Databricks Data and AI platform to build a scalable data lake that unifies security data, eliminates silos and enables advanced threat detection and response capabilities.

How do I build ML models for threat hunting?

Learn how to develop ML models on the Databricks Data and AI platform that deliver threat hunting tools directly to SOC analysts. These models enable faster investigation of suspicious threat actors and reduced incident response time.

How is Arctic Wolf using Databricks for security threat detection?

This video showcases Arctic Wolf's use of the Databricks Data and AI platform to detect and respond to cloud security threats at scale. Arctic Wolf combines data from multiple security sources, analyzes it with machine learning models running on Databricks, and identifies anomalies and threats in real-time. The platform's ability to handle massive data volumes, perform sophisticated analysis, and provide AI-driven insights enables Arctic Wolf to deliver managed security services that would be impossible with traditional infrastructure.

What role does AI play in modern cloud security?

AI and machine learning are essential for modern cloud security because threat patterns evolve faster than manual detection rules can adapt. This video demonstrates how the Databricks Data and AI platform enables Arctic Wolf to train models on historical security data and continuously detect new threats. By combining pattern recognition with contextual analysis, the platform enables security teams to respond to sophisticated attacks in minutes rather than days.

How can organizations modernize their security infrastructure?

Organizations can modernize security infrastructure by adopting AI-driven threat detection platforms like Arctic Wolf that leverage the Databricks Data and AI platform. This video shows that modern security requires consolidating data from diverse sources, applying machine learning analysis, and automating response workflows. Databricks enables this modernization by providing the unified analytics and AI platform required to process security data at scale while maintaining compliance and audit requirements.

Full transcript

Well, welcome everybody. Thanks for coming. I am the head of cybersecurity marketing here at Databricks. Just really excited to you know, to have cyber as a key growth pillar. If you were at the cyber forum yesterday, I talked a little bit about how has stated this year that cyber is going to be a primary growth driver for the company. It's a bit of a nascent business at this point. But one of the main ways that we're going to grow our cyber use cases and our revenue is through awesome partners like Arctic Wolf.
So they're one of our biggest partners in cyber and today you're going to hear from and Amisha how they're enhancing security with Databricks. So I'll pass it to you guys. Thank you. Good morning everyone. My co-presenter Amisha and I are so excited here to be here today to talk about enhancing cybersecurity with Databricks and Gen AI. For today's talk, we're going to talk about all the great things we're doing within our data lake, using Databricks to create ML models, delivering threat hunting tools developed in Databricks to our MDR SOC analysts in order for them to respond to cybersecurity incidents faster.
A little bit about myself. I spent the past 10 plus years in the security space. I've been doing five years I've been working with Databricks for five years now doing development there. I'm setting up the and I was part of the initial team that set up the initial implementation of our data lake strategy in Silence and Arctic Wolf. I've guided our the evolution of a lake data lake platform from one pipeline to a data platform serving a diverse set of internal users.
Hi everyone. I'm a senior delivery solutions engineer here at Databricks. Over the past two years I've had the pleasure of working with our manufacturing and high-tech enterprises to design scalable applications on the Databricks platform. And today we're really excited to talk you guys through to what through one of our unique and rewarding journeys and our partnership with Silence and innovator that's been redefining how the cybersecurity approaches threat detection and response.
Before we dive into the solution itself, I do want to take a moment to zoom out and share some context around how we got here and what problems we set out to solve. So to give you a brief rundown of Silence, it was founded in 2012 and was a pioneer in AI-driven threat prevention. And after their acquisition by BlackBerry in 2019, they expanded into enterprise security through mobile and endpoint intelligence. And finally in 2025, BlackBerry Silence joined forces with Arctic Wolf Networks, a recognized leader in the MDR XDR space.
And this has been a natural evolution blending Silence's prevention-first DNA with Arctic Wolf's robust security operations and SOC expertise. We've been partnering with Silence since early 2020s. And what began as laying the foundational bricks within Databricks has since evolved into a deeper collaboration. We have been supporting Silence's transformation into a modern AI-driven security organization. And throughout this time, the land the cybersecurity landscape has continued to evolve facing increasingly sophisticated threats and data sprawl.
But the focus for Silence remains on faster, smarter, and more automated threat detection and response through prevention-first security, which is their North Star, focused on stopping threats before they can actually happen using AI to proactively surface and block those threats through building a simplified solution which reduces complexity at scale while providing you a comprehensive endpoint protection solution so that your security teams can focus on what really matters the most.
Um but what we've seen is that with even the strongest vision and a clear strategy in place, bringing that vision to life at scale is rarely straightforward. While the tools and technologies exist and have advanced significantly, organizations still grapple with foundational challenges that limit the effectiveness of even the most well-designed MDR XDR solutions. One of the most common issues that we've seen is fragmentation across the security stack because the data often lives in silos spread across different endpoints, OSs, networks, file systems, tools, and formats.
And all of this makes it incredibly difficult to correlate the signals, understand the context, or gain a unified view of your process tree while threat hunting. And the result of this is operational inefficiencies which leads to slower investigations and critical blind spots that adversaries can exploit. Along with this, the data continues to surge in volume and velocity and yet much of it is noisy, inconsistent, or incomplete.
And without the right data foundation, AI ML simply can't deliver real-time insights or support scalable detection workflows which you might be looking for. And these challenges at the end of the day end up compounding at an operational level creating pressure on your security teams and they're overwhelmed with facing alert fatigues, delayed responses, and mounting operational costs. So despite the increased investment, many organizations aren't seeing meaningful improvements in protection or ROI.
And this is precisely where Databricks supported Silence to help solve for these challenges. So with Silence, the focus was on building not just a more scalable infrastructure, but an intelligent unified platform that supports every layer of the modern security stack. So the Silence team started with streamlining the detection workflows with automated runbooks and playbooks that accelerated and standardized their response across tools.
And their agentic workflows now surface only the most relevant signals cutting through alert noise and enabling analysts to focus on real threats that matter the most. Using the persona-based access in the Databricks applications, stakeholders including data science teams, product teams, SOC analysts have role-specific visibility which fosters collaboration without compromising control and also helps them stay ahead.
Silence also needed to scale its machine learning efforts and Databricks was able to provide that end-to-end machine learning platform supporting the model development, training, deployment, and continuous monitoring process. Their production models are version auditable and continuously improvable enabling a more adaptive intelligence and defense posture for some of the models like they build like the behavioral threat model.
Now, with being in the cybersecurity space, governance is never an afterthought and Silence was actually one of our earliest adopters of Unity Catalog where they established centralized control over permissions and access policies and lineage. And this not only strengthened their compliance, but also reduced that friction across their teams. So overall, the lakehouse architecture enabled Silence to manage all the different types of data data sets that they had on a single platform.
All of the telemetry that they had with serverless, they could also offer their teams compute on demand without having to manage the infrastructure taking the load off of the platform teams. And this simplification also reduced the tool sprawl bringing compute, storage, AI workloads into a cohesive system. And all of this again has resulted in a measurable operational impact by eliminating those silos and reducing duplication across systems and Silence has cut down on data movement and associated costs, paying for only what they use with serverless.
And with that, I'll hand it over to showcase how all of this is coming to life at Arctic and how they continue to improve and iterate over time. Thank you, Amisha. Wow, that was quite a lot of content. Let's just get started with this presentation with a problem statement. This problem statement is a statement that our data lake team must deal with every since the beginning. There's too much data that we need to ingest and we we always need to ingest it almost close to real time with infinite data with retention.
And for cheap. Everything wants to everyone wants their data enriched. They want it to be done for free or very very cost-effective. And they want us to point those features that points the needle in a haystack in our telemetry data in milliseconds or just create or creating a single view of data to highlight all the needles in a single panel with no distraction and doing it all right away. For today's presentation, I'm going to focus on how we're building a process to enable our internal and external team to easily leverage new and exciting feature built on Databricks to feature to accelerate the workflow and work toward ending cybersecurity risk.
In ideal world, cybersecurity incidents should be easy to find. It's a simple as finding. He's right up there in the foreground. Right in the middle. Point it out. But in reality, that's not the case. It's more like trying to find a needle in a haystack, which I like to use that analogy quite a bit. Can you spot in this picture? You have 60 seconds and there's if you can spot him, we have a prize for you. Here's the here at Arctic Wolf, we are extension of our customer security team.
We help them detect and respond to cybersecurity incident. Or in our analogy, imagine your company as one giant chaotic Where's Waldo page packed with thousands of people, distraction, hidden details. Somewhere in that mess, cyber threats, the bad guys, are trying to blend in just like is. Now, instead of flipping through the page yourself with a magnifying glass, hunting for it, Arctic Wolf is like hiring a team of expert spotter who constantly scanning every page of your system 24/7, and we know exactly where tends to hide.
We don't just point it out, but we just we jump right in to stop the bad guy and help you clean up the mess. We keep a We keep a close eye on, too. If they changes the hat If he changes his hat, changes his glasses, we'll know right away because of our threat intelligence. In short, while you're focusing on running your business, Arctic Wolf places the expert finder in the background, making sure nothing dangerous goes unnoticed.
Um Please raise your hand. Uh Oh. Sorry, you were first, I guess. Top left? Yes, that is correct. Um so, if you if you could just stay behind, I'll you get your prize. Before I deep dive further in, I would like to talk about how our platform evolved. I've presented in multiple Databricks conference. This is my third time. Each of my presentation talks about a stage within our data lake building journey. We started out with a single pipeline we call EDR.
We collected telemetry data from our endpoint devices, and we load the data into Kinesis and Autoloader, and then we join two separate workflow into a single Delta table, and where we flatten the data and then surface that to a SQL warehouse for our consumer to process, to show to our customer. We later supplemented this telemetry data with control plane data to better to enable better visualization on the front end, and also to meet some of our front end requirement.
In our second presentation, in my second presentation, our data scientist started investigating the use of Databricks for building models and conducting the research. Through this collaboration, we started ingesting data from our existing data science science science environment, as well as bringing every and to bring everything into the daily platform. And on top of that, we brought in additional threat enrichment to help supplement and label our telemetry data to ensure our model training is is accurate.
And finally, as we're building more and more models, we begin our next step in our daily journey. We reach out to our managed EDR folks to bring them into the daily lake so that they could start evaluating and collaborating to build our new exciting feature that are for models and data does on our data platform. As we're building our data platform, we we went through this process of assisting our internal customer for the past three or four year.
We started circling around this pipeline process. The idea is we want to help our internal customer effectively use data to create the process of researching from research to product feature. Research. Everything starts off as a research project where we work closely with a limited set of audience to scope the idea out. What this typically start with is our internal customer, such as our MDR SOC analyst or threat researcher, comes to us with a research problem or a data engineering problem.
We identify what type of data we we need and approach we need to take to solve it, and then we specify the outcome we want to achieve. Once the notebook has been created and both side agree, "Hey, this looks like a viable solution." We move to the next stage, and which we call runbooks. What runbook essentially is is a user-friendly notebook that refines the idea based on the research we've done. It allows for us to easily disseminate this notebook to a broader set of audience within our organization.
As you can see, a runbook typically is targeted for product manager, threat research, and SOC analyst who may not necessarily have a full Databricks background. The main idea is we do not want the original author of the notebook to have to knowledge share to all the this broader audience every single whenever they need to use it. As we hone in on the runbook and collect feedback from our internal customer, we start expanding this to make the determination whether or not we want to open up to a broader set of audience, which brings a even bigger set of new challenges.
Data application. We ran into a problem as we opening the um as we're opening up this this feature to our internal user, a lot of a lot of our user don't want to deal with the complexity of logging into Databricks or accessing, navigating the notebook UI, or just logging in. So, we decided to create create a simple web UI. We reach We reach out to them and ask, "How How can we get you to engage in the feature?" They They pointed out a couple of issue friction points that they encounter while using notebooks, such as using a single notebook and being able to share the notebook with each other.
This is why we look for alternative. A data application essentially is host is hosted on Databricks and is a Databricks application underneath. As our data application evolved, we start collecting more and more feedback and to rapidly iterate on this product. And once we make the determination based on feedback that this product is now a viable feature, we go into the next phase, which is the product feature phase, where we integrate where we take the infrastructure we built within the data application and pass it to our production team to integrate it into our final internal product to expose to our internal SOC analyst or external customers.
On top of that, we have a daily portal. Our daily portal helps us discover new feature for runbooks and data application. One of the challenge of our internal user have always told us is is very hard to find feature that we've built within Databricks itself. I can navigate the UI, but I can sometimes I just have a hard time finding the right data set or a dashboard if I have like over 20 dashboard. They just want to see the features that they want to used on a daily basis readily accessible.
So, what is the daily portal? You could think of it as a GPS to our data lake. Um this was an internal service we created as a way to onboard user to request access to different data within our data catalog. What we found was when we were working with the other internal team to create a form to request access, often times they're two distinct system, and the metadata aren't shared, so our user lose context. So, we created this portal to allow us to take control of that process to help our user to provide you some more descriptive details.
It enables data discovery. It enables feature discovery within the lake. And it connects our user directly to us, allowing us to notify them of new feature that are being being made available or client outages that we're planning to do on on the production infrastructure. And last but not least, we have 40 plus user on using this daily portal requesting access, temporal access, on a daily basis. The core philosophy of portal is it has to be user-centric.
We We value our feedback. We collect analytic provided by Databricks via the system table to help us understand which page is being used, which feature is being used. It has to be automation driven. So, we don't want two set of description for infrastructure. We don't want a wiki that gets out of date. So, we took a active step to make sure all of our user all of our engineer provide meaningful description to the data catalog description, to notebook description, to dashboard description, so that when they deploy, we capture that information and serves them and surface them directly to our user for the UI so that the details as the contents get updated stays fresh.
I'll now provide demo of the daily portal. Oops. There we go. Um This is the home page of our daily system. Um here, you can request you can ask commonly asked question to our daily that we as a daily team commonly answer in a very simple way. You simply click once to start to get access. Uh-oh. Looks like there is internet problem. No problem. I will switch back and play the video. So, here we click on on a chatbot to basically make the determination to provide steps on how to answer the questions.
It provide detailed onboarding instruction to our user. Next, we looked at telemetry data. We are our data our internal user wants to find out I need access to a product specific data, but they don't know what data catalog to use. So, they are able to make a request and ask through the request group. Here you can see a surfacing a runbook and a threat research runbook and our data catalog runbooks all in the common UIs to help them really quickly go to the feature we're surfacing immediately instead of navigating a complex UI.
Well, a runbook is, like I said before, it's a framework. It is made of six major component. One is a common repo. We this common repo is shared about from multiple team all storing share runbook data, runbook source code in a single repo for that everyone could look and research and have the same information they have to use. We provide share framework that are essentially easy to use function to help our notebook offer create easy-to-use notebook such as automating creation of personal compute that has the right permission.
Like I said, a notebook offer or a data scientist know the compute they need to use to create to run the feature effectively. This this share framework allows us to provision this really quickly for every individual user using this this runbook. Next, it has to be self-descriptive. It we need to provide what it does, what's the input, and what's the output. We use a basic two-tier design to ensure this is detailed that's not necessarily relevant to our end consumer is not shown to the user and that's kept and all the interface is kept to minimum.
And lastly, it has to be accessible to user. Runbooks are automatically deployed within our workspace to everyone of our user in the in the workspace account. We update this on a weekly cadence or when you first onboard and they and they could access it directly from the portal. So, when they click the portal link, they go to the runbook instance that's local to the workspace. This is a visualization of our runbook high-level runbook architecture.
Uh on the right are developers. Data scientist, data engineer, ML Ops engineer who are experienced with using Databricks. They provide the insight to build runbook features that our internal consumer will consume. Those internal consumers are junior data engineers, threat intel up scientist, data scientist, security operation. Junior data engineer uses runbooks for data operations. That's they might be fresh they might be on a co-op term.
So, they're not familiar with the best practice of how to delete data. So, we provide runbook that essentially truncates the table, run set the correct value for vacuum to clean up the data and then remove the reference to Unity Catalog in order to permanently remove all trace of the data immediately. Good morning, everyone. Today, I'll be guiding you through how our BlackBerry Managed Detection and Response Team leverages Databricks to keep our customers secure.
This demo was recorded by my colleague, but since he's feeling a little under the weather today, I'll be providing the narration. In our first example, our analyst is investigating a suspicious script found in one of our customers' environments. They took the script and ran it through our script analysis runbook to analyze its nature. This runbook vectorizes the script and uses a model trained in Databricks to classify it.
Once the analysis is complete, it categorizes the script as malicious, of interest, or benign and also provides a detailed explanation of its function. In this case, the script was identified as malicious with a description explaining why. In the next scenario, we identified that a customer is at high risk of a cyber attack. To proactively monitor this, we use a runbook that searches for indicators of compromise. Here, it appears the runbook detected a few malicious scripts along with some potentially suspicious ones that warrant deeper investigation.
Our team can then dive into these alerts to determine the affected devices and users and assess if there's a broader attack underway. In the final example, we're using our correlation runbook. This tool filters and clusters millions of alerts and events to give us advanced insights helping us detect any abnormal behavior on a customer's devices. The interactive runbook allows analysts to review device activity over hours, days, or even multiple days.
If suspicious activity is detected, an escalation ticket is raised which includes detected minor tactics and techniques to guide the investigation. What you've seen here is a small sample of the runbooks our MDR team uses within Databricks. While today's demo showcases manual operations, most of these processes are fully automated in production with analysts only needing to run these runbooks manually on rare occasions.
Thank you for Good morning, every So, obviously I'm not feeling sick. So, I'm talked a little too much, socialized a little too much, but I'm feeling relatively well. Um next, once a runbook had time to soak against a broader set of audience, we can decide if it's worthwhile to get more user using the feature. To accomplish this, we convert a runbook into a data application. So, what is a data app data application? Well, it's a Databricks application underneath.
Um notebooks are messy, they're complicated use. Sharing a notebook with multiple user can lead to messy interaction where multiple user could use it. We try to solve a lot of these challenges using our data lake portal, but we often time we're still seeing a lot of friction with adoption. So, we investigated. Nothing beats the simple point-and-click UI that allows our threat hunters, SOC analysts to just focus on the task at hand without having to deal with distraction of a of the Databricks UI.
They just want to do use the feature and that's it. So, I'm now going to talk about the threat hunting data application called the incident summarizer. So, what is incident summarizer? Well, it collects it collects and summarizes telemetry data collected by our endpoints. Why who is it for? It's built for MDR analysts who is analyzing incident on a daily basis. Why do do they need it? Well, it custom the time of analysis.
They they spend they could spend a lot of time trying to analyze a single incident. Using this incident summarizer, they could really quickly generate an incident report. Where is the data located? Well, our telemetry data is all stored in Databricks managed on the Unity Catalog. Our process summarizer is a Databricks workflow that gets triggered by our data application. Our data application, well, it's a Databricks runbook.
It's a Databricks It's a Databricks application. And it's all hosted within Databricks with the proper permission management. Using Databricks application, we're able to just leave the of authorization authentication of the app with the already data governance that's already in place by Databricks. At a high level, the incident summarizer takes all the incident take an incident and the telemetry device on the device for that incident and collects it.
So, typically this would be around 6,000 7,000 rows of telemetry data. It then filters it and correlates it into a couple hundred rows. And then it will then enrich that and annotate that data with our cyber our threat intelligence data related to those telemetry events. And then we then pass that into a large language model back by our cybersecurity data to generate an incident report that ultimately gives them a verdict to assist in their analysis such as either it's benign, of interest, or it's malicious.
My colleague, who's a data scientist, will now provide some additional detail of the incident summarizer. She couldn't be here today, so she is joining us in a video. Hi, everyone. I'm a data scientist who collaborated with to create this service for the threat analysts in our organization. So, the idea for this project actually came from one of our threat researchers, who showed me how painful it was to try to figure out if an isolated alert corresponded to malicious activity or not.
In order to get the full picture in which the alert had been triggered, he would have to find other related alerts, kind of piece all of these different indicators of compromise information together kind of manually. So, his ask was, is there any way we can use ML or data science to provide in this alert additional context so that we can see at a glance if this alert corresponds to malicious behavior or not. And so, my first approach was from the single alert with our telemetry data, construct a process tree in which that process belonged to.
So, I had to be careful in how I generated that process tree because it depends on what processes you have, you can have thousands of nodes, and then that is not something that threat analyst can check at a glance and quickly decide if this is something worthy to investigate further or not. And so, I created an algorithm that had some statistical methods to decide whether to explore certain branches of the tree or not.
And so, once I had what I call this minimal process tree, I could annotate it with other sources of data from our telemetry, our alert database, our threat intelligence stuff. Uh And once I had that process tree that was annotated, I could further apply another algorithm that I developed to prune parts of the tree that didn't have any relevant cybersecurity information. So, in this case, now instead of a full process tree, I had like a very compact process tree with very relevant uh threat uh intelligence associated with it.
And so, once I had this and a lot of this information, by the way, was in natural language because it came from our threat research sources, we could pass it to an LLM to try to summarize like the key parts of this behavior and like this alert so that a threat analyst from a single alert, they could just see these are the main processes that are involved and are related to this alert, and this is the summary of what is most important.
And that LLM, like we could further improve it with our act system with our threat research sources and like our proprietary data. So, that is how this project came to light, and happy to talk to you all today. Thank you. Hi. To summarize, um basically, all start with initialization. We collect all the relevant telemetry data. We find the top parent of the event that triggered the incident. We build a process tree and find the top very top parent on the time span that we want to analyze.
We then prune the tree, removing any sub branches that are not relevant to the incident based on threat intelligence. And then we start handling known prolific nodes that are known to be very noisy and typically not of interest. We prune those, and then we annotate a second time with relevant threat intel data for after telemetry data. And then we feed that into our large language model to generate the incident report.
Well, enough of me talking about this design and how we do it. I would like to present a demo. Hopefully, the internet will cor- will work this time. Uh okay. Here, you can see we have our data lake portal. There's free view on it, and each of them represent a iterative development of our feature. We started with an ad hoc where a threat hunter or SOC analyst know exactly the company they're they were doing research or they're looking for.
They provide incident date and the event they want want to work with. And then they could just click analyze. Next, we started with we we explored use case where we created interactive hunting where they could actively look through our customers' information to when there's a cybersecurity incident to determine what needs to what event to specifically hunt for. And then finally, as we saw adoption wasn't increasing as we opened it up, we reached out to the team based on feedbacks, and we created the incident final tab where they could just simply ins- type in incident number, and we'll collect the data from other subsystem to generate the analysis automatically and push the analysis report via notification to them so that they could just click a link once it's done to see the analysis report.
And then right now, we have plans to automate the entire process um to process as much all the incident that is coming through our pipeline. So, I'm just going to do a quick demo here. I'm going to select a tenant ID. So, the analysis is now submitted. So, then we could then click on view request. So, just So, just so you can see I'm not doing this like this is not pre-planned. I'm This is actually an active workflow that was triggered by the Databricks app.
So, it's running the analysis. But clearly, waiting 2 minutes for the analysis report makes for a boring demo. So, I've already pre-run this ahead of time. Here. So, this is the sum- This is the process tree that we generated based on a single incident where we correlate multiple alerts and telemetry data together. And this is the end result of all the of everything filtered out. Here, we've got an incident summary with what time the incident happened from the beginning to the end, the affected device name, the end user that was logged in at the device at the time.
In this case, it even provide detail on, hey, a Tomcat 9 service was the trigger of this. And then what notable activity has happened as part of that process tree event. So, it provides detailed steps through as it moves down the process tree, describing every detail of the execution. And then lastly, it provides a summary of what action our SOC analyst could should take based on the information that was provided. And I would like to give a thanks to our purple teaming who created this event today just so we could do a presentation.
So, thank you. Oh. There we go. So, these are some of the feedback we've collected for us incident summarizer. We have positive feedback, we have some negative feedback, um and some constructive feedback where we actually take and reach out to them to change to up their app based on the feedback so that we incrementally improve this before we hand this off to the product team. This is our future road map. Um I'm running a little short on time, so I'm just going to really quickly high-level skim it.
Um we're looking to investigating Iceberg table, Delta table. We're looking to federate our catalog between Unity Catalog and Glue Catalog because within Arctic Wolf, we have multiple data lakes that were built by different business organization. And we want to leverage federated query to enable us to have a single point web user interface to access all the distinct data lake out all data catalog out there. From a research perspective, our our team, our data team are hard at work looking into binary and script classification using Vector DB in Databricks, and we're continuously enhancing our process tree graph to add more detail.
And also, our large language model team is hard at work building a next-generation agentic workflow within Databricks. In short, um Databricks provide great set of tooling that enable us to build our cybersecurity data lake. The journey was long, and it took many iteration to get right. What I present today is just a res- is a result of a multi-year journey. The feature power by our data lake enable us to provide a comprehensive managed solution to protect your infrastructure immediately.
And to find out more, we strongly encourage you to visit www. arcticwolf. com

Learn more about the Databricks Data and AI platform.