Trinity Attack Incident Part 3: Key Learnings & Takeaways

Update: The IOTA Trinity wallet is deprecated with the Chrysalis upgrade and will be replaced by the new Firefly wallet. You can easily transfer your tokens following these instructions.

Summary: Trinity is a software wallet for the IOTA digital asset that has been developed for desktop and mobile operating systems. Managed by the IOTA Foundation, this open-source software project enables the user to manage their tokens over the IOTA network. On February 12, 2020 the Trinity Wallet was attacked via a third-party dependency from Moonpay, which resulted in the theft of around 8.55 Ti in IOTA tokens.  

This blog post is divided into a 3 part series:

1. Part 1 summarizes the series of events that led to the attack and the measures taken by the IOTA Foundation. You can read it here.
2. Part 2 is the seed migration plan put in place to protect users that might have been affected by the attack. You can read it here.
3. Part 3 offers an overview of key learnings, takeaways and measures that the IOTA Foundation will implement to ensure the highest security standards for all of our software development. (This blog)

The IOTA Foundation already integrates many security development lifecycle best practices in its existing projects. Due to the recent events, we have, however, identified improvement areas that will be integrated into the Foundation’s existing model. Many of the practices below are already integrated but will be reviewed in detail and strictly enforced throughout the Foundation.

• We increase the focus on our approach to software security. We will add to our current security processes a new CSO who will oversee all security practices.
• The IF (IOTA Foundation) is increasing its existing engagements with external security auditing firms and will require thorough external audits for major releases of any critical software.
• The IF will require the same standard from any 3rd parties we integrate with.
• The IF will adhere to a model for the overall security architecture of applications and review application security for key security objectives on a regular basis.
• Requirements for new functionality, in both existing and new software, will be [more] strictly assessed through a security requirement framework.
• All application risk levels will be revisited and reviewed on a regular basis. The security framework requirements for applications will be based on their risk level.
• Threat modeling methodology will be put in place for all application security levels to identify and manage architectural design flaws.
• The IF will review its current bill of materials for all existing applications.
• All existing and new projects and their integrations of tracking 3rd party dependencies will have a stricter policy for vulnerability levels of 3rd party dependencies.
• All 3rd party integration PRs require a manual sign-off from the team’s security champion, SecOps, or the CSO.
• The IF also identified the need for better data analytics tools on the Tangle. While we currently have a capability to analyze Tangle behavior and transaction patterns, we are building better tooling on top of our permanodes to allow us to identify and filter patterns in real-time.
• Finally, the IF will strive to make its security posture and audit results more transparent, wherever this is possible and appropriate.

Coming out of this incident, the IOTA Foundation will continue to invest more significant resources in our internal security procedures for all software and involve external security experts where needed. We hope that through our continuous transparency and external validation of our open-source software, that we will continue to increase the trust in our community and ensure that IOTA is successfully adopted as an enterprise-ready distributed ledger.