Bug Bounty Program Proposal

#1

Rationale:

Given the fact that ThreeFold aims to create an ecosystem that wants to compete with existing enterprise grade hosting providers, its security must be on par or better. Currently, no known research into the security of the platform has been done. Since the platform aims to be decentralized and holds a lot of value in its community, it is important to incentivise security researchers with a bug bounty program to motivate research into security issues and to reveal issues in a controlled manner.

Bug Bounty program process:

  1. Ethical Hacker generates a new private key, and submits a PGP encrypted bug report to the GitHub issue tracker. She keeps the private key to herself.
  2. Ethical Hacker contacts Security Manager (e.g. security@threefold.me) about the bug report submitted to the issue tracker. The Ethical Hacker establishes contact, indicates in clear wording the security issue category and severity of the security issue, and any expectations on the reward bounty. She must also send the signature of the private key used to submit the bug report, but does not reveal the decrypted contents of the bug report yet. In any case, the Security Manager ensures that both parties are aware of the Bug Bounty process and rules.
  3. The Security Manager verifies that the expected bounties comply with the reward categories and severity as indicated, and otherwise communicates this to the Ethical Hacker. For each bounty, the Ethical Hacker is expected to give proof of their newly found security issue. The Security Manager then proposes a test period (what is the time frame over which the proof of concept is demonstrated) and an embargo period (what is the acceptable date after which the private key of the bug report is revealed, i.e. public disclosure) and the Ethical Hacker and Security Manager negotiate on these data until they reach consensus. Finally, the Security Manager gives the Ethical Hacker permission to proceed with executing the Proof of Concept (PoC) on a test network for the duration of the test period.
  4. Only now, the Ethical Hacker performs a PoC on the test network as indicated (there may be multiple test networks active, only the one for which permission is given may be used for demonstration of the issue): the security issue must be demonstrated.
  5. After the test period expires, the Security Manager contacts the Ethical Hacker to request the bug report and discuss the results of the demonstration. The Ethical Hacker now reveals the bug report, and the Security Manager can independently confirm the presence of the security issue (e.g. by inspecting logs of the test network). The Ethical Hacker must ensure (before submitting the bug report!) that the PoC is structured in such a way that the Security Manager can independently verify the presence of the security issue (e.g. to demonstrate root access on a node, write a file in a location that only root can access).
  6. The Security Manager confirms the presence of the security issue, and that the demonstration indeed matches the category and severity of the issue as reported, by contacting the Ethical Hacker within a workweek after the bug report was revealed by the Ethical Hacker.

Rules for the bug bounty:

  1. Only bug reports that contain a PoC will be eligible for a bounty.
  2. PoCs will be executed only on TestNet.
  3. Assume that the DAO is already in place and if a human is involved in the process, that the human will make a mistake.
  4. Threefold employees are excluded from participation.
  5. Full disclosure happens after fixes are pushed to source control.
  6. Bounties paid in TFT will be converted to the USD bounty reward based on the exchange rate on the moment of payment.

Categories:
The payout would have to be set by ThreeFold. I propose that a range is given for the different categories depending on the severity of the bug.

  • Deployments

    Deployment can only be manipulated by the twin that owns the deployment. Creating deployments requires that the amount of TFT can be paid by the creator.

  • Farming

    Farms should be in full control of the nodes they provide on the grid. The nodes that are hosted on the grid by these farms can be trusted to have the capacity available that they claim to have.

  • DoS/DDoS

    Any bugs that allow a single actor to take control of the grid and its capacity fall into this category.

7 Likes
#2

I like it a lot. Thank you. :upside_down_face:

1 Like
#3

This is a fantastic idea, and you are correct that we need people from outside the project to come and really test all aspects of it.

1 Like
#4

Can you think about the amount of the rewards for the bugs? It can also be a range.

#5

Hi @zurga. I think we have to set a number of ranges to cater for a number of levels of severity for bugs. Doing some research (light, and looking at different type of project / organizations) shows that other projects do the following:

polkadot

Layer-1 Blockchain project: They do not specify any amount, but keep it at their discretion to reward found bugs.

G-Core Labs

Cloud and cloud services: They use an impact / vulnerability taxonomy and then have a payout table:

Priority Reward [$]
P1 1,000 - 1,500
P2 400 - 1,000
P3 200 - 400
P4 50 - 200
P5 unrewarded

hackerone - helium bounty program

hackone: HackerOne was started by hackers and security leaders who are driven by a passion to make the internet safer. They run programs for projects and have a platform that manages bug hunting and rewards.

Payouts are based on a severity level:

Low Medium High Critical
$50 $100 $500 $1,000

So in conclusion I think we should aim to have a simple to understand taxonomy of bugs classifications and the range should be from 50 USD to 1000 USD (500 to 10,000 TFT at current TFT value). What do you think?

3 Likes
#6

Sure sounds good! Let’s go bug hunting!

1 Like
#7

I’ll try to get internal alignment on how to formulate this as a GEP proposal and them come back. Happy :bug: hunting!

1 Like