|
|
# [Security Policies](202209MeetingSecurityPolicies)
|
|
|
|
|
|
* Facilitator: rhatto and whoever else wants to join :)
|
|
|
* Who: ideally at least one for each team
|
|
|
* Duration: 1 hour
|
|
|
* Description: a discussion about how teams can build, maintain and evaluate their own security policies. We want to hear suggestions in how security policies can be implemented and what they can contain. Goal is to write some templates and recommendations so each team can use to build their own policies.
|
|
|
|
|
|
Context
|
|
|
|
|
|
- we have no security policies, but some ad-hoc practices, an oral
|
|
|
tradition
|
|
|
- there is also team-based variations (e.g. Network Team has a bug
|
|
|
security policy, TPA has undocumented logging policies, Tor releases
|
|
|
signing policies, etc)
|
|
|
- no answer to the question "how do i configure my laptop?" when
|
|
|
joining
|
|
|
- rhatto found a Nextcloud file from a previous meeting that
|
|
|
enumerated some policies, per team
|
|
|
- got stuck at establishing a common policy
|
|
|
|
|
|
Discussion
|
|
|
|
|
|
- maybe we can't have a unique policy at all
|
|
|
- maybe there can be baseline security requirements for all teams, a
|
|
|
template then per-team policies?
|
|
|
- who is "everyone" anyways? TPI? tor-internal? how about relay
|
|
|
operators?
|
|
|
- practices should be enforceable otherwise they will likely not be
|
|
|
applied
|
|
|
- TPA has tried to approach the security policy from a disaster
|
|
|
recovery perspective (TPA-RFC-18, TPA-RFC-17)
|
|
|
- tradeoff between comfort and security
|
|
|
- requires cultural changes
|
|
|
|
|
|
Resources to protect
|
|
|
|
|
|
- signing keys
|
|
|
- source code integrity
|
|
|
- code reviews?
|
|
|
- email / communications privacy
|
|
|
- data retention (logs, emails, ...)
|
|
|
- employee records, accounting data
|
|
|
- user support requests
|
|
|
- donor records
|
|
|
- builds integrity
|
|
|
- bridges inventory
|
|
|
- high availability
|
|
|
|
|
|
Attack scenarios
|
|
|
|
|
|
- ransomware attack against ops people
|
|
|
- can limit service (e.g. "no paycheck")
|
|
|
- but also leak personal data (e.g. blackmailing under threat of
|
|
|
publishing donor data)
|
|
|
- developer laptop compromise
|
|
|
- phishing attacks:
|
|
|
- login bypass (e.g. someone getting access to Nextcloud through a
|
|
|
fake site)
|
|
|
- password resets (e.g. someone convincing TPA to reset a password
|
|
|
to an evil party)
|
|
|
- physical attacks, e.g. datacenter compromise or stolen phone
|
|
|
- slander lawsuits (e.g. "someone is saying bad things about me on the
|
|
|
dark web, you are responsible" which would lead to emails leaking)
|
|
|
|
|
|
Possible practices
|
|
|
|
|
|
- review logging policies regularly
|
|
|
- checklist of things to surveil on services (e.g. logging, backups,
|
|
|
etc)
|
|
|
- password managers and recommended software
|
|
|
- avoid password reuse
|
|
|
- 2FA or just U2F?
|
|
|
- maybe not for code signing
|
|
|
- maybe not possible to enforce on all services (say ldap/ssh)
|
|
|
- no dual use computer?
|
|
|
- CT-style logging (cf [sigstore](https://www.sigstore.dev/), [research about alternatives by
|
|
|
anarcat](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab#git-repository-integrity-solutions))
|
|
|
|
|
|
Next steps
|
|
|
|
|
|
- make a (private!) survey of security practices, e.g.:
|
|
|
- 2fa? u2f?
|
|
|
- password manager? which?
|
|
|
- what critical resource should be protected?
|
|
|
- do you dual-use your computer?
|
|
|
- nick can help with the survey
|
|
|
- survey needs to be destroyed after, summarized
|
|
|
- have checklists for each service
|
|
|
- audit services to match policy
|
|
|
- training at the next tor meeting
|
|
|
- threat modeling
|
|
|
- start deployment with TPA, then ops, because latter is most likely
|
|
|
to block deployments |