Security issue intake process

Introduction

The current process and intake around external reporting of security issues is lacking and problematic. The goal here is to remove friction around the current security intake (tor-security@ schleuder list), adjust who is responsible, and have a simple, documented, life-cycle process. These are outlined below under "Resolving Intake Pain" and "Resolving Process".

I'm putting this out here to get feedback from @ahf, @meskio, @gk, @richard, @dgoulet, @gaba, @mikeperry, @anarcat as Team Leads, service level admins of Schleuder, or otherwise affected. Timeline for resolving this will be in +1month.

Security intake process

This page describes the process for handling security issues when they are reported via the security@torproject.org alias. It describes who is responsible what they are responsible for and the process that will be followed from initial submission to resolution.

Security point people

Each team lead identifies a security point person from their team to be the responsible party for their team. This can be the team lead, or someone else in the team. This person is responsible for timely intake of issues related to the team. Although security issues reported this way are infrequent, ignoring these can be disastrous. This person is simply ensuring that the process is activated for the team, and not solely responsible for triage, evaluation and resolution of these issues.

OpenPGP role key

A Tor Security "role" OpenPGP key is generated for the uid security@torproject.org and its fingerprint is published on the Tor Project's help pages detailing how to report a security issues. It is up to the reporter to encrypt the mail to the alias with this key, encryption is encouraged, but not required.

The OpenPGP secret key material for the security@torproject.org UID is distributed to the security point people, so they can decrypt any encrypted mail.

If an individual who is a security point person is no longer working with Tor, or needs to otherwise rotate out of this role, then they are to be replaced with a new person from that team and the key material is rotated and redistributed.

Intake process

When a security issue arrives to security@, the team security point person should create a confidential issue in the appropriate gitlab project, with the Security label. If this person is on vacation, then another point-person could optionally step in and route the issue to the correct team.

Teams should then begin an evaluation process to determine its relative severity and priority.

As necessary, convene a meeting of subject matter stake-holders to triage, or integrate this process into regular team meetings (respecting confidentiality). Team leads should make sure this process goes smoothly, and route help as needed.

The issue must be assigned to someone, it should also have its severity/priority set and an expiration date for when the issue should be resolved. An issue without an assignee can be easily lost.

Because security issues need to be properly addressed in a timely manner they should be continuously evaluated in scoping sessions so they are not dropped.

Possible methods

The current method of submitting security issues externally to Tor is sub-optimal. We have a few options here, none of the options are ideal, here are the different options to decide between:

Continue with Schleuder: just update the existing subscribers. This means that each point person will need to become familiar with Schleuder, and we'll need to beg the list admins to adjust the subscribers each time. This will not solve the encrypted spam problem, which will continue to obscure existing issues. As far as I can tell, this option is not desirable by anyone.

Use Hackerone exclusively: Downsides: not everything we might want as security qualifies as bounties, uncertain verification level required for accounts (eg. is a bank account link required to report?). People who may report issues may decide not to if the bounty dynamics do not fit. Trusting a third party with our vulnerabilities comes with risk, there has been issues with H1 employees attempting to take vulnerabilities and sell them.

Unencrypted list/alias: Replace Schleuder with a simple list/alias. This would remove most friction points, at the cost of security, due to email. One path could be to come up with minimal email security requirements for security point people, however this is tricky. Additionally, public may be nonplussed that Tor does not provide an encrypted way to report issues.

Security role OpenPGP key: We create a Tor Security "role" OpenPGP key, and distribute the secret key material to security point people. The documentation for reporting security issues would contain an alias for reporting along with where to obtain the Tor Security "role" public key, and it is up to the reporter to encrypt the mail to the list with that key. This would eliminate Schleuder from the process, yet keep encryption possible for issues. Downsides are dealing with the OpenPGP secret keys, and ensuring that on-boarding/off-boarding rotates this key. Additionally, it is possible for people to submit issues without encryption, which seems acceptable.

Other: Research some other incident management tool (eg. the Zammad instance used for Community outreach for Telegram/Signal support . This would suffer the same 3rd party data problems, or would require that TPA take on new service hosting requirements. It would also need to integrate with our Gitlab process and not be some corporate bloatware that we have to pay for.

Additional considerations

Further improvements can be made to this process, but for now we will address this first and address additional pain points later.

Gitlab confidential issues generate clear-text emails, gitlab upstream does not intend to fix this. A further refinement, at a later date, could be to filter these emails so they do not get delivered.

It has been noted that Anon-ticket could be patched to make it confidential, however this software has had confidentiality issues in the past, and is not properly maintained at the moment, so relying on it for critical security issues would require these characteristics were changed.

Possibly incorporate TROVE organizationally, a session in Ireland will cover this.