Raising the Bar: Security Leadership for Mass Adoption

Transcript

[music] All right. Hello everyone. All right. [music] So, our Steam MC is not here, so I'm just going to go ahead and kick us off. This is the start of our five minute lightning round. [music] Um, okay. There we go. Now, the music's gone. All right. So, we'll simmer down and get started. Uh, five minute talk. So, timer hasn't started yet, but it will soon. Uh, so it's going to be a quick one. Okay. So this is a general topic just a collection of thoughts that I've had over the indust the years working in the industry on uh how we're going to meet institutional adoption in the industry in terms of security leadership what security leaders in the space should be thinking about if you're a protocol lead or you work with or rather security lead at a protocol or a CISO or just someone who happened to

have been given the security hat at your company because they haven't figured out a formal title yet. These are generally things to keep in mind that kind of differentiate I would say people that are good at security, security researchers from people that are actually like good security leaders and actually know how to take on a lot of the additional responsibilities that implies. Um so these are all very just simple three points fit into five minutes. The first one um because I worked at a security vendor for about four years and then I actually worked at a different security vendor uh before my current job at turnkey where I do solution engineering. Um, we do notice that like I would say in this industry, especially when you're getting started, there's a big focus on like working with external vendors on security audits, on setting up a bug bount platform with

people like Immunifi, maybe even getting monitoring software, which are all good things and these are very important things to spend money on. Uh but I've often seen teams sometimes skip the step of actually building up internal security proess and building and you know paying for both internal security personnel hiring a security lead or security engineer security researcher at some point. Um, sometimes their CTO or a specific security or specific software engineer will take on those responsibilities initially, but eventually you need to start spending internally, maybe also building internal tooling, spending a lot of internal time on bug fixes, maybe also assigning time from your for your software engineers to do uh bug hunting rather than just coding the whole time. Um, and then generally just looking out and thinking

about like okay, what kind of return on investment are we getting for security spend? You know, I've seen people spend uh buy five audits on the same codebase and have them run in parallel and then you basically paid five different auditors to find mostly the same bugs all simultaneously. So start thinking about like what are you actually getting for the money that you're spending so you can do it more effectively. Uh maybe start to evaluate some of your auditors against one another if they are looking at similar scopes. Think about who's most effective. I think what's a really effective is starting out with some, you know, very cheap security research auditors, uh, that you have a very productive relationship with to find a lot of early security issues in your codebase as well as working with your internal security team and then bring in a really like brandame uh, security firm

like Open Zeppelin, like Trail of Bits, Spearbit, others uh, to actually do your final audit uh, who can hopefully find the very obscure stuff that your original team could not find. um because a lot of the like very simple stuff has already been found and it's not going to like uh detract and distract them. Uh second, I think what differentiates good security leads is that you're not just focused on your internal security. You're actually having external conversations. You're talking to your customers. You're talking to your integrating with you. You're talking to ecosystems. If you're deploying on a chain, you're talking to other people building on that same chain. If you're going multi-chain, you're talking to node operators, bridge operators. uh ideally you are even communicating with uh security uh ecosystems such as uh

seal 911, BSSC, web 2 and web3 security groups and learning about like active threat landscapes. And I think the most important aspect of this is that you know who to reach out to in like high-risisk situations where you're like okay we got to like you know there's some funds that have been stolen. We need to move quickly to see what can freeze them. We need to contact Zero Shadow. We need to contact Seal. We need to contact these exchanges, these bridge operators. If you have those pre-existing relationships or you have a relationship with someone who at least knows how to reach out to them and is trusted, you're not going through an email or a form. You're you're directly contacting someone you have a prior work relationship with. That is going to greatly accelerate your speed and being able to resolve an incident. Um, so I

think this really differentiates a good security researcher who can sit in in a cubicle or in, you know, uh, just anywhere in the world and find bugs, but if you can't actually reach out and find the people that are going to help resolve those bugs, that's not going to necessarily uh, make you a good security leader. A good security leader is someone that can actually go out and communicate with these people and establish these relationships. Uh and then the third thing is like when it comes to actually showcasing security and this is probably the most important part for uh institutional adoption is that you're showing substance and not just security theater. Now security theater maybe works for initial conversations. You can say hey we got these certifications we've gotten all these audits etc. That doesn't mean your current security state is good. You know someone can do an audit of your codebase

a year ago. That doesn't mean today's codebase is actually going to be safe. Um but if you're showing like hey this is the deployment process that we do this is the way that we have uh separated our access control. you can speak to it intelligently beyond just like maybe ranting off what ISO 27001 is telling you you should do or websock should do which are still good certifications to have don't get me wrong but can you actually establish what your security practices look like can you maybe even give advice uh to the integration partners you're working with and actually tell them what their security model should be consider where you fit in their security model um and then can you like align those controls do monitoring and actually like maybe showcase things have an incident page uh and of course if you have find yourself

in an incident, you can actually uh communicate that effectively and talk to a lot of different teams, have very detailed postmortems, have very detailed communications with all the teams that depend on you and showcase that like you know even in a case where your security might have failed in some sense, you show a very robust process in how you deal with incidents. Um so the final quote I'll leave you with is institutions don't just adopt technology, they work with leadership they can trust. Most security le leaders out there in web two, they don't know how to evaluate good security in web 3. But if you sit down in front of them and you speak intelligently about your security model, even if they don't understand all of it, if they understand that you take your job seriously and that you think about a wide array of

threats and that you're protecting against them, that will go a very long way. They will say, "Maybe I don't understand the technology enough to trust it, but I trust you because you're building the technology and you're securing it." So keep that in mind. All right. and welcome Rejief. [applause]