Loading summary
Transcript58 lines
- [00:00]
A
Foreign and welcome to this special soapbox edition of the Risky Business podcast. My name is Patrick Gray. These soapbox editions of the show are wholly sponsored and that means everyone you hear in one of them are paid to be here. And today we are chatting with Ed Wu, who is the founder of Dropzone. For those who are not familiar, Drop Zone is, I guess, the OG, like AI SoC company, right, where they built an AI agent that acts as a table tier one sock operator. Right. So it helps with alert triage. It's a really good use case for AI. It works very well. I feel like when I first started saying that a couple of years ago on this microphone, people were skeptical. But now when you go out there and say someone's built a sock agent that can do alert triage, people believe you. Right? Because it is a very clear cut efficiency use case for AI. So Ed is joining me today to have a nice long conversation about all sorts of stuff, including the volume apocalypse frontier models, how the bug apocalypse is going to influence the sock, what it's going to do to detection and response, whole bunch of stuff. Ed Wu, welcome.
- [01:12]
B
Thank you for having me.
- [01:14]
A
So, Ed, let's, let's kick it off here, right? Like there's been, I think the starter's pistol on the, on the whole volume Apocalypse or bugpocalypse freak out was Mythos. But I think we've realized since then that, you know, it's a bit bigger than Mythos and we're going to be drowning in vulnerabilities for the next five years. I guess. There's a competing view, right? There's competing views on what this means for the SoC. It either means that the way we've been doing SOC forever gets like thrown out because it can't keep up, or it means that we lean heavily on preventative controls, try to minimize what actually makes it into the SOC in the first place, and then automate as much as possible with AI in the SoC to do detection and response. But I guess, like, you know, you're the one who actually works in AI and SoC technology. How do you think this goes over the next, I guess, half a decade to a decade? Like what's in your crystal ball?
- [02:14]
B
Yeah, the way I think about this is with the upcoming, you know, see, AI vulnerability tsunami, ultimately it's what's going to translate to is attackers is, are expected to have a much easier time getting onto the network. Maybe traditionally, you know, it takes them more effort to either, you know, find the vulnerabilities themselves or piggyback on Kind of the timing difference between the disclosure of zero days and patching. But now the expectation is with more vulnerabilities, more zero days, they should have an easier time getting to the environment in the first place. So now in my mind, the detection response or the enterprise immune system becomes the frontier of the defense, right? When attackers are in the environment, what can we do to make sure they don't achieve their objectives? So I do believe actually see vulnerability apocalypse will make actually detection response even more relevant. And part of that makes everything.
- [03:23]
A
I mean, it's funny listening to you talk about this, right? Because one of my talking points has been, well, we need more preventative controls to deal with this. Right? But for the same reasons as you're talking about, which is there's just going to be more vulnerabilities, more opportunities for exploitation. Right? So the idea I've had in my head is, well, we need more preventative controls, access controls to stop people from being able to be in a position to exploit those vulnerabilities. Right. But what you're saying also makes complete sense, which is you still need detection and response. So it's like, what do we need more of? Everything. As it turns out, probably though, we do need to swing the pendulum back towards preventative controls because I do think people have been over relying on detection response. But your point that detection response is still going to be, you know, everything gets more important, I think is your point. And it's true, you're right.
- [04:15]
B
Yeah. I do see detection response overall to be obviously under a lot more stress. Right. Under a lot more, under a lot more pressure. When attackers have a far easier time getting the initial foothold. We always talk about, you know, the assumed breach mindset, but. But now armed with a lot more vulnerabilities and a lot more exploits, I think it's even more important to assume that attackers might already be in the environment. And how do we build a DNR function that ensures that even if the attacker is already in, they don't get to take away our ground rules.
- [04:57]
A
Okay, okay. So what does it look like to improve the sock or not even the sock, Right? Let's just say detection and response. What is the detection of and response? What does detection and response look like in this paradigm? Right, because at the moment what you guys have built is something that is really good at automating a bunch of, you know, busy work in a soc in terms of doing that first stage alert triage, which is horrible work that everybody hates. So if you work in a sock and you don't want to do that part of the job anymore. Definitely give these guys a call. Um, so you've automated that part, but is that what is going to, you know, is that, is that what is automating that part of it? Is that the future? Or do we need to reimagine what detection and response looks like? You know, which I know I'm asking you, you know, you've built a business on SOC automation, but I'm wondering if you're looking at the future of DropZone, like beyond that.
- [05:54]
B
Yeah. So at DropZone we started initially with a single agent. It's our AI SoC analyst that autonomously investigates security alerts. But right before RSAC this year, we announced a much broader agentic SOC vision which actually incorporates seven different AI agents, each of them automating different parts of the detection response function and then have those agents also collaborating with each other. And that's kind of where, like when you think about how do we leverage AI agents to make detection and response better, a lot of that comes down to we need more of everything. We need more detections, we need more hunts, we need more threat intelligence, we need to look at more alerts as well as we need to drastically reduce the latency across all of them. So one phrase we have started to use, and I think a lot of other folks in the community started to use, is we really need detection and response ultimately to be operating at both machine scale and machine speed. And that means doing a lot more, but also drastically reducing the latency.
- [07:12]
A
Yeah. So that means, I guess what you're saying there is that AI SOC operator part of it. You know, this isn't the end state for dropzone. Right. This is, I mean, you seem to be saying that was like the beginning and now you're moving into that, into that more like, well, how do we reimagine detection response to operate at machine speed and scale?
- [07:33]
B
Yeah, absolutely. And a big part of it is really looking at both the left hand side of the alert investigations and the right hand side of the alert investigations. Right. For example, we are building agent sets focused on automating threat hunts. We're also building agents that's automating detection engineering, both on the left hand side of the, you know, the alerts. And then on the right hand side we have agents that's focused on scoping and performing analysis, actual incidents to help people understand, okay, now I have somebody who clicked on an executable that they are not supposed to. What do I do? Who else in the environment actually has accessed and has touched this same executable or maybe part of the analysis will identify what are the C2 servers that the executable file reached out to and see if anybody else in the organization has communicated with the same C2 server. And ultimately what we kind of have in mind is detection response involves a lot of distinct chunks of manual work like our goal. Historically we automated one part, which is alert investigations, but now we are looking at other groups of work and building specialized agents to help really force, multiply and bring a step function in those capacities as well. It's actually quite similar to the progression you have seen with AI coding tools. Most of the AI coding tools start off by solving a single problem, which is, how do you generate more code? They focus on code generation. For anybody who worked with agentic development or AI coding, once you use an AI code generation tool for a while, you immediately discover, okay, now I can use AI to generate code. The bottleneck become code reviews, because who's going to review all the code that AI just generated? Okay, now a lot of the agentic tools, in fact I think cloud just maybe today or yesterday announced their code review solution. Exactly. To solve this problem. Because when you have AI generating a lot of code now, the review becomes a bottleneck and then that's where you start to apply AI. But even after that, the next phase is, okay, okay, we have AI code generation, we have AI code reviews. Who is writing all the test? Who is actually scoping out the ticket in the first place? Right? And in order to really truly, you know, get software engineering specifically to machine speed and machine scale, you end up having to build multiple agents like AIPM and AI UX designer. Right?
- [10:23]
A
Well, you're also, under this scenario, you're also creating quite a lot of human work as well, which is kind of, you know, I guess, what do you call it, like a white pill moment, right? Which is that software engineering still exists, it's just different now. And I mean, it's funny, right, because we're doing a bunch of like AI coded apps for internal use At Risky Business Media. The funniest conversation I had with James, who's doing the apps, was yesterday where he's like, he suggested building another feature in the app and the AI agent told him it was a bad idea and had a really good list of reasons why it was a bad idea given the sort of information architecture that, you know, the app was built on and whatever. And he was like, huh, I just got, you know, he just got schooled by the app. But I mean, that's the point he's building now a platform and you know, associated mobile apps and stuff. That would have taken a team previously, but there's still a lot of work in it. Right. So I think this is the thing that we're learning with AI and I've been saying it for literally years, which is it's an amazing productivity tool that enables people to do more with less. But the idea that there's not going to be humans in the mix just doesn't seem very realistic.
- [11:34]
B
Yeah. And both in SOC or you can say software development, which arguably is like two years ahead of soc or two or three years ahead of SOC in terms of AI adoption is even looking ahead. You see developers nowadays who are working in these kind of agentic software development life cycles actually spend their work is more intense and they actually spend more time kind of doing designs and architectural reviews and scoping and building alignment versus spec.
- [12:08]
A
Right. Which is like now you're writing, you're kind of writing software in English, but you're still writing software. So what's changed? Right.
- [12:17]
B
Yeah. And you have to oftentimes make architectural trade offs. Right. Because if you leave AI coding tools to do whatever, then they will always pick the simplest path or the shortest path. It keep introducing different architectural paradigms and very soon your code base become a union of 50 architectural paradigms. And ideally for a historical maintainable code base, you want as few number of architectural paradigms as possible.
- [12:47]
A
Well, and this actually, this actually brings me to another part of this conversation that I wanted to have with you, which is, you know, it seems like a bunch of people in the SoC, they already have token budgets. Right. So what they're doing is instead of looking at some of the AI like SoC platforms, they're trying to vibe code their way to a better state and it is working. Right. So they could take their existing token budget, they can vibe code some automations in the SOC that solve them, you know, solve some of their bigger problems. Right. So you know, we always talk about the jar and then you fill it with rocks and then you fill it with pebbles and then you fill it with sand. It seems like they're able to throw quite a few rocks into the jar.
- [13:25]
B
Yep.
- [13:26]
A
By vibe coding some of their apps. But I think also this ties into, it's a, it's. That approach is limiting though. Right. Because I think it's like any other software. Okay. You can put together a rudimentary script that does xyz, but if you're going for the commercial tool, it's obviously had A lot more time thrown at it. And what that time gets you, what that development time from a vendor gets you these days, I mean, ideally, the end state of that is what you're going to get is something an order of magnitude better than what you can vibe code yourself. And I think that's the part that's missed in the vibe coding or vibe coding is going to kill SaaS argument. And I put my money where my mouth is. I bought quite a lot of SAS shares during the SASS apocalypse. You know, the point is, I think the death of software vendors and that we're going to replace them with vibe coding because you can achieve some rudimentary things easily with your token budget. Like, I don't know, man. I think that's, that's a strategy that's going to feel old real quick. And I'm. Look, I'm guessing you're agreeing with that because it suits your interests just fine, if that's right.
- [14:40]
B
Yeah, kind of vibe coding or DIY is. We definitely have seen a lot of that. I think at the end of day there are two things at play, right? One is there's always the economy of scale. Right. A software vendor is going to spend far larger R and D budgets.
- [15:01]
A
But this is my point, is that that equation, that fundamental equation doesn't change just because we have AI coding agents now. You know what I mean? Like using a CO1 person, using a coding agent is not equivalent to a software development company that's very specialized with all of their developers using coding agents and working towards a common goal.
- [15:22]
B
Yeah, that's absolutely right. I can assure you modern software development companies are under tremendous pressure to use AI coding agents as well to, to make sure we achieve the productivity and kind of iteration speed that modern business requires. But I think there's a bigger portion, which is the second part that we see as a historically overlooked part of DIYing or vibe coding, which is there is this interesting phenomena with AI agents where it's actually not that difficult if you have a very narrow use case to build something that just works, but the continuous maintenance and testing of that thing actually ends up being a whole lot more expensive than the resources you need to vibe code it in the
- [16:16]
A
first place or when it breaks and no one notices until there's a real problem. That's another thing that happens with this stuff.
- [16:23]
B
Yeah. And this is a part like if you built an agent and you never plan to touch it and just leave as is, I think that's one thing. But most people, when they build something they are obviously continuously iterating on it, which means you need continuous expertise and resources in the maintenance and testing of the product. In fact, I think modern AI, you know, modern startups, building AI agents, most of us probably spend a lot more resources and efforts in quality assurance testing and validation and evaluations than actually building the prompts, the agents in the first place. And that's kind of one dynamic I think a lot of team often under kind of appreciate is they say, hey, we can build this thing very quickly, but forgot about the fact that somebody needs to actually continuously test it. Unless you are never touching it. Right. As long as you are continuously touching it, then you have to continuously test it and evaluate it. And that's like ongoing, a lot of ongoing maintenance and expertise that the security team will need to allocate.
- [17:33]
A
See, I think this is going to be the journey for a lot of your future customers, right, is you started off going out there and talking to people. This is like a couple of years ago you're out there when this was radical thinking, going out there talking to companies, saying, hey, you know, we built this agent that can do alert triage and investigations. And people are like, wow, that's pretty crazy. You know, like that's a, that's a very out there sort of thing. Whereas now I think, you know, you would get some early adopters and you did get some early adopters signing up. Whereas now I see that the customers for the future for Drop Zone are going to be the ones who have Vibe coded their own stuff for the soc and they've got a lot of value out of it when it's working. And it's also turned into a pain to, to maintain and monitor and you know, update and keep relevant. And so they're going to be looking for a commercial solution. Is that happening already?
- [18:29]
B
Yeah, it is happening because these people
- [18:32]
A
are obviously already comfortable with the idea of using agentic AI in the soc. Right. But they've discovered that it's maybe a little bit more work than they realize to do it themselves.
- [18:42]
B
Yeah, we definitely have a number of prospects and customers who were kind of building this in house. They build up a lot of conviction on the technology actually has the ability to deliver high quality outputs. But like you said, they run into ongoing maintenance starting to become a burden or even sometimes the cutting edge security engineer who vibe coded it decided to work somewhere else and now suddenly they are left with a tool that's kind of not really maintained.
- [19:16]
A
The old dev lead gets hit by a bus conundrum.
- [19:20]
B
Yeah, I think at this time. Also, as you can imagine, a lot of people are really interested in hiring security engineers who has AI coding or agentic development experience. So I think the job market on that particular niche is very small.
- [19:36]
A
Yeah, right. So Sally builds a vibe code's an AI sock agent, and then immediately gets poached by anthropic or something, right?
- [19:46]
B
Yeah, or Palo Alto or maybe someday Drop Zone. This is where we have definitely had a number of these, you can say boomerang conversations. That's happening because of, because of this kind of experience. But at the same time, we are seeing more teams kind of still at the beginning part of this journey, which is they finally have convictions that, okay, cloud code plus MCP and a lot of custom prompts can do a good enough job on some of these analysis.
- [20:26]
A
But I mean, that would be using like, I mean, look, that, that's my next question, I guess is one thing we've seen through recent work in vulnerability development.
- [20:36]
B
Right.
- [20:36]
A
Or exploit development, vulnerability research is that the model itself is not really the important part. It's the harness quite often is where the, you know, the core capability kind of sits. Once a model gets to a certain level of sort of complexity and, and competence. And I'm wondering though, because you have traditionally used the frontier models in Drop Zone to do a lot of the sort of alert triage, are you finding that you still need to do that? Because I'm thinking a lot of people now when they're automating some of these functions in the SoC, they're doing it with like Claude, they're doing it with like premium 24 carat tokens. Right. Like they're doing it with these expensive models. It strikes me that for a use case like alert triage, that's probably overkill. And as I say, I know traditionally you've used the frontier models because you've needed to, but I'm guessing at this point, like when you experiment using lesser models, it's probably still okay. Like what's that, where's that all at with Drop Zone? Are you still, you know, using the top tier models or have you found that you can get a similar rate of effectiveness with, you know, say some local models or all the ones?
- [21:49]
B
Yeah, I think you definitely don't need Frontier models 100% of the time.
- [21:54]
A
Kind of.
- [21:54]
B
The analogy I generally use is initially when you build a plane, you build everything out of titanium or carbon fiber because you want the best. Right. And then over time, as you get more iterations and mileage with your plane, you start to look at different pieces and be like, okay, that do we really need this trim piece to be in carbon fiber or titanium or we can get away with some, you know, wood pieces or plastic trim pieces. Right. And over the course of last couple years, that's kind of essentially what we have done is if you peel back the curtain a little bit, a typical autonomous end to end alert investigations. At Dropzone, we are making over 100 distinct large language model invocations. And at this point I would say probably 20% of them we are still leveraging, you can say the premium models that cost an arm and a lag, but the vast majority of the 80% of the model invocations, we get good enough results from not using the most premium models. And also one other aspect is generally with large language models there is the latency and the cost are somewhat proportional. Right. Because when a model is very premium and big, it obviously costs a lot of compute. But also because of that it generally also takes a long time to respond.
- [23:21]
A
But I mean, this is what I mean about it being kind of overkill. Right. Because you are burning a lot of everything just to get those results. So you want to make sure you're only using that when you really need to. Like what's the type of thing that needs to get kicked up into that 20% of premium inference?
- [23:40]
B
Yeah, I think the biggest part is kind of the planning and the conclusion determination phase because that's kind of intellectually the most critical piece. Right. When you are planning an investigation and you kind of a lesser model might miss certain caveats and directed the whole investigation in the wrong direction, that obviously becomes very problematic. And then conclusion determination, when you have 20 pieces of findings and some of them might be contradictory to each other, you kind of need more intelligence to really reason through these and make a sound judgment call.
- [24:21]
A
You need the right statistical weightings when there's conflicting info. I mean that makes so much sense.
- [24:27]
B
Yeah. But when it comes to like Here is a 5 kilobyte JSON response from a particular SIEM or particular threat intelligence feed, you definitely do not need the state of the art models to make sense of them.
- [24:42]
A
Yeah, well, and you don't need a. Yeah, I mean to kick off a basic automation either. Like what is the IP that corresponds to this domain name, et cetera.
- [24:50]
B
Yeah, yeah. And also again, the expensive models are very slow. So if you only use the expensive models end to end, the whole investigation might end up taking like 20 minutes. And that's just unnecessarily long at this day and age.
- [25:09]
A
So when we say we go to the logical extension of this vision, Right, which is about. Okay, so we've started with the tier one SOC analyst, right? And then you're kicking up to agentic everything. I mean, look, I've long said that I think the way this lands is you wind up with some big blob of storage that you're kicking logs into, you know, both structured and unstructured data. And then you're going to have agents crawling all over it and, you know, detection, response and I guess real incident response and threat hunting and all of that sort of stuff is going to consolidate into an agentic thing crawling all over data. I mean, first of all, do you agree with that? And second of all, how long do you think it takes before we're there?
- [25:57]
B
Yeah, that's definitely a good question. I think there are a couple of different components of your prediction. One is kind of this big unified data storage. At least in our experience, the whole SAM security data lake is still pretty fragmented. I don't think the community has reached a consensus on what is actually the right approach here. One could say with AI agents, they are very good at piecing and correlating disjoint data from different tools. One phrase you see a lot of agentic SOC or AI SOC vendors talk about is federated search, which essentially means you don't actually need to mirror a lot of data into the same data lake in order for the system to join. You know, crosstrack data with okta data with AWS data. But still for a lot of that,
- [26:53]
A
that is one of the powers of powerful things about agents is being able to do that. Right. Being able to have something with a little bit of smarts that knows how to use an API, Right?
- [27:01]
B
Like, correct? Yeah, correct. But at the same time there are also questions. Okay, different tools might have different retention. Right. It's still nice, at least for human practices.
- [27:11]
A
Sometimes, I'm guessing, you know, you're still going to want to pull in like subsets of these huge data sets into one place to kind of work on them and do some processing, right?
- [27:19]
B
Yeah. So in my mind, the unified data lake is still like a tbd. I wish I have the perfect answer so I can make some stock bets accordingly. But so far I don't have a ton of good insights other than things are probably going to be somewhat fragmented and flexible. There will be people who's like, hey, let's build a big security data Lake using S3 and maybe Asina. While other folks will be, hey, we are against data lakes that's just, you know, push federated search to the nth degree and just have an agent that's continuously piecing different pieces of data together for security analytics. But beyond that, I do, I guess
- [28:01]
A
what you're saying is that the information architecture of this vision might change, but ultimately it will go agentic, you know, just maybe with a different data structure.
- [28:10]
B
Yeah. If you think about detection response in a number of layers. Right. There is a security data layer, and I think that's where there are still some questions and uncertainty on which ways this will go. But in terms of analytics layer or intelligence layer, it's pretty clear the future of detection response will involve a lot of agents. Like you said, detection, engineering, hunting, alert investigations, threat intelligence, incident response. All of those ultimately boils down to data analytics of slightly different inputs, slightly different outputs. All of those are just data analytic tasks. And that's where I definitely agree with you. It will be an army of agents during the JSON, parsing, log analytics, looking at data from different angles, and also these agents working together. Like one thing we have been experimenting with, which is pretty exciting, is how do you have two different agents, such as an AI threat intelligence agent and an AI threat hunter agent working together so you can achieve like 24, 7 autonomous emerging threat response where you can go from a random security researcher posting something on Twitter to a completed threat hunt within five hours. So that I think is also like very exciting when you have agents kind of working in these loops to autonomously improve the overall, overall security posture of the environment.
- [29:48]
A
Well, and then what is left for your human in that point? Right? Is there just a, just, is it just a chatbot? Is it just you, you rock up to work as CISO and you just ask your detection response and threat hunting platform, hey, what's going on today? Yeah, or does it, does it page you like, hey, you know, I'm gonna need you to go and like physically isolate that machine because there's something I can't contain. Like, is it, is this, is this the end state? I remember, like when I was in high school, they showed us some video about the, the future, you know, and what it could mean with computers. And it really was someone talking to a computer like that. And everyone was like, wow, you know, that'll never happen kind of thing. And that's, that's really. It is like the future vision. That video I saw on VHS at high school, like, that's what's come true. Is that where it goes? Is it, is it seriously just a Chatbot that just handles it.
- [30:40]
B
Yeah, that's a good question. We do think it's going to get pretty close to that. Like when you have a lot of different agents like automating different pieces of work. Like we see the primary human practitioner, engineer, analyst responsibility to really be up leveled to be maybe not all the way up to ciso, because you could argue CISO has a lot of board communication responsibilities and accountability responsibilities, but definitely closer to everybody should operate as like a senior manager or director level. Right. And as a senior manager or director you are kind of doing a couple of things. First you are defining strategy. Like okay, I have a lot of agents, but still it's not infinite number of agents. So what do I want my agents to focus on? Right. That's kind of one part which is defining strategy.
- [31:30]
A
Talking about turning literally everyone into a manager. It sounds like hell
- [31:36]
B
yeah. I guess it could be argued both ways and it definitely involves a shift. Right. And again this is where obviously as a technical founder who is building a startup, I've spent a lot of time looking at agentic software development and I felt like some of that transformation is already starting to happen within software development. The best software developers right now. I'm sure if you grab a random software developer at Anthropic and ask him, have you written any actual code in the last months? I. I'm pretty sure the answer will be no. They'll be like, hey, I haven't written any code in the last months, but I've been like directing.
- [32:18]
A
Although was it OpenAI that just. No, it was GitHub just had an issue where someone using like a compromised, like supply chain compromised VS code extension or something got owned and it's like, wow, you're still using an IDE like what's going on at GitHub? Crazy. But I know what you mean.
- [32:35]
B
Yeah, yeah. And I think like I do anticipate detection response in a couple of years to be closer to like the cutting edge software development teams where most of these software developers are not touching the code base directly, but they are continuously providing input. You know, they are debating with AI agents or brainstorming with AI agents on different approaches to solve the problem. They are reviewing architecturally the work of AI as well as ultimately also establishing the framework for AIs to work well. Right. So for a lot of people who worked as a manager, you know, one of the key responsibilities of the manager of being a manager is for each individual on the team, they might work well in different projects. So as a manager, one of Your responsibility is create this environment where a particular individual on your team can really excel. And I think that's kind of really applies to AI agents as well. Like if you have AI agents working on some very nebulous, vague projects, they are going to fumble. But if you have it working in a very tightly strictly defined task, most of the agents are going to do pretty well. So I felt like another part of the human responsibility is to identify these, kind of set up these environments where the agents are going to be successful and then you can say the the managers are kind of shielding the agent or taking on tasks as the agents are not very good at. For example, the agents are not very good at building a relationship. They are not very good at convincing other teams to add additional instrumentation to the applications. They are not very good at negotiating with the finance team and network team to figure out where are the additional subnets that we should deploy NDR sensors to. So the DNR team actually have more visibility. Right. Agents are not going to magically just allow you to see everything in the environment. And we know as defenders you cannot protect what you see. So I felt like a lot of part is like the future of DNR team will involve a lot more projects like those or as well as for example selecting new technology. If folks want to look at a browser kind of security tool to protect against malicious browsers, browser extensions, an AI agent is unlikely to end to end run the evaluation, assess the personality of the engineering teams of different vendors and all of that. So there's definitely still a lot to do. But to recap, we do believe that in a couple years we want to see most of the existing security engineers and analysts to either operate as a director or senior manager, essentially like a field general kind of a role, or they are operating as special forces like really tackling some of the most gnarly and tricky projects. For example, the CEO clicked on something apparently that he is not supposed to. Are we really going to trust an AI agent to really untangle that mess? Or we actually want one of our security engineers who have expertise, who have context and to really perform some of the remediation tasks.
- [36:02]
A
Yeah, yeah, well, I mean that's the future that we're headed for. Edwoo, always a pleasure to chat to you my friend about your vision of the future future. It's fascinating stuff. Anyone interested in checking out Drop Zone could do so at Dropzone. AI Edwu, thanks for joining me.
- [36:19]
B
Sense catch you next time.