How to send secure email attachments (original) (raw)

Sending sensitive information in attachments is inherently unsafe, and the main way to secure them -- encryption -- can be implemented inconsistently, negating security benefits.

Published: 05 Aug 2020

Sending sensitive information securely in an email or as an attachment is possible, but enabling encryption to do so can have issues that could negate any security benefits.

Sending an email is like sending a postcard: Everyone or every system that handles it can see and record what was written. This is not a problem obviously if the contents are nothing of interest or importance. It is a big problem, however, if the contents include sensitive data, such as banking details, network passwords or customer data.

Many enterprises opt to use a secure email gateway, which not only helps protect email attachments, but also provides a slew of other email security benefits, from scanning inbound and outbound emails for malware to scanning messages for sensitive data and blocking the email from being sent.

However, because many employees need to send emails with sensitive data, outright blocking this is often ineffective. Therefore, if an employee must send sensitive data via email, the best option is to use encryption.

How to encrypt email attachments

The most basic form of encryption is TLS, which encrypts data in transit. Web-based email services, such as Outlook.com and Gmail, use TLS to encrypt email messages in transit being sent to the same service. However, if the receiving server doesn't have TLS enabled, the message will not be encrypted, and often, there is no warning that a message was not encrypted. Additionally, because TLS only encrypts the data in transit and not the message itself, it does not protect against emails being intercepted and read once delivered.

To further protect email attachments, enterprises and users should use either Secure/Multipurpose Internet Mail Extensions (S/MIME) or Pretty Good Privacy (PGP). Note, however, that the recipient and subject line of the email will not be encrypted. The options are similar aside from two points: PGP uses a web of trust, whereas S/MIME relies on certificate authorities for trust. In addition, S/MIME is often more compatible with enterprise email clients, including Outlook or G Suite.

Both forms of encryption require the use of a public-private key pair, where the public key is used to encrypt the email and only recipients can decrypt it using their private key. With PGP, the sender must obtain the recipient's public key directly or from a decentralized service, such as a key server.

Asymmetric encryption graphic

How public-private key pairs are used in encryption

With S/MIME, the process is simplified somewhat because certificates -- specially wrapped keys -- can be stored by email clients or in an enterprise's Active Directory and exchanged automatically. S/MIME certificate can then be exchanged via an unencrypted email for subsequent emails to use.

A number of enterprise email providers have been adding email encryption options. These often work through S/MIME and require the purchase of a digital ID or certificate from a certifying authority, such as GlobalSign or IdenTrust, before enabling email encryption. Certificates can then be stored by the email provider and exchanged automatically.

There are some special considerations for particular email providers. For G Suite customers, for example, rules must be set up to govern how and when email encryption occurs. Gmail will attempt to obtain the public key for the recipient, but if that fails, the email may be sent unencrypted if the rules aren't set properly. Outlook users can enable S/MIME encryption certificates and digital ID certificates manually, but for more fine-tuned control and automated encryption, Microsoft 365 subscribers can use Microsoft 365 Message Encryption to send encrypted emails to both Outlook and non-Outlook addresses. Outlook users will be able to read the encrypted email without issue, but non-Outlook users -- for example, someone with a Gmail address -- will get an Microsoft 365 link to read the email.

The risks of email encryption

The process of encrypting an email can be complex. It requires senders and recipients to understand and navigate public-private key pairs and often requires the use of a third party, which, in PGP, involves a browser or email client extension and, for S/MIME, a certificate authority.

Beyond potential issues in handling public keys, users must worry about losing their private key or having it stolen. Private keys are encrypted with a secret password, which opens the door to all security issues related to poor password practices. If a private key is lost or stolen, it must be revoked, rendering all emails encrypted using that key pair unreadable.

Even if all is done well and keys are kept safe, email encryption still leaves the email header -- with recipient information and subject line -- unencrypted, so sensitive data can accidentally be leaked that way. And PGP and S/MIME have had vulnerabilities in the past -- such as Efail -- that could enable an attacker to decrypt emails using them.

In certain industries, such as healthcare or finance, where regulatory requirements demand, encrypted email may be required to ensure compliance. Outside those under regulatory requirements, the use of email encryption is decided by each organization's company policy.

If you are unsure about the state of encryption in your email provider or in the ability of the recipient to handle an encrypted email properly, the best option may be to use an end-to-end encrypted messaging service -- such as Signal or Wickr -- or a secure file transfer product to send sensitive data.