... | ... | @@ -7,4 +7,93 @@ |
|
|
* Note taker:
|
|
|
* Duration: 1 hour
|
|
|
* Description: The network team uses a set of security policies to decide how to classify and respond to security issues, and a simple registry to keep track of them. This helps with transparency and visibility into our security process. Who else would like to adopt this kind of practice, and how might we want to adapt it?
|
|
|
* Links: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SecurityPolicy https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/TROVE |
|
|
\ No newline at end of file |
|
|
* Links: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SecurityPolicy https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/TROVE
|
|
|
|
|
|
## 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): 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); 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
|
|
|
|
|
|
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:
|
|
|
- look over netteam sec 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. TROVE has nothing to say about browser fingerprinting which Tor Browser might want)
|
|
|
|
|
|
types of severity might not make sense for browser
|
|
|
|
|
|
- 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)
|
|
|
|
|
|
- how to track upstream sec bugs
|
|
|
- for tor it does not make sense to file separate tickets for upstream sec
|
|
|
bugs
|
|
|
|
|
|
- severity (and thus release-scheduling) is not affected by exploitation in the wild (maybe it should)
|
|
|
|
|
|
- GeKo mentions that we have a sec policy for Tor Browser on HackerOne right now
|
|
|
|
|
|
Should other teams use the same TROVE database in case they want to use TROVE as well?
|
|
|
- severe enough bugs get a CVE
|
|
|
- nick recommends against using gitlab labels for that (no "trove" or "security" label)
|
|
|
|
|
|
Who is the intented consumer of that TROVE list?
|
|
|
- teams should keep a look at that and if a report comes in we need to make sure
|
|
|
- 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 but maybe we want to have a real database at some point
|
|
|
|
|
|
How to deal with bug reporters and interact with them? There is nothing like that in TROVE yet but it might be a good idea to have a propor process here, although there is some disclosure process right now
|
|
|
|
|
|
trying to be non-committal about commitments
|
|
|
|
|
|
no tooling around TROVE 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 TROVE changes taking other teams' ideas into account; having one document and different TROVE documents per team seems to be a smart idea
|
|
|
|
|
|
MR workflow would be good in general, maybe sticking everything in to a separate repo to make that one easier might be good
|
|
|
|
|
|
TPA has incidence response flow; sometimes Incidents and confidential Incidents for sec related things
|
|
|
|
|
|
Maybe teams that don't ship software might need something else (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 technical possible to enforce)
|
|
|
|
|
|
many folks have a hard time to evaluate the severity of their own issues they report
|
|
|
|
|
|
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)
|
|
|
gitlab account creation tool and approval process is not really maintained (not run on TPA servers), juga might look at it for maintenance purposes
|
|
|
|
|
|
TODO: add links to anon-ticket and lobby projects
|
|
|
|
|
|
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
|
|
|
|
|
|
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 |