... | ... | @@ -11,83 +11,84 @@ |
|
|
|
|
|
## Notes taking during the session
|
|
|
|
|
|
question several years ago: what is the process for rating a bug? The team set down to create a policy to not need to do that ad hoc
|
|
|
- question several years ago: what is the process for rating a bug? The team set down to create a policy to not need to do that ad hoc
|
|
|
|
|
|
categorize bug by severity (low means public work, medium means private work, high is private work and released asap; high vs. critical (difference is in case of the latter there is a shout-out to people and urging them to upgrade/update)
|
|
|
- categorize bug by severity (low means public work, medium means private work, high is private work and released asap; high vs. critical (difference is in case of the latter there is a shout-out to people and urging them to upgrade/update)
|
|
|
|
|
|
TROVE (Tor Registry Of Vulnerabilities and Exposures) is used; private ticket with work and public ticket just as a placeholder with minimal info
|
|
|
- TROVE (Tor Registry Of Vulnerabilities and Exposures) is used; private ticket with work and public ticket just as a placeholder with minimal info
|
|
|
|
|
|
"exposure" = maybe data leak in a wide sense
|
|
|
- "exposure" = maybe data leak in a wide sense
|
|
|
|
|
|
gitlab confidential tickets are tricky (who is allowed to look at confidential tickets); it's a good enough way for network team right now, though
|
|
|
- Gitlab confidential tickets are tricky (who is allowed to look at confidential tickets); it's a good enough way for network team right now, though
|
|
|
|
|
|
dev patches on individual private forks, CI does not work currently so there is none yet
|
|
|
- dev patches on individual private forks, CI does not work currently so there is none yet
|
|
|
|
|
|
security policy/TROVE system works well as
|
|
|
- no discussion of how severe a bug is while dealing with the incident
|
|
|
- no need to reinvent the process while dealing with the issue
|
|
|
- we don't lose security issues
|
|
|
- security policy/TROVE system works well as
|
|
|
- no discussion of how severe a bug is while dealing with the incident
|
|
|
- no need to reinvent the process while dealing with the issue
|
|
|
- we don't lose security issues
|
|
|
|
|
|
nick's suggestions for other potential teams/the org:
|
|
|
- look over netteam security policy and think about what you like to change
|
|
|
- maybe we get to a single inter-team policy
|
|
|
- maybe different definitions for what security levels are (e.g. the netteam security policy has nothing to say about browser fingerprinting which Tor Browser might want)
|
|
|
- types of severity might even not make sense for browser
|
|
|
- look over netteam security policy and think about what you like to change
|
|
|
- maybe we get to a single inter-team policy
|
|
|
- maybe different definitions for what security levels are (e.g. the netteam security policy has nothing to say about browser fingerprinting which Tor Browser might want)
|
|
|
- types of severity might even not make sense for browser
|
|
|
|
|
|
GeKo mentions that we have a sec policy for Tor Browser on HackerOne right now
|
|
|
-GeKo mentions that we have a sec policy for Tor Browser on HackerOne right now
|
|
|
|
|
|
level high etc. could be dependent on how hard things are to exploit, platform exposure etc.
|
|
|
- security level "high" etc. could be dependent on how hard things are to exploit, platform exposure etc.
|
|
|
|
|
|
no embargo for upstream issues (can't get told about secret openssl bug but not to tell the openssl devs)
|
|
|
- no embargo for upstream issues (can't get told about secret openssl bug but not to tell the openssl devs)
|
|
|
|
|
|
how to track upstream sec bugs: for core tor it does not make sense to file separate tickets for upstream sec bugs, maybe for other areas it does
|
|
|
- how to track upstream sec bugs: for core tor it does not make sense to file separate tickets for upstream sec bugs, maybe for other areas it does
|
|
|
|
|
|
severity (and thus release-scheduling) is not affected by exploitation in the wild (maybe it should)
|
|
|
- severity (and thus release-scheduling) is not affected by exploitation in the wild (maybe it should)
|
|
|
|
|
|
Should other teams use the same TROVE database in case they want to use TROVE as well?
|
|
|
- should other teams use the same TROVE database in case they want to use TROVE as well?
|
|
|
|
|
|
Who is the intented consumer of that TROVE list?
|
|
|
- who is the intended consumer of that TROVE list?
|
|
|
- teams should keep a look at that and if a report comes in we need to make sure the issues are correctly tracked
|
|
|
- security bug retrospective if wanted
|
|
|
- transparency for external consumers (how many sec bugs we know about, when did we fix them etc.)
|
|
|
- could be helpful for packagers whether they should backport patches
|
|
|
|
|
|
The wiki is fine for now for tracking purposes but maybe we want to have a real TROVE database at some point
|
|
|
- the wiki is fine for now for tracking purposes but maybe we want to have a real TROVE database at some point
|
|
|
|
|
|
How to deal with bug reporters and interact with them? There is nothing like that in the security policy yet but it might be a good idea to have a propor process here, although there is some disclosure process right now
|
|
|
- how to deal with bug reporters and interact with them: there is nothing like that in the security policy yet but it might be a good idea to have a propor process here, although there is some disclosure process mentioned right now
|
|
|
|
|
|
trying to be non-committal about commitments in the security policy
|
|
|
- trying to be non-committal about commitments in the security policy
|
|
|
|
|
|
no tooling around TROVE/security policy yet, but nick would love to have some if we know as an org what we want
|
|
|
- no tooling around TROVE/security policy yet, but nick would love to have some if we know as an org what we want
|
|
|
|
|
|
maybe next steps could be different teams suggest security policy changes so we can take other teams' ideas into account; having one document instead of different security policy documents per team seems to be a smart idea
|
|
|
- maybe next steps could be different teams suggest security policy changes so we can take other teams' ideas into account; having one document instead of different security policy documents per team seems to be a smart idea
|
|
|
|
|
|
MR workflow would be good in general, maybe sticking everything into a separate repo to make that flow easier might be good
|
|
|
- MR workflow would be good in general, maybe sticking everything into a separate repo to make that flow easier might be good
|
|
|
|
|
|
TPA has incidence response flow; Incidents and confidential Incidents for sec related things are used
|
|
|
- TPA has incidence response flow; Incidents and confidential Incidents for sec related things are used
|
|
|
|
|
|
Maybe teams that don't ship software need something other than the type of security policy used by the network team (e.g. what does a sec bug look like in network-health land)?
|
|
|
- maybe teams that don't ship software need something other than the type of security policy used by the network team (e.g. what does a sec bug look like in network-health land)?
|
|
|
|
|
|
nick explains the pain with the schleuder list bug intake (e.g. mostly encrypted spam)
|
|
|
- nick explains the pain with the schleuder list bug intake (e.g. mostly encrypted spam)
|
|
|
- nick thinks we might want to use gitlab confidential issues more and make that flow nice
|
|
|
- there is a gitlab plugin for schleuder (BUT then we'd get the spam problem in gitlab)
|
|
|
|
|
|
could we require email submitted to schleuder list to be encrypted: no (although technically possible to enforce)
|
|
|
- could we require email submitted to schleuder list to be encrypted: no (although technically possible to enforce)
|
|
|
|
|
|
many folks have a hard time to evaluate the severity of the issues they report
|
|
|
- many folks have a hard time to evaluate the severity of the issues they report
|
|
|
|
|
|
there is sympathy for sunsetting schleuder list
|
|
|
- there is sympathy for sunsetting schleuder list
|
|
|
|
|
|
no way right now to submit anonymously sec issues to gitlab and then being in the conversation (no maintainer for [anonymous sec reporting tool](https://gitlab.torproject.org/tpo/tpa/anon_ticket))
|
|
|
[gitlab account creation tool](https://gitlab.torproject.org/tpo/tpa/gitlab-lobby) and approval process is not really maintained (not run on TPA servers), juga might look at it for maintenance purposes
|
|
|
- no way right now to submit anonymously sec issues to gitlab and then being in the conversation (no maintainer for [anonymous sec reporting tool](https://gitlab.torproject.org/tpo/tpa/anon_ticket))
|
|
|
|
|
|
maybe HackerOne as a solution to sec bug reporting and getting a convo going with the reporter
|
|
|
- [gitlab account creation tool](https://gitlab.torproject.org/tpo/tpa/gitlab-lobby) and approval process is not really maintained (not run on TPA servers), juga might look at it for maintenance purposes
|
|
|
|
|
|
- maybe HackerOne as a solution to sec bug reporting and getting a convo going with the reporter
|
|
|
- problem of external provider selling bug reports
|
|
|
- attracting the wrong folks (some just scanning your website for some supposed sec bugs)
|
|
|
|
|
|
security policy could be seen as part of a disaster recovery policy
|
|
|
- security policy could be seen as part of a disaster recovery policy
|
|
|
|
|
|
summary:
|
|
|
- overall summary:
|
|
|
- decommision schleuder for sec bug reporting
|
|
|
- consensus for looking at TROVE process for other teams/whole project, getting specific gitlab project going for that for tickets to coordinate that discussion (maybe rhatto can help with that) (repository opening first week after the meeting week, having this finalized at least by the end of the year)
|
|
|
- getting anon-reporting/lobby tools maintained |