... | ... | @@ -2,7 +2,7 @@ |
|
|
|
|
|
* Title: An organization-wide security bug registry?
|
|
|
* Proposed-by: Nick
|
|
|
* Facilitator: Micah
|
|
|
* Facilitator: ~~Micah~~
|
|
|
* Who: Developers, admins, anybody who fixes security issues
|
|
|
* Note taker:
|
|
|
* Duration: 1 hour
|
... | ... | @@ -12,100 +12,65 @@ |
|
|
## 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
|
|
|
|
|
|
- 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
|
|
|
|
|
|
- "exposure" = maybe data leak in a wide sense
|
|
|
|
|
|
- Gitlab confidential tickets are tricky (who is allowed to look at confidential tickets, many roles have access); it's a good enough way for network team right now, though
|
|
|
|
|
|
- sometimes working over two tickets, one public, one private
|
|
|
|
|
|
- dev patches on individual private forks, CI does not work currently so there is none yet, unclear if that is possible with private branches at all
|
|
|
|
|
|
- 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 it could be a good organisation-wide policy
|
|
|
- but we may have 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 or other teams
|
|
|
|
|
|
- GeKo mentions that we have a sec policy for Tor Browser on HackerOne right now
|
|
|
|
|
|
- security level "high" etc. could be dependent on how hard things are to exploit, platform exposure etc.
|
|
|
|
|
|
- some things are *not* security issues, like ignoring security warnings
|
|
|
|
|
|
- some things are _not_ security issues, like ignoring security warnings
|
|
|
- the netteam actually went through historical vulnerabilities to classify them and determine how to answer future issues
|
|
|
|
|
|
- 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:
|
|
|
- how to track upstream sec bugs:
|
|
|
- for core tor it does not make sense to file separate tickets for upstream sec bug
|
|
|
- for tor browser, sometimes tickets are filed for upstream issues, other times just released
|
|
|
- for TPA, some problems are tracked in incidents (special gitlab issues!), most are not and just automatically deployed, those type of problems treated as the wider problem of "incident response"
|
|
|
|
|
|
- severity (and thus release-scheduling) is not affected by exploitation in the wild (maybe it should)
|
|
|
|
|
|
- questions over whether the policy specifies response time frames or specific workflows:
|
|
|
- netteam has a policy of answering incoming requests systematically
|
|
|
- can do coordinated releases with (e.g.) researchers
|
|
|
- 60 days release limit?
|
|
|
|
|
|
- should other teams use the same TROVE database in case they want to use TROVE as well?
|
|
|
|
|
|
- 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
|
|
|
|
|
|
- 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 proper process here, although there is some disclosure process mentioned right now
|
|
|
|
|
|
- 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
|
|
|
|
|
|
- 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
|
|
|
|
|
|
- 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 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)
|
|
|
|
|
|
- many folks have a hard time to self-evaluate the severity of the issues they report
|
|
|
|
|
|
- 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
|
|
|
|
|
|
- nick's priority for those two tools:
|
|
|
- ability to delete spammy users (not reported, will report)
|
|
|
- ability to immediately reject submissions if they haven't modified the template
|
|
|
|
|
|
- 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)
|
|
|
|
|
|
- broader security policy question (https://gitlab.torproject.org/tpo/team/-/issues/41) could be seen as part of a disaster recovery policy (https://gitlab.torproject.org/tpo/core/team/-/issues/17)
|
|
|
|
|
|
- overall summary:
|
|
|
- retire schleuder security list 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 2022)
|
|
|
- getting anon-reporting/lobby tools maintained
|
|
|
- for further ideas, discussions around this problem, see the [security issue intake process ticket](https://gitlab.torproject.org/tpo/team/-/issues/73) as well |
|
|
- for further ideas, discussions around this problem, see the [security issue intake process ticket](https://gitlab.torproject.org/tpo/team/-/issues/73 "Security issue intake process") as well |
|
|
\ No newline at end of file |