Cybersecurity for Lawyers: 4 – Your email

December 20, 2019

Securing your email

If you use email — and, let’s face it, how many lawyers do not? — it is vital that you secure it. 

You are probably communicating a lot of sensitive information by email and email is likely to be the system used to reset passwords on other accounts. At the very least, secure your email. However, you should also consider if email is the right tool at all – there are alternatives which may offer security more appropriate to the risk. 

If your email account gets compromised, it could be very difficult to unpick it. 

If you have used your personal email account to sign up any accounts for work (e.g. social media accounts), follow this guidance for your personal email account too. 

Use a unique password

You should use a unique password for every account you have, but this is especially true for your email account. 

Secure your DNS: it’s critical

If you have your own domain name, make sure you secure your DNS

Host your server (physically) in a suitable country

See no 3 in this series here

Keep your software up to date

See no 3 in this series here

Secure the connection between your mail client and your email server

Check that your mail server permits encrypted connections and make sure you use them. 

When you set up your mail client (e.g. Outlook, Thunderbird, or macOS’s Mail), look for an option like “Use TLS/SSL”. 

If you do not do this, someone spying on your connection might be able to see: 

  • your username and password and then access your email — they could read your mail and send email coming from your account.
  • the content of your messages, including attachments.

As you cannot be sure whether your recipient has done the same if you are sending anything sensitive, encrypt it before you send it by email (e.g. by using PGP, or an encrypted .zip folder, or use something other than email. 

Secure the connection between your mail server and the mail server of your recipient

Ask whoever administers your mail server to configure what is known as “opportunistic TLS”. 

When it is correctly configured, each time  you attempt to send an email to a third party, or someone tries to email you, your server and theirs will have an initial chat to see if they can make an encrypted connection before transferring the actual email. 

You can test if you already have it working for your mail server here

If it can’t, it will still transmit your email anyway and, in doing so, it will pass unencrypted over the Internet. 

Because of this, if you are sending anything sensitive, encrypt it before you send it by email (for example  by using PGP/GPG,  an encrypted .zip folder, or  something other than email -see below). 

Minimise a fraudster’s ability to spoof email from you

A common fraud is where a fraudster sends an email pretending to be from a lawyer, asking the recipient to do something expected and reasonable, but in favour of the fraudster rather than the solicitor. For example, getting a house buyer to transfer their deposit to a fraudster’s email account, rather than the lawyer’s client / trust account. 

Spoofing an email — making it look like it has come from your email address — is trivial. You cannot stop someone attempting to spoof an email from your address, but there are some things you can do to lessen the likelihood of it succeeding. 

SPF

SPF — sender policy framework — involves setting a text record in your domain’s DNS, which says which IP addresses are permitted to send mail for your domain. This is another reason why securing your DNS is critical. 

When someone receives an email, their server will hopefully check your domain’s SPF record, and determine if the email has come from one of the authorised IP addresses. If not, it might be marked as spam / junk, or else rejected. 

An example of an SPF record, for domain example.com, is: 

example.com.  IN TXT “v=spf1 mx ip4:203.0.113.7/32 ip6:2001:db8::/32”

There are a number of tools to help you generate your domain’s SPF record. For example,  here

DKIM

DKIM — DomainKeys Identified Mail — is a mechanism for signing and verifying messages. 

As with SPF, you need to add a text record to your domain’s DNS but, for DKIM, you also need to make changes to your mail server’s configuration. 

What you will need to do will depend on your email server or service provider, so either check the manual or help pages or get someone who knows what they are doing to help. 

DMARC

DMARC – Domain-based Message Authentication, Reporting & Conformance – is an authentication and reporting mechanism. It builds on SPF and DKIM, and lets a sender state whether their email are protected by either or both of these things, and what a recipient should do if those tests fail. 

Because it builds on SPF and DKIM, get those in place first before you look at implementing DMARC. 

As with SPF and DKIM, this is another text record for your domain’s DNS. 

From a security point of view, setting your DMARC reject to suggest to recipients that they should reject messages from your domain which fail SPF and/or DKIM checks offers the best security. It requires you to make sure that your SPF and DKIM records are correct and up to date as, otherwise, “genuine” email might be rejected. 

Enable two-factor authentication if you use webmail

If you use webmail — where you can access your email through a web browser — enable two-factor authentication on your login. 

If you can only access the webmail interface via a VPN (that is, it is not exposed to the public), the risk of not having two-factor authentication is reduced. 

Consider PGP/GPG for email encryption

Securing email is difficult, as you are trying to bring an acceptable level of security to an inherently insecure system. 

If you’ve done the steps above, and still want added security, PGP — Pretty Good Privacy — and its open source implementation, GPG, is a means of encrypting your email and its attachments “end-to-end”, meaning that only the recipient (or someone who has compromised their security credentials) is capable of seeing the content of what you have sent. 

PGP/GPG secures only the content of what you have sent: it does not hide the existence of a communication, nor the identity of the sender or recipient, nor — importantly — the subject line. 

Because of the way it works, both you and the recipient have to be PGP/GPG users, and you have to have some specific information about them: their “public key”. 

PGP/GPG is not perfect, but it is better than not encrypting your email. Depending on your needs, you might want to look at alternatives to email, which offer better security (some suggestions are set out on the wiki from which this article has been adapted). 

Warnings:

  • PGP/GPG does not hide the existence of a communication, nor the identity of the sender or recipient, nor — importantly — the subject line.
  • If you lose your private key, or forget your passphrase, you cannot access your email.
  • If someone gets hold of your private key and your passphrase, they can access all encrypted email sent to you with the corresponding public key, and they can send email pretending to be you, signed with your own private key.

For help on implementing PGP/GPG for different operating systems you could try the suggestions below:

If you cannot encrypt your email, consider encrypted attachments

PGP/GPG is not for everyone and, even if you use it, it is of no use if your intended recipient does not. 

If you need to transfer something sensitive as a once-off by email, put your message or the files you want to send, into a directory and then encrypt the directory. Send that encrypted directory to your recipient, via email, and give them the password by a separate, secure channel. 

Do not email the password, as then  you have sent both the thing you are protecting, and the password to access it, by the same means: someone monitoring their email would get both elements. Send it some other way, such as by text message, or give it out over the phone. 

As with PGP/GPG, this would still leave the subject line and content of the email, along with sender and recipient information, available to anyone. 

You will be able to see the name of the attachments and, in the case of files in a zip folder, potentially the names of those files too, so use non-identifying names for the files if that is a concern. 

How you do this varies from platform to platform. 

On macOS, you can do it using Terminal, but it is not particularly user-friendly. 

For Windows, 7zip offers easy-to-use encryption

Do not trust that the sender is who they say they are

It is very easy to make an email look like it has come from someone else — the email you receive from your boss, or client, or someone in another law firm, may not have come from them at all. 

It’s easier said than done but, before you take action based on an email, especially if anything about it strikes you as unusual (time of sending, tone, the fact that you thought you’d had a conversation about the topic already etc.), check with the sender via a different means of communication already known to you. 

Do not trust unexpected attachments

An unexpected attachment may be an attempt to attack your systems. 

There is no harm in ringing up the purported sender and asking if it was really from them. Don’t use the phone number in the email itself (as that might not be their actual phone number) but verify some other way, such as using a number you already have on file with them. 

Disable automatic loading of remote content

Some people tart up their email by adding images hosted on remote computers. When you open the email, you connect to those remote computers and download the images. 

When you do this, you leave a footprint on the remote computer. Sometimes, this is used as a tracking technique: using small, invisible images as a means of detecting when you opened an email. 

Check that all your email clients have disabled loading of remote content. 

For example, in macOS’s Mail application, it is in Preferences / Viewing: 

 mac os remote load image

In iOS, it’s in Settings / Mail: 

 load remote apple mail

Don’t use tracking pixels or remotely-hosted content

Although it might be convenient to know who has opened your email and when, using tracking pixels or remotely-hosted content is bad practice. 

Be aware of phishing email

“Phishing” emails are spam emails where the sender tries to trick the recipient into handing over sensitive data. It could be someone pretending to be your bank, your accounts department, or even a client. Some phishing attacks are very good, especially when they are targeted at you (for example, based on information obtained from a previous successful attack, or a breach). 

See the guidance from the National Cyber Security Centre on how to spot phishing attempts, and mitigate risks. 

Further reading

Read Part 1: First Steps

Read Part 2: Using Wifi at home and aboard

Read Part 3: Your website

Visit the Cybsersecurity for Lawyers wiki

neil brown decoded legal

Neil Brown is Director of decoded:legal, a telecoms, technology and Internet law firm. @neil_neilzone