The Rekt Test

Introduction

The Rekt Test is a short questionnaire for web3 projects to ensure they operate at a minimum baseline of security performance.

This questionnaire was crafted by a working group of web3 security experts in early 2023 at the Gathering Minds conference. The group included participants like Mitchell Amador from Immunefi, Dan Guido, CEO of Trail of Bits, Nick Shalek of Ribbit Capital, Nathan McCauley of Anchorage Digital, Lee Mount of Euler Labs, Shahar Madar of Fireblocks, and others.

The intent is to raise the bar of security in the web3 industry, as it is still immature and low-quality, despite tremendous amounts of capital flowing through the ecosystem. It is this low quality that has led to billions in unnecessary losses through private key thefts, social engineering, lack of documentation, absence of security roles, ignorance about best practices, and much more.

Poor security practices go far beyond flaws in smart contract code, which is the main focus of much of ongoing security education efforts. However, it’s important not to neglect that private key thefts alone have been extremely devastating.

Simply put, we will fail at onboarding the next billion users into web3 if we do not succeed in improving security standards.

The Rekt Test is an excellent way for projects and organizations to think about and improve security on a high level without getting too in the weeds of specifics that would only be useful to some projects and not others. It’s also an excellent way for users and investors to assess the security posture of projects they use.

As part of this effort, we’re releasing some of the answers we’ve personally come up with to the 12 Rekt Test questions. While the questions themselves are standardized, the answers will be somewhat unique to every organization, so we also recommend reading the Trail of Bits blog post on the Rekt Test.

The Rekt Test Questions

1. Do you have all actors, roles, and privileges documented?
2. Do you keep documentation of all the external services, contracts, and oracles you rely on?
3. Do you have a written and tested incident response plan?
4. Do you document the best ways to attack your system?
5. Do you perform identity verification and background checks on all employees?
6. Do you have a team member with security defined in their role?
7. Do you require hardware security keys for production systems?
8. Does your key management system require multiple humans and physical steps?
9. Do you define key invariants for your system and test them on every commit?
10. Do you use the best automated tools to discover security issues in your code?
11. Do you undergo external audits and maintain a vulnerability disclosure or bug bounty program?
12. Have you considered and mitigated avenues for abusing users of your system?

Implementation

If you want to implement this questionnaire in your project or organization, we recommend setting up a regularly recurring time with important project maintainers to work through each question, one at a time, so you can develop solutions that work for your unique context.

Security often takes a backseat to development, especially the more non-intuitive security requirements, such as dedicated security role selection and documentation, but those requirements can be the difference between the life and death of a project or organization when things go wrong. A regular security meeting where you work on implementing the Rekt Test will return dividends over the long run and in many cases the short run, too.

If you are able to answer “yes” to the majority of these questions in a substantive way, your organization will have objectively met a baseline of security performance. And while it is just a baseline, it will dramatically raise the level of security relative to what is commonly seen in web3.

1. System Documentation and Roles

• Have you documented all actors, their roles, and their privileges?

It’s immensely challenging to protect your system and engage in any kind of incident response if you don’t have any documentation. By answering this question–and crafting documentation–you’ll find lots of low-hanging fruit in terms of misaligned assumptions, gaps, who’s actually responsible for which functions, who is and is not supposed to have access to what, and more. This information is especially important for developing an incident response plan.

• Have you documented all the external services, contracts, and oracles you rely on?

Your system probably has dependencies, and you have to know exactly what they are, what could go wrong, and what would happen to your system if a bug was introduced in an external service. Many exploits have occurred because of reliance on third-party libraries or oracles. Documenting also forces you to understand how these external services work, so you can be assured that you’re using them correctly, such as APIs.

2. Key Management and Access Control

• Does your key management system require multiple humans and physical steps?

Key management is the trickiest thing in crypto, as we’ve seen from many hacks involving private key theft. As the saying goes, “Not your keys, not your coins.” But best practices for proper key management are unclear.

The simple answer is that you want to create multiple steps and include humans as part of the process, so if there is malicious activity or incompetence, there are multiple opportunities to catch what would otherwise be a catastrophic error.

It’s worth it, for example, to require hardware wallets for multisig signers, and it’s also worth it to look at custody systems that require multiple signers.

• Does access to production systems require hardware security keys?

It’s important to institute two-factor authentication (2FA) for your hardware and software systems involved in production. SMS 2FA is better than nothing, Google Authenticator is even better, and a hardware security key like YubiKey is preferable.

For production assets on-chain, your deployment or treasury wallet should be a multsig. Hot wallets are notoriously dangerous. So many things have gone wrong in the history of crypto because of hot wallets, and projects regularly experience big hacks because of private key theft. Additionally, it’s crucial that the private key itself is never exposed to the internet. That means the key should not be on any password managers connected to the internet.

3. Incident Response and Crisis Management

• Do you have a written and tested incident response plan?

You’re only ready for what you’ve drilled for. There is a reason that professional militaries around the world constantly conduct military drills. You might think you know how to use the equipment, but you never know for sure until you actually use it in the field.

Likewise, if you don’t have a written and tested response plan in the event of a crisis, you don’t have a plan. In this industry, you will experience many crises. For that reason, you need to document your plan and store it in the right place so that everyone who needs to know about it and access it can do so readily. Your plan must contain who the specific parties are in every crisis, what their roles are, how decisions get made, how documentation happens during a crisis to keep track of all the moving parts, and importantly, how to contact all relevant parties and have them available to execute the incident response plan at a moment’s notice.

We’ve seen many cases of crisis situations that have spiraled out of control for hours because key parties who control assets or access to important information were asleep and could not be contacted because they had “do not disturb” settings on. In other cases, team members did not have reliable contact information for other parties at all.

In still other cases, we’ve seen war rooms drag on for hours because it’s unclear who is running operations and coordinating everyone involved in incident response.

We’ve written a guide available here on what to do after you’ve been hacked, which includes how to run an effective war room.

4. Team and Personnel Security

• Have all employees undergone positive identification and background checks?

There is a strong norm of anonymity and pseudonymity in crypto. This has made the industry both strong and unique, but also presents obvious pitfalls. Would you trust the role of head of security to a person who’s been convicted several times of fraud and other misbehavior? Sometimes positive identification on its own is enough to discourage people from abusing trust to steal funds.

This step can include things such as:

• Reference checks of employees. Did they actually work at a previous company they said they worked at?
• Identity checks. Are they really who they say they are?
• Background checks. Do they have any criminal convictions? It may be useful to hire a company to perform more in-depth background checks on prospective or current employees in crucial roles.
• Does someone on your team have security defined in their role?

Currently, most web3 projects don’t have a specific person who is focused on security because development and marketing tend to be prioritized instead. But if security isn’t prioritized, it won’t exist, and it doesn’t happen by default.

It’s certainly not enough to hand security off to an external auditing firm, and it’s not enough to hand off security to a bug bounty platform, either.

The lowest bar to meet here is making sure at least one person on your team has ‘security’ in the description of their role and has active security duties on a daily basis. It’s even more ideal if security is their primary responsibility.

5. Code Security and Testing

• Have you defined key invariants for your system and do you test them on every commit?

An invariant is a property of your software system that does not or should not change. For example, the invariant on a lending system could be that a user can only withdraw an amount of funds equivalent to the collateral they deposit plus interest. If that is ever not true, then it’s actually a variant, not an invariant, and that event could demonstrate a possible security gap. You need to answer the question: what are the parameters of the system that should be ironclad? You should aggressively test against your invariants at each new iteration of your code.

• Do you use the best automated tools to discover security issues in your code?

Before your code even gets to the auditing or bug bounty program stage, have you made sure to manually review your code? And in particular, have you made sure to use to the best automated tools to discover anything you might have missed in a manual review? Static analyzers and fuzzers are two popular categories of tools that developers can use to review their own code. Static analysis focuses on finding simple errors in the code. Fuzzing on the other hand, is more dynamic, generating random inputs and testing them against the system

6. External Audits and Vulnerability Management

• Have you received an external audit and do you run a vulnerability disclosure program / bug bounty program?

An internal audit is great practice for building your own capabilities, but it’s also important to have an external audit to check your code. Additionally, you should run a vulnerability disclosure program/bug bounty, or host one on a bug bounty platform, so that everyone is incentivized to constantly review your contracts to report bugs in the live code. A bug bounty is a safe and effective way to protect live code.

Over at Immunefi, we’ve used bug bounty programs to help save more than $25 billion dollars in hack damage that could have devastated the web3 ecosystem.

7. Attack Mitigation and User Protection

• Have you documented the best ways to attack your own system?

Have you thought like an attacker in approaching your own code? If you don’t do it, actual attackers will. If you red team your own code and systems, you’ll minimize the chances that actual attackers will find a soft spot in your armor.

But it’s not just the code that’s important to look at from an attacker’s perspective. It’s any part of your system and processes that could be vulnerable to penetration.

• Have you considered and mitigated avenues for abusing users of your system?

Without necessarily being malicious, users will end up interacting with every part of your system–often more than you do. It’s important to walk yourself through as many user actions as you can to make sure that intentional or accidental abuse doesn’t happen on your watch.