FTX Would Have Failed A CCSS Audit
Marc Krisjanous is one of the first CCSS Auditors, assisted C4 in developing their auditors program and is a member of the CCSS Steering Committee.
**** Free CCSS Implementation Guide! ****
Marc also co-authored the CCSS Implementation Guide for a Full System - click here to download - it's free!
I should state that FTX ("FTX.com", "FTX.US" and "FTX exchanges") would have failed even the most base-line information security standards had they even bothered to look at one. Which, I highly doubt this since they never had a full-time CISO, or anyone qualified keeping an eye on information security for that matter, as reported in the FTX Debtors report.
This post continues from where I left my last post (1) on John J. Ray III’s first interim report on FTX failures (2). In that post, I highlighted the top 12 major information security failures that the FTX Debtors report identified.
Information security failures so bad, so very very bad, that if this information got out while FTX was still operating, it would have caused a bank run, in my opinion.
In this article I will show how the CryptoCurrency Security Standard (CCSS), if applied to FTX, would have highlighted all of the information security failures (and more) documented. FTX would have failed the CCSS audit on numerous CCSS requirements. In fact, I would take a punt, based on what I have read in the media, that FTX would have failed every requirement in CCSS.
For the remainder of this article, I will match each identified information security failure in the FTX Debtors report with the applicable CCSS requirement(s). I have added two more major information security failings to this article that I located from the FTX Debtors report after a second read.
This provides the reader with a clear understanding that CCSS is an information security standard that all crypto platforms, including exchanges, must be certified against.
CCSS certification requires a third-party auditor to conduct a rigorous audit of the people, process, and technology components of the systems which provide cryptocurrency functions.
How else will the crypto community and the general public be able to trust a crypto exchange that they have not got the private keys of their wallets stored in plain text on numerous servers with hardly any access controls?
FTX - 12 Major Information Security Failings
1. Not using cold wallets to store bulk of funds - most of the funds remained in hot wallets
The CCSS 2.01 Security Tests/ Audits Aspect ensures independent verification of information security controls applied to the information system.
2. Private keys to wallets containing 100's millions of dollars stored in plain text on multiple cloud-based servers accessible via other servers and in multiple locations
CCSS 1.03 Key Storage -1.03.1.1 Cryptographic keys and/or seeds must be stored with the use of strong encryption when not in use.
CCSS 1.04 Key Usage - 1.04.2.1 All keys/seeds are only used in trusted environments.
CCSS provides clear and very detailed requirements on the protection of private keys and seeds while at-rest.
3. Access credentials to third-party exchanges stored in plain text
The CCSS 2.01 Security Tests/ Audits Aspect ensures that there is independent verification of information security controls applied to the information system.
While there is no direct requirement in CCSS for protecting user account credentials at rest, this aspect gives the CCSS auditor a clear requirement to ensure that an independent assessment/audit of the information system is being done and remediation is conducted. The assessment/audit would have highlighted this major failing in the report.
4. No backups of private keys
CCSS 1.03 Key Storage - 1.03.2.1 A backup of the cryptographic key/seed must exist. The backup can take any form (e.g., paper, digital).
CCSS 1.03 Key Storage - 1.03.2.2 A backup must exist for at least as many keys as are required to spend funds.
CCSS 1.03 Key Storage - 1.03.3.1 The backup must be protected against environmental risks such as fire, flood, and other acts of God.
CCSS 1.03 Key Storage - 1.03.3.3 Backups are resistant to electromagnetic pulses that could induce currents in electronics and damage the data stored within.
CCSS 1.03 Key Storage - 1.03.4.1 The backup must be protected by access controls that prevent unauthorized parties from accessing it.
CCSS 1.03 Key Storage - 1.03.5.1 The backup must employ some form of tamper evident mechanism that allows an operator to determine if it has been accessed.
CCSS 1.03 Key Storage - 1.03.5.1 The backup must employ some form of tamper evident mechanism that allows an operator to determine if it has been accessed.
CCSS 1.03 Key Storage - 1.03.6.1 Backups of cryptographic keys and/or seeds must be stored with the use of strong encryption when not in use that is at least equal to the security prescribed for cryptographic keys/seeds above.
As you can see above, a multitude of CCSS requirements addressing the backup of keys is defined within the CCSS 1.03 Key Storage Aspect.
5. No detail records of private keys and their usage and critically
CCSS 1.05 Key Compromise Policy - 1.05.1.1 An inventory of all keys/seeds exists and the organization has an awareness of which keys are critical to the successful operation of the information system.
As part of my CCSS audit process, a readiness assessment is first conducted with the assessed entity. One of the first pieces of information I ask the assessed entity to provide is a detailed key inventory. If the assessed entity cannot provide a key inventory listing every signing key under their control and detailed information pertaining to each key's function, then the assessed entity is not ready for a CCSS audit. Read "Are You Ready for a CCSS Audit?" (3) if you are preparing for a CCSS audit.
6. No monitoring controls of private keys being accessed - therefore employees could copy keys without anyone knowing
CCSS 1.06 Keyholder Grant/Revoke Policies & Procedures - 1.06.1.1 An awareness of how roles should be managed when onboarding or offboarding staff from keyholder positions exists within the organization. A staff member who is knowledgeable about the system is able to ensure that permissions are granted/revoked to/from the affected staff appropriately.
CCSS 1.06 Keyholder Grant/Revoke Policies & Procedures - 1.06.1.2 The organization maintains checklists that cover all tasks that must be completed when staff vacate or transition into keyholder roles within the organization. These checklists have been reviewed by knowledgeable personnel to ensure “least privilege principles” are applied to the information system, as well as necessary access where required.
CCSS 1.06 Keyholder Grant/Revoke Policies & Procedures - 1.06.2.1 All keyholder grant/revoke requests are conducted over Approved Communication Channels.
CCSS 1.06 Keyholder Grant/Revoke Policies & Procedures - 1.06.3.1 The organization’s checklists include auditing information that record the identity of the staff member that performs the grant/revoke operations. Each entry within the audit trail is attested to by the staff member who performed that task.
CCSS 2.01 Security Tests/ Audits
CCSS 2.04 Audit Logs
CCSS defines several requirements around access management for keys/seeds including the least privilege principle.
7. Failure to implement the least privileged principle for access to systems (including private keys) - for example over a dozen people had access to FTX.com and FTX.US central omnibus wallets which held billions of dollars in crypto assets
CCSS 1.06 Keyholder Grant/Revoke Policies & Procedures - 1.06.1.1 An awareness of how roles should be managed when onboarding or offboarding staff from keyholder positions exists within the organization. A staff member who is knowledgeable about the system is able to ensure that permissions are granted/revoked to/from the affected staff appropriately.
CCSS 1.06 Keyholder Grant/Revoke Policies & Procedures - 1.06.1.2 The organization maintains checklists that cover all tasks that must be completed when staff vacate or transition into keyholder roles within the organization. These checklists have been reviewed by knowledgeable personnel to ensure “least privilege principles” are applied to the information system, as well as necessary access where required.
CCSS 1.06 Keyholder Grant/Revoke Policies & Procedures - 1.06.3.1 The organization’s checklists include auditing information that record the identity of the staff member that performs the grant/revoke operations. Each entry within the audit trail is attested to by the staff member who performed that task.
CCSS 2.01 Security Tests / Audits
There is even a CCSS requirement - 1.06.1.2 - focused on the least privilege principle.
8. MFA not enforced on staff and third-party accounts to systems
CCSS 1.04 Key Usage - 1.04.1.1 Access to the primary key/seed requires an identifier (e.g. username, email, GUID, etc.) and at least 2 (two) other factors of authentication, which restricts access to the authorized operator.
CCSS 1.04 Key Usage - 1.04.1.2 Access to the key/seed requires an identifier (e.g., username, email, GUID) and at least 3 (three) other factors of authentication.
CCSS addresses MFA via the CCSS 1.04.1.1 and 1.04.1.2 requirements. Notice that requirement 1.04.1.2 requires at least three different authentication factors!
9. No patch management on servers and other critical infrastructure
CCSS 2.01 Security Tests / Audits
Patch management is considered a base-line information security control and not directly addressed by CCSS. However, the CCSS auditor can review independent security/audit assessments to ensure that patch management has been implemented to the required standard in order to address CCSS 2.01 Security Tests / Audits.
10. No vulnerability management
CCSS 2.01 Security Tests/ Audits
Vulnerability management, just like patch management, is considered a base-line information security control and not directly addressed by CCSS. However, the CCSS auditor can review independent security/audit assessments to ensure that vulnerability management has been implemented to the required standard to address CCSS 2.01 Security Tests / Audits.
11. Almost non-existent secure coding techniques applied - hardly any peer review and testing procedures
CCSS 2.01 Security Tests / Audits - 2.01.1.3 A regular security audit at a level similar to SOC2, ISAE3402, or ISO-27001, that includes vulnerability, penetration testing, and code audit (if applicable) has been completed by an independent qualified third-party. Documentation shows that all concerns raised by the audit have been evaluated for risk, addressed by the organization, and known vulnerabilities have been removed from the system. Ongoing audits are scheduled on a (minimum) yearly basis.
The CCSS requirement 2.0.1.1.3 specifically calls out code reviews/audits for CCSS Level 3. However, the overall CCSS 2.01 Security Tests / Audits Aspect will allow the CCSS auditor to ensure secure coding techniques are applied.
12. No architecture documentation or any procedures that explained the architecture or operation of its computing environment or storage of crypto assets
While CCSS does not directly address the presence of architecture and design documentation for the information system, the CCSS auditor must use these documents/diagrams to define the CCSS audit boundary / scope. Therefore, if there are no component or network diagrams then the CCSS auditor cannot define an accurate audit boundary or audit scope.
The CCSS 2.01 Security Tests / Audits Aspect will allow the CCSS auditor to ensure network and component diagrams exist and architecture documents for the information system.
13. No dedicated roles in information security including no CISO, and only one full time staff in IT
CCSS 2.01 Security Tests/ Audits
As with other findings on information security documented in the FTX Debtors report, the CCSS 2.01 Security Tests / Audits allows the CCSS auditor to review independant security assessments and audits to ensure baseline information security controls have been implemented. In this case, ensuring a senior executive is responsible for information security and the person is also qualified to fill this role.
14. No incident response management
CCSS 1.05 Key Compromise Policy -1.05.1.3 A Key Compromise Protocol is documented which details: each specific classification of key used throughout the system; a detailed plan of dealing with its compromise that includes the use of Approved Communication Channels during execution; identities of actors via roles (not names), and includes secondary actors in the event any primary actor is unavailable to carry out the KCP.
CCSS 1.05 Key Compromise Policy - 1.05.1.2 While no formal KCP documents may exist, there is a staff member who is able to direct operators in the procedures necessary to regenerate cryptographic keys, regenerate cryptocurrency wallets, and send funds to these newly-generated wallets in the event any operator or keys become compromised.
CCSS 1.05 Key Compromise Policy - 1.05.2.1 The Key Compromise Protocol is tested periodically to confirm the viability of the procedures and to ensure staff remain trained to use them in the case of a compromise. Logs of executed tests exist which outline any/all comments of the test. Improvements identified during the tests are written back into the protocol to ensure the most effective and efficient protocol is always maintained. As changes are made to the information system, the Key Compromise Protocol is revisited to assure it is updated with any new class of key.
The entire CCSS 1.05 Key Compromise Policy Aspect addresses incident response for keys and seeds.
Summary
In summary, this article provides the reader with a clear mapping of CCSS requirements to the information security failings of FTX, as documented within the FTX Debtors report.
The crypto community and general public need assurance from their crypto platforms, including crypto exchanges, that they take information security seriously. This assurance can only be achieved by conducting a rigorous CCSS audit by an independent third-party auditor.
Links
1. https://www.dhirubhai.net/posts/marckrisjanous_ftx-homepage-activity-7052133510853115904-phzp
2. https://www.courtlistener.com/docket/65748821/1242/1/ftx-trading-ltd/
3. https://www.dhirubhai.net/pulse/you-ready-ccss-audit-marc-krisjanous/