David Ding

Kia Ora Kotou everyone and welcome. I'm David Ding. I'm a business innovation advisor in the commercialisation team at Callaghan Innovation focused on frontier Innovation in the Web3 and AI space. Our guest today is Marc Krisjanous from Confide. Confide is a qualified security assessment company.

And our topic today is security best practices for Web3 businesses. The format today is Marc is going to be taking us through a presentation and he welcomes your questions while he is presenting. So just put your hand up and we'll get to you. And you can ask a question in real time, and then if we've got time at the end, we'll have a Q and A as well.

So, over to you, Marc.

Marc Krisjanous

Thank you.

So the presentation today is, is going to be at a high level for information security. So we're going to cover what is information security, what is an information security standard, and how it can be applied to a Web3 platform or project.

So just a little bit about me. I've got a developer's background. So started off nearly 20 years ago in the IT space and started off as a developer and then progressively moved into security operations and then went in over to the the dark side, which is the auditor's side. And that's where I am currently. I audit under ISO 27001 PCI DSS and CCSS so a whole bunch of acronyms, but basically they're what you call information security standards and you can certify against these standards.

Been in the crypto space now for, I'd say about three years. Pretty much enjoy anything that is crypto and there's my LinkedIn profile. Happy to connect with anyone at any time on LinkedIn. At confide, we are a New Zealand based company. We've been around for over 10 years now. We're basically known as the, the main PCI DSS auditing firm in New Zealand.

And we've just currently gotten into auditing under CCSS, which is the cryptocurrency security standards. We found it very easy to cross over from the PCI DSS to CCSS because of PCI having a very, very strong focus on encryption. So it was easy to transition over to the cryptocurrency security standard because obviously, encryption is a major factor or major importance in cryptocurrency, blockchain.

Marc Krisjanous

So if we just cover the overview of, of Web3, security risks and threats as I see it security in, in most startups is not of, of maximum importance as you'd imagine. There's always the vanity, vanity metrics that everyone is looking at for startups, which is how many users, how fast is the growth how much revenue is coming in.

And security is normally at this stage, considered to be done after we reach a certain point in the number of users or after we reach a certain point in revenue. And then there is a focus on retrofitting security into the system. Which is never, ever a good thing. Anyone can get into Web3. Just like anyone can get into Web2, anyone can build a website, an e-commerce website start selling stuff.

Therefore, so everyone can get into Web3 as well. What we've noticed though, and I think the general public has noticed via the media is that these platforms are started, defi platforms and so forth they get hacked because there's normally, generally poor coding practices. The members only can be reached via a Discord channel or a, a signal channel or a Telegram channel.

And as soon as something bad happens, they all disappear. And you can't get hold of them. And this is the, the perception of the general public. And it's, it's actually very damaging. I will, I would believe in my opinion that it actually causes a lot of people who are interested in crypto and defi to actually avoid it like the plague because it sounds like the wild West out there.

And it's also attracting government as you were well aware of government regulation around the world. Just for the simple things of not providing proper security, information security on these platforms. Another distinction we've noticed with Web3 is that in the Web2 arena, when you hack a website or you hack a online database, you're generally giving personal identifiable information and then the hacker has to sell that information to other users and use it for social engineering and so forth.

So there's, there's two steps in the process. You hack the site, you get the the information, and you sell that information. With Web3, you're missing that you actually missed out one of those key steps. You actually, when you hack a Web3 platform, if it's defi, you get instant funds. So there's the risk and reward for Web3 hacking is far greater than Web2.

One information security is not that great in Web3. And when you do hack a platform ultimately you're getting, you are getting funds instead of just information that you need to onsell. And as I mentioned, the easy attack vectors. Web3 currently with crypto as well. Currently you've got a huge complex onboarding process.

I mean, if you think about just the just the ability to download a web browser plugin like meta mask and, you know, configure your wallet. And have that working connecting to platforms providing consent on the connection or the, or the transaction information. I mean, most of the time you wouldn't even have a clue what you're actually clicking on when the wallet software starts prompting you for things or prompting you for permission.

So it's very confusing and very complex for the average user. Again, we've got poor InfoSec information security, and also this whole concept of hiding behind an anonymous chat profile. It's not good and it's, it doesn't look really great in the, in the public arena. I mean, can you imagine if your banks, when they, you try and get hold of them because something's wrong and they all hide behind pseudonyms or anonymous accounts that you can't communicate with.

So really need to lift the game up with Web3 in, in these regards.

Marc Krisjanous

Information security, sometimes incorrectly called cybersecurity. Cybersecurity is a term that is used but doesn't really reflect much. The, the correct terminology is information security, but cybersecurity sounds a heap more sexy. And the marketing department just got hold of that and now everything's cyber, cyber security. The correct terminology is actually information security. And that what is information security? It's, it's basically the implementation of security controls to protect data. And these information security controls can be grouped together in an information security management system.

And so that just allows you to manage all your information security controls in a structured way. Information security controls can be at a high level, they can be preventative. So you've got things such as security cameras, encryption data classification, HR. So these are the types of controls that would prevent this activity or reduce malicious activity.

You've got deterrent, deterrent controls, which are things that deter people from malicious activity. Guards, CCTV, firewalls, encryption awareness training. You'll notice that a number of these security controls are actually in the same categories as well. For example, encryption can be a preventative control, but it also can be a deterrent as well.

Detective - so this is the ability to actually look and see retrospectively. All real time malicious activity going on, such as logs being produced by the platform being looked at by automation tools such as seam detecting unusual activity and then alerting people to that activity. Honey pots, so attracting malicious activity in order to understand how they go about compromising or what their attack vectors or their methodologies are. Also things like mandatory vacations where you can actually spot insider threats. You've also got corrective controls. So those are things such as how do we recover or how do we stop and recover from an attack?

Antivirus is a classic example. That virus may land on your desktop, may start doing something, but the antivirus detects the malicious activity and stops it. Business continuity plans is another form of a corrective security control, as well as key compromise protocols. There's also another security control group called Recovery, which is your security controls around backups, database shadowing and fault tolerant drive system.

So backups, backups always seem to be ignored until you really, really need them. With information security controls that cover backups, you would look for things such as testing your backups every month, making sure that your backup is actually not corrupted. This becomes incredibly important when you're actually trying to recover from an intrusion or a breach and you have to revert to a backup, and then you find that the backups are actually corrupted.

That's a pretty serious position to be in.

Marc Krisjanous

So we have all the information security controls which can be in the hundreds. So how do we actually apply that to our organisation in a structured way that we can measure the success. We can also maintain this whole information security management system.

So there's things called information security standards, which is just documented techniques in a structured framework for how do you apply your information security controls. Most of the information security standards will focus on risk first. So a common example would be is that you define your business.

What, what is my business? What am I providing? Then you work out what your risks are in your business. Then you work out such things as who would cause me harm or what would cause me harm. And how would I protect against that? So you may be in a position where you are offering financial services.

Your risks are that you lose money, you lose your client's money. The result being brand damage. So how would I protect against that? And you would look at, well, what information security controls can I apply? It's not only just information security controls, it can also be financial controls as well.

Some of the most well-known information security standards are ISO 27001 PCI DSS. So that's the information security standard that was created by the major card brands in the world. Visa, MasterCard, for example. They were getting very tired of breaches involving their credit cards and the cost of recovery of those credit cards.

So they started with, they created an information security standard around the protection of credit card data. It's a very robust and rigorous standard. SOC 2 is another type of information security standard which it seems to have quite a lot of prevalence overseas. You'll see a lot of especially in LinkedIn or you'll see a lot of platforms or startups that saying, you know, congratulate us we are now SOC 2 type two compliant. I think a lot of that's brought on by the encouragement of investors as a way to ensure that the investment is actually going to be worthwhile.

We've also got CCSS, which is the cryptocurrency security standard. Fairly recent standard compared to the others. This was created in 2015 by a whole bunch of Bitcoin enthusiasts who really wanted to see the value and the security around Bitcoin improve. And so they came together and created the standard and it's completely focused on cryptocurrency and underneath the underlying structure of key management like with signing transactions for the blockchain.

Marc Krisjanous

So what are the types of information security controls that you can have? You've got patching. So this is probably one of the most important and basic of all information security controls, is to patch your systems when updates are provided. You've also got vulnerability management. So this is the continuous scanning of systems for vulnerabilities.

Penetration testing in is included in this code audits. We've got hardening of systems. So when a system is brought up, there are international recognised standards that say if you configure it in this way, then additional protections will be applied. So it's about ensuring that your system is configured correctly and reduces the chances of malicious activity. Secure coding techniques training, something that is very, very important but often overlooked when looking at developers and training them is to ensure that they understand how to code securely.

So, If your developers don't understand how to code securely or what type of vulnerabilities are being introduced, this is a major attack vector, especially for the likes of Web3 or smart contracts and so forth. Data protection. So this is another information security control where you classify data so you understand what, what data is in your organisation, what is, what data is critical to your business. How do we protect this critical data?

What is data that is really publicly available and with the data classifications, then we apply things such as the encryption, retention, and the destruction policies. Security training and awareness. Another important item, as you well know, with fishing and social engineering attacks. The weakest link in any system is, is the human.

And so security and awareness training is, is absolutely critical for any organisation. Incident response, another basic information security control that is often overlooked. Not only should you have an incident response plan, so how do we firstly detect malicious activity? How do we respond to the malicious activity and how do we recover from the malicious activity?

And then lessons learned. What have we learned from this incident that we can make our incident response plan even better? The other important consideration with incident response is to actually practice and test your instant response plan. So there are information security controls, especially in PCI DSS ISO 27001 that actually state that you need to test your instant response plan periodically or maybe annually. Whatever is deemed required.

Marc Krisjanous

If we continue on with baseline security controls, we've got access control. So restricting access to information to the people that need to see that information or need to interact with that information. Very uh, classic example here is startups where the CEO or the founder may have access to everything.

And then in a, a couple of years time, you've got hundreds of employees, but still the founder has got access to everything. That's where access control should be applied and identified that maybe the founder of the business doesn't actually need god access anymore. And in fact, it's actually quite a serious risk to the business.

Also the different types of authentication factors such as multifactor authentication. Just a note here with the cryptocurrency security standard at level three requires three factors of authentication to access keys. We've got logging and alerting. So this is monitoring the logs to ensure that there is no unusual activity.

We've got implement and test the backups. So again, backup, very important for recovery purposes, but also far more important as well is testing your backups to make sure they're not corrupted and that you can recover from an event using your backup. Another one that another information security control that is often overlooked is service provider management.

So again, I mentioned before that some of the most major hacks known in, in the IT space was actually caused by, or service providers not having very good information security. So they may have a connection into their client's environment. The client may be quite secure, but the service provider isn't, and there is an entry point for a malicious user to attack the rather secure entity, but via the, the service provider who, who has a very weak security posture. As mentioned just below, there are hundreds of security controls, but these are the, the most basic. There are guides and also recommendations on like for CIS, where you can actually say the top 10 information security controls to apply first or the top 18.

Marc Krisjanous

With an information security standard, generally you can certify against the standard. Certification is normally obtained by using a third party auditor to audit these systems against the standard. And if the systems meet the certification requirements, then they become certified against that standard.

This provides very powerful assurance to the general public, to customers, to prospects, that this organisation takes information security seriously. Time and time again, you'll see organisations saying that they're certified in PCI DSS or their ISO 27001 certified, or their SOC 2 type two certified.

This means that an independent auditor has come in, applied the standard against these the systems, the people, process, and technology components and that they've met the standards requirements. What you can do in the meantime as you build up your information security system in order to meet certification requirements is that you can align to the standard.

So you might see terminology with some organisations to state that they align to ISO 27001 or they align to SOP 2 type two. Generally, doesn't mean that they're certified. What it means is that they're actually following the standard to, to a certain level, but they have not been certified by a third party auditor yet.

Marc Krisjanous

So in the section we're just going to look at information security as it applies to Web3 and also how CCSS can also benefit Web3 projects.

I have seen some communication on forums and, and discussion , in LinkedIn and so forth that the current information security standards don't apply to Web3 because Web3 is all about decentralisation. I'm not going to go into the debate about centralisation versus decentralisation, but the key thing to ask yourself here is if I have a Web3 project, can I use information security standards that are current, that are in the world today?

Well, there's things like you can ask yourself, if you're still coding in Web3, which is eg smart contracts, then you still need secure coding techniques. You still need to ensure that your developers are trained in how to code securely. That they're aware of the vulnerabilities that are prevalent in the languages that they use. That they understand what peer review process is. That they understand what an a third party audit is of their code.

They understand the importance of the separation of duties between someone who codes the smart contract and someone who deploys the smart contract to production. So, secure coding techniques is a well-known security control for Web2, and it still applies to Web3 in my opinion. The other interesting thing with Web3 is that when you get down to it and look at some of the Web3 components or some of the services that are used by Web3 platforms, as it stands today, it appears that they're using Web2 type infrastructure.

For example, you may have certain components of your Web3 platform running on AWS. Well, my opinion would be that AWS is actually a centralised hosting provider, doesn't provide any type of decentralised hosting as I know it. So we would look for patching vulnerability management and also service provider management as well, ensuring that the Web2 components that you are using, whatever organisation is offering those products and services, that they're actually either certified against an information security standard or they're aligned to one just to provide assurance to yourself that they take information security seriously as well.

And this drops down easily into our third party services and products. Web3 platforms that I see today are not just comprised of in-house development. They're using services and products from service providers all over. So again, this is where we want to check that our service providers are compliant as well, or certified in information security standards.

You wouldn't expect AWS to not take information security seriously. So what you can see when you go to AWS, to their compliance area, as you can see the raft of certifications that they have everything from ISO 27001, PCI DSS, SOC 2 type two financial certifications, the list goes on and on. And this is what you wanna make sure that the service providers you use are taking information security seriously.

Because at the end of the day, if you look at a Web3 stack ultimately, some of your components may be running on environments that you do not control or own. So if the servers that are running those components aren't patched properly, then there's a vulnerability that you can't even control.

Your wallet software may be secure because you coded it and you applied information security controls to it. But what, what about the server that's actually running this wallet software? Are they patching this operating systems?

Incident response: again, if a Web3 project gets breached, you're going to apply incident response. So still for Web3, you still need to apply incident response management.

And finally protecting keys. This comes back to data management, identifying the keys in your organisation, the criticality of your keys, your signing keys. Who has access to the keys, how are the keys protected at rest in transit and while being processed. These are all information security controls that are still with the standards as we see it today. So they apply to Web3 as well.

Marc Krisjanous

So here's my rather basic mockup of what I believe to be components of a Web3 platform. We've got the UI front end, which can generally be comprised of your basic Web2 stuff, which is running on a web server. You've got your identity layer, so this is your wallet. This is where you can see proof of ownership of an address.

We've got our application layer, which can be smart contracts. We've got our blockchain nodes so this is the layer which communicates with the blockchains. And of course we've got our blockchain ourselves. And on the other side, we've got services that Web3 platforms may use. We've got job schedulers, we've got IPFS Interplanetary File Systems.

So this is the ability to store data off chain because storing data on chain is incredibly expensive for some blockchains. We've got blockchain indexes. So the ability to query events on the blockchain. We've got blockchain no providers. So instead of writing your own code to talk to the blockchain, you utilise the service provider who already provides the software that communicates with blockchains.

You've got online key volts you're communicating with a blockchain in a, in a, an application environment, then obviously you need to protect your keys. You can't you know, you need to be able to access your keys via code in an automated fashion in such a way that every time there's a transaction required, it doesn't require manual signing of keys, a manual signing of transaction, sorry.

And then you've got your monitoring and alerting as well. So those types of off chain services are also, as I see it, part of a Web3 platform. And you can see here that all these components will have some type of ability to be vulnerable, to attack. And again, this is where information security standards can be applied to these components to make them more secure.

Marc Krisjanous

If we just break down the cryptocurrency security standard a bit more. The cryptocurrency security standard is designed purely for cryptocurrency systems, which provide cryptocurrency functions and also underneath the underlying blockchain infrastructure as well. It is not what they consider a baseline security standard.

So C4, which is the not-for-profit organisation, which manages CCSS, they state that you should first look at a baseline information security control. And then once that is established, apply CCSS on top of the baseline information security controls.

We see with CCSS, the requirements in the standard are very focused on technologies and concepts within the blockchain and the cryptocurrency space. For example, we have requirements around the need for multisig wallets or MPC. We've got things such as focus on entropy or key custodians.

Some of these are already on the baseline information security standards, such as having key custodian or key management practices. But the CCSS standard really drills into these at a very detailed level.

Marc Krisjanous: So where does CCSS the cryptocurrency security standard add value to Web3. So we go back to our Web3 component stack. We can see that the baseline information security standards apply to all of the components. Where CCSS really focuses and adds value is at the identification layer. So the wallet and the key management layer.

Marc Krisjanous: We can see here with the signing of a transaction. So the encryption component of signing a transaction is where CCSS really focuses on. And what we'll do is, we'll, we'll go through at a high level the requirements or the aspects in CCSS.

Marc Krisjanous:

So, CCSS is broken down into a number of aspects, which can be considered to be concepts or, or categories and in each aspect a bunch of requirements. And CCSS has three levels of certification. You can be certified to level one, which is the implementation of the basic requirements. You can have level two, which is above and beyond level one, and then you can have level three, which is the ultimate level, which is applying all the requirements within CCSS.

There are currently two entities that have met CCSS level three requirements in the world. That's Fireblocks and Liminal. They are wallet infrastructure providers, and I audited both entities and they're the first two in the world. The audit program for CCSS only started literally about six months ago. So it's just starting now and it's ramping up very fast.

With key seed generation. These are the requirements around the creation of keys, particular focus on entropy requirements as well. We've got another aspect, which is wallet creation. So this is the creation of wallets the people in the process and technology components around wallet creation.

We've got key storage. So storing your keys at rest, how are they protected. Is there a key encrypting key? If that's if there's a key encrypting key, where is that stored? How are the security controls applied to the key encrypting key? How many keys are there? Are they stored at different locations and so forth?

Marc Krisjanous:

Key usage. So there's requirements that look at keys while they're in use. How are keys protected, for example, when they're being used to sign a transaction? Are they stored in memory? Are they stored in a secure enclave? Are they stored in an HSM? These are the requirements that focus around key usage, they're in this aspect.

Key compromise policy. So this is the further refinement of the incident response, security control. So you have your general information security management for incident response, but the CCSS goes one higher where it really drills down on how do I deal with the key that's been compromised?

How do we recover from it? How do we alert our customers? How many copies of the key were there? How do we rotate keys if we have to? All these types of different incident responses related to keys in these in this aspect. Keyholder Grant Revoke policies and procedures. So this is a, a further refinement on your user access management or your access management security controls.

Making sure that the people that have access to the keys require that access, are authorized to access those keys. Things such as if a person leaves the organisation, are their is their user account revoked? Access to the keys. The classic example of making sure that the founder of the business after a couple of years still doesn't have access to the keys if they don't need it.

Those are the aspects in CCSS that cover the key management and the wallet activities. CCSS also provides additional aspects around operational security. We've got security tests and audits. So, what we have here are requirements around ensuring that the people, process and technology around the assessed entity have been audited or there's been internal security assessments, that there's been smart contract auditing going on third party.

At the highest level for CCSS, which is level three, you'll find that there is requirements around pen testing, security audits all done via third parties. As an auditor for CCSS, this is where we would look at how organisations are ensuring that the code or the platforms that they have and provide have been tested by third parties, that are skilled in, in penetration testing or, or smart contract audits.

So it's about ensuring that there have been external eyes looked on every component within the CCSS in scope environment. Data sanitization, another key thing if there is an organisation that requires to have keys that are shipped around put on removable digital media sent to their clients, and so forth, how are this digital media securely cleaned and destroyed?

It can also extend to the the servers or the repositories that store these keys. For example, if HSM is decommissioned, how do we ensure that the keys that the HSM maintained have been securely destroyed? Once the HSM is decommissioned. We also have audit logs. So we have requirements around ensuring that audit logs are maintained and are checked on a regular basis.

Marc Krisjanous:

And finally, we have our proof of reserve requirements. So, CCSS, as I see it, is one of the first and probably only standard I've seen that actually has a proof of reserve requirement. I haven't seen it enforced in any other standard. I could be wrong because I only really focus on information security, but that's what I believe to be the case.

And so CCSS has a proof of reserve requirements. We know that proof of reserve is something that's still being worked on. It's not a hundred percent guaranteed. We've seen that some of the reports that have been produced only focus on chain. There's issues around the fact that how, how do you actually trust that their proof of reserve reports are accurate?

It doesn't. It may not take into account off chain liabilities or off chain investments or other types of debt or contractual obligations. But it's starting and with further refinement for proof of reserve it looks like it could be hopefully a, a, a positive financial control because proof of reserve, in my opinion, is actually a financial control.

However, the CCSS committee members who maintained the standard felt that it was absolutely important that it somewhere that someone was actually providing some type of financial proof. That they have reserves available if there's such things as a bank run. So it's unique. Many people will comment on CCSS proof of Reserve saying, well, wait a minute.

That's a financial control. It's not an information security control. But the fact of the matter is, it's such a important thing to consider that the CCSS committee added it, regardless.

Marc Krisjanous:

And finally if I was building a Web3 platform, I would I would introduce information security in an approach that would be as cost effective as possible. The first things I would look at doing would be to offer a bug bounty. So with that, we may find that the initial team building the Web3 platform don't have the skills in house for information security or the ability to detect vulnerabilities.

We may want to have a smart contract audit, but we may not be prepared to wait six months, which I believe is the average waiting time to have your smart contracts audited by a third party smart contract auditing firm. So why don't we offer a bug bounty that will entice people that are very smart and very knowledgeable in, in such things as smart contracts to review our code and they get rewarded or incentivized for, for, for doing this, this effort.

So that's one of the first things I would introduce is a bug bounty program. I will, of course have third party audits done as well. But the bug bounty is a faster and quicker way of actually getting eyes, eyeballs on my code to ensure that the bulk of the vulnerabilities have been detected already.

Another thing I would look at is the, the concerning use of anonymous people within a team. The, the use of anon for, you know, for the developers. So you might have a team of developers that are all over the world, you only know them by their Discord channel, or maybe an email address from Gmail or some other generic email service provider.

And you build up quite a relationship or rapport with them. But you never really know who these people are. Now, there are well known attack vectors where state actors or organized crime or more sophisticated attackers will actually join projects to offer their services such as development for the express reason of getting access to the code and with malicious intent, it's called an insider threat. So we know that that's actually quite a, a relatively easy attack vector to use with platforms that don't mind having anonymous people have access to their code. So for me, I would ensure that I know the person who was coding on my platform.

I'd like to see them you know, in a, in a meeting, like to see their face. I'd like to know who their personal information is. Well, not personal information, but you know, at least understand who they are. It's vital. Absolutely vital that you know your team members well enough that there is accountability within the team and that you know that if something went wrong, you could actually see or understand who that person was that caused that issue and you'd have some recourse to that.

David Ding: Marc, you've had a question come through, would you mind if we just jump in and answer a question?

Marc Krijanous: Yeah, sure.

David Ding: So, regarding proof of reserves, what is the lens taken by CCSS in terms of ensuring off chain asset reserves from a security point of view?

Marc Krisjanous:

Very very good question. Currently, the proof of reserve requirement has not been tested with CCSS.

As I mentioned, there's only been two entities in the world that have actually signed up for certification, and both of them were service providers. So the proof of reserve requirements did not apply to service providers. It doesn't apply to service providers because in both cases, Fireblocks and Liminal stated that they are not in charge of all the keys for signing and they have no control on the customer's use of their wallets.

So we are currently waiting for an entity who would invoke the proof of reserve requirements so we can test the the CCSS requirements. The CCSS requirements are vague when it comes to proof of reserve, I have to admit. They talk about reviewing proof of reserve reports or proof of reserve mechanisms, such as Kraken's tool that you can use to see proof if your wallet was included in a proof of reserve.

There is no requirement for off chain reporting and a proof of reserve report for CCSS. The key issue that is that we face as auditors for proof of reserve is that currently, as my understanding has it, there is no internationally recognised proof of reserve standards that provide testing procedures, that provide guidance to auditors on what a proof of reserve report should include.

So as it stands right now, when an auditor audits the system under CCSS for proof of reserve requirements, it will be up to the auditor's interpretation of proof reserve requirements on how that is implemented. And it sounds a bit scary but what the CCSS committee have decided is that when we get to this stage where we have to audit an entity and apply the POR requirements is that the CCSS committee will be involved in the discussions around the mechanisms that provide the proof of reserve reports.

The POR reports themselves and will come to a consensus instead of just relying on one auditor's interpretation of what they believe a POR report is. So at this stage, it's untested. The requirements are there. We're just waiting on an entity to, to test the requirements. It will probably result in further refinement of the POR requirements. But rest assured it will not just be one auditor in their interpretation. It'll be a CCSS committee. And probably the rest of the auditors would come around and reach consensus as to if the entity has met the requirements.

David Ding:

That's great. What would be the ideal entity from your perspective to be that use case?

Marc Krisjanous:

It would be so CCSS has three designations. You have a service provider that is defined as an entity, which does not control all the signing keys. Classic example, Fireblocks and Liminal. They're wallet infrastructure providers at the core. You have another designation, CCSS, which is self custody. These are the types of entities which provide crypto facilities in the e-commerce website.

They accept cryptocurrency and they use it for their own benefit. They're not managing other people's funds or wallets. The third designation is what is called full system. And this is the, this is the designation that will invoke the proof of reserve requirements. And it would be something on the, along the lines of exchanges that control all the keys.

So what would be absolutely fantastic is if we had someone, the likes of Kraken wanting to do the CCSS certification, and that's where we would apply the testing procedures for POR. So it would more than likely be any entity which controls all the keys.

[00:43:41] David Ding: Brilliant. Thanks, Marc.

Marc Krisjanous:

The other thing I'd, I'd really focus on with Web3 is incident response. So more than likely, when a Web3 platform would be put up, when my Web3 platform would be brought into production, there will be a raft of scanning. There'll be a raft of testing or proding to to try and find out ways of hacking the site.

So, one of the first things I would do, even before the production site is online is I would create an incident response plan and I would test it and I'd ensure that all my, all the team knows how to invoke the incident response plan. With that, I would ensure that there were auditing in place or other types of security controls in place that would alert me to any kind of suspicious activity.

I would provide channels for third parties to communicate with me as quickly as possible if they've detected that something malicious is occurring on my platform. And with all these types of channels and processes, I'd make sure that all my team members knew how to invoke the incident response plan.

And we would test it. So we would at least test it. I'd say every quarter or whenever a new team member comes on, we would test the incident response plan again. It is, it is my opinion, I've been in auditing for nearly 10 years now and based on my experience is that if you have a very good and robust incident response plan that's been tested and improved, like so lessons learned from incidents those lessons learned have been applied to the incident response plan and improved that we should be able to have a more robust security posture.

So organisations that are, have a robust security posture are ones that have very good instant response procedures. And it's, it's, there's nothing worse than actually finding out that your site is being attacked and you don't know what to do. You don't know who to contact. You don't know what to shut down.

You don't know how to isolate the event. You don't know where the backups are. You don't know if the keys have been compromised. If the keys have been compromised, you don't know how to rotate the keys or change the wallets. There's you can, you can be left floundering quite a bit if your incident response plan hasn't been implemented correctly.

The other thing that I would focus on would be service providers. Again, some of the, the biggest hacks that we know of in, in IT have been done via service provider. Service providers that have not had really good security posture and that have resulted in an attack vector that comes in via a service provider who has access to the entity systems in some shape or form is a classic, classic attack vector.

So I would make sure every service provider that I use is doing some form of information security. Whether it be from the largest posting providers, AWS, Azure, ensuring that they're taking information security seriously right through to you know, an external web designer who has FTP access to the web server.

Again, I'd just make sure that they were at least aware of their responsibilities to protect my information when they use it. E.g. -. How do I protect against them being able to FTP into my site? Do I only turn on FTP or access to them when they need it? And as soon as they've finished what they need to do, revoking that access immediately, changing the passwords for the accounts that they have on a regular basis, or ensuring that they use multifactor authentication and and so forth.

So those are the, probably the, the information security controls that I'd implement right off the bat. Bug Bounty, ensuring that I know all my team members, even though they might be half a world away or I only talk to them via video calls, I would not allow any anonymous user into the platform or into my environment.

Absolutely no way. Developers, I'd ensure that the developers that I use have been trained in secure coding techniques so they know how to secure code in, in in the smart contract programming languages or whatever other languages that are used. I'd ensure that my incident response plan is there, it's tested thoroughly and all the team members know how to invoke it.

And I'd also ensure that every service provider I use has some form of information security management practice in play. These, apart from offering the bug bounty, depending on how much the reward is, these are the, these overall basic information security controls are not expensive to implement.

I mean, you can do all this work pretty much yourself. It's not going to cost a fortune. On top of that, I would also align to an information security standard such as ISO 27001 or CCSS or the CIS top 18 controls. And I'd align myself to them, meaning I would look at the standard and I would choose what security controls make sense to me.

I'd follow their methodology on how to work out which security controls are of importance. And I'd just start at the top and say The information security standard I'm using has recommended these security controls as being the most critical. And then I'd implement those based on the criticality and I go through the list. Because I'm aligning, I don't have to worry too much about engaging a third party auditor. I can do that at such a time where I can actually afford the certification process or that it's required that I do certify for some specific regulatory reason or some investment requirement.

Marc Krisjanous:

Well, that's, that's basically it for the presentation. So it was really just to focus around looking at information security what it is, how do I apply it? Is it still is there information security standards in existence today still applicable to Web3? I believe they are. You can pick and choose.

There's also things such as aligning to an information security standard. There are some organisations out there that believe that unless I have to certify against an information security standard, I can't use that information security standard. Well, of course you can. You can align to it and pick and choose what suits you at that time.

Information security standards are there to, to provide a methodology and a framework for applying information security. It doesn't demand or require that in order to use the standard, you must be, you know, certified in this. So, and finally we had a look at what I would be implementing in regards to information security for Web3 if I was starting a Web3 project.

Marc Krisjanous: And, and that's basically, that's basically it. Is there any, any questions about anything?

David Ding: Yep. That's great Marc. We've got a couple of questions in the chat here. So first one is: how do you see the adoption of multi-party computation frameworks? e.g. used by Fireblocks in the context of projects operating fully in the defi ecosystem?

And there's a comment to go with this. From Will, I can clearly see the likes of Fireblocks operating with intermediated services, e.g. Exchanges and banks but less clear about their work with fully open source defi projects.Marc Krisjanous: So is that using MPC as it pertains to an information security standard?

David Ding: Yep. Is that right? Yup.

Marc Krisjanous:

Yeah, so, CCSS, if you look at the standard as it stands today, it was created in 2015. So there's talk of multisignature but the standard, when we applied the auditing program to the standard, we ensured that the standard would not restrict new protocols or new approaches to implementing key management.

Therefore, with Fireblocks and the use of MPC, we were able to apply the CCSS requirements to MPC. What we did is we considered MPC as each individual key shard or key share that is used would be classified as its own entity or as its own private key, so to speak. So we applied the CCSS applicable requirements to each key shard or key share.

So being a service provider as well, Fireblocks cannot be responsible for the management or the protection of the key shards that the customer is, is managing. So this is where Fireblocks is designated a service provider in CCSS. So they are responsible for the keys or the key shards that they control.

The customers of Fireblocks. In order they, in order for them to be CCSS certified, they need to undertake an audit as well. And the auditor will audit their keys that they are responsible for. They will use Fireblocks' CCSS certification as you know, Fireblocks the entity as managing the keys that they do to the requirements of CCSS.

But now we will look at each Fireblocks customer and see how they're managing their key shards that they're responsible for. So this is the key distinction between a qualified service provider. Fireblocks, Liminal. And a full system, which is an exchange that will control all the keys. I hope that answers your question.

Marc Krisjanous:

Oh, sorry. Just, and the other thing too, if there's any suggestions, comments, feedback regarding certain protocols, certain approaches to platforms or, or defi or Web3, then please don't hesitate to either contact C4 or contact me. I'll be happy to pass on any questions, suggestions, or concerns onto the CCSS committee?

Because the standard is being actively maintained, we are already considering the feedback from the two audits I've conducted and looking for ways to update and improve the standard. So the standard is moving and it will change in order to take on and support more newer protocols, concepts and so forth.

So please contact me if you've got any questions or concerns about the implementation of the standard to your platform, because I will definitely pass that on to the committee members.

David Ding:

Great stuff, Marc. Okay, next one is two part question.

There are a number of organisations like Gitcoin offering bug bounties to security auditors. In your view, how should these bounties be regarded vis-à-vis actual full security audits by reputable firms such as chain security, et cetera. Would you see them as complimentary, like for like, for security audits or something else for ongoing ops security?

Marc Krisjanous:

Under CCSS I would consider them as additional to, the, the use of external third parties qualified external third parties for auditing smart contracts is part of the CCSS requirement.

So the entity being assessed must prove that they're using qualified third party service providers that provide these auditing services that they're actually being used. In regards to people who are providing bug bounties, we the situation, there could be a, a sole individual, a a group of people.

It could even be a hacker or a malicious user that finds a vulnerability and works out the bug bounty program is profitable enough to engage with. So, for an auditor seeking assurance that the entity is using third party providers, we would look at the audit report and ensure that the audit was undertaken by a qualified service provider.

So qualified as a subjective term, but it normally means internationally recognised organisations that have a proven track record in implementing the audit methodologies and also if they have any industry recognised standards themselves. Classic example, going back to penetration testing.

So for penetration testing, we would look at a penetration test report and we would see who conducted the penetration test. Are they certified in pen testing methodologies. E.g. are they crest certified and we would ensure that they were qualified enough in order to have actually done the pen test to be able to provide that report and provide it as assurance in the audit.

So, long story short, I would use the bug Bounty findings as additional evidence, but I would still require that the entity conducts a formal program engaging with a qualified service provider for code audits. Just because with the formal program and the qualified service providers, we can track the entity and track and understand their certification, how they train their auditors. You know, the, the level of professionalism and so forth. It's, it's subjective, but that's, that's how I'll I would apply it to the standard.

David Ding:

Great stuff. Thanks, Marc. Well, we've got about just under 25 minutes left, so I do want to go a bit deeper on a couple of topics. The first one is do you believe that the framework being administered by C4 is robust enough, for example, for a CBDC for a nation?

Marc Krisjanous:

Yes. I, I do because ultimately, end of the day it's about key management and nformation security when applying key management is covered in your baseline information security controls, ISO 27001 PCI. They all cover key management or, or encryption, or cryptography as basic security controls. And then on top of that, CCSS focuses on the cryptography related blockchain signing transactions, wallet management, and so forth. So I believe that the CCSS as it stands today, has enough requirements that can cover you know, central Bank digital currencies in, in, in their current form.

And as I mentioned before, CCSS committee is very focused on improving the standard and bringing it up to date with the new technologies. As mentioned before, it continuously talks about multisig, whereas you know, with Fireblocks they're using MPC. Which you can argue is a far better technology to implement to meet the intent of a requirement that states there must be more than one signer of a transaction. MPC seems to provide as an opinion a more robust secure way of doing this. The other thing with CCSS is that the auditors program allows for the auditor some degree of interpretation.

So the and, and this is how we applied MPC to the CCSS standard, where it was just talking about multi sig, is that the standard allows for this scope of interpretation for the auditors as well. The other thing too is when the audit report is completed, it goes to a peer reviewer who is completely external.

From the auditor who, who undertook the the audit and they also review some of the evidence, or not the evidence, but the audit report itself to make sure that the auditor has considered all evidence gathering techniques and considered you know, the concepts and the intent of the requirement and, and how the entity has applied information security controls that meet the intent of the requirement.

So again, yes, I, I believe CCSS is robust enough to, for, to be considered as one of the information security standards for central Bank digital currencies because the focus heavily on key management and wallet management.

David Ding:

Okay. So my next question is about alignment versus certification. The risk profile of a bootstrapped Web3 venture in the space is a lot different to someone who's, you know, got a self-reliant company and employing staff, much more to lose.

So how do you see the, where do you see the entry point into alignment and, and what tools or handrails are there for a bootstrapped Web3 organisation to begin aligning as early as possible? And is that something you can help with?

Marc Krisjanous:

Oh, a absolutely. And if we take ISO 27001, for example, there is numerous websites that offer free information and guidance on actually how to start applying an information security standard such as ISO 27001.

Numerous, numerous articles online on, on actually how to start it. Because when you look at the standard itself, it, it can be quite daunting in, in regards to what it's, how it's communicating. Some of the, the terminology that it uses can be confusing and because the information security standard itself has to encompass or allow for any type of organisation from a one person organisation through to a, a multinational, multi-billion dollar organisation.

So the, the, the security standards are reasonably high level and vague, but you just gotta try and understand the terminology and yes, so there is lots of free guides on, on how to do that, how to start. I'm, I'm happy to you know, provide any kind of commentary on that if, if you contact me, but it can be as simple as just applying things such as understanding your business.

Providing an asset inventory. So what are the systems that I control? What, what are the things or the components that are my responsibility? Getting a list of that down, that's an asset inventory in a way. And looking at the risk profile for each of those components. For example, if I'm using an HSM, for example, to store my keys, well, what, what are the, what are the risks to, to me, if that HSM you know, is compromised?

Who would want to attack me? So I've got state actors, I've got criminal organisations. I've got you know, script kiddies. We've got also more more dedicated teams. We've got insider threats. So I would identify all the possible threat actors, people who want to do me harm, and then I would look for ways on how they could actually attack the HSM.

And then once I learn for each threat vector, what their attack vectors would be most common, I would then look at security controls to see how I could protect against that threat or that attack vector. For example, ISO 27001, there's actually a a separate paper called ISO 27002 that actually provides a list the list of the information security controls and what information security control for, you know, what each one actually is designed to protect against.

So you can apply even the most basic ways of applying information security. Another top way is if you search online, and I think it's CertNZ that provides maybe like a top 10 or a top 15. These are the information security controls that you should apply off the bat. You know, they, they deal with things like putting on AV on your desktop.

They, they deal with things such as training against phishing attacks patching, vulnerability management. So you don't even initially straight off the bat, you don't even actually have to look at an information security standard to dip your toes into this area. You can just look at the the sites that recommend the top you know, the top 10 or the top eight information security controls.

A, a classic one is CIS top 18. If you look that up online or, or contact me and I'll send you a link. It actually has the top 18 information security controls you should apply as a business.

David Ding:

Okay. That's super useful. Okay. So we've had a comment on the in the chat. Looks like it could be a bit of a plug, so I'm not going to plug it.

But what I would say to who's put this comment in is that they're saying they that they have a company that offers consulting services to organisations who want to align with or gain ISO 27001 certification. Happy to chat there and need some guidance. I'd say to whoever posted that message this recording is going to be posted in the Web3 NZ forum, so maybe dive in underneath there because you know, I can't really promote anyone without vetting them first. So that'd be my recommendation. So that's all the questions in the chat. Is there any more? Okay. We'll leave it there.

Thanks so much, Marc. Really appreciate that. I certainly got a lot out of that and hopefully you guys did too. Thanks Will for the questions. Hope that was useful and this recording will be saved in the web Web3 NZ forum if you wanna check it out later. So thanks again everyone.