We’ve been thinking a lot about how organizations implement secure communication practices across a team and work with groups to develop policies. We’ve also been applying these ideas to our own team, which has grown significantly over the past year (from 2, to 4, to 10). As we bring new staff on board, we have been re-evaluating and strengthening our own organizational communication practices.
We decided to start with our email. Securing an organizations’ emails isn’t a small feat. It requires thoughtful policies, significant staff buy-in, and ongoing support and training. But don’t be intimidated! It’s not only possible to secure your organizations’ emails – it is well worth the effort.
The policies our team developed together
It was important to us to develop our email policies collaboratively. Our communications and technology teams drafted the policies, shared it with the team for input, and revised them accordingly. Here’s what we came up with.
All team members commit to:
- Always using encryption in communicating with other staff via email, including internal email listservs, unless you’ve been asked to send the information over another channel, and that information is not sensitive. Rationale: we encrypt emails to protect our operational information from prying eyes.
- Never store your private PGP key on your mobile phone. In other words, do not encrypt/decrypt work emails on your smartphone. Rationale: Mobile phones are inherently insecure because the baseband processor on your phone always has potential access to your data. This will mean that you won’t be able to read emails from your colleagues on your mobile phone because you won’t be able to decrypt them. When an urgent-seeming email comes through, to write back and say “send unencrypted?” If the person feels comfortable doing so, then they will. If not, oh well – that urgent task will have to wait (hat tip to Jillian York for this idea).
- All emails to people outside of the organization will be signed with your PGP key. Rationale: Your signature provides authenticity that it’s really you emailing, and it can prompt others to say, ‘hey what’s that zany content in your email?’ To which you can say, ‘oh, have you heard about PGP?!’
- Your organization email will include a link to your PGP key in your signature. Rationale: This will make it easy for your contacts to send you encrypted emails if they prefer. For help on how to add an email signature to Thunderbird, visit https://support.mozilla.org/en-US/kb/signatures.
Note regarding signing emails by default: As pointed out in the Surveillance Self-Defense toolkit, in some parts of the world (including China, Iran, Belarus, and some Middle-East states) using unlicensed encryption, even for personal use, is illegal, so you might have very good reasons to not let others know you use PGP. Take away: it’s important to know your own context when developing your organization’s email security policies.
How we support the team in implementing the policies
Developing the policies is just one piece of the organizational security puzzle – you have to make sure people know how to implement it, and that they have the tools and support to do so.
Through a series of online informal, focused skills-training sessions (which we call ‘microskillz’) we’ve been able to get everyone comfortable with email encryption. These microskillz trainings have made these skills, tools and policies approachable (and sometimes even fun! Try hosting a key-sharing happy hour!).
The team also enjoys these meetings because they have an opportunity to interact with colleagues that they may not usually talk to. We document and archive all of these microskillz trainings so they are accessible to refer to any time.
Challenges and opportunities
Some of the challenges we’ve run into have been around the software:
- We’re all using slightly different tools and versions of tools. Some are on Linux, others on Mac. Some are on Thunderbird, some are on Apple Mail. So when bugs pop up (like, ‘why can I only decrypt Tom’s emails when I click “Fwd” or “Reply”’?) it can sometimes be really hard to figure out what’s going on and how to fix it.
- It took us a while to figure out a solution to allow our Apple Mail users to send encrypted emails to our internal email lists because Enigmail for Mail doesn’t come with per-recipient rules.
Despite these setbacks, we’ve been able to make it work pretty well so far! And the team feels that it has ownership of these policies, as well as empowered and supported to carry them out. We all feel good knowing we’re taking steps to keep information about our work and partners secure.
What has been your experience in creating and implementing organizational email policies? What challenges have you faced along the way? Any advice for us regarding the challenges we’ve faced? Please share resources, ideas, questions and examples by adding a comment below!
Thank you for this post.
In helping an organization implement their email security, the following issue came up:
If an employee uses their PGP keypair for encrypting work emails, it presents a dilemma when this employee leaves (or is removed from) the organization, since their departure will mean either loss of organizational legacy of their prior email communications, or them having to surrender their (personal) privatekey.
The solution we came up with was for the organization to require (and help) each employee create a PGP keypair for their organizational use (tied to their org email), and a copy of this keypair to be (securely) sequestered by the org.
There are advantages to this in terms of maintaining legacy for the org, but also some disadvantages, such as employees having to maintain multiple keys (where one such pair is challenging enough), the discomforting concept of having one’s private key be sequestered elsewhere, reliance on org-wide safekeeping of data (i.e. all employees’ keypairs).
We mitigated the ‘discomforts’ by adding appropriate other policy elements to make sure employees understand and agree to protocols relating to work-email being ‘organizational assets’, explicitly specifying additional safeguards for storage of these keys, etc.