edit intro

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

@@ -4,34 +4,36 @@ title: Safe{Wallet}/Bybit incident report and mitigating controls
 date: 2025-03-20
 ---
 
-The Safe{Wallet}/Bybit incident is an example of a nation state actor using a series of sophisticated attacks to compromise high value targets. When the value at stake is such that it justifies spending funds on buying 0-day vulnerabilities, in some cases, multiple 0-day vulnerabilities, and combining them into elaborate exploit chains, attacking multiple different layers of the tech stack, highly targetted social engineering, compromise of individuals, planting of moles or even phsyical attacks, the threat model which needs to be assumed to adequately address risks needs to be extreme. This type of attacker requires that the defender assumes a more rigorous set of assumptions around the capabilities of the attacker, and in turn takes the time to implement additional controls, which most companies don't have to.
+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.
 
 ### Threat Model Assumptions
 
-The assumptions we make about nation state actors at Distrust:
+At Distrust, we operate under the assumption that nation-state actors are persistent, highly resourced, and capable of compromising nearly any layer of the system. Accordingly, our threat model assumes:
 
 * All screens are visible to the adversary
-* All keyboards are logging to the adversary
-* Any firmware/boot-loaders not verified on every boot are compromised
+* All keyboard input is being logged by the adversary
+* Any firmware or bootloader not verified on every boot is considered compromised
 * Any host OS with network access is compromised
-* Any guest OS used for any purpose other than production access is compromised
-* At least one member of the Production Team is always compromised
+* Any guest OS used for non-production purposes is compromised
+* At least one member of the Production Team is compromised
 * At least one maintainer of third party code used in the system is compromised
-* At least one member of third party system used is compromised
+* At least one member of third party system used in production is compromised
 * Physical attacks are viable and likely
 * Side-channel attacks are viable and likely
 
-The suggested mitigating controls which follow in this report consist of design strategies and tooling which we developed to address exactly this type of threat model. The good news is the reference designs and concepts are available to you today, but some of the tooling needs more work - so if you care about these issues and want to help us complete the work on the missing pieces, please [talk to us](https://distrust.co/contact.html).
+These assumptions drive the design strategies and tooling outlined in this report. The controls we've developed are built specifically to address this elevated thread model. Many of the tools are ready to use today, some are reference designs, while other tooling requires further development. If you care about these issues and want to help us push this work forward, [talk to us](https://distrust.co/contact.html).
 
 ### Summary
 
-This report highlight the major single points of failure, which rely on a single individual and/or computer, thus creating an opportunity for compromise. Blockchains benefit from security of the network via strong cryptography and decentralization. More "traditional" parts of the infrastructure historically have not had the ability to distribute trust, but there are tactics that can be leveraged to achieve distribution of trust which helps us reduce risk from a single individual or computer undermining the integrity of a system.
+This report highlights the major single points of failure, which rely on a single individual and/or computer, thus creating an opportunity for compromise. Blockchains benefit from security of the network via strong cryptography and decentralization. More "traditional" parts of the infrastructure historically have not had the ability to distribute trust, but there are tactics that can be leveraged to achieve distribution of trust which help reduce risk from a single individual or computer undermining the integrity of a system.
 
 ---
 
 ## Root Cause Analysis and Mitigating Controls
 
-In our opinion the main reasons this hack occured are these two points found in the [Sygnia report](https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/)
+In our opinion, the main reasons this hack occured are these two points found in the [Sygnia report](https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/):
 
 * > ... a developer’s Mac OS workstation was compromised, likely through social engineering.
 
@@ -39,7 +41,7 @@ In our opinion the main reasons this hack occured are these two points found in
 
 ## Introduction
 
-The compromise occured due to several key factors which have been nicely summarized in other reports, so this report will focus primarily on expounding on how this incident could have been prevented. It is important to address the naive mitigating controls while helpful, are not enough to mitigate the risk adequately. The naive security controls which we often observe as recommendations are improving safeguarding measure of the access tokens, access controls to cloud resources, such as the storage used for the JavaScript which is used to serve the web-application front-end, as well as monitoring (the quintessential reactive control, rather than a preventative one, and we strongly believe it's always better to prevent wherever possible). While these are improvements which are important, they are more of a "plugging holes on a sinking ship" exercise, rather than upgrading the hull to titanium. Even if improved controls are introduced around the token and cloud platform management, there are still many different single points of failure in the system.
+The compromise occured due to several key factors which have been summarized in other reports. This report will focus primarily on expounding on how this incident could have been prevented. It is important to address that the naive mitigating controls, while helpful, are not enough to mitigate the risk adequately. The naive security controls which we often observe as recommendations are improving safeguarding measure of the access tokens, access controls to cloud resources, such as the storage used for the JavaScript which is used to serve the web-application front-end, as well as monitoring (the quintessential reactive control, rather than a preventative one, and we strongly believe it's always better to prevent wherever possible). While these are improvements which are important, they are more of a "plugging holes on a sinking ship" exercise, rather than upgrading the hull to titanium. Even if improved controls are introduced around the token and cloud platform management, there are still many different single points of failure in the system.
 
 To quickly dive into the first principles we can apply here to reason about how risk shifts around let's take the example of how the deployment pipeline is secured. Most companies have a system admin, or developer who has individual ability to modify the server (or software it runs) that's part of the build pipline used to build or serve the application, or can even modify the application code itself. This is considered to be a single point of failure in the Distrust threat model. The risk is difficult to migitgate, because even if the effort is taken to set up a hardened deployment pipeline to try to address the risk we elucidate here, it is simply shifted elsewhere. Assuming that the whole infrastructure is methodically hardened throughout the whole software development lifecycle, in the end there is always 1 super admin who has access to the cloud platform - which gives the individual complete control over the infrastructure. This is a problem most cloud platforms simply ignore as the industry has gotten used to accepting this risk. It is worth nothing that this is not about "not trusting" one's team, it's about distributing trust (Dis-trust, get it?). The question then is "does it make sense for a single individual to undermine the integrity of the whole system"? Those involved in the blockchain space would likely agree it does not.