blog edits

_posts/2025-03-20-bitby-report.md

@@ -6,7 +6,7 @@ date: 2025-04-02
 
 The Safe{Wallet}/Bybit incident is an example of a nation-state actor executing a series of sophisticated, multi-layered attacks on high-value targets. In cases where the potential gain is significant, it may be justified for attackers to invest in multiple 0-day vulnerabilities and chain them into elaborate exploit sequences. These campaigns often span multiple layers of tech stack, involve precision-targeted social engineering, insider compromise, or even physical infiltration.
 
-As such, threat model required to defend against this level of aversary must be extreme. It demands defenders adopt a much more rigorous set of assumptions about attacher capabilities and invest time in implementing controls that typical organizations may not need. When protecting high value assets, the game changes.
+As such, defending against this level of adversary requires a threat model that accounts for their full range of capabilities—and guides the design of equally rigorous mitigations. It demands defenders adopt a much more rigorous set of assumptions about attacker's capabilities and invest time in implementing controls that typical organizations may not need. When protecting high value assets, the game changes.
 
 ### Threat model assumptions
 
@@ -29,7 +29,7 @@ These assumptions drive the design strategies and tooling outlined in this repor
 
 This report identifies critical single points of failure—cases where trust is placed in a single individual or computer—creating opportunities for compromise. In contrast, blockchains offer stronger security properties through cryptography and decentralized trust models.
 
-Traditional infrustructure has historically lacked mechanisms to distribute trust, but this limitation can be addressed. By applying targeted design strategies, it's possible to distribute trust across systems and reduce the risks of a single compromised actor undermining the integrity of the entire system.
+Traditional infrastructure has historically lacked mechanisms to distribute trust, but this limitation can be addressed. By applying targeted design strategies, it's possible to distribute trust across systems and reduce the risks of a single compromised actor undermining the integrity of the entire system.
 
 
 ---
@@ -42,11 +42,11 @@ In our opinion, the primary causes of this incident stem from two key issues ide
 
 * > ... the modification of JavaScript resources directly on the S3 bucket serving the domain app.safe[.]global.
 
-These findings highlight both endpoint compromise and weak controls around cloud infrustructure. The following sections focus on how such risks could be mitigated through architectural decisions and more rigorous threat modeling.
+These findings highlight both endpoint compromise and weak controls around cloud infrastructure. The following sections focus on how such risks could be mitigated through architectural decisions and more rigorous threat modeling.
 
 ## Introduction
 
-The compromise occured due to several key factors, already documented in other reports. This report focuses on how the incident **could have been prevented** through a stronger, first-principles approach to infrustructure design.
+The compromise occurred due to several key factors, already documented in other reports. This report focuses on how the incident **could have been prevented** through a stronger, first-principles approach to infrastructure design.
 
 While many security teams reach for quick wins—like access token rotation, stricter IAM policies, or improved monitoring—these are often reactive measures. They may help, but they're equivalent of "plugging holes on a sinking ship" rather than rebuilding the hull from stronger material.
 
@@ -54,9 +54,9 @@ For example, improving access control to the S3 bucket used to serve JavaScript
 
 > At the core of this breach lies a recurring theme: single points of failure. 
 
-To explore this from first principles, consider the deployment pipeline. In most companies, one individual—an admin or developer—often has the ability to modify critical infrustructure or code. That person becomes a single point of failure.
+To explore this from first principles, consider the deployment pipeline. In most companies, one individual—an admin or developer—often has the ability to modify critical infrastructure or code. That person becomes a single point of failure.
 
-Even if the pipeline is hardened, the risk shifts, not disappears. They's always one super-admin who has full access. Most clould platforms encourage this pattern, and the industry has come to accept it.
+Even if the pipeline is hardened, the risk shifts, not disappears. They's always one super-admin who has full access. Most cloud platforms encourage this pattern, and the industry has come to accept it.
 
 But this isn't about distrusting your team—it's about designing systems where **trust is distributed**. In the blockchain space, this is already accepted practice. So the question becomes:
 
@@ -67,7 +67,7 @@ Those who've worked with decentralized systems would say: absolutely not.
 
 #### Mitigation principles
 
-To adequately defend against the risks outlined in the Distrust threat model, it is critical to distinguish between **cold** and **hot** wallets. The following princpiples are drawn from practical experience building secure systems at BitGo, Unit410, and Turnkey, as well as from diligence work conduced across leading custodial and vaulting solutions.
+To adequately defend against the risks outlined in the Distrust threat model, it is critical to distinguish between **cold** and **hot** wallets. The following principles are drawn from practical experience building secure systems at BitGo, Unit410, and Turnkey, as well as from diligence work conduced across leading custodial and vaulting solutions.
 
 * A **cold cryptographic key management system** is one where all components can be built, operated, and verified offline. If any part of the system requires trusting a networked component, it becomes **hot** system by definition. For example, if a wallet relies on internet-connected components, it should be considered hot wallet—regardless of how it's marketed. While some systems make trade-offs for user experience, these often come at the cost of real security guarantees.
 
@@ -85,7 +85,7 @@ In our view, **when billions of dollars are at stake**, it is worth investing in
 
 State funded actors are highly motivated—and when digital assets are involved, it's game theory at work. The cost of compromising a weak system is often far less than the potential gain.
 
-We've seen this playbook used in previous incidents, including Axie Infinity, and we will see it again. Attackers are increasingly exploiting both human and technical single points of failure—while defenders often uner-invest in securing this surface area. 
+We've seen this playbook used in previous incidents, including Axie Infinity, and we will see it again. Attackers are increasingly exploiting both human and technical single points of failure—while defenders often under-invest in securing this surface area. 
 
 #### Strategy 1 - Run everything locally
 
@@ -119,11 +119,11 @@ This reference design was developed for the Safe{Wallet} team, but it can be app
 
 	* Includes a full set of tools needed to secure offline key operations
 
-	* Distrust also created **[AirgapOS](https://git.distrust.co/public/airgap)**, a custom custom Linux distribution designed specifically for offline secret management.It has been independantly audited and is in production with several major digital asset organizations.
+	* Distrust also created **[AirgapOS](https://git.distrust.co/public/airgap)**, a custom custom Linux distribution designed specifically for offline secret management.It has been independently audited and is in production with several major digital asset organizations.
 
 4. **All sensitive operations are fully verified offline before any cryptographic action is taken**
 
-This deisng drastically reduces exposure to remote attacks and central points of trust, aligning closely with Distrust's first-principles security model.
+This design drastically reduces exposure to remote attacks and central points of trust, aligning closely with Distrust's first-principles security model.
 
 #### Strategy 2 - Use remotely verified service
 
@@ -139,7 +139,7 @@ The core implementation steps include:
 
 	* TLS termination occurs **inside** the enclave
 
-	* The web interface is served **from within" the enclave
+	* The web interface is served **from within** the enclave
 
 	* Nothing outside the enclave is trusted
 
@@ -149,7 +149,7 @@ The core implementation steps include:
 
 3. **One engineer deploys a new enclave** with the updated application code
 
-4. **A second engineer independantly verifies** that the deployed code matches the version in the source repository
+4. **A second engineer independently verifies** that the deployed code matches the version in the source repository
 
 5. **Clients are issued a service worker** on first load that pins attestation keys for all future remote verification
 
@@ -160,7 +160,7 @@ The core implementation steps include:
 
 ## Implementation considerations
 
-Implementing these strategies can be technically demanding. They represent two ends of the trust minimization spectrum: one favoring offline, air-gapped assurance; the other introducing verifiability within connected systems. Both approaches significantly reduce risk but vary in complexibity, tooling and requirements, and rollout timelines.
+Implementing these strategies can be technically demanding. They represent two ends of the trust minimization spectrum: one favoring offline, air-gapped assurance; the other introducing verifiability within connected systems. Both approaches significantly reduce risk but vary in complexity, tooling and requirements, and rollout timelines.
 
 This high-level overview is meant to illustrate the kinds of problems we focus on at Distrust. Depending on the chosen strategy and organizational context, implementation can take anywhere from a few weeks to several years, especially as tooling continues to mature.
 
@@ -168,7 +168,7 @@ This high-level overview is meant to illustrate the kinds of problems we focus o
 
 The Distrust team has helped build and secure some of the highest-risk systems in the world. This includes vaulting infrastructure at BitGo, Unit410, and Turnkey, as well as security work with  electrical frid operators, industrial control systems, and other mission-critical environments. 
 
-We've conducted deep security due diligence across most major custodians. Through our experience with organizations that operate under constant threat—where **every class of attack is viable**—we've developed a methadology and set of open-source tools designed to defend against even the most sophisticated adversaries.
+We've conducted deep security due diligence across most major custodians. Through our experience with organizations that operate under constant threat—where **every class of attack is viable**—we've developed a methodology and set of open-source tools designed to defend against even the most sophisticated adversaries.
 
 Today, we're taking the hard-earned lessons from that work and sharing them with the broader community. Our goal is to help others strengthen their security posture by making what we've learned—and the tools we've built—available to everyone.