Has your organization deployed a secure email appliance? If you have deployed email encryption, you probably take one of two approaches – endpoint client or network appliance. If you’re using a network appliance or have implemented a cloud-based, managed or hybrid approach to email security, chances are you can trigger email encryption by adding a keyword to the subject line of your message. For instance, if you add “Encrypt:” or “Secure:” to the beginning of the subject line, your email encryption appliance downstream knows to encrypt the message and send it off as an encrypted message.
If you let users trigger encryption via the subject line, I can almost guarantee that some of those users are misspelling this trigger from time to time. For example, if you used “EncryptedEmail:”, you’d surely get users who type “encryptemail:” or “encryptedemail;” or “EncryptedMail”. These failed attempts at encryption are a perfect example of the byproduct of having humans as a component of an information security process or system: even though users have the full intention of encrypting their message, at least a small percentage of them will fail to do so because they don’t properly utilize the trigger keyword.
Knowing that this will happen, you really have 2 options:
- Auto-encrypt messages that have misspelled keywords
- Block/monitor and notify on messages that have misspelled keywords
The third option, of course, is to simply let these messages pass unencrypted and don’t worry about the problem. While one might be envious of those of you who have that luxury, chances are if you’ve deployed email encryption it’s because you actually intend to encrypt messages when your users ask, even if they don’t fill out the paperwork quite right.
Instead of choosing one or the other of the above options, I would recommend doing both.
Step One: Quantify the Risk
You’re not going to have a good idea of how large this particular problem is at your organization until you get some metrics. If you’ve had data loss prevention (DLP) deployed for a while, I would recommend taking part of your encryption keyword (Secure, Encrypt, etc.) and searching for it at the beginning of the subject lines of past true positive DLP incidents. If you don’t have a wide history of data, then you can brainstorm a list of failed keywords with your team or utilize your email backup/retention system for another historical view. If you’re just deploying DLP, this is a great way to dip your toes into the water by deploying a monitor-only policy that does not block the message.
Step Two: Analyze the Result
We discovered dozens of misspelled keywords by looking at past data, and by exporting the data we were able to subtotal it by misspelling. Be sure to look for keywords that use other punctuation if you require a colon, or triggers with one letter missing or misspelled words or dropped punctuation all together. We shared this information with the team that runs our encrypted email strategy, and determined the half dozen or so triggers that were most often used.
Step Three: Implement Auto-Encryption
The email encryption infrastructure team took the 6 most used misspellings, ones where the user absolutely meant to encrypt the message, and began to auto-encrypt messages passing through the email security gateway that had those misspelled triggers in the subject line. Some DLP vendors talk about the idea of auto-encrypting a non-compliant message, but we have found that blocking and notifying users of the correct process is better than auto-encrypting the message because it doesn’t interrupt the customer service flow with a potentially unknown and disruptive event.
Step Four: Implement Monitor/Block then Notify on Failure
A preference for notification, and the inherent opportunity for meaningful user education, led us to develop a notification for failed attempts at encryption that the user would get when they misspelled the keyword. The notification explained exactly what the user had done wrong, attached the original message, and even highlighted the subject line to draw attention to the error. The notification did not have to be acknowledged, but often was because we copied two levels of management with the error.
With the right notification, you could be pleasantly surprised – our monthly failure rate dropped by 90% within two months, a quick win with wide visibility. Your team (via DLP appliances sitting before your encrypted email infrastructure), the encrypted email team, or your email infrastructure team should also be able to quantify any increase in encryption as a result. We also used our notification to push the user to install the Outlook client for encryption, which didn’t require the user to type a word to encrypt the message, and quantified this change by using our enterprise systems management solution. Hopefully this approach might work for you as well.