When sending out an email, a lot can go wrong. To get around that, many people encrypt. And that’s a great solution. But a lot can go wrong with that, too.
Is the answer to this to start delivering all your messages by hand or pigeon carrier? No. But it certainly involves having a multi-dimensional view of what it is to send a fully secure email and an understanding of the ways in which we can mess that up. And then, of course, to avoid making these all-too-common mistakes.
Mistake #1: Encrypting a File Your Recipient Can’t Open
The point of encrypting a sensitive email is twofold: make sure it isn’t tampered with and to actually get the intended message over to the recipient so they can use whatever you’ve sent.
Before you jump into using the strongest encryption possible, ask yourself: Will they be able to decrypt this or will I be delivering something even they can’t see? For example, if you’re sending something like a password-protected ZIP file, that’s something anybody can do (just create it on your desktop and stick a password to it). So, chances are that it will be decryptable for the party in question – no problem.
But if you’re really astute, you’ll think: Well, that’s exactly the point; I don’t want something that just anyone can decrypt. So, you opt to properly secure it using AES 256 ZIP encryption. Only now, the built-in Windows ZIP Opener can’t open it, leaving you with the option of having to send your recipient the password.
And how do you do that?
Mistake #2: Sending the Password in a Risky Way
Many people get to this step and, with all the best intentions, accidentally make the encryption process an exercise in futility.
It looks like sending the email with the encrypted file – and the password is right in the subject line or the body. Either one renders encrypting moot off the bat because if an attacker intercepted that email, they’d now have your AES-secured message and the key to decrypting it. Handy. If you must send it that way (or choose to – there are other options), at least don’t send it with the word “password” prefacing it.
One way to do it better: if it is a password-based system you’re using, send the credential via WhatsApp, SMS message, or some other form of nondescript delivery (and not with the work password in the message, of course). While this is the way to do it if you insist on using a password in the first place, it is difficult to get all of your users to adopt creative methods like these all of the time. Plus, it requires your business associate to have WhatsApp or give you their personal contact details, or whatever. While it technically works, there are other methods that are more practical.
These methods include key-based encryption protocols such as S/MIME or PGP. These protocols spin up public and private keys and as long as you keep your private key secret, you can share your public key with anyone. They can then use that public key to send you encrypted messages, which you will use your secret private key to open. No need to share that secret online or with anyone, and the worst someone could do if they came across your public key would be to encrypt something and send it to you (not decrypt anything you’ve encrypted).
How do you send an encrypted message to another party, then? The same way, only this time they spin up the public and private keys and send the public one to you.
Mistake #3: Thinking Everyone Knows How to Use S/MIME or PGP Encryption
While leveraging asymmetric protocols like S/MIME or PGP is a secure solution, there are still some pitfalls of which to be wary.
First, not everyone is going to know how to use it. If your recipient is unfamiliar with how cryptography works, you could try to remotely teach them how to spin up and use asymmetric encryption, but ideally that’s something they would handle in-house.
Even if you had set up a key server for the convenient exchange of public keys, this only works in scenarios where the other party knows what you’re talking about and is on the same page. In other words, it works best for mature organizations that have well-established cybersecurity systems and internal experts on their side.
While that setup is ideal, we all know it is not always the case. So how do you send something to a fledgling organization or someone who has never heard of public and private keys before?
Mistake #4: Overlooking Portal-Style Encryption
In the event that you’re sending sensitive files to third parties that are unfamiliar with the finer points of asymmetric encryption, portal-style encryption is a great option.
This is something that nearly everyone has seen from their bank, in which the real (sensitive) message is held back in a portal and the only thing that comes through to your inbox is a stub of the message directing you there. It says something like, “You have a secure message. Click here to view it.” Then, it will route you to the portal where you can log in and gain access to it.
The upside is that it’s ubiquitous and easily accessible by anyone—all you need is a web browser. The downside is that you, as the sender, must now manage this extra infrastructure (the portal), which includes server space, maintenance, security, and the like. In cases where you need to frequently send out secure emails to large numbers of non-technical users, the upkeep might be worth it. Or, you can host it in the cloud, which drastically cuts down on the load (though you must always remember your part in the shared responsibility model, or perhaps even that won’t be secure).
Another additional downside is that portal-sent mail can look like spam, raising suspicion and requiring you to add some kind of ‘trust marker’ in the body so your recipients know it’s from you. Besides the right logos and fonts (these are a given), this includes ensuring your portal mail comes from a legitimate domain and will not be flagged as spam.
Mistake #5: Forgetting About TLS Encryption
There’s another way to encrypt that takes a lot of the guesswork out on both sides. Transport layer security (TLS) encryption doesn’t require you to encrypt the message upon sending, nor does it require the other party to decrypt it upon opening.
Instead, you send the message free and clear, but as soon as it hits the wire it gets encrypted. This will keep it safe from a lot of the threats you’re really worried about, such as interception, man-in-the-middle attacks, and so on. As soon as it arrives at the remote end (its intended destination), it automatically becomes unencrypted so your recipient can read it. However, this only applies if you’ve turned TLS on in mandatory mode (also called “forced TLS”).
If you haven’t, then you’re in Opportunistic TLS mode. While any TLS is better than none, augmenting non-mandatory TLS with other tools (MTA-STS, for example) is highly recommended to guarantee your messages are secure.
The Benefits of Fortra's Agari & Clearswift Solutions
It should be apparent that what you get out of your encrypted messages is what you put into them. Or, what we do.
With automated email encryption and other anti-phishing mechanisms from Fortra Email Security – including Agari and Clearswift solutions –organizations don’t have to know how to leverage asymmetric encryption, or any other kind for that matter. We support all the cryptography mentioned above to secure your sensitive email messages, and the benefit is that with these platforms in place, teams can send encrypted emails with the push of a button – no previous experience required. They can even encrypt mail as it comes in.
With all the encryption work done in the backend, your users don’t have to slow down or retrain in order to send safe, secure emails every time. However, the most important security tool remains the users themselves. Teaching them which assets deserve encryption is just as important as giving them the tools to encrypt themselves, and for that, only more employee training will do – well that, and perhaps an investment in Secure File Transfer (SFT). But that’s a topic for another day.
