War Room Chronicles: Stories, Scars, and Survival

Transcript

Now >> folks, >> uh thanks for coming. We have a wonderful panel today with uh special some special guests and trust me it was not easy to get this panel together. We had to find a bunch of legal teams, a bunch of PR teams and we finally got a great set of people together. Um war rooms are always a sensitive topic. So it was that way. We'll start with some intros. Uh for those who don't know me, I'm Modet. I'm the CTO at Polygon Labs. I lead engineering and security there. And with us, uh we have Joe from Mandant. Uh Julia from uh Zero Shadow and Seal 911 and Huane from Balancer.

I'll guess pass it on to you guys for some quick intros. Starting from you, Joe. >> Sure. So, um, I think we were introed as old-timers, and I think I have more gray in my beard than than anyone else. So, uh, I'm Joe Dobson. I work for Mandant. I've been doing cyber security for web 2 and web 3 for for quite a while now. And mostly focused on threat intelligence nowadays, but I've done instant response. I've done threat hunting, uh, a wide variety. >> Hi everyone, thanks for coming. Um, I'm Julia. I'm a co-founder and head of investigations at Zero Shadow. Zero Shadow does um preventative work to try to uh help be prepared for in the

security space, then also reactive work. So, if you do have an exploit, we'll help with the recovery efforts. Um I'm also here as a representative of Seal 911, which I'm a volunteer for. And many of you probably know that Cal 911 is a volunteer group uh to help with a lot of war rooms and a lot of uh triaging of investigations. >> Hi everyone. Uh I'm Quani. I'm smart contracts leader balancer. Um and well I'm also like dealing with ECN response. I'm the first one to read the immunifi reports and I've been in a couple of war rooms. So yeah hopefully I can say something about it.

>> Perfect. Uh yeah, unfortunately or fortunately all of us have been in many war rooms. Um so we'll here to share some insights. Joe, we'll start with you. I don't see much gray hair there, but any case uh tell us your most nerve-wracking incident in this space. >> So I would say the most nerve-wracking are the ones that have some real world element. Right? when I say that any any incident where there's a real life uh interaction and so the threat actor not just doing something virtually on chain on computers but them actually following up with a phone call

right uh we've had incidents before where there have been adversaries that we you know kick out of systems and because they know what the network looks like they can pick up the phone they can send a fishing email to someone at the and then call that person, they'll send letters, right? So, anytime you have that real world component, I would say really that's that's probably the most nerve-wracking to me. Not because there's that imminent threat of harm to life, but it it is a reality check that this is real life and those are people on the other end and those people will try to reach out and communicate or touch you in a variety of different

ways. That's very true and people can do some of the real world interactions in reverse also. There's one time there was a miso protocol by sushi that got hacked a little small amount but the sushi team for some reason decided to they figured out who the hacker was their address or alleged address and they decided to Uber deliver them a miso soup just to let them know they know. Um, so funny things can happen both sides.

>> I I I think that is probably a very calm way to handle it. What I've seen a lot of times is when when someone gets compromised, right, the first feeling they have is they they feel violated in a sense, right? They thought they were secure, they thought they were comfortable, their systems were good, and then when they get compromised, there's that feeling of of being violated. Then they get angry. They get upset, right? It's like they're going through the stages of grief. And when they get upset, that's when they're like, "Well, I want to know who it is, right? I want to I want to go after them. How do we punish them?" And so, on one hand, you know, there's recovery and cleaning up systems, but they also get a little bit of of almost a blood lust there of of of want to go after. So, I

think sending some soup is is a very diplomatic way to handle it. >> Yeah, fair enough. Okay. Uh, let's start with the basics. Uh, Julia, can you define for us what a war room actually is? >> Yeah, definitely. Um, a war room is basically your home base for when an incident occurs for um, all the coordination that's going to happen afterward. So, you want it to be um, an isolated communication center from your day-to-day operations. A lot of times it's going to be a telegram channel because that's where a lot of us operate here, but um, you could also have a Slack channel or another kind of form.

um you're going to want to make sure that within that war room you have some key players um as part of your your response. So um someone who's more of a project manager who's going to make sure that you're engaging the right people um including security experts externally that you might want to bring into that war room and that you're following up on next steps that need to be accomplished. someone who's more of a technical lead and that's the person who's really triaging what happened, making sure that everything that can be paused or uh shut down at the moment is and trying to make sure that you're in a safe place before you resume operations. And then someone who's more of a communications lead.

That's going to be someone who's thinking about what are we telling our uh community online. What is our post-mortem looking like? Are we going to contact law enforcement, which um is definitely recommended to do? And who's going to organize actually filing those complaints and more of that external communication uh aspect. >> Perfect. Thanks for that. Uh, Huani, you have been in war rooms of both kinds where hacks have not happened yet and hacks that have happened and now you have to think about recovery. Can you tell us like how do they differ from each other? What your experience was?

>> Yeah, sure. Um, so as I said in my talk earlier, I think uh having the Unifi backounty report or any backbound report whatsoever, as long as it's well founded and up to date, I think it's always a very good investment. Uh and the differences between knowing that something's wrong in advance and not knowing it and waking up to an exploit uh are like yeah the contrast is very stark and very sad. Um so yeah whenever you get a a a report you always have some time to react. You can evaluate options. You can evaluate communications. you can reach out to partners, reach out to security experts and you can do that with a like let's say in another state of mind and like

planning much better than when you are uh with a live exploit. Um when you're in a live exploit is more about like trying to reduce the damage that is being done, trying to freeze as much as you can, trying to reach out to partners, trying to reach out to the security community. But the hard truth is that is that at least in the very short term there's very little to do about the funds that are already gone like yeah maybe uh at some point in the future uh we can track them we can check the movements and so on and so forth which is what we will be doing in those cases but in the short term it's all about uh contain the damage as much as possible uh and I think that in both cases like yeah knowing in advance

allows you to do that much more efficiently. >> Yep. Perfect. Uh just continue on that Joe when a protocol detects an incident what do you think the their first steps should be. I would a few different things. One is I would hope they have an instant response plan, right? And with that instant response plan, the first thing they should do is open it, read it, and follow those steps, right? And if they have some sort of monitoring service, if if they're using some sort of managed defense, then when that alert comes in, if the alert didn't come from that that company or organization or

service, they should check with them for validation to ensure what what they're seeing is reality, what's going on. But I think having that instant response plan, referring to that, that's the first thing. And and here's a subtle hint for you. If you work for an organization that doesn't have an incident response plan, plea, please, please make one. Please build one. Please have someone, be it Seal or someone else, advise you on creating a solid, effective incident response plan. >> Yeah, perfect. Like one key takeaway from there is have an incident response plan. Even if it just says wake up security researcher, ju just have it written down because when things go south and people are panicking, you miss the most basic steps. Have that

checklist there. Follow it would help you a lot. >> It's it's been said quoted a thousand times before. I I assume it's a real quote. I think it was Mike Tyson that said supposedly, you know, everyone has a plan until you get punched in the face. It's like you that's why you need something written down that you can refer to because you're the emotions will be running high and you're not going to be thinking clearly. That's why you have to have that in front of you, that reference document. >> And I'll just add a quick plug in here that SEAL just released their certifications this past week. And part of getting those certifications is that you're going to know what your insert response plan is and you're going to have a a next step forward. So be sure

to check that out if you haven't on the website. >> Nice shout out to Seal. Definitely doing great work in this space. Um Julia, you have been probably the in the most war rooms in the whole like I I think the whole room here. So tell us from your experience what are the most common mistakes people make in a war room. >> Yeah. Um I think that there's two main ones that I really want to highlight. Um, one is just centralizing where you're going to actually be handling um, this incident response because we'll see someone has an incident happen and they just want to reach out to everyone that they know. So, they send a SEAL 911

ticket, they contact Zero Shadow, they contact Crypto Forensics, they contact their buddy who had an incident the last week. And we have to then coordinate amongst ourselves and figure out who knows what who might already be engaged because that's something where we don't want to duplicate work and and ultimately time is of the essence here. So you really want to be centralizing and making sure that you have those experts together and everyone can coordinate amongst each other to think about all the different aspects because we want to look at this from that mitigation side from the tracing and the freezing of the fund side from more of the the analysis of of what actually

happened. There's a lot of different steps here and so having that centralized space is really key. I think the the other big mistake I would say is just um uh I I don't want to say I want to say this correctly. Maybe a a need for um evaluating the situation before going full steam ahead um might be the best way. Um, there's a lot of different aspects to consider when you have an exploit and you're not going to know right away exactly for the most part exactly who the exploiter is um or or even how much uh might be at risk. And so before you run into

uh immediately a negotiation or immediately trying to uh just just post online. Um really thinking about what do we know now? What can we uncover in the near term and how might we use that as leverage to actually um have better results going forward. So that that requires a little bit more time than the first couple hours of the exploit. >> Yeah, that's good. And a followup to that, how many people do you think are the ideal number of people in a war room? The more the marrier, right?

>> Of course. No, definitely not. Um, yeah. Uh, that was one of the key things with having that separate war room. This is not your dayto-day. The whole team is going to be involved. And I think people can feel a little um intimidated when they see some of the number counts from a war room. If like all of SEAL 911 is coming into a war room or even the Zero Shadow team, we have a lot of investigators. It can look like a big number, but you really just want trusted people in your war room. So, I think it's not necessarily, oh, the number should be X people, but more that you know that all of those people that are in there are going to be able to contribute to helping that investigation and provide new

perspectives. And and I think importantly, you do need that 247 element. So, you do need people across time zones so that whenever something is happening, someone's awake. Um and and I think one thing to consider is that while we do want transparency in these uh in these exploits, you don't want to reveal everything and you want to have some time to do investigations. And so each additional person that's in a war room is in a way um a vulnerability towards leaking information that you don't want to. um even if you you do trust a lot of these people, it still could be a word of mouth or or an

accidental mention on on some kind of forum. And and that's just something to consider is that uh this is something with your communications lead, you can also be very upfront with the people that are helping you, especially externally, and say this is what we do and do not want to reveal at this time and make sure everyone's abiding by that. That's a very good point. Like uh how do you so in a war room information is always coming in fresh. A lot of it is sensitive. Some you might want to release to the public to reduce panic and so on. How do you decide what should be released to the public? What should be kept private? How do you control

panic? How do you do PRs? Like how do you manage all of that? Anyone can go. Yeah, I can start. Um, I think that having some kind of information revealed is going to be important because if you just say like a very blanket statement like we're evaluating the situation, you get a lot of rumor mill that's going on and you want to control those comms and you want to control the perception of the incident. So, you do want to have at least some knowledge put forward, but I think especially information about who you think the attacker is is something that's that you should keep more confidential because that can be really important in the recovery side. Um,

unless it's like North Korea and and honestly, everyone knows that based on onchain information, so you're not really hiding anything anyway. Um, but I'll let the others also contribute. >> Thank you. Um, okay. Um, yeah, I mean not I'm not a coms expert, but I would say like in general like treat everything as need to know as as it comes and only then if you think there's something worth sharing, always bring in someone that has experience with public communications and try to curate the message before just like sending it out there. At least that's the approach we take. Yeah, I think when it comes to public communication, moving carefully and precisely is better

than moving quickly, right? You you want you want, you know, depending on the situation, acknowledge what's going on, especially if you know there's impact to others. However, you don't want to put out incorrect information. You want to ensure things are accurate. You also don't want to release uh sensitive information without appropriate review first. So I think that it's it's a delicate situation that you want to handle very carefully and so you want to have the the right people in the room or the right people in the process for that public release.

>> Yeah, that makes sense. Okay, I'll throw in throw in another curveball. Uh I need just a percentage number from all three of you. What's the right percentage of white hat white hat bounty to offer after a hack for return of funds? Um that's a very tough question. Uh I think the like the interest the industry standard is usually 9010. Um in my personal opinion like there's a gray area there. Like if you're truly a white hat, you should probably try to disclose things uh via a back bounty report whenever it's available. Um, I think that's also some less degree and

less risk if you're truly a white hat because you don't need to like do the full exploit breaking uh all the pools or bolts or whatever like in a very efficient manner. You just need to prove that something is wrong and that the TVL at risk is uh some amount but you need to actually execute it which is a whole different problem and has like a lot of different challenges. Um, so I mean from a project perspective that's much better because it allows you to uh react first. Uh, it's less of a reputation issue like everyone will shake your hand as a white hat and you'll be the community hero.

Um, if you go past that line and you actually exploit first in the hopes of getting something back, then I think it's more about uh containing the damage more than actually uh a clean whitehead rescue. Um, but yeah, that's just my personal appreciation. I I I think I largely agree that it depends on the motivation of the attacker and I I'm not sure there's a a fixed like dollar amount or percentage breakdown, but what is really the intent behind the compromise and um figuring that out can help to define the dollar figure >> and and this has definitely been getting better, but just something to think

about for your own protocol is how much are you offering building off of that for a white hat bounty versus a black hat bounty. And you want those to be pretty in line with each other because you don't want to incentivize someone to get a bigger profit from from a a bounty that you negotiate on chain. I think people have been thinking more thoughtfully about how much they're offering um on their their bug bounty website, but it's just uh worth considering.

>> Um maybe one comment on that note. I think that's a very tough question to answer. Like there's a lot of discussions in I at least what I see in the security researcher community about what's the fair compensation for a white hat report. Um the truth is that it's never going to be the same. Like I mean if you just drain all the TVL of course you're going to get more but the problem is that it's usually a crime and you will get persecuted for that. Um so I mean yeah it will never be on par with what you get on a on a whitehead bounty. So yeah you should go as high as possible. um what's the exact number that is that will prevent I mean at the end of the day it's all about the intentions of the attacker white hat like if you're a white hat it more

depends on your morals than uh the real value perhaps like between getting 1 million or 2 million or 10 million yeah maybe of course it's better to get 10 than one but uh I think lots of security searches won't change their stance just because of the monetary value it should be fairly compensated and how much that is it's a valid that we need to reassess from time to time. Um, but yeah, I do think that there's probably a line and most security researchers know the game they are playing. >> Yeah, I would hope that organizations before they ever reach the point where they're debating like how much should should we have to give that they actually sit down and consider what does their security budget actually look like? Do they actually have full-time security people? How much are they

spending on that? because it's a lot cheaper to have a security team that protects your your protocol, protects your organization than to pay off someone who compromised and stole a heck of a lot. >> Yeah, for sure. I can probably count on my fingertips how many teams have a dedicated security team in this space. >> Not near enough. >> Okay, moving on. Uh Dwani tell me if you had a time machine would you do anything different in balancer war rooms? >> Um so yeah I mean hindsight is always something very complicated to deal with.

Um so I I work more on the protocol design. Uh when I go into the war room I'm more on the side of like okay this is what happens. This is like the value effected and maybe try to think how to contain the damage from from there onwards. Um again as I said before it's like there's a like there's after the exploit there's no going back and in the short term like the funds that are gone are gone. Um if I had a time machine I look more at like the design perspective of the contracts and like how you could have prevented the exploit in the first place. Um I go back to the question of the of the post windows like what's a reasonable design for DeFi like should we have like a

government governance that is completely minified with very little powers or should we have governance that can step in and post the system when things go south. Um I think that's a very valid question. I think your users should know um what they are depositing funds into and what is the trade-off between those two like yeah because both of them have have risks. Uh upgradability is another very big question like yeah you can potentially stop many hacks by upgrading contracts but you can also introduce bugs uh as you do so. So I think it's a double-edged sword. Um, finding the balance is very complicated, but I think it's it's worth uh asking that question from time to time and reviewing what

your um security premises and hypothesis are. >> That's good. Uh Julia, tell us how much of a typical war room is a planned precisioned process versus how much is just improvision uh and just instincts? >> Yeah, this is a great question. Um firstly it goes back to what dos was saying which is uh that we want to put a lot of emphasis on planning ahead for this and being prepared. So that means that you have an instant response plan. You know who is going to be taking what task. You know um maybe what's possible to freeze versus what's not possible to freeze in advance. Maybe you've even

done a war room exercise before, so you've tested it out and you know what it feels like in that moment because as we've said, like in the moment when you're you're not as practice, you kind of just default to to basic behaviors. Um, in my experience with war rooms, a lot of it is improvised, but I think the good thing is that this community is very collaborative. And so even though the protocol itself might not have a game plan, there's a lot of security uh personnel who do have experience and they can come in and steer in the right direction. I think ultimately it's always the protocol's decision about what course of action they take and that

can kind of steer the war room in one way or the other. But we're always trying to hit these same principles of mitigating the existing theft, triaging exactly what happened, following and trying to recover the funds there. Those are those three main components there. And so um that I think never feel never feel that you can't reach out um if you need help. And even if you can't hire um a a long-term team to help you with the recovery, you'll definitely get that triage, that initial uh are we safe at this moment um component.

>> Uh Joe, you have been doing war rooms before web 3 was really a thing. U now web 3 war rooms are sort of new and special, but also the same same thing. So can you help us compare and contrast what a typical war room in the traditional world looks like where what what it looks like here? >> I I think traditional war rooms have a lot more ex or have fewer external players than in web 3. Uh in web 3 there's there's a lot more external players. I I do want to hit on a point that that Julia mentioned though about, you know, doing some sort of war room exercise, right? When I was in the military and we would do training

exercises, one thing that they love to do is take whoever the key player is and say, "Oh, they're they're out of the game now." Right? Whoever that key person you have, they're unavailable. They're on an airplane. They're, you know, their family member's sick. They can't respond. And so now you have to make decisions and take action without perhaps your best player in the game. And I I think that having that kind of preparation is really important. But um there's still levels of panic, right?

There's still people worried about losing their jobs. Um grown adults breaking down in tears, but uh a lot less phone calls in uh in web 3. >> That's for sure. Uh okay that's great u okay coming back to balancer tell us like what changes have you made uh in your processes uh what lessons have you learned from the war rooms you have been in >> um so yeah we're trying to reassess everything that is left essentially we won't just take the audits and the back boundary for granted and say like okay that's enough to filter all the issues

like it's very effective for uh maybe 99% 99.9% of the cases but as we have just seen that's not enough even even after the protocol has been live for several years so I think that's something that we need to revisit and I think that that's probably something that we need to revisit as an industry like what's the point to keep reoditing or revisiting contracts that are immutable and were deployed like years ago and apparently there is value in doing so and asking questions on whether like okay is is this fine like um and maybe also compare against newer threats that are appearing perhaps take other exploits as an example and think okay how would that pattern apply to my protocol um and that's exactly what we

want to do um another interesting thing that we've been doing so far and we keep want to keep doing it is um yeah try always to think in terms of simplicity like not add features that you won't need as a protocol just in case because that's where problems start appearing. Um again try to keep the code as simple as possible. Of course I mean we are not in the in 2017 18 anymore. So it's not that we can just develop another uni2 and be successful. Um but we do need to keep it as simple as possible within our means. Um so yeah >> and and I just want to add one thing there which is so many exploits that we

see are because of the human risk and not the contract risk. It's the social engineering that comes through. So that's really thinking past your audit and thinking about your social or your operational security. Um, especially your developer teams, they even if they have their own devices, you want to make sure that you have some kind of controls there because there are so many thefts that are because of malware, because of what they thought was a job interview. Um, or they thought that they were going to go on a Zoom that wasn't real. Um, even that the developer is not actually who they say they are. there's there's just a lot of elements there where it's not actually the contracts at fault and

that that takes like looking into specifically and not just trusting that people are reading the news. >> One of the things that bothers me the most um I would say about web 3 versus web two is in web 3 there's not enough like corporate devices, right? It's a lot more bring your own device, bring your own hardware, bring your own laptop. And part of that is because you have folks that work on multiple projects. And so they have a laptop. It is simultaneously their personal laptop and the laptop for all three projects that they work on. And it's the laptop they use for social media. So what happens is they get infected through social engineering. Malware gets implanted on their machine. They realize

that something bad happened. So they take it to somewhere, you know, they take it to the store where they bought it from and they get it wiped, right? And let me tell you that doesn't actually solve the problem because in the time that they you know that they didn't realize that they were infected or you know when they were taking to get it wiped other folks in their organizations have already been compromised and now the evidence around patient zero how that happened is gone. it was wiped away. And that means it's harder to identify what was the origin of the intrusion, what was the infrastructure used. And those things can be critical in an instant response engagement because you can identify, okay, well, if we know it was this piece

of malware, then it's that threat actor. Here's how long you have to take action. Here's how you clean them out of the system. They usually do negotiate. They don't negotiate. All those details can be lost because someone in a panic took it and got got their machine wiped so that would be clean. Please don't do that. >> Yeah, for sure. And uh like with me running security for larger orgs, I can tell you it's especially in this space can be hard for to convince developers to use corporate devices because everyone feels like no, I'm not going to get fished. The thing is like it doesn't matter if it's you who is getting fizzed or your your de developer friend. Uh I'll give you an example like let's say

we in polygon we have over 100 engineers in the org. um all of them use GitHub and if even one of them gets compromised uh so the attacker can push the malware through to one of our GitHub repos it won't make it to production always because of checks but for PR reviews and so on if anyone if their colleague pulls it runs it and that's it that that's games game over so if anyone tells me hey like I'm not going to get fished do I I I just ask them do you trust every single colleague you work with to also not get fished and I've not heard a yes so far. So, uh that that gets people convinced.

>> Yeah. And and you know, people don't want to use corporate devices, but they also don't want EDR software and point detection response software on their personal machines. It's like you you need to really choose one or the other and you need you really should choose the corporate device because then EDR software can run. So, if someone does get compromised, there's a better chance of an alert of something being detected. it, you know, at the very least, you know, some details of the origin of the infection can be identified, right? So, there's there's so many really basic security things that can be done that should be done that we lose when folks are just using personal devices that don't have really, you know, protective

software on them. >> That's nice. Okay, let's uh start wrapping it up. We'll leave five minutes for audience questions as well. Um, final question for everyone. If you guys had to leave one message to your younger self about war rooms, what would that be? >> I can start. Um, so I I'm a tracer. That's my starting origin. So tracing where funds go. So when I was first in war rooms, all I could think about was the forward looking. Where did the funds go to? Can we find any leads that way?

And what I've learned is that a lot of the leads is from the source. So, it's where did they get their gas funding from? What do we know offchain that might have some leads? Um, especially from from the victim themselves from from their organization, their socials. Um, so, so now that's really what I keep in the forefront when I'm in a war room is really digging into the actually the attack itself and not necessarily just where do the funds end up. >> For me, I would say war rooms are a marathon, not a sprint. And so, be prepared for them to go longer than expected. You're not going to solve

every problem in the first six, eight, or 12 hours. And um don't don't burn out is the advice I would give my younger self. >> Um yeah, I would say like get your priorities straight. Um there's a time and place for everything. Um again, you have to think that what's gone is gone in the first few minutes, but there might still be some time to do some damage control. And that's probably where your efforts should go in the first few minutes. And after you realize the impact and that you have minimized the damage as much as you could, then you move to the next stage. Uh that's hard because you're always under pressure and you're nervous and maybe you don't have all the information that you need. And usually exploits come from

something that behaves differently than what you thought it would behave. Um but yeah, trying to follow step by step, getting understanding, getting priorities, and only then executing is usually a good idea. And if if I could give a second piece of advice to my younger self, uh be careful about planning around holidays and weekends because that's when the bad stuff happens. >> Yes, for sure. It's always on a weekend. For sure. >> Okay, so that's all the questions I had for now. Thanks everyone. We'll open it up to the audience for any questions now if anyone has anything. Ryan, I can't see person.

Okay, so I have to ask, Balancer is been pretty successful in the space and you've heard kind of all this advice about security teams. Why hasn't Balancer hired a security team? So, we do have Hyper Native for incident response. We do have auditors that we have very close and we work together. It's not that they just do the audits and they disappear. Um, and we do have people of operations like dealing with all of that constantly. Um I don't know if that answers the question.

>> It's a it's a I guess place people are still learning that uh yeah you can have more than just an auditor as well. It's it's in this space in my experience I' I've noticed that all of the protocols want to be secured. It's not a money question. They'll throw throw money at bunch of audits any day. Balance had like 10 auditors or something like that. Uh but oftent times people still don't realize okay having one engineer dedicated to security in house can be better than a full external audit um just because of that long-term context and vision. But we are getting there. We are getting there now.

Hello. Um, I don't know if this is in topic, but I I have been in one or two of these war rooms in the one of the first people coming in into these basically Telegram channels and I I don't know at some point I found out that I didn't know all the people joining in like so I have this kind of feeling that not I'm not in control of this situation. So I have a kind of a controvers controversy question for you. Like if I have an exploit, I know how to exploit it. It is a big protocol. What should I do? Should I uh try to report it or exploit it?

I I know where you're coming from. Um so I think if the project has a back mounted platform, that's probably the the way to go. uh I know that you might be a bit skeptical about uh those platforms and adding more intermediaries because it's very sensitive information like essentially yeah you have a list of steps that you if you execute it suddenly someone else's money is yours so that's that's huge uh it's a lot of responsibility and the moment you add more intermediaries to the party like yeah there's always a risk of leaking but I mean if the project is serious enough I think that's the way to go and it's probably the way to handle it that doesn't mean that you you might be end up like doing the rescue yourself. uh

but perhaps you can touch base with the project to see what they think to see if there's any other risk uh in executing that if there's anything else affected just to double check that uh your understanding of the thing is complete enough to make a clean exploit because one thing is okay I I stole uh I don't know 1 million out of 100 million that's already a lot uh and it's going to become messier because others will try to copy that and yeah essentially it will be very messy but when you try to do a white hat exploit, you need to try to make it as clean as possible, hopefully in one transaction so that others cannot copy you. Uh you know more than me better than me that there are a lot of considerations uh in that front.

So yeah, I mean I would first try to be as careful as possible. maybe try to discuss it with the project in a way that uh is secure enough and if there's no other option then yes go with the for the rescue and of course yeah yeah you you need to arrange the terms of that rescue always reach out to the project first if you can't get hold of them reach out to seal 911 doing anything on your own should be the last resort thing >> yeah here quick question thank you very much for coming guys very insightful conversation So nation state actors are using AI agents to exploit system also smart contracts. My question to you is what

avenues do you see for agentic let's say software or autonomous agents to help in the war room process and if you're using any why or why not >> I mean AI now is part of everyone's workflow. It includes uh war rooms to some extent as well. But you can't feed all the war room information into an AI because you should not feed confidential information to AI which just keeps record of everything and logs everything. Uh but for like when you are in a war room creating a PC for example uh and things like that you can still people use AI uh people use AI for things that happen before a war room as

well. securing your codebase. AI is getting better at catching bugs. Uh Sattorra now actually is working on a very cool tool that they will announce very soon. But imagine formally verified AI written code. Um so something very cool things like that. Uh security researchers are also using AI for any new technology that comes up both the good people bad people use it. Um it's always a cat and mouse game. I I think we will see AI help us deal with friction.

So that way, you know, things that traditionally take a little bit longer can be done a little bit faster and folks can focus on things that require more expertise. Um, but we we could talk about it all day. >> Yeah. One last thing is just if you use I think AI if you're using it for your comms at all just make sure that you're really watching that and and proofreading that because that could just really put a bad taste in people's mouths publicly. >> Perfect. So we are right on time. We'll wrap it up here. Thanks everyone for coming and a shout out for our panelists.

[applause]