While the security industry may disagree about most topics, there is no shortage of security control frameworks. NIST 800-53r5, NIST CSF, SOC, HIPAA, PCI, ISO 2700, and SASB. While those standards address everything from technical implementations to job descriptions, more niche frameworks have emerged. These include MITRE’s ATT&CK and Google’s SLSA, which provides software supply chain security guidance. None, however, address the needs of Web3.
InfiniteSn4ke | Forkbomb | Helianthus
For international corporations, many of these frameworks may be applicable. In the United States, NIST frameworks are the most popular, but ISO has more recognition internationally. While these frameworks aim to help organizations secure their information and establish trust with their customers and partners, the approaches of these frameworks can vary so much that little to no overlap exists for seemingly the same pursuit - security.
Why Current Frameworks are Insufficient
If you’re an international corporation, you likely have security teams spread across the globe with expertise in regional security frameworks. These teams work together to create a cohesive security strategy to report security compliance to customers, shareholders, and regulators. In addition to internal teams, the corporation engages third-party auditors and assessors to validate its security strategy and execution.
What if you’re not an international corporation with thousands of employees but a Web3 project bootstrapping NFT collections and grants to achieve your mission of decentralization? Do you need to know all of these frameworks? Is there one to rule them all?
Not surprisingly, most of these security frameworks have a similar target audience - large, publicly-traded corporations. These frameworks’ complexity mirrors the complexity of the organizations they serve. While it’s easy to burn it all down and start from scratch in Web3, Web 3 founders and developers can learn much from these frameworks. Compliance for audits may be irrelevant to a loosely-regulated decentralized application, but the battle-tested best practices often recommended by security frameworks are still relevant.
The 3 Keys to An Effective Security Framework
Before we create a Web3 Security Controls framework, let’s dive into the shortcomings of the current frameworks. In the “3” spirit, there are three key concepts to discuss: applicability, ambiguity, and measurability.
Applicability
Frameworks list NIST target the largest of organizations. NIST 800-53r5 has over 1000 controls spread across 20 control “families”. These families range from fundamentals like “access control” to ambiguous and complex families like “system and services acquisition”. Not all of these controls apply to their mission for even the most complex organizations. Yet, security experts have to analyze each control, determine its applicability, and justify whether or not it applies to the organization’s mission.
Other frameworks like HIPAA approach security specifically from the perspective of individual information protected by health regulations. While this information has a unique use case, this data is stored and accessed through the same technology infrastructure software engineers use to develop solutions. In some cases, the healthcare information might be part of the product being developed. Therefore, HIPAA controls might apply to the same systems which ordinarily, you might choose to comply with NIST 800-53r5 controls. But wait, it gets even more complicated. If your organization does business with governments in the United States, you might be bound by FedRAMP or FISMA, which requires compliance with NIST 800-53r5. And wait, if you also accept payments through credit cards, PCI compliance is also required.
Compliance requirements can quickly spiral out of control for large organizations. Even worse, these frameworks are written by different groups for different use-cases and different views on how to secure information. In short, these control sets often cause conflicted guidance for the same technology choices. In these cases of conflicted control overlap, what do you do? To be blunt: there is no correct answer to this question. Most organizations choose which controls they believe are most applicable and justify their reasoning. 3rd party auditors and assessors might disagree. Entire teams of people dedicate the bulk of their time to making these choices and writing justifications that are shockingly similar to how the legal process works.
Ambiguity
Complying with multiple frameworks is a horribly inefficient process requiring security compromises to satisfy different perspectives of different framework authors. None of these frameworks directly apply to Web 3, but that might not stop someone from trying to impose compliance upon a Web3 project. Are there controls describing wallet security and how to prevent rug pulls?
Subject matter experts didn’t write frameworks with over 1000 controls quickly. NIST 800-53r5 (the 5th revision) was in review for multiple years. That’s just IN REVIEW. Web3 radically changes daily, making it tempting to define broad security controls that require subjective interpretation. However, to be helpful as a tool to improve Web 3 security, a Web3 Security Controls Framework must be directly applicable to Web3 projects and reflect the current needs of investors, builders, and users.
Whether you’re an NFT project, an L1, an L2, or even an L0, a standard set of core security controls provides a starting point for approaching security. Despite the wide range of projects, many security threats share common vectors aimed at the individual members of a project.
Because most control sets are aware of the broad range of applicable projects, the controls are written to accommodate many solutions. Depending on the project's scope, a 3rd party auditor might interpret the security solutions as inefficient to satisfy the control. This binary, yes or no, approach to compliance leads to a highly inefficient process that creates uncertainty for the project on how to approach security and tension from the auditor in how to make their judgment as fair as possible compared to other projects.
Measurability
Controls must provide mechanisms for measuring the security posture of a project to provide practical guidance. Much like the “Grand Unified Theory” in physics, a quantitative and measurable security controls set is the “Holy Grail” of security compliance. Yet, this pursuit might be more realistically a quest for a “white whale”.
Some argue the measurements should be in project USD loss associated with a cyber attack. While this argument has merit, the data behind monetary loss for cyber attacks is unclear and highly disputed - and that’s not even addressing the methodologies of how to arrive at these values.
The ASID framework, our Web 3 Security framework, introduces “attributes” for each control to help standardize compliance measurability. The attributes represent common methods for satisfying the control. In some cases, the attributes are additive, but in other cases, the attributes represent design implementation choices. These attributes could represent both qualities for complex projects. The attributes provide users, partners, and shareholders a method for understanding how the project has chosen to implement security.
The Privacy Tightrope
Many believe blockchain technologies were explicitly created to guarantee user privacy. Over time, others have realized total anonymity results in an ecosystem where criminals can exploit that anonymity to steal and easily launder assets. There are compelling arguments for and against anonymity. In addition, privacy laws and AML (Anti-Money Laundering) laws appear at odds.
Rather than ensuring privacy, blockchain technology can be utilized to support a system of radical-non privacy. Assuming that any information written to a blockchain is immutable, accessible, and distributed enables solutions architects to create applications that take this into account.
Nuance is the key to balancing the privacy tightrope. Arguing for total transparency seems an obvious solution to the problem of money laundering, but what happens in the case of dissenting opinions or whistleblowers? Many oppressive regimes use the control of information to exploit the power and suppress democratic discourse.
There is no single “right” answer on how to approach privacy. The project must choose its philosophy toward protecting anonymity and embracing transparency. Based on a project’s compliance with the privacy controls, users, partners, and shareholders can decide if its privacy values align with their goals.
The ASID Core Controls Families
A wide range of Web 3 project and application types; the core controls families represent security concerns applicable to most projects. The ten core controls families borrow concepts from existing controls frameworks and introduce families specific to the needs of Web3. The ten core controls families are:
- Personnel (P)
- Development Environment (D)
- System Design (S)
- Frontend (F)
- Backend (B)
- Wallets and Treasuries (W)
- Risk Management (R)
- Incident Response (I)
- Notifications (N)
- Privacy (V)
Personnel (P)
Trust is essential when investing, partnering, or using a platform. Such personnel may include developers, project owners, node operators, dependency maintainers and other stakeholders. While Web3 strives to create a boundary layer between PII and Web3 identifiers (DIDs), it is imperative to establish relationships with key organizational personnel that give confidence that a DID matches a unique individual working towards the best interests of all stakeholders.
Development Environment (D)
The first step to securing a Web3 environment is securing the source, development, build, IDEs, and deployment pipeline. Securing the pipeline helps prevent vulnerabilities, including code tampering, dependency poisoning, and other attacks resulting from poor oversight of the early stages of the decentralized SDLC.
System Design (S)
Architecting solutions that are secure and well-planned is key to implementing secure dApps. Secure architecture doesn’t happen by accident: careful planning and consideration go into building secure, reliable solutions, and the work is never done. Risks must be continuously monitored and re-assessed as dependencies are introduced and features are added.
Frontend (F)
The front ends of decentralized applications face similar risks to their counterparts, especially if these Web 3.0 applications utilize Web 2.0 components. Secure development practices for React, Typescript, Swift, Kotlin, and any other utilized front-end languages should be considered, and developers should take care to avoid leaving any hard-coded secrets from testing in the code.
Backend (B)
While the backend architectures of Web3 projects can look very different to past infrastructures, the security principles for protecting these architectures remain largely unchanged. The key word is “resilience” where architectures should provide the ability to maintain maximum service uptime and be able to recover information. Decentralization does not guarantee information or service availability with many blockchains having suffered from total stoppages. Organizations should also consider scalability.
Wallets and Treasuries (W)
Digital asset wallets and treasuries represent a new technical implementation unique to Web3 projects. Not surprisingly, many cyber attacks have already successfully targeted wallets and treasuries resulting in billions of dollars of stolen assets. Securing wallets and treasuries leverages many “old” security techniques involving hardware solutions, airgapping, and physical redundancies. Securing wallets and treasuries is critical as compromises of these digital leads to non-recoverable losses.
Risk Management (R)
The most effective tool for improving a project’s security posture is implementing an effective risk management program. The ability to assess risks and determine the impact of those risk scenarios to the project provides evidence and justification for security tradeoffs and investments. During growth phases, projects must make wise resource allocation decisions. Risk management improves the efficacy of those decisions, but it also provides users, partners, and shareholders insight into the logic behind those decisions.
Incident Response (I)
A project must accept that incidents will occur. In fact, the most successful a project becomes, the more likely an attacker will want to target it. Being prepared for an incident can mean the difference between preventing a non-recoverable event or losing your entire treasury with no recourse. Often a swift and effective response to an attack bolsters user, partner, and shareholder confidence that the project will be able to continue to respond to future attacks effectively.
Notifications (N)
Users, partners, and shareholders depend on communications from the project to build a trusting relationship. Frequent and transparent transmissions provide confidence that the project will quickly notify all affected with concise instructions on what to do next in the case of a cyber-attack. Silence during and after attacks can lead to fear, uncertainty, and doubt that a project will survive or that the project was even legitimate.
Privacy (V)
The balance between transparency and anonymity is a philosophical choice for the project. Based on a project’s compliance with privacy controls, users, partners, and shareholders will have to decide if the project’s privacy philosophy matches their values. A project should be transparent regarding its personnel, goals, and communications but can choose to protect user data. On the other hand, the project might value total transparency to align with their values.
ASID Project Specific Families
- Smart Contracts (SC)
- NFTs (NFT)
- Payments (PAY)
- DAO Governance (DAO)
Smart Contracts (SC)
Most blockchain ecosystems have approached smart contracts with different tech stacks. Different languages, deployment processes, and execution environments make specific smart contract controls tricky. However, smart-contract developers can apply the fundamental security guidance across the various technical implementations inherent in each ecosystem’s smart contracts.
NFTs (NFT)
While some NFT security issues are covered by the smart contracts that deploy them, NFTs have unique ownership and intellectual property rights issues. NFT projects should disclose how rights are assigned to NFTs and how those rights transfer with new NFT custodians. In addition, what mechanics does the project provide in the case of theft or forging of NFTs.
Payments (PAY)
Some blockchain projects focus solely on being a payment mechanism. These projects transact tokens between users, convert between tokens, and possibly even convert the token to fiat currency. Depending on the jurisdiction, converting to fiat currency can require compliance with banking regulations that require collecting PII from users to satisfy KYC requirements. These projects must balance protecting this PII and complying with various jurisdictions' privacy laws.
DAO Governance (DAO)
Corporate rules and regulations exist to prevent manipulation of an organization’s ownership or asset distribution by exploiting the organization’s governance model. These governance models have many layers of oversight and checks and balances to prevent manipulation by large corporations. On the other hand, DAO governance is administered autonomously with smart contracts. If this governance model has flaws, a malicious actor may be able to manipulate a DAO by using its governance model against itself.
Framework Usage and Growth
The framework's design, namely atomic representations of controls and attributes, is deliberate. Creating a concise data model representing control compliance enables projects and auditors to embrace tools that can capture compliance visually, completely, and continuously. Hypothetically, projects could even mint utility NFTs that transparently show their self-assessment of their security posture with auditors. Such a representation of the security assessment would enable incredible transparency in showing the deltas between the project’s review and the auditor’s review.
As Web 3 changes, this framework will also change. A DAO is an ideal structure for managing a controls framework. Standards bodies and industry consortiums are notoriously slow to react to emerging technologies. A DAO can democratize and expedite the decision-making processes so that the framework can respond to Web 3 needs and maintain a fair framework that doesn’t favor any particular project or group of projects.
The Future of ASID
ASID is not just an aspirational framework. The controls have already been written. Today we introduce you to ASID, and coming soon, you’re going to get to meet ASID much more. The full framework, controls, and data structures are right around the corner. Follow us, engage with us, and join us bringing ASID to the world and securing Web3 for everyone!