Threat Modelling for Complex Systems in web3 | Rahul Saxena, ZkSync | ETHTaipei 2024
ETHTaipei·Wed, Oct 9, 2024, 12:00 AM
Threat Modelling for Complex Systems in web3 | Rahul Saxena, ZkSync | ETHTaipei 2024
Transcript
hello uh so hey everyone I'm Rahul taka and I work at the security team at Zas SN and uh it's late in the evening and it's been a long day so thank you for sitting whoever is sitting uh so let's keep this very nice short and high level in the sense that I want everyone who is here to take away something from this presentation because it's not very easy to dive into into the technical details in a like short presentation so we'll try to keep it in a way that it helps everyone who is here so just with a show of hands can everyone tell me like who all is a developer here in this room okay who all are specifically into security like Auditors and security researchers nice uh and who are are on the business side of things like stakeholders shareholders BD okay got it uh nice so threat modeling of complex systems and uh interlude to that is my shift away from independent security research so my background is that right now I am in the security team at zync I look at the systems at the sync make sure that they do what they're intended to do no bugs are there but before that I used to work independently take on uh private audits help clients and so on and so forth so somehow the threat modeling of complex system is related to my move from independent security research to going for working in security for a particular company so let's see how so this is the big idea that I have that the threat modeling part would go on for 15 minutes uh my transition my personal story would go on for like 5 minutes then some Q&A and uh buffer time so what is threat modeling so I I think everyone has some kind of preconceived notions when they think about what can threat modeling mean but it's very good to start off from the very Basics and build up from there so let's do that uh in any given system identifying the biggest threats based on your business objectives is threat modeling right and when I say in any given system I mean any given system I do not mean a particular web protocol I mean any system for example if you were standing outside to get your bks sandwiches today your threat analysis would have been hey there seem to be like 20 sandwiches there and there are 50 people ahead of me so probably I won't be getting more sandwich right that's the threat analysis based on your business objectives here basically means that if your objective was there to get the sandwiches that your threat should have been how to get the sandwiches right and when I say business uh objectives in terms of web 3 it means if you are a gaming company that wants to come on to web 3 your objectives are not really security and ownership and all that you need speed so you want to analyze the threats that affect your speed on the other hand if you are a digital asset ownership company then you do not really care that much about speed all you need is very very secure transactions so yeah threat modeling is the precursor to a full-blown line by line code audit so usually when people think of security they think of audits they hire fantastic firms like constam or open Zeppelin and they take on uh code audit but threat modeling is something that should be done in house uh because it basically supercharges your audit how do we do that like let's let me give you a very rudimentary example of that uh sure so this example is taken from the ongoing zync contest on C4 right now and uh the purpose of this threat modeling report is to attract the attention of the bug Hunters to the most critical parts of the zync smart contract system right and by the way when this was done people did not even realize that this is threat modeling but this is a very rudimentary example of why this was so so this is taken from the C4 page and if you read The Heading it says attack ideas so basically uh a bug anywhere in the smart contract is bad but what we are seeing as a company is is that if you can find a bug in Access Control and permissions or if you can find a bug in data availability issues that's a huge concern for us right and just imagine blindly holding uh giving your code for audit to a company versus telling them specifically that hey we want your special focus and attention on these two particular areas which one do you think would yield better results I said this one uh this is continuation a bug anywhere in the smart contract would be bad news but a bug in the placees specifically mentioned as as critical would be really bad makes sense right and now when it comes to like simple protocol such as like what should I say lending protocol right it is possible for one person to really understand how lending Works how Game Theory Works how the economics of the protocol work as well as how solid works right if that kind of person exists they can do a threat modeling of the entire system by themselves but if you want to do a threat modeling of slightly larger and complex system such as recasing which has circuits which has rust VM which has transpilers which has smart contracts on L1 and L2 both then how do you do it it's not possible for one person to have expertise in all these subjects right uh IDE I mean realistically so how do we do that the answer to that lies in the sufficiently Deep level uh line you don't need to have a very deep understanding of how things are going but you need to have a sufficient understanding of what is going on to identify the threats let me clarify that a little because once you do that it helps you do two things very well identify the most critical areas of a system with the context of cascading effects of that part filling on the entire system so basically when you are threat modeling you have to realize a very big distinction your job your objective is not to find bugs your objective is to find the places where if bugs were discovered would be very detrimental and why your uh sufficiently deep knowledge of the system is required because a place may seem very innocuous a same place may seem very Innocent but it may be possible that from that place a cascading effect happens a call is being made to some other contract or some other contract is making a call to that contract delegate call is happen whatever is happening that could Cascade into a much much larger issue like that is usually the difference between like low issues and critical issues and the second thing is once you have that once you have the contextual understanding of how the system is working and a sufficiently deep understanding of what are the parts that make up the system then you know how the system works and then you have the capability to come up with solutions to minimize the blast radius for containing the effects with minimal damage Interruption and cost overhead so one thing you have to realize very well that you as a security researcher and an academic and an engineer cannot ignore the business uh interests of your company right uh you have to ensure that whatever mechanism you come up for the uh prohibition of these things or uh like stopping the bad effects of these things it has to have these three qualities it has to limit the damage to the minimal damage possible it has to do so with least amount of interruption to the system and the cost overhead of doing that should be very low right and when I say containing the blast radius what I mean is this uh small image have you heard of the butterfly effect someone yeah so the for people who do not know that it's basically a theory that says that one butterfly flaps its wing in Brazil and a cyclone comes up in Chicago so that that's the kind of chain effects and cascading effects that happen so if you are not knowledgeable about the context of your system and how one system connects with other system this may very well happen in your system as well so that is why you need to understand the context of the system more than the you know language level bugs and the specific finding the bugs right so that that is why this is a precursor to audits not the AUD itself so yeah when I said threat modeling of complex systems what did I mean by complex right so many people confuse complex with complicated or difficult which is wrong so then what is complex anyone so with the English definition for complex complex simply means consisting of many different and connected Parts essentially if I wrote the same system in a single language in a simple in a single consistent format it would be the same system but that would not be a complex system because it has a single part however large it may be but if I wrote a very simple uh system in like five different languages in 10 different formats and 15 different styles that would be a complex system because it has multiple parts that need specialized attention so uh yeah wouldn't it be very difficult for one person to carry out the threat modeling of a system with lots of different Technologies as I alluded to this earlier not really why because your primary objective as a threat modeler is to identify threats and not to identify bugs right so if you are building something like a lending protocol right you should have very very clear invariants or threats that should never never happen for example uh the borrower should always be able to repay their loans they should not be locked out the borrower should not be able to borrow more than they have put in the collateral and the collateralization ratio things like that normal things so these are the threats that you build around because you work with the assumption that things can break and things will break and once that happen how do you ensure that you come out of it with minimal damage uh minimum cost overload and minimum coruption so uh you need to be able to accurately tell the exact places where if a bug was found would be catastrophy for the entire system discussed this earlier reviewing this areas for bugs is ideally not your job so mostly teams are small and whoever is doing the threat modeling is asked to hey like just take a look at the code as well but ideally in a big enough team in a formal enough team someone would do be doing the uh threat modeling and someone else from the team or another team would be doing the uh code analysis for that for the exact bugs so uh threat modelist if they knew marketing would be like I guide others to a treasure I cannot possess so to give you a very short um practical example of this suppose you are a Bug Hunter a bug Bounty Hunter right how do you decide your targets like how do you decide to invest your time in a particular Target right suppose if you have a friend who was a threat modeler and he told you that hey I think these are the protocols that are getting a large T nowadays and in these protocols these are the most critical areas where if a bug was found uh that would be catastrophy for the protocol so if you already have such a clear Direction on where to look for bugs you would save a lot of your time and you would save a lot of your mental energy and attack directly the part that affects the system the most and uh go home a Richard man so uh who is a threat model like if you had to identify the traits of a good threat modeling person what would that be uh here is a non-exhaustive set of things expected out of a threat model I say non-exhaustive because you you can like put in a lot of things that they should be a cat person they should be good whatever but technically speaking the this list is good enough um have excellent contextual knowledge of the system architecture the kind of threats being searched should be aligned with the business objectives as I told you earlier and actually this is what makes this very interesting because usually when threat modeling security audits these kind of words are thrown around the non-technical people essentially shut their ears and go into their own Zone thinking about what they have for dinner but if you are talking about threat model in anyone from any Department can contribute because they have their own system of analyzing threats for the particular system a finance guy would be able to tell you what are the biggest Financial threats to our system the BD the marketing team would be able to tell you that what is the biggest uh narrative driven threat to our system so these are not uh technically speaking very technical things that you can build protection around but these are very good to have in your discussion and have a you know safety net around that as well so that is why this is very inclusive if you ask me compared to audits or I mean or compared to water it but compared to traditional security resch this is very inclusive um ideally the threat model should be an expert in all languages and Frameworks used but since that is not really needed I mean like why so all you need is enough knowledge of these Frameworks to accurately assess what particular piece of code is trying to do so a lot of people basically are raging about Rus nowadays and agreed that there are language specific bugs in Rust but if you can tell uh by looking at a piece of code of rust that what it is trying to do that should be good enough as a threat modeler because if you can tell what is the logic that is being tried to put through by these rust code then you can tell that hey this is a particular place where I do not feel very easy uh with the code please ensure that this has multiple tests unit test integration test e2e test whatever just make sure that this particular piece of code is bullet proof so uh yeah so the fundamentals of that language slf framework are intact so if you are looking at a piece of uh code in Rust the fundamentals of that language should be very clear in your mind and those fundamentals should not be broken what are the fundamentals of like the things that make up zika sync let's see that um for example if you're looking at rust code you better know what uh ownership models and lifetimes look like I mean if you have done memory management in any language whatsoever you'll have a good understanding of that and before doing a threat modeling of something that is written in rusp have a very clear understanding of these basic concepts if you're looking at circuits you should be able to identify what are the what are the constraints that are used in circuit and if the circuit is over constrained or under constrained because there are a lot of things that are very specific to languages for example if you're using circom there are version related issues there are like I mean issues in the earlier templates that I used things like that but the basics remain the same that the constraints have you are written should not be under or over constrain for a particular circuit uh and for smart contracts the smart contract should be as trust minimized as possible do not use a delegate call if you can avoid it do not call to addresses that you do not know stuff like that so as long as the person doing the threat modeling is very clear in the basics of all the systems of all the parts that make up the system they could be a good enough threat model uh understanding of security and risks should be very Broad and subjective and yet be backed by practicality so this is the biggest uh point for a threat model I had taken a lot of time to come up with this point because saying this point is pretty dangerous why because have anyone seen like how new Auditors report issues in C4 and Sherlock things like that yeah so uh for context C4 and Sherlock are places where you do audit audit competitions and uh in places like that new Auditors come and they say that hey you have not done a uh add zero check for this address this is a critical issue fix it so for these new Auditors everything is a bug and uh they say that everything is a critical bug so when I say that your understanding of security and risk should be broad I do not mean that everything is a bug but you should have a fairly large idea of what bugs or at least threats mean and your understanding should be backed by practicality not like how the newb Auditors want want to just push everything at the critical bug uh hopefully this explains it a little that uh this dimit says that everything is a bug which is a false positive everything is not a bug it's a false positive the mid with usually uh people like uh me people like some devs that are protecting uh that are defending the uh protocol say that our code is secured and audited that's unlikely to happen acknowledge the bug won't fix so this kind of things is false negatives like if you do these kind of things you tend to overlook things that could have been actual bugs but you missed them because you were slightly arrogant and in most largely Parts angry with this guy who says everything is a bug anyway the person on the right the threat model he says everything is a threat right and then he decides whether after everything being a threat whether it needs our attention or not and what kind of attention do we need to give it right so this is the summarization of uh how a threat model should be anyway so why do you need threat modeling so mostly like uh people say uh that threat modeling is a very nice to have and you do not really need it so uh let's let's very uh quickly break down why you need it so the odds are always tagged against you you have to defend your your entire protocol meanwhile the bad guys need only one vulnerable spot they need one entry point while you need to defend the entire Castle so the odds are always against you threat modeling streamlines the most important resources of the Auditors and developers their attention right so if you tell your developer that hey this this particular piece of code this particular contract is very important they pay special attention to it as well as the Auditors like let me bring this back uh the second Point good Auditors would will do threat modeling on their own but if you give them a threat model before uh or beforehand then that will save their time and like give you a deeper level of uh audits threat modeling helps you reason about a wide variety of abstract security and design questions that are deprioritized during a traditional security audit so when you look at bug bounties and you look at traditional security audits they are somehow very forced to be uh very practical and find specific bugs and not really go into details about how your architecture is dangerous or how your testing strategies are not very good or how your things could be affected by XYZ things which are not direct bugs so that kind of things can be addressed via threat modeling threat modeling increases the efficacy of the protocol testing Suite because if you have done the threat modeling if you recognize the areas that need special attention you can uh increase the impetus of those areas in your testing Suite A sufficiently Advanced threat modeler can abstract the process enough to make it inclusive and gather data points from all stakeholders so basically everyone right from your devs to your CEO CTO de whoever a threat modeler can abstract the concepts of the protocol enough so that they can take their inputs and put them in their threat modeling uh documentation helps you sleep better at night because all doomsday scenarios are taken care of I mean like when I say all doomster scenario you like literally think of everything suppose you are deployed on an L2 and next day the world governments come together and shut down ethereum what happens nothing you store your data somewhere Bo strap your CH again and things go fine so anyway so you do all kinds of Doom stay scenarios even like stupid like this so yeah this is how normal audits are and these are how audits get when you get give your Auditors good threat modeling for your protocol and this is how you sleep after good threat modeling anyway uh right so this is a little background on me and uh why this is somewhat connected to threat modeling so this is a very subjective topic like doing independent security research for just working for a company so I'll stick to personal experiences I won't generalize stuff so here are some of the key trade-offs that I made for my transition from my independent security research researcher status to a security role at Z sync uh so as Chez is as it may sound uh the first reason is impact so what I realized was that I worked really hard with all my clients and gave them the best possible reports every time but the very next client came up with the same issues same problems same uh same vulnerab ities and it almost felt like my work was very localized and going into a void so I wanted to work at a place where I could set the standards of what it means to do secure development right so for that I needed a bigger company and at that bigger company a security role so that I can Define what security means at a slightly authoritative level silly but yeah that's the reason anyway when you have uh a security role at a bigger company you can do things that you can have never done as a independent security researcher you can impact development practices you can impact testing decisions you can impact architectural decisions you can okay you can do uh theoretical stuff such as like how do you do onchain governance and stuff like that like we'll come to that uh if we have time anyway so as a as a security researcher you have a choice to be a journalist versus a specialist and this is slightly nuanced so stick with me uh trading depth of understanding for novelty of exploring new code bases regularly so when I went to zikas Inc it was very clear that I would not be able to participate in every other contest and have a new client with new code base every day and I won't have that hit of uh novelty every time but what I will gain is a depth of understanding in a particular system right so that was my tradeoff specialization in a system and generalization in its component was the other way around so what does that mean is I wanted to specialize in ZK and l2s and generalize in its component that means I want to be a generalist security researcher in uh rust circuits smart contracts whether the other way around people who do independent smart contract researchers are generalized in a system so basically they take any kind of smart contract and are very specialized in a particular uh component for example they're very good at Perpetual protocols they're very good at Ling protocols things like that so again personal preference money I make less money now but hope hope uh Alex doesn't see it anyway so if you're are good like if you're like legitimate good uh you'll make lesser money in a job there is no way around it but again I like to be poor I guess um regarding threat modeling realistically you would only get to do that at larger companies that have the budget and inclination to take their security seriously so this is this was the biggest point that influenced my decision because I could not have done that as a independent security researcher because even if I did say something to them that hey let me take a look at your protocol and give you suggestions on your testing on your architecture a very likely scenario would have been that they would have ignored me they would have not paid me of course and they would have like I don't know not done anything with my work so yeah I wanted to be at a place where my work would hold some value and so I came to zikas syn and that is this particular point is the connection between me living independent security and uh this presentation so this was one of my tweets and this I tweeted after a small discussion with my head of security uh regarding uh Security Council so this is a lot of English just read that so why this was prompted was because when you think of Security Council what you think is we need five different people who will get a system update and they will approve it and the system would get updated right that's it but as someone who is not an independent security researcher but a researcher for a team you get to take this to a deeper level how do you take this to a deeper level you ask deeper questions you ask are the people who are in the security Council qualified enough how do we know that are the people in the security Council who will get the update actually reading it do they actually understand it or are they signing it because of the rest of the people have signed it right are the people that exist in the security Council uh are they like are they people who are friends and travel together and they are susceptible to a $5 wrench attack are they so should we disclose the identif identity of every security council member to every other security council member things like that uh do we keep the members to zync only or we do not uh keep any member from zync who do we include things like that things like that you cannot get as a security uh independent security researcher so yeah cool stuff uh yeah these are changes in my day-to-day life when I switched from uh independent security research to working for a company I did not write less money but yeah there also the part um thank you for not sleeping through the presentation and uh if you want you can connect with me on Twitter you can ask me any doubts if you have thank [Applause] you any questions okay thank oh oh there's [Music] one um what are your thoughts on um ai's application to threat modeling on what ai's application to threat modeling so uh I I see that uh people tend to a lot on uh AI applications but I think these are the best for the first dry run because if you look at gold Arena right now so what they have done is the first hour of any contest they allow Bots to go through the contracts and find out uh the vulnerabilities okay so it has two purposes once they have uh created a competition out of finding bugs from Bots the Bots will keep on getting better and once the actual human Auditors step in they will know that what are the areas that they do not need to look into and create a report out of and not spend their time on so basically it's like AI is like getting your free personal assistant to help your help you in your first research it's like a junior auditor who you pass your first uh uh first run of the code too and I think it's great it's good it's very good once you have ai you have the freedom to go much deeper into into the code base and find out the vulnerabilities that would not have been able to be possible possibly F found because you did not have enough time but now you have enough time to go through it so it's all good yeah oh yes I do use it uh I mean uh yes I do there's a thing called analyzer which starts with four thing like that I have my like I have foged it and added some new things to it so that it can detect things in the L2 contracts of Ving but uh yeah it's it's not AI it's pattern matching right now but uh if I was raising funds from a VC I would yeah thank you all right let's give another round of applause
Automatic transcript — names and jargon may be misspelled.