The Big Red Button: How to Plan and Design for Security Events

Transcript

pretty excited for day two of D5 security Summit uh we have an initial session on white hat hacking and so I'm going to call up Emiliano bonassi to get us going here today thanks everyone for coming thank you okay cool um so uh today uh I would like to um explain you how you can basically design your protocol in a way that during security events or security incidents it's easier to manage uh the

uh the situation so uh before starting uh just give you some few bits about myself uh I'm in these industry since a while uh working for a mobile company for a mobile World company and then has a white hacker uh helping protocols like curve synthetics and you're on excelling about their uh security it was also a young contributor with strategies with more than a quarter of billion managing and side to my security advisory and security activity I also built a protocol for renting nft currently so um I would like to give you a little bit of context I had a lessons on Friday

to stand for students about how you effectively manage security events and then we will discuss uh about how you can effectively design a protocols in that way so the first uh the first part of the context is that security and in general Automation in security is pretty important and that's why you have a security flywheel that help you to grow safely your protocol so security is should be a pillar of your protocol and of your design because only through security you can effectively save safely uh grow your TBR and here is a little

diagram it may be later I can dive deep uh the other part is that you have to be prepared so you have to plan ahead uh for uh bad things uh happening so you have to understand how to recognize those kind of events and uh follow a Playbook that you design before the uh incident uh happen and we will see what you can do uh uh when an incident uh occurs and before that I would love to explain what's a big red button so uh we have big red buttons everywhere also here in

this building and the big red button basically it um a big red button basically is a device designed to let's say quickly activate any emergency measure for mitigate an emergency situation that can pose three two persons or property or assets and this is a general definition of a big red button so what's a big red button in web3 uh it's not just a technical thing but it's a collection of mechanisms to safely and gracefully pose a protocol to protect users in first instance

their assets and the protocol itself so I use collection of mechanisms because you have on chain actions as you may see here an example for Ave V3 where you have a function that is able to pose a specific pool but you have also off-chin actions that are part of that incident response plan of alerts and off-chain mechanisms that help you to gracefully pose a protocol but you have also human processes so War rooms who you call what they have to do all the communication parts so the big red button is a way to describe all those things that help you to safely manage security events and

sometimes is not possible to have a big red button you know that many Proto cores are immutable many Protocols are impossible and in those cases managing a security event a security incident could be difficult I wanted to share here an example uh that I managed together with immunify and data Hub that originally discovered the bug where basically primitive Finance has a bucket enable an attacker to drain all the user funds of any users that interacted with the protocol so in that case we don't

have any sort of big red button to press and you know protect the users but instead we had to basically guide the team of primitive Finance to self why Tech the uh the protocol so I wanted to share this because having a big red button is a choice of the development team so the the amount of degree of control that obviously exposed you to other risk is part of your decisions so how the best design for failures how to best implement the big red button I

wanted to share here some of the leading protocols like Ave compound and yearn on how they you know have States in their protocol to pose and to safely [Music] put in Stand by the protocol so have it for instance uh had the architectural decision of isolate liquidity in the pools and that's pretty useful because if you have to block something you can selectively block this specific asset the specific lending pool instead of blocking all the world protocol this bike you have maybe switches that help you to block all the protocol

and you have also roles inside the program so not everyone is able to press the big red button but you have people like the emergency admin that can shut down or can post the uh the protocol uh in compound for instance uh another interesting thing is that you can pause the protocol but users are always able to interact in the in the way of withdrawing assets so basically posing the protocol means any footer deposit is not any more possible so basically you cap the maximum uh losses that the protocol could have but the users can basically withdraw autonomously from the

browser so the protocols still work and you have also here uh somewhere like the post Guardian that can basically block post those uh operations I think that is the most complete in this sense because you have different roles and you have for instance the guardian that can trigger an emergency shutdown for the various various volts and can be a single eoa so a single uh wallet but could be either for some specific puts there are multisig so you need at least two people that have to

authorize this big red button but you can also have I mean you have also specific roles that basically can tune uh how much the strategy uh stop to work so let's say that the protocol that yearn is interacting with could have or could move to not to not an healthy State when you deposit too much Capital There are rules that can limit the amount of capital so the there is a gray line between you know roles that can manage and can pose a protocol and the

risk management that you may have in the uh in the uh in the protocol anyway the uh the message here is that you have to design your protocol to achieve your business goal but at the same time you have to design the architecture the architecture in a way that you embed the eventual security operations or processes that you want to have when those events happens he he uh I uh uh share a repository where for educational purposes you you have experiments on how you implement roles and how you can have how you can

decorate your protocol in a way that have those pose functions and in this repo you have three level of security so the first level of security that you can Implement is that you have two roles the operator and the governance the operator is the one that is able to press the big red button together with the governance but the operator can pause but only the governance can impose so the idea here is that there is a specific group of people that is able to recognize an emergency situation and can immediately block but then for restoring the normal operation for the protocol you want to have a lot larger audience that understand

to okay let's put on on the normal steady protocol the security level 2 is a a collection of contracts that enable your protocol when it's posed to the governance to execute specific operations I mean that when the protocol is posed maybe you want that the governance withdraw all the assets or maybe execute specific operation on behalf of your protocol so if you implement the security level 2 you have this feature only and only if the protocol is posed otherwise obviously governance can have access to the user funds normally and the security

level 3 instead is the most let's say complete Security level and is where you already mentioned that there is a security event and you prepared a specific implementation of your protocol so let's say that in the normal State your protocol realize specific business functions and you know that when there is an emergency you switch the protocol to operate in a different way just enabling let's say withdrawals or maybe moving automatically the funds to a specific wallet controlled by the uh by the token holders so the idea here is that as soon as you press the big red

button the protocol Works in a complete another way that you design in in advance uh but again here is not let's say nothing production already but is a something that should be used as inspiration for okay I should have rules I should have protocol with States from normal to emergency to various degrees and to basically inspire you on how I can improve the security of my uh of my protocol so uh the takeaways uh for this short presentation is for me that I want to

you to bring at home are uh you have to embed security as a design principle so you have to start today not tomorrow many protocols many teams think about security after we have to think first how to design for the business course yes it's true because otherwise you wouldn't have your protocol but when you do that immediately not after you have to embed those principles uh the second is that you have to think that your protocol must not operate only in the normal state but should have some sort of emergency state

or let's say a limited operating function just to let's say uh Drive the protocol to a safe Doc in case of emergency so you have to design what is allowed and what's not when the protocol is in this state the third thing is that you have to design the operations so which are the roles which are the parties that can make the protocol transition from one state to the other one we saw the Guardians we saw the operators we saw the governance so you should uh design your protocol to have people if you want obviously that manage somehow uh your protocol and the first I think

that is the most important don't reinvent the wheel just copy uh what the others are doing what's the best are doing and test test test and simulate if you just design and you don't simulate your protocol from moving from the normal to the emergency you you you you will never understand if what you design is effectively working I've seen in my experience many that maybe design the incident response plan or maybe some safeguards roles in the protocol and then when they trigger the emergency it wasn't working as expected so you have always to simulate also these let's say states that occurs in uh

not so funny let's say situation and that's all so thank you for uh listening and if you have any questions willing to answer [Applause] please do you recommend only two roles operator and Governor or are there more roles you would recommend at least two rows so one for uh in general I see that the operator role the guardian role so the one that can press the big red button and transition to an

emergency state should be a a multi-sig with two people that have to approve and have someone else maybe an extended let's say at least five people that are able to unpause so the opposing function should be asymmetric you should be able to immediately trigger the emergency because the quickest is the response you reduce most of the risk for the users but for getting back you have to be sure that everything is okay so at least two roles but there are protocols like for instance here and then that has multiple depending on how you may want to manage the risk but at least two a case because you need to be able to

react faster yeah the um the I think that you have to um let's say I prefer that is at least a two people just because uh um you want you want to avoid the fast positives and on the other side I think that you uh get a you have to achieve the quickest response not because is just an eoa just an account but because you train people to react fastly that's ideal please that's a good question

innovation in order to work you fill it all together yeah yeah that's that's a good question I mean in web3 is very hard to react promptly I mean that if a bad transaction is already in the mempool you have to front-run them you have to detect them and most of the time it's very hard so in general uh react fast for me is that you have to have uh in a war room immediately the team to understand what's going on and then effectively the action that could be press the big red button whatever should occur let's say in less than an hour let's say but

fast for me is you have to reduce and time box all the decision that you may have in the uh um lessons on Friday we discussed about that and basically the triage path should occur in no more than 50 minutes so you have to understand what's going on at least you page your security uh our Auditors or whatever that can help you to understand and immediately uh you know understand if you have to take an offensive of a defensive action 50 minutes is a long time yeah we can follow up and be yeah we we for any other question please reach me uh Indiana so we can go ahead with the other right