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.