So why don't we start by introducing our committee and then we will get into some of the details. So do you wanna start, Petri? - Yep, happy to. So thank you very much, everyone. Thanks for everyone who's joining. Petri Basson currently sitting as the chair for the CCSAs. My background is in finance and IT, so a chartered accountant and certified information system auditor. And relevant to this conversation, I used to be at one of the big four audit firms and worked with a lot of different digital asset companies from funds all the way to custodians, perform SOC 2s. So I saw exactly how SOC works and also where there might be some things missing. So looking forward to this conversation. - Awesome, great. Noah? - Hey everybody, Noah Buxton here. Partner and CEO at the network firm. Sometimes it feels like a lifetime ago, but I helped build the SOC practice, IT controls assurance practice at a top 20 CPA firm in the US. And so I've done more SOC reports than anybody would ever want to. So I've been through hundreds of these engagements and yeah, looking forward to kind of diving deep on what SOC is and some of the distinctions between other standards and specifically how the CCSS can be an incredibly powerful compliment to the SOC standard. - Perfect, I love that more than anyone would ever want to. All right, Michael. - Hi, I'm Michael Perklin. I serve on the CCSS steering committee alongside these wonderful gentlemen. I also serve as the chairman of the board for C4. I've been in the information security world for about 20 years, serving as the CISO of ShapeShift for about six years when it was a company. And now I continue to focus on cryptocurrency security and all things digital. - All right, cool. Jameson. - I'm Jameson Lopp. I've been building multi-signature wallets for about eight years now. - Okay, cool. And I'm Jessica LeBecque. I'm C4's executive director. And today we're gonna be talking about SOC 2 and why it's great to go through SOC 2 audits. But if you are in web three and in particular, if you are managing private keys, why the cryptocurrency security standard or CCSS is something that you should be getting certified in as well. So Michael, will you start us off just talking about why audits are so important within web three? - Yeah, absolutely. Whenever you're doing anything that is very important, and I would definitely classify working on security of your system as very important. It's vital to have somebody else take a look at it. If you're the only person looking at something from your point of view, you could miss things from the side, you can miss things from behind. So having a second pair of eyes double check to make sure that you've done everything that you need to do is very important. We've seen so many hacks in the space where money is taken from one system or another. And it's rooted in the fact that they didn't have a security audit done, or they didn't have a different type of audit done. So having these third party audits is always good. Now, not all audits are the same. There are so many different types of audits, all of them focusing on different types of things. So being aware of the different types of audits and what they do cover, they do not cover is also important if you're gonna be looking for one. And on this call, we'll be talking about one specific type of audit, the SOC 2 audit. - Great. - To build on that real quick, I would say that Web3, whatever you wanna call it, digital assets, crypto today, a lot of the activity, right? Some of it is pure, let's say Bitcoin as a commodity trading, right? A lot of it's pure capital markets. And then there's things that are finance adjacent, capital markets adjacent, right? Participation in DAOs, other community activity, NFTs and artwork, right? All of these sort of new subsectors of the crypto space, all of them ultimately have some financial aspect to them. Again, they're sort of pure finance, they're innovation in finance, or they're sort of finance adjacent, right? Even in artwork, right? So you're not only buying a tokenized piece of art or digital rights to a piece of art, but you're probably participating in a community where you're staking or having some other financial related participation in that community. And finance forever essentially has been supplemented or improved by audits, by third parties, right? Confirming some activity, some balances, some period over time, whatever the scope of these engagements can be, but you can go back hundreds of years and see that this has been a critical part of capital formation, trust in markets, ability for users to kind of be able to trust and transact. And so now we're in this new space, right? I remember when I first got into it in 2016, in a professional context, again, I was working at a large audit firm and some of the narrative at that time was like, wow, this blockchain thing is really gonna replace auditors, right? We're just gonna be completely boxed out because it's all on chain. Everyone shares the ledger. Everything's open and transparent. Well, that has today turned out not to be true. And that's not true because centralized counterparties are still a big part of this space, right? And there's different viewpoints on this, right? Maybe if you're say a purist or you're sort of on one side of the spectrum, you say, hey, look, it really should all be on chain. I hold my own keys. I transact without counterparties. I engage directly in this space. And then sort of the other side of the spectrum, maybe a more retail perspective is, I can't do all that myself or I just wanna get into this space. So I'm gonna trust a counterparty ultimately. I'm gonna use an exchange to custody my keys and allow me a quick exchange, or I'm gonna use a custodian or a lending provider or things like that. So in any case, most there will always be a significant part of this space that deals with counterparties, right? There's always gonna be the purist, but there will always be counterparties in the crypto and digital asset space. And to that extent, you need audits, you need third-party involvement for confirmation. We've have so many historical examples of this need, and there's just another painful one recently with Prime Trust, right? Just over the past two weeks, we've sort of seen the slow information leak out, and then we see the Nevada regulator actually put this business in receivership. First, allegedly a pretty massive hole in its balance sheet for what? Ultimately when it all boils down, the Prime Trust problem was mismanagement of private keys, mismanagement of crypto wallets, mismanagement of custody, right? The pretty disaster scenario allegedly sending customers crypto to legacy wallets or sort of prior used wallets that management no longer had private keys to. So essentially sending them to the waste bin. And then later again, allegedly trying to refill those coffers by using customer cash to do OTC deals and buy more crypto and sort of refill the new wallets. That catch-up scheme has never worked for anybody in history, it will never work. And so you think about something like CCSS, a private key security standard, if a player like Prime Trust had been implementing this, had people at the business that were knowledgeable about it, they were implementing the controls, doing the oversight, this problem, which allegedly again ran for over a year, sending crypto to the waste bin would have been caught quite a bit sooner or maybe even better, not even happened to begin with, so. - Yeah, and I think that when we're talking about security audits or private key audits, anything like that, we wanna make sure that we're not suggesting that the CCSS should be instead of SOC 2, or instead of another security audit that you are already doing necessarily. We're saying that this is an audit that complements what you're already doing. And so we'll get into that a little bit more later on in this call, but Noah, you bring up really good points. There is this standard that exists right now, the CCSS that we see time and time again, if it had been followed, these things would have been prevented. And yet we see within this ecosystem that we're all a part of this cycle of these same things happening over and over again. And so part of it is making sure that you're as secure as possible, doing things like SOC 2 audits, but also CCSS if you are managing private keys. So why don't we talk a little bit about what SOC 2 is, and then we'll get into some of the comparisons between SOC 2 and CCSS. So Noah, I know you were just talking a little bit, but I'd like to call on you again to discuss what SOC 2 audits are. I know there are two different types of audits, but maybe you can just walk us through briefly that, and then why we're focusing on type 2. - Yeah, for sure. And I'll invite Petri to interrupt me 'cause I know he's done a lot of this work as well. So if I missed something. So SOC, the often discussed and often misunderstood reporting standard. So SOC stands for System and Organization Controls. And it's a standard that's issued by the American Institute of Certified Public Accountants. And importantly, it's actually what's called a reporting standard. It allows a CPA to sign an opinion over management's report or some subject matter. It's actually not a security standard. If anyone at the AICPA hears it referred to as a security standard, right? They don't like that very much. And CPAs definitely shouldn't refer to it that way. It's a reporting standard. And so there's actually, yeah, there are two types of SOC reports. There's a SOC 1 and a SOC 2. And down from there, there's a type 1 and type 2 for each of those. So there's kind of, you know, four, let's say, four reports you could get. There's also SOC 3, which is a public distribution version of a SOC 2. It's just a really limited form public distribution report. But basically, I think what we're focused on today is SOC 2. That's probably the most relevant when you think about quote unquote security. And of course it gets a little bit more confusing 'cause the SOC 2 standard itself does include a trust services criteria called security. So not a security report, but includes a TSC called security. So again, they are CPA attestation reports and a CPA must sign these examination opinions. And ultimately what the CPA is doing is providing a whole lot of auditor judgment. We'll talk more about that. But auditor judgment to make an opinion that the controls at the business were suitably designed to meet specified SOC 2 criteria. And in a type 2 engagement, which runs over a period of time, that over that period of time, those controls were operating effectively, quote unquote operating effectively to meet those specified trust services criteria. So the trust services criteria are kind of like a buffet basically. If you wanna go to the buffet, you gotta buy a plate. The plate is quote unquote security. So the baseline sort of entry point for every SOC 2 report is security. Management can then determine with the auditor what other trust services criteria are relevant and which they want to include in the report. And so that's sort of the a la carte items that you can go get at the buffet, which is additional stuff. Availability, is the system highly available to its users? Confidentiality, does the system adequately protect the confidential information of users? Processing integrity, which is a very flexible criteria, but basically says, does the system take what it's supposed to and output what it's supposed to through all the processing that it may do? And then privacy, a more relatively new trust services criteria. Does the system adequately protect the private or PII, personally identifiable information of the users that are in the system? So there is again an international component for these as well. So you might see ISAE, International Standard for Ad Test Engagements, 3000 and 3402. Those are SOC 2 and SOC 1 respectively for international. And then another intersection here internationally is ISO 27001, which is a pretty good matchup for SOC 2, has a lot of the same sort of principles within it and sort of, it's a lot different. We won't go down that rabbit hole. Kind of says ultimately at the end of the day, the same thing, but in practice, how these engagements are done and sort of the details are quite a bit different. So, okay, so that's a little bit about SOC. I don't know, maybe Petri, just check me real quick. Is that enough on the baseline understanding? - Yeah, I think maybe to make it a little bit clearer for people is especially with the SOC 2, the way that it works is you've got specific criteria. So you've got common criteria, that's control environment, communications, risk assessment, logical access, all kinds of things like that. And what you're doing is you're mapping the controls the company has to these criteria. So the criteria sort of say, you should be meeting this requirement. And then the company says, well, we do this thing, this thing and this thing, and they make sure that we achieve this. So it's much more of a general information system control. And when you're doing a SOC, I mean, this is very broad scope. It isn't just a private key control. You go from sort of the board level, corporate governance controls down to logical access, change management, those kinds of things. So I think it's important for people just to understand that a SOC is a really good report to have the security of the company. So broad scope, what the company is doing, they're doing the right things, but it doesn't really get into that very narrow vertical of private key control. So key generation, key storage, all those kinds of things. - Absolutely. Yeah, thanks for that. And they're super flexible, right? Like there's this concept of auditor judgment, right? Which is applied in financial statement audits and SOC quote unquote audits as well. And so, not all SOC reports are created equal. And that's a big distinction from other more prescriptive security standards. So, another example that's common in the finance space is PCI DSS, which many of our listeners are probably very familiar with, maybe more than me probably, probably have some PCI auditors here. And you know that that standard is very prescriptive, right? There's of course a little bit of auditor judgment here and there, but ultimately you have a defined scope and your testing systems, whether they sort of rise to the bar or not, right? And the bar is pretty clearly set. In a SOC 2 engagement, as Petri says, the bar is, you know, is the system secure? And there's a few points to say whether it's secure, logically protected, physically protected, et cetera. And all of the controls to meet it are determined by management. So that bar is actually kind of set by the auditor in many ways. It's the auditor's interpretation of what is security given the scope of the engagement I'm looking at, right? What is logical access, sufficient logical access protection given the system that I'm looking at, right? Where again, PCIA, PCI very prescriptive and same for CCSS, right? There's no, the CCSS auditor does not set the bar, right? There's certain areas where yes, there's gonna be some auditor judgment and understanding the system and things like that, but pretty much it's, you meet it or you don't, right? It's black and white. And I think one other quick point on that black and white aspect is, you know, SOC reports, third-party assurance reports, these are really, these are widely circulated. These are sort of the most common reports that you've never heard of basically and never seen. They're behind the scenes, they're traded between, you know, business to business communications. They're built into compliance contracts and requirements between banks and service providers and others, payroll companies, et cetera. So they're widely around, but you don't really see them. They're sort of this under layer. And, you know, that's ideally not, I think my perspective, it's good, it's a good layer of assurance, but it's not really what the crypto and digital assets space needs. Individuals, retail, so to speak, are really looking for transparency directly, right? They're looking for assurance in a more direct way with their service providers. And so, you know, a SOC 2 stamp on a website, again, how do you parse that? It could be very good. It could be, absolutely. Management has done everything that they need to. They have a very good auditor and they've been put to a lot of scrutiny to meet these requirements. But I think a really good supplement to that is CCSS, right? Because then you know for sure that the company has designed controls around their private key security, creation, backup, storage, et cetera, where, you know, a system that manages private keys for crypto has a SOC 2. You don't really even know if the auditor has covered that, right? And even if they have covered it, it might be only sort of at a test basis, meaning show us one example of when you created a wallet or show us one example of when you backed up a wallet, right? A test of one is not sufficient in the crypto space. And so there's other examples where, you know, assurance reports over crypto are really a hundred percent test basis, right? We're testing everything. To be sure, to make sure I'm clear, like a proof of reserves is an example, right? A CPA tested proof of reserves. You don't test, you know, a material portion or 25% of the assets that management holds. You need to test everything. You need to test all of the liabilities on the platform owed to customers and all of the assets in custody. And so that's kind of similar to CCSS, right? It's, you know, it's not a test basis. It's, again, it's much more black and white. And when a user sees CCSS, I think they have a lot more confidence or ability to have a lot more confidence once they properly understand it, that this company is kind of doing the right things around private key storage. - Yeah, and I think we should just zoom out for one second and say, why is this so important again? Because I'm just going to point out that talking about audits is not the most thrilling thing, at least for people that don't do audits. I'm not like, oh my God, yes, we get to talk about audits and standards, but it is so important. And there is a reason why we're talking about all this. And Michael, do you want to zoom us out for a second? - Yeah, I would. - Let's get into the business of the big picture and then we'll dive back in again. And that was such a good explanation, Noah and Petri. - Yeah, Noah, great deep dive. It was said at the top of the call, and I think it's worth repeating. When you're doing something that is important, it is required for you to make sure that you're covering all of the bases. Getting the right audits done is having somebody else come in and double-check what you're doing. There are so many different types of audits, financial audits, information system audits, cryptocurrency, private key audits. Even just knowing which audits you need is an important skill. And I think one of the things that Noah illustrated pretty clearly when he was diving deep into the SOC 2 world is just how involved these get. And these types of audits aren't something that you can just do on your own because you read a little bit about it on a webpage. You need to find someone who understands that specific type of audit thoroughly before you bring them in. In the Web3 world, if you're gonna have somebody review your smart contracts to make sure that your smart contracts have no bugs or gotchas in there that can allow someone to steal funds, you don't want to just pay for a rubber stamp. Slap the audit of this company on your website to show that you've done something. And now, hey, you're good to go, you're good to launch. Everybody uses it. And then a week later, all the funds disappear because that company that slapped that logo on your website for you didn't actually dive in deep enough. They didn't cover all the bases that need to be covered. It's, yeah, I'll just leave it there. Surround yourself with experts who understand this stuff deeply so that you don't have to. That way they can root out all the problems before your customers find them. - So there's, I think also just the question of, what are you acting as? And really all of these financial auditing mechanisms exist because companies are acting as trusted third parties. And when you're acting as a trusted third party, you're essentially a black box. Whoever is using you, they only know whatever you reveal to them. So in the case of like crypto custodians, generally the only thing that is revealed is some sort of user interface for depositing and withdrawing. Everything else that goes on behind that form is completely opaque. And so what we're really doing with audits is you're creating a level of transparency that doesn't require for that entity to completely open up all of their internals to the entire world. You know, it's kind of like a trust transfer. There's some reputation involved, of course, like whoever's auditing the system needs to have a reputation to go along with what they're doing. Because like we said, a simple rubber stamp doesn't actually provide anything. But when we are advising people to follow the various standards that our consortium puts out there, it's difficult for any of these entities to prove that they're actually following the standard. You know, there has to be some other process in place so that we can have this transfer of proof, if you will. - You bring up a great point, James, and that's actually the history of SOC. That's part of the reason SOC reports were even developed into a standard is that there used to be this right to audit that was included in contracts. And so it got to the point where, let's say a large payroll company would be one that a lot of huge customers, and each of those customers has the ability to a right to audit. And when they would exercise that, you have five, even 10 customers a year exercise that, management is completely inundated with these individual audits just for a single customer. So you're right, it's a much better mechanism to have a standard and have management be able to do this reporting. - In the end, it's trust but verify. You're trusting these guys in everything they say on their website, but you've got an auditor actually going in there verifying that they're really doing it. And I think that's why everyone's passionate about that. There's definitely a need for that in the industry. - Yeah, so we, or no, I guess you focused a little bit on what SOC 2 does cover. I think everyone jumped in a little bit about that, but why don't we talk now, if we're ready to, about what it is that CCSS covers that SOC 2 doesn't and why it's not like C4 in 2014 created a standard just for the hell of it. - This standard was created because there was a need within the cryptocurrency ecosystem to focus on private key management. And so this group of people came together among others to say, here's what we need to do to stop the mismanagement of private keys. All of these things that were happening in 2014 and before, since 2009, have continued to happen. And we're now in 2023. So this standard remains relevant and necessary. And what is it that is not covered in SOC 2 that we're specifically focusing on in the CCSS? Jameson, did you wanna start or anybody else? - I mean, really it's the nitty gritty of the actual private key management itself. I'm not highly versed in the SOC 1 and 2 stuff, but I think as we've already covered a bit, it leans more heavily on the controls around reporting and auditing of the system. And that's great if you want to be sure that you can do like forensic analysis. If something goes wrong, you have a level of integrity around the historical data of what has happened in that system. And that is one control in the CCSS, but it's kind of the cherry on top. Really, I think the issue with crypto finance compared to traditional finance is that it's a lot less forgiving because we're talking about bearer assets. And if something goes wrong, there's often no way to undo what has gone wrong. So as a result, you need to front load your security more. You can't just rely upon having strong audit trails so that you can go back and undo anything that went wrong. And so that's where the CCS comes in. And it's really more about making sure that you have strong key generation, key management, key storage, and then internal controls around the humans that are actually interfacing with these keys. - Yeah, when the CCSS was first being drafted, before it even had the name CCSS, it was just a project to itemize all the different hacks that had occurred at that time. In 2014, the large MTGOX hack had just occurred in January of that year, amongst many others. And information security professionals, including myself, we just started categorizing, okay, well, MTGOX lost its money this way. This company lost their money that way. This wallet lost funds the other way. And as we were identifying the root causes of each of these, clusters started forming. Oh, well, these people didn't create the key properly. So it was easily figure outable by other people who are a lot smarter than us. Those people, sure, they created the key, great, but they didn't store it properly. They cheaped out on this over here. These people cheaped out on that over there. And suddenly when we looked at it, Jameson mentioned it on this call, it's sort of the life cycle of the key, from cradle to grave, when it's created, how it's stored, how it's accessed when it's needed, and how it's decommissioned when it's no longer needed. The standard just sort of jumped out of this data at us, and we realized that this should be a guiding light. The PCI industry, the payment card industry, all those credit cards and debit cards that we use every day, if any company wants to accept credit cards or accept debit cards from their customers for payment, they have to follow something called the PCI standard. The PCI standard, the payment card industry standard, is something that was created by the payment card industry to help protect the payment card industry. Self-created, self-governed. And when we look at how the CCSS has evolved, we realized it was created by crypto geeks who want to protect other crypto people from all these crypto hacks. And the controls in there cover that same life cycle, making it quite effective at private key security in the same way that the PCI is effective for credit card security or SOC 2 or ISO 27001 are effective in what they are governing. - I'll take a shot at your question too. So what does the CCSS include that SOC 2 doesn't? It's actually kind of hard to answer because if I go back to the top, I told you that SOC 2 is a reporting framework, not a security standard. So one way I would answer it is to say of all of the SOC reports or SOC 2s that have been issued over a system that in some way custodies private keys on behalf of users or behalf of management even, I would say it's probably a low percentage of those reports that actually include the controls that should be there to evidence proper private key security. But really every SOC 2 report could and should, if it's again, related to a crypto scope or private key scope, could and should include the CCSS requirements aspects essentially. So you could have a SOC 2 on the one hand, again, that covers the scope that's crypto security or excuse me, crypto custody, and literally doesn't include any of the sort of inquiry or testing that it should to give comfort over a private key security. Or you could have one that does. So it's a little bit of a backward answer to your question because I'm not specifically saying what aspects of the CCSS aren't included in SOC 2 because it's again, a hard question to answer. But one thing that maybe auditors wanna know if there's auditors on the live stream. So there is, I've told you there's a lot of different types of SOC reports. Under the standards, there's something available called the SOC 2 plus. And what this allows the, it's the gold version or whatever, it's the upgraded SOC 2. What it allows the auditor to do is to opine not only over did management's controls meet the trust criteria of, let's say it's just security, but in an appendix to the report, the auditor can include, did those controls also meet any other sort of standard criteria or reporting framework? And so a common example that I've done in the past is related to PII. So we do a SOC report that has security, availability, confidentiality, and privacy criteria. And then at the end of the report, it can be mapped to HIPAA requirements or health information privacy sort of requirements in the US. I've also done a readiness in the past where we use CCSS as the plus and said, okay, well, here's your SOC 2 report with all the controls mapped against TSC, but if you remap everything, here's how it meets CCSS requirements as well. So I think that's a really kind of interesting opportunity for people that sit at the intersection, whether you're management and you're looking for transparency reporting for your users, or whether you're an auditor that has the ability to sort of sign SOC opinions and do the CCSS work, that could be a pretty powerful combination for management, right? Where they can get the CCSS cert, but they can also include those controls and report on them through a SOC 2 vehicle. So. - Yeah, there are a couple of specific differences between the CCSS and the SOC 2, and they all mainly focus around the cryptocurrency. As Noah mentioned, the SOC 2 cover is more of a reporting framework, whereas the CCSS is razor focused on protecting your private keys. Some pieces that are in the CCSS that are not in the SOC 2 reporting framework would be the key compromise protocol. One of the aspects of the CCSS governs the creation of a key compromise protocol. Basically a playbook on what to do if the shit hits the fan. There are a variety of ways for a key or a key holder to become compromised. A key could be compromised one day when you're looking at, or you return home and you find that your home has been broken into, and the locked area where you keep your private key backup, there's evidence that someone has tried to get in there. Without even knowing whether they did get in there or they did not get in there, there's now a significant risk that that key is compromised. Even if you see that they've taken it, they may not have been able to use it yet. So now you're under the gun and you need to work fast. A person can become compromised as well. Maybe they have a new belief on who actually owns those tokens versus the reality. Maybe there's some problems happening at home in their financial life where they suddenly need access to more funds than they did yesterday. Maybe God forbid, and I hate to even think of these types of things, but maybe someone in their family has been kidnapped and now they're being leveraged. Either you do this with the funds or else. Whether the person is compromised or whether the key is compromised, having a playbook pre-written for what you should do, what your organization should do, what your team should do when a key or a person becomes compromised is a essential step. It's a big piece of the CCSS. SOC 2 doesn't cover that. I'm sure we can, if I was more familiar with the SOC 2 reporting standard, I'd be able to identify more things that the CCSS does cover that the SOC 2 doesn't. But it's important to highlight here that the CCSS is not something that replaces the SOC 2 standard. It's not something that replaces the ISO 27001 standard. It's not something that replaces the PCI standard. CCSS is something that complements it. Because ISO 27001 is razor focused on general information systems, because PCI is razor focused on payment card systems, because SOC 2 is razor focused on reporting, there is nothing else that is razor focused on cryptocurrency private keys. So for that reason alone, you should absolutely be doing multiple of them to cover off where the other ones don't. - Noah, did you want to jump in? I saw you were unmuted, so I thought you were about to say something. - Oh, sorry, I didn't know I was unmuted. - I didn't want to cut you off. - Yeah, no, no. - No, that's okay. - Well said. - No worries. Yes, agreed. So someone told me recently in a conversation that they don't need to get their CCSS cert because, or audit, because they are going through SOC 2 and their auditor is covering everything that the CCSS does not cover. So their auditor is covering everything needed. And I think that based on this call, we have uncovered the fact that that is not actually enough, but what would your response be if someone was to say that? Petri? - I mean, I can probably speak to some very practical examples here, is the one thing I've actually seen is key generation, because if you look at that SOC 2 and the mapping, there isn't really somewhere to fit that. It's a very big round hole problem. So you definitely want to do some work over how the keys were generated, but there's no way to really fit it in there. I mean, the SOC 2 plus is potentially one way to do it. So that might be a good question to ask, but generally you can't really get it in there. And then the other issue we've seen is key generation is normally something you do once, and then you're using those base keys, depending on how your system works. But a SOC 2 is sort of an annual process. So if you add it into your SOC, you can maybe test it in the 12 months that you did it, but in the following year, you can't really test it again because it's not in that scope of that period. So that's where the CCS is, it's a really good supplement to that, where you can test that control that happened once. You can look at those controls, whether there's good documentation and everything around that, but you can't really fit that into a SOC 2 because you'll have this control that every year you just say no opportunity to test if you put it in your SOC 2. - All right, then- - Sorry, I love that example. Because one I've seen in practice, it's not crypto security, but is private key security, is encryption of data at rest, right? So in security, you're in a SOC 2 focus, one of the criteria within there will be protection of the data, right? And so you look at management's controls and they say, oh, well, we encrypt all of the user data at rest, and we also encrypt it in backups. And then, okay, how does the auditor test that? Well, you get access to a system, you view documentation or work with the control owner to see the system is configured to encrypt data at rest. But to Petri's point, like, well, how was that encryption key created? Because once you have the private key, if that's leaked or improper users have access to it, or it's not properly physically protected, well, it doesn't matter that the data is encrypted at rest because it can be unencrypted by a bad actor, right? And the same is true, of course, for private keys that relate to crypto assets. So I love that example, that's a really good one. - Even just taking a look at your home, if you're gonna be leaving on a trip and you just wanna double check, oh, did I leave the stove on? You should also make sure that you left the oven off as well. Or if you're gonna be locking your front door, you should also make sure that you lock the back door. Doing something like SOC2, but not doing something like CCSS is the equivalent. It's covering some of the bases, but not the rest. Like any chain, security is as strong as its weakest link. And you gotta make sure that you're doing both. You can't do one and ignore the other. - There's big pitfalls when companies, to your point, Jessica, or to your question, and sort of to Michael's point too, is when a company says, hey, we have a key partner, we've got a big customer, we really wanna sell this deal, but they wanna put SOC2 as a requirement in our contract and we've gotta get this done to make the sale. You sort of have this top down sort of requirement. And what happens? Management and legal push it to the team, product, security team, customer team, they say, we gotta get ready for SOC2. Like, just get ready. And of course, management probably sets the timeline a little bit short on the team. And then so the auditor comes in and they say, all right, show us evidence that you've done your quarterly user access review. And the team is like, oh no, we look at users all the time. Every time we add someone to the system or remove someone for a terminated employee, we look at the access list. We audit it all the time. And the auditor says, yeah, sorry, but the control is you perform and document a quarterly user access review and it's signed off by the appropriate manager. As the auditor, I can't accept your evidence. Like, it's nice that you do that and you tell me that you do it, but I don't have the evidence of it. So I think this is just one example. But if you think about as management, if you think not in a top down way, oh, I need to do this reporting standard. I need to get this report out to a big key partner. If you think instead around risk assessment, what are the key risks in my business? Like what are the, oh crap scenarios that could go wrong and how should I control that and get some expert advice where you need it. But now you're building from the bottom up. And then when you need a SOC report, you need to evidence this to third parties and you need an audit over it. You actually have your own controls. You can actually say, oh yeah, we built these controls months or years ago because these were the key risks that we're actually worried about. And here's how these controls that we've built and operated and documented can map to SOC 2 or can map to ISO 27001 or PCI or whatever, pick a standard or pick a reporting framework. And now you actually have management's controls that you can use to evidence that. There's big pitfalls with the other approach, which is, oh crap, we just need a SOC 2. But you haven't actually built any controls. And so CCSS would be a great place to start. If you are custodying, you know, anyone's your private keys or custodying assets on behalf of others, that's a key risk in your business. You should build controls around it. How are you gonna build controls around it? You have some experts, but why not look to an industry accepted standard that says, here's how you should do it for the whole key lifecycle, build controls that way. And then again, they can map to anything, right? You can have your CCSS certification, but you can also report that out through SOC 2, ISO 27001, et cetera. - You know, something that Michael has referenced in the past is this idea, and I think we've all talked about this, how you're only as secure as your weakest link. And so when we're talking about custodying and we're saying that, okay, we're trusting somebody else to do X, Y, Z with private keys. If we compare it to, and this is the example Michael has said, securing a house. If you say, okay, they lock their front door and you see them locking your front door, you're like, okay, I feel safe that this house is secured. Okay, I see someone saying they're doing this with their private keys, it's secure. Okay, but what else are they missing within the security, both within the house and within the private keys? So just 'cause someone locks their front door doesn't mean their windows are locked, it doesn't mean the garage door is safe. There are all these different components. The same thing with private keys, just because someone says, oh, we're doing this one thing doesn't mean they're doing all of the other things that make it safe. And I might've butchered that example 'cause it's not mine, but Michael, do you wanna touch a little bit on what that actually looks like in practice? - Yeah, you pretty much hit the nail on the head. Just because you see somebody doing one thing or just because a company is shining a bunch of lights and saying, look at this one thing that we're doing doesn't mean that they're doing everything. This is why having a knowledgeable auditor is important because somebody who is an auditor, they make this their day job to know about all of the little things that need to be covered. Not just that one thing that marketing loves to tout on the website, every little thing. And I should mention that for anybody who is watching and you're working on your own crypto project, you're working on your Web3 project, you're working on your company that deals with crypto, whatever system it is that you are working with that you have a concern about making sure that you're doing everything that you need to be doing. If you need to find a auditor, a CCSS auditor who can do all these things, who knows all this stuff through and through, there's a directory of these CCSSAs, the CCSS auditors on the cryptoconsortium.org website. I'm sure Jessica will be tweeting the address shortly. Just head there and you can see a list of them. You've got your pick. - I have a question. If somebody is a SOC2 auditor, are they necessarily a cryptocurrency or cybersecurity expert? What is the, I guess, overlay with that? So if someone comes in and you're a crypto company, and so for example, Jamison, if you were going to have somebody come in and do a SOC2 audit of Casa, how would you need to evaluate that they understand all of these other cybersecurity and cryptocurrency pieces to be ensure that what they're looking for is indeed what they should be looking for to be able to prove to your customers that you're in fact doing all the right things? - Right, I think Noah mentioned it earlier, but I think a SOC2 auditor is more likely to be a certified public accountant. And I think the likelihood that someone is a certified public accountant and a cybersecurity expert is very, very low. So these are two very different specialties. And once again, that's why these audits are complementary and they overlap a little bit, but not really enough to be significant. And so you're really, each of these audits is giving you some reliability, some protection around completely different aspects of a business. - Yeah, to add on that, that's spot on, right? Like definitely have to be a CPA to sign these reports. So what you'll find is that the partners might have a financial, the sign-off partner might have a financial audit background. A lot of times though, the practice leader or signing partner is probably more like a mix of financial audit and information systems sort of audit. Maybe they've worked, a lot of my background, I've seen partners that have public company experience, they've worked on sort of internal controls, reporting for public companies. So there's a little bit of intersection, but what you wanna look for is a team under that partner that has information systems background. So I know like my prior team, a lot of the people that I hired would have an information systems degree, a graduate degree, right? Or they'd had internal experience working in IT or actually been in a business actually working, managing an information system. So yeah, you definitely wanna look for that part of the team, a specialized team. And then the, sorry, the last piece here, okay, that's just the information systems. What about the crypto piece of that private key subset? I would say that that's still a pretty limited skillset, unfortunately. If you look across the market, it's a very small number of people compared to the total that work in this space that have the sufficient skills, knowledge, experience to really cover these scopes. - I think I'd agree there. You wanna sort of build or stack the skillset. So if you start with the CPA, you add on a CISO or a CISP or some qualification like that, and then you add on a CCSSA at the back of that, I think then you potentially have someone looking at everything, or if you've got a team with those different qualifications, because they're gonna be picky and paranoid about the right things, especially in a SOC. I mean, the CPAs are looking at a lot of the entity level, the big controls, the CISP, CISO guys are really in the IT stuff. And then the CCSSA guys will be really into the private key controls. So you can really sort of build up that skillset. - So I think that we're coming close to the end of our time, and I wanna close by just bringing up something I was just thinking about when we brought up Prime Trust, or you did know, I was thinking every time we get on a live stream, it just so happens that there's the most recent hack or the most recent company that's gone down, whatever it is, it seems like every time we come to do this, we've got this quick example right at our fingertips, didn't really have to do much thinking on it. And I think that says a lot about the need for the CCSS and building trust within this ecosystem. We have an industry that is unfortunately sometimes mocked by people outside of it. And it is because of this lack of security, I think, and these issues continuing to happen. We've got big players that try to peek their heads into the crypto space, and then we see something like Prime Trust, or we've seen, I'm not gonna go through the long list of companies that have had issues with this, but we see it time and time again. And unfortunately, it's not going to get better if we continue to do the exact same things, which is just SOC2 audits, or just PCI DSS, or whatever it is. We need to make sure that we're increasing security, increasing private key management skills. And I think to do so, one of the best ways is to use this standard, which is curated by cybersecurity and cryptocurrency experts. And so anybody wanna jump in before we sign off? - Yeah, and to your point, Jessica, it's not just that there's another recent hack, or another recent big event. When you take a look at that thing, whether it's Prime Trust, whether it's FTX, whether it's MT Gox 10 years ago, all of them are repeating the same mistakes. And if the CCSS were to have been followed by that company, that mistake wouldn't have happened in the first place. Or the bad actor who was trying to grift people under the banner of the company, the trusted banner of the company, they wouldn't have been able to get away with it. And they would have rooted out far sooner protecting people. It's my hope that we as crypto users, Bitcoin users around the world, we start demanding transparency from the companies that we deal with. It's my hope that users start demanding to see CCSS compliance reports from the companies that they trust to handle their crypto. It's my belief that if every single company in the space followed the CCSS, none of these attacks would occur. But yeah, I'll leave it there. - Yeah, and the last thing I wanna say before we all sign off is that we recognize that one of the challenges to becoming certified as CCSS for one of your systems is really understanding what that entails and what a system needs to be doing in order to reach these different levels. So we've got the standard, but, and this might be news to some of the members of this committee, we are creating a course all about level one CCSS, what you need to know and understand in order to begin to reach out to an auditor to become compliant or to prove compliance. And so this course is going to be available on August 15th of this year. And so it's already in the middle of being created and we will be formally announcing it then. Michael is giving a presentation at the Futurist Conference in Toronto on August 16th, I believe, and so this will be ready by the time that he is giving his presentation and keep an eye out. So if you wanna learn more about level one and we'll be adding to this, you can access this course starting on August 15th. So any last minute sign-offs, any warnings we wanna give people other than please do the right thing, make sure if you're managing somebody else's money that you care about it as much as you care about your own 'cause these are actual people out there that you are losing their money and they may have worked pretty hard for it. I'm guessing they did. Any last words? - Time flies when you're having fun. Can't believe it's been a full hour stream. Thanks everyone for joining. Thanks to the team.