Skip to content

Changes

Page history
Update SecurityIntake authored by micah's avatar micah
Hide whitespace changes
Inline Side-by-side
Process/Engineering/SecurityIntake.md
View page @ 5f220979
# 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](process/engineering/SecurityRoleKey) is generated for the uid `security@torproject.org` and its fingerprint is published on the [Tor Project's help pages](https://support.torproject.org/misc/bug-or-feedback) 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.
# 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](process/engineering/SecurityRoleKey) is generated for the uid `security@torproject.org` and its fingerprint is published on the [Tor Project's help pages](https://support.torproject.org/misc/bug-or-feedback) 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.
Because there is a not-insignificant overhead involved in doing such a rotation, we prefer to not rotate that role often.
# 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.
# Communications
## Team communications
The `security@` alias receives a number of spam messages, bogus reports, legal requests, legitimate support questions, etc. The security liaison is responsible for looking at each message coming in and making a determination if it is for their team or not, and if it is something that needs to be handled by that team. In many cases there are reports that are, on their face, not serious reports. If there is any question, then please reply to the `security@` alias to let people know that it is being handled (ideally with a confidential gitlab issue link). If there is no notification from the team liaison that an issue is being handled, then you will be contacted by the Director of Engineering to ask you if you have seen it.
## Communications with the reporter
If the person reporting the issue has used encryption to send the report, you should use encryption to reply to them. If they have not provided their public key and it is not possible to retrieve it from the keyservers, then you can write to them unencrypted to ask them for it. If you need to reply, please CC the `security@` alias, and please use your `torproject.org` email address to do so.
\ No newline at end of file