Security Standards: Code, Ops & Communications - George Kobakhidze

Transcript

[Music] Perfect. All right. Sorry about that. Sorry about all the technical difficulties. Um, so today we're going to be talking about uh well security standards in the Ethereum space. There are a lot of them and at the same time there are only very few of them and you'll kind of see what I mean as we go through it. But I think uh it'll be quite evident as to the adoption of standards in the space. Um at the same time, standards, security stands especially are very very prevalent in

the general tech space in the enterprise space and there's a lot we could learn from. Uh one of the problems with that is is that it's a very broad broad subject and so talking about it could take hours and hours and hours. So today I decided to focus just on the smart contract aspect of things and specifically on the code of the smart contract pretty much kind of like the meat and bones of it the operations around smart contracts and communications around it which is uh something that's forgotten quite often but it's very very important as far as I go. I am an auditor and a researcher at consensus diligence as uh uh I was introduced and I've been doing this

stuff for four years professionally now in the Ethereum space and then I've been in enterprise tech for highly regulated and litigated industries specifically the big banks and big pharma um with very regulated heavily regulated technologies like their communication stacks which was very boring but very useful specific specifically for this talk in fact. So let's get started. To wake everybody up, I'm starting with a little bit of a funnier joke as things go in presentations and that is of course the state of standards across any technology in the world. And

that is I mean I'll give you a few seconds to look over it but the story goes of course is there is a million standards for everything. an engineer comes and says that's way too many. There should be one that unifies them all and then creates yet another standard and now it's a million in one. Um unsurprisingly that is of course the case in the Ethereum space. Uh we'll see it most prevalent in the um interface part of the space but again we'll see it in just a second. As far as the agenda of today's talk, uh it's going to be quite focused because sadly this is a quite a dense topic, but I'll try to kind of pinpoint the big

takeaways for us all as we talk about these standards and what worked in the space with actually very concrete examples about projects that I've worked with and you may have used as well. So, first we're just going to define standards, what the heck they are, what they are going to be about, what people are uh what people mean when they say standards in our space, and then of course we'll go through how they help us build products, operate them, and communicate about them. So, what makes a standard? Uh, typically standards is something that can be separated kind of in three different categories or maybe they're all one category.

um with just three different descriptions but very very typically standards is something that is uh given by an authority figure or by legal right and that's something that can be described as a dour standard right so it's something like government tells you such and such thing as a standard and now you have to comply with it it's not super applicable to the Ethereum space because we're of course quite decentralized in that regard and we don't really have an authority figure or or an authority body. Uh now another big definition for a standard is something that is very very technical. It's very specific. It is something that answers to specific

tests, something that qualifies for specific claims. Um and that's like your technical specification standard. Very popular in our space, very popular in the technology space in general. And then of course a standard which is also very popular in our space is something that is a best practice that is very very very common to be used very popular may not be something that's formalized but it's certainly something that is standard as far as usage goes in the space and again we'll see a lot of that in uh Ethereum. The very important part about standards, and this is something that's going to be kind of like the big takeaway in my opinion from my talk, is that it's not something that you get for

a certification. It's not something that you get as a badge or a or a patch from an auditor such as myself. It is something that will legitimately improve your organization through policies and processes. Um, it's it's boring, but it's actually very very important. And frankly, security should be boring. And u that is exactly why the most secure institutions of our time are very very boring and have a lot of processing in them. It's because they have a lot of standards, checks and balances that kind of help with that. And that's what they're for, what they're there for, not for certification or piece of paper.

So speaking about Ethereum, why is it that standards kind of like are should be a big deal in the space kind of are a big deal in some senses and why is it that I even made this presentation? Well, that is because of course it's kind of a perfect fit for standards. Uh the technology itself is uh something that praises decentralization and you know we like to believe I believe that myself is a decentralized technology in itself. Ethereum smart contracts are accessible by everyone and anyone are they're managed by everyone and anyone and to kind of do that properly to do that efficiently you need to have some sort of a standard to kind of understand how

to operate these things how to build these things so that other people can kind of well cooperate with it very luckily in our neck of the woods in Ethereum I will uh say very spicy take is that this is not the case for a lot of other cryptocurrency ecosystems um and that is in Ethereum there's a very rich culture of open-source collaboration a lot of other projects um deploy their contracts and they don't even verify them they don't even have their own GitHub available for you which is really frankly a shame and in the Ethereum space this is a cardinal sin right if you do anything in the space it's got to be open source especially if we're talking about smart contracts um and uh this is very much welcome and

what's also welcome is The the kind of the corollary of that open source is that it there's a lot of collaboration. People use each other's stuff very much. They fork each other's stuff. They change it and they collaborate and they build up on each other. Again, to do this effectively, you need to have a standard around these things. And finally, and this is most important and I think we're finally realizing it in the last few years. Um, Ethereum is missionritical infrastructure. This is a financial world. This is new financial rails for the world. This is not a joke.

This is not apes and monkeys, frogs, and we're going to make it. This is people's life savings. I think FTX was a big wakeup call where a lot of people like it was shield to everyone and a lot of people used it and although it was web 2 technology, it was still very much cryptoreated and it blew up and lots of lots of lots of people lost their life savings when it was touted as one of the most secure and safe things. And uh well finance is very important and this is something that we need to take very seriously and is mission critical as far as people's literally sometimes food on the table goes. So we need to take it seriously and for that we do need to do the boring thing. We do need to check

through all the checks and balances standards and and whatnot the lists. So it's a perfect fit the Ethereum technology for the standards space. Uh with the one caveat of course that I mentioned there is no official body of certification of authority as far as standards go and that kind of makes things a little bit difficult as far as coordination goes of course especially in something like standards but we'll we'll see how that works out for us. So in preparation for this talk, I made the awful decision to go through a lot of enterprise standards and technical specifications. A lot maybe all frankly standards in the Ethereum space and kind

of like the best practices for it. And then I evaluated them all. Uh we'll go through that fairly quickly and then we'll dive into a little bit more detail. This is how I evaluated them. I mean this is very very simple. It's just basically like what's the standard? Does it affect code process or communications? And then is it a general standard from the tech space or is it something that is cryptonative i.e. Ethereum native like we made it within our space for ourselves. So starting with u the enterprise world there are a lot of standards. I mean, way way more than that, but um I've kind of picked out a few of the big ones that are actually applicable specifically to smart

contracts. And uh this is what I got or at least this is what I've read through for our talk today. Uh a couple of them such as the very first one ISO 27001 is uh a very general standard. It's an information security standard. Um but it is actually critical for us today in the Ethereum space to take very seriously. We'll kind of see why. Um although it doesn't affect code. I mean if anybody here is building a company building smart contract protocol or is in the security space helping do that or even if you're a vendor like me, you got to know it. I mean you have to um it'll become evident why.

Um, outside of these general ones, there are actually quite a few very specific standards to smart contracts in our space, this is uh surprising at least to me and I think to a lot of people in this space uh because uh the enterprise world actually knows a lot about us. It knows very very very clearly what a smart contract is, what it isn't, what a DT is, what a blockchain is, what a consensus is. And let me tell you these smart contract standards from the enterprise world such as ISO 23257 um and NIST IR8202 they legitimately talk about token incentives and governance. I mean

I know protocols that are cryptonatives that don't have that that don't really talk about how their token incentives are structured and if that's effective or not. And uh this is very very much discussed in the in the security aspect of things in these standards which is um very nice to see in the sense of the adoption of the technology but a bit frightening to see from a cryptonative perspective because uh in my opinion I've always thought you know we are ahead of the game and we know this stuff and they kind of don't uh they very much know it they very much understand our technology quite as well as we do and then they understand quite a bit more that we don't and what I mean by That is uh oop nope that was too far. Standards

in the Ethereum space is something that is very heavily focused on code uh with the exception of one that I wanted to kind of point out. This one over here. That's pretty much all we care about really guys. This is this is what we do. This is what we like. We're very technical people. We hate people. We hate trust. Uh we like tech. We like code. We like tests. We like bite code. like API and in fact that's what most of the standards talk about 90% of the time it is how to build the product how to build the code how to very explicitly have your functions defined sometimes down to the compiler level within the standard not even just technology or excuse me the language itself is very welcome to see though

that there's a couple of um standards now that such as the EA ones and the CCS CSS that are now talking about processes as well. Um it's not something that's super very very well adopted, but it is nice to see that processes are starting to break into the crypto world as well as far as standards go. Uh but something that really isn't even though it kind of looks like it's not so bad is the communications part of standards. Uh that is really really lacking and again we'll kind of talk about it. You'll you'll see what I mean.

um in the reality of things very sadly standards are uh standards but they're not actually adopted. What's adopted is best practices. And I mean I kind of just threw this up there. I mean this is all true. We can probably all talk about each one of these for an hour but uh what's actually adopted is not a standard for contracts outside of the ERC world. It's the contract best practices, the token best practices, the how the role of best practices. And very very few of them of these best practices actually talk about how to manage these things in in the sense of a kind of formalized standard within the industry.

They just talk about what it is that you deploy and then you have to figure it out on your own. This isn't to say and I'll repeat this later. This isn't to say that people don't have processes around these things. It's that there are no formalized processes around these things that are shared amongst the industry as a popular standard. Um yes so again to kind of wake us all up what's the state of the standards world in the Ethereum space is that uh they exist they're quite I wouldn't say a lot of them the but there are a few of them they're known but like nobody uses them or very few people use them uh instead what people use is their knowhow

and their do-it-yourself type of an approach for But that doesn't mean we can't learn from it. That doesn't mean that we can't push it. And uh for us to kind of get there, I've come up with a couple of big successes from the standards that I've read that could be applicable to our world and some of the best practices that are shared within the big projects. So as promised, let's start with the code aspect of things uh which is how do standards affect building smart code smart contract code. Again starting from the enterprise world I'll mention a couple of standards over here which is the ISO 23257 and uh NIST SP800 208. Um the reason I'm just going to be

very quick here the reason I want to point them out is that is not because we can learn from it because again we know this better or we thought better than anyone but that they know it too. By they I mean the enterprise world I mean the incumbents I mean the big banks the the big tech they know very well what a smart contract is what a function is what Ethereum is what Bitcoin is what a very niche consensus mechanism mechanism is they really really do know it um what they one thing that they they do that we I mean we also do but they really focus more than us is that they do it on a much more academic level kind of like the math functions of it the hash functions of it as opposed to like actual code engineering although they do have it of course. So

uh standards that are out there right now in the enterprise world definitely do define and help people actually come up with smart contract code. Uh in the Ethereum world uh we actually do have of course standards that really define what your code should look like. Uh I really want to give a big shout out and I'm going to be doing that a little bit throughout this presentation to the EA people specifically their standards for Ethra security levels is very impressive. It defines on a very explic explicit level u what your code should look like what it should um answer to what it should test to how it should be

tested and all things of that of that manner. It's very very nice. I heavily recommend everybody to kind of go over it and I don't just say this because I was a contributor to it but because it's actually quite powerful. Uh they have a couple other standards specifically one I really want to point out is the D5 risk assessment guidelines because this one is much less uh about code although there is some code guidelines there. It's more about processes but we'll look over it as well. And one more I wanted to mention although it's actually sadly not maintained anymore is the SWC registry smart contract weakness classification registry and the OASP smart contract top 10. I mean that's a very very small uh standard. In fact OASP is of course giant but the smart contract top 10 is

very very small but I just wanted to give a shout out to I think it's only couple of people that made it maybe over a hackathon but it was kind of nice. Long story short, super codeheavy, vulnerability heavy, kind of interesting. Again, something that we all know, but uh it's nice to see people come up with it. And of course, naturally the ERC standards that we all know and love, like ERC20 tokens, ERC 72:1 and stuff like that. Uh and in fact, the ERC tokens are the ERC, excuse me, standards are something that's uh a very good example of the standards in the Ethereum space. And that is because of course we have so so so so

so many of them. There is so many standards. I mean how many of them are used? Uh not that many. There's a couple of big ones. I'm not saying we shouldn't come up with more. We should. And in fact, these are the ones that are accepted, so to speak. There's a bunch that are under last call on the EIP website, and there's a bajillion more, like an unfathomable amount more that are either deprecated or under review or whatever. And again, these are ERC's. These are not EIPs. This is not hard fork, soft, soft fork, none of that.

These are actually standards for just writing smart contracts on the Ethereum foundation website. We love coming up with standards. We love taking a standard just tweeting tweaking it just slightly and making it your own. Uh doesn't really help with adoption sadly. It would be much better if we kind of more formalized around a couple of standards as we have around ERC20 but uh this culture of I'll take it tweak it a little bit make it my own is definitely very prevalent in our space which is good and bad at the same time.

Uh but again as I mentioned standards are standards but the reality is that people don't use standards in our space they use best practices and they do it by doing their own thing. The real standard is don't follow other people's standards is take it and kind of change it a little bit. Uh and people even go as far as to because of course our technology allows it to is take a deployed technology and use that directly such as deploy smart contract. But if you're going to change it you don't just change it under and use the same standard. you change it, change the standard and then change the technology as well or change the smart contract. It is what it is. Uh but as far as other best practices go that of course they made it into the actual standards like EA mentioned before. But some big ones

that again I'm sure everybody here knows but are so important I would really would like to mention them again is use audited libraries like of course our folks at open zeppelin uh use uh things like role-based access control very very important especially for processes as I'll mention later have upgradable contracts I know this is a bit of a hot take around around some purists but uh the reality is the reality that you'll find bugs and you to fix them use module patterns. This is something I see so many newcomers fail to do is create giant smart contracts as opposed to make a very small smart contract and then they uh complain about how it's so hard to audit and certify it because of

course certifying a 1500 line of code smart contract is much harder than a 300 line smart contract. But uh the most impactful ones are the 300 line smart contracts and of course invariant-driven development. Something that's been a trend a couple years in the last couple years in the industry is a very nice best practice that I keep seeing around a lot of my clients and the projects that I work with and use of course. So uh kind of the big takeaway here as far as standards and code goes is that we love code specs. We love to be technical. love creating them, modifying them, making them your own.

But we don't like following them. Uh if there isn't popular one, the general gist is maybe I can do it better and then you change it instead of just following it directly. It is what it is. Uh which is kind of ironic because while we do that with standards, we still use other people's technology and we fork it and their patterns. So it's kind of a kind of an interesting spot that we're in as far as standards go. Uh somehow we don't like to be constrained that much. Now u there's a couple of other things I really want to say and I kind of have to hurry up I think uh and that is of course the smart contract operations part of things is something that is becoming much more important over the last couple of years in our

space. So again this is something that the enterprise world knows by heart. Uh, it's super boring. Standards and operations are something they live and breathe. And it boils down to, I mean, I'm not going to go through it all because it's a lot, but it really boils down to change request of a change request, an audit log of an audit log, uh, recording everything, documenting everything, knowing the where everybody stands, getting a sign up for all these things. And it sounds awful, it sounds super slow, but it is necessary. Um and uh again kind of a scary thing or was a scary thing for me to realize is that

they have very much understood the importance of that in the Ethereum and the cryptocurrency smart contract space and the standards outside of the super general ones like the 27001. the other standards that I mentioned that are about smart contracts, they explicitly talk about very very cryptonative things in these in the kind of through the through the lenses of proper processes. So they do talk about key management techniques and procedures um as far as like proper processes go. They do talk about literally token incentives and how they can modify your security posture and how you should think about it properly and what are the processes there. And a big thing that we hate but it is very much a big part of

all these standards is that the human element is the major risk factor indeed and it is it is why the processes are there to try and address that part. Uh heavily recommend anybody to look over these. Um a big thing that is touted in the enterprise uh space is the secure software development life cycle and it is something that frankly you're required to do if you are developing in that space and again now it's coming to our space and that is it's not just you know you don't just yolo your contract and you write it and you don't even just write it p it test it and then get it for review you get that review when you start the p you get that review when you

just start writing the contract In fact, what you do is you have a whole suite of tools for your tool for your code as you're just starting to write the contract. That's things like fuzzing, of course. That's things like even just like some unit test software uh in the beginning of the development is that's things like monitoring the blockchain and transactions when you actually deploy the the contracts into production. As far as our space standards go, uh again big shout out to the EA people. They have done a very very good job of trying to actually map the enterprise processes onto our world and emphasizing some of the things that work there. And again, unsurprisingly, one of the biggest things they emphasize

is uh um tools. Tooling is a giant part of security standards and getting things secure, getting things done right. Um but one of the other things that they really very much emphasize too is things like information security uh hardening and just the general standards for infosc that we don't really follow or maybe the m I mean the major companies do but frankly really not everyone as is evident by some of the latest operational hacks. Uh, speaking of uh I really want to give a shout out to to the CCSS people which is uh a crypto cryptoconorient.org and CCSS stands for literally cryptocurrency security

standards. Uh it focuses pretty much on one thing. There's a couple other things but key management. Key management is uh not in a great state in our industry right now. uh from this from like where your keys are because again we're remote uh to their access geographical implications of that uh clearing your keys rotating your keys. It's uh separating of keys for your colder and hard and hot and colder wallets. It's not in a great state but it's kind of getting there.

um best practices for operations is something uh again as I mentioned it's something that's not quite standardized but it is used across and it is nice to see that in our world today uh again while we don't quite qualify for standards with a lot of these companies what we do is we they do pick up a couple big processes there which is of course the the tooling that I mentioned uh there's a lot of very complex tooling uh for like fuzzing formal verification and all that type of stuff. Of course, audits as well. And then um some of the things for when things go wrong. There's more and more best practices around um things like seal. But for general part, you do your own thing. Uh again,

this doesn't mean that they don't they don't do anything at all. It just means that what they do is kind of like not really shared across. I think I'm coming up on time, so I'll have to hurry up a little bit very sadly. uh a thing that I would like to mention is a couple of couple of big successes. I'll just run through that and then uh the rest of the stuff you can see online. So a big one that uh for example my team does is uh fuzzing. uh we do fuzzing for moonmath frankly for ZK and uh it's now starting to pick up across several teams because of course the more complex the technology the more applicable things like checks and balances are and uh we f a lot of different technologies across the zk

stacks and for example linear we have found several million-dollar bugs there and you can see that quite well uh a big one that I want to give a shout out to is Oiler with their processes around uh well frankly anything. But the big one I want to point out is their postmortem processes because they were able to recover several hundreds millions millions worth of dollars by focusing on the human link aspect of things in the uh in in in the exploit kind of uh recovery part of it. Uh very very important to to follow the appropriate policies and processes for that and that's why they were able to do that. Uh so smart contract operations is ne grow next growing pain point. Get ahead of

it. Uh again I'm out of time sadly. I'll have to run through a couple of things. Communication super important. Enterprise world definitely understands that very quickly. What does that mean? That means having the right channel set up having things documenting and notifying the right people. Again the EA people have done a great job actually pointing that out. There's a whole section that says this can help with against all kinds of risk. Very true. Uh communications, proper communications build trust and trust builds security. Um we suck at that uh in the reality of things. You'll be lucky to see GitHub and Twitter on a project. Uh maybe docs, but probably they're unmaintained. And

that's something that you can see a lot in our industry is its big immaturity. A couple of big shout outs I would like to give to is some companies like Lido which have really impeccable security communications for things like their upgrades. Every single vote that their uh token holders do uh is uh provided with a guide on how to actually check the vote with several scripts through an open source manner and verify them. Very impressive. Wish this will become a standard in our space. It's not. Uh, another thing we'd like to give a shout out to is things like security charters.

So for security councils, not something that's everywhere, but it's coming up more and more. Again, it's very important to tell people what your security council actually does, what it's meant to do, their responsibilities, and that's something that's becoming bigger. Not again, not quite a standard. I wish it will be. Uh, communications are super duper important. We're stuck at it the most right now and uh it's it definitely affects us as far as hacks go and recovery of funds. So uh one last thing I want to mention too, this is literally my last two slides is that all of this stuff is super duper boring. I understand. But security is and it's it's meant to be kind of boring for things like critical information uh

critical um um infrastructure and uh look we are not very good at it. We are not very good at the operation side of things and the communication side of things. This is not even an updated slide. This is a slide from Pablo Sabatella from Bangkok and it's not updated with the bybit $ 1.5 billion hack or 1.3 I don't quite remember. Uh that was a full just fully in operations hack. Our hacks in the last couple years are not because of smart contract code which is great. Our code is now secure.

It is because we do stupid stuff and we forget to follow policies and we forget about separation of privileges and it's very very very important. Uh that's about it. Thank you very much. So one last thing. Okay. just if we don't get our stuff together, the incumbents will come and do it better because if they if we can stomach 1.3 billion worth of losses for a big company, they can stomach it even better and they can go through it much better.

So if we don't, they will and it better be not goddamn big banks that take over our space. Thank you. [Music]