What we’re learning about keeping organizational emails secure

This article is cross-posted from the engine room blog.


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:

  1. 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.
  1. 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).
  1. 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?!’
  1. 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:

  1. 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.
  2. 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!

Image: Private Mailing Card (Source: Flickr)

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s