Email technology presents a host of security concerns for financial institutions, many of which can be mitigated by implementing the proper controls. Virus and malware infection risks, for example, can be mitigated with email antivirus and spam filtering software to sniff out malicious attachments or phishing attempts. Legal or reputation risks related to employee misuse can be addressed by training users on acceptable email usage and appending email messages with a disclaimer message. However, one powerful security control designed to protect messages in transit has yet to become standard fare – email encryption.

The protocols that make modern email flow have remained largely unchanged since the early days of the Internet when the security of transmitted data was not a pressing concern. When you email a sensitive attachment to a coworker on the same mail server, there is likely little cause for worry; however, email messages to and from external parties must leave the protected space of your local network. By default, these email messages are transmitted in clear text, and are susceptible to interception, eavesdropping, or tampering while in transit. While the exposure of sensitive information is never good for any business, financial institutions face an added regulatory compliance risk if an intercepted message contains non-public customer information. While end-user training can limit the amount of sensitive data sent via email, it is not a guaranteed method of preventing the unintended disclosure of sensitive information. Bank security personnel should look toward a technology solution to fill this gap, and this is where email encryption comes into play.

Free White Paper

Dispelling 5 IT Outsourcing Myths within Financial Institutions

Learn why five of the most commonly believed “facts” about IT outsourcing within community financial institutions are actually myths.

Dispelling 5 IT Outsourcing Myths within Financial Institutions

Email encryption is almost synonymous with the Transport Layer Security (TLS) protocol. TLS was created to work alongside existing email protocols to protect messages as they traverse the wilds of the Internet. When using TLS encryption, the sender’s email server first encrypts the many individual data packets that make up an email message before transmitting them. Once the batch of packets reaches the relative safety of the recipient’s network, the receiving email server then unscrambles them using a decryption key before piecing them back together. While these encrypted packets of information can still be intercepted during the journey from sender to recipient, they are jumbled and useless to a malicious 3rd party without the proper decryption key.

In order for these secure communication sessions to work as intended, both the sending and receiving email servers must support and be configured to use TLS. So, even if you properly set up your system for TLS, there is no guarantee that your recipient’s email system can service secure communications. This potential mismatch in mail server capabilities is handled differently by different encryption solutions. Perhaps the least sophisticated way to jump this hurdle is to configure email servers and systems to use opportunistic TLS. Email systems using this method of encryption will always attempt to establish a secure channel for email communications; however, if the receiving mail system does not support TLS, then the sending system will opt to use traditional insecure delivery.

While opportunistic TLS is better than no encryption at all, this method of encryption does not provide the guaranteed security necessary for financial institutions. More robust encryption solutions close this opportunistic TLS security hole by delivering messages that are unable to be sent through secure channels to a secure portal site rather than the recipient’s email system. Instead, the recipient receives an informational email notifying them that a message is waiting for them to pick up. While there is a small hassle for the recipient to log into the SSL-secured website to collect their message, it maintains a consistent level of security.

Enabling TLS is a conscious decision, but it is not always an option. Many widely-used applications and devices have a built-in SMTP server, and can be configured to send email directly; unfortunately, many of these systems lack the sophistication to use TLS. Some common examples of such under-the-radar SMTP servers are SAN appliances that send performance and alerting information, backup software that sends backup status alerts, and standalone multifunction printing devices configured to email scanned documents. Multifunction printers in particular can be problematic. Loan packets or new account documents are goldmines of customer NPI, and if these are being sent across the Internet unencrypted, then they are at risk. For networks with an internal email solution, all email messages should be configured to flow through the internal mail server(s) to prevent any unintended email exposure. If a financial institution opts for a hosted or cloud-based email solution, they may face a trickier encryption gap.

White Paper Download

Driving Compliance Through Technology

Learn how automation and documentation can improve your financial
institution’s compliance posture

Get a Copy

Since you cannot simply stop scanning from your MFP altogether just because you use a hosted email solution, management and IT staff should make efforts to mitigate the risk of unintended exposure. Luckily, there are a few options to consider. First, older network scanning devices could be replaced with more modern equipment that supports TLS, but this is not a viable option for many institutions. If the device cannot be replaced, then investigate if the device can be configured for scanning to a network folder location in lieu of scan-to-email. Finally, if all else fails, consider adding a secure relay to your network. A secure relay is a TLS-capable hardware or software solution placed on the network that receives, encrypts, and forwards messages to the remote mail system. All devices, appliances, or software that are sending messages but are not TLS-capable must then be pointed toward the secure relay. Once properly configured, a secure relay may be the last piece necessary to finally plug the encryption gap.

It is important to note that auditors and examiners do not currently require email encryption; however, encryption is considered a security best practice for any network that needs to keep the contents of their email messages secure. Depending upon your policies, network, and email solution, setting up encryption may be as easy as enabling TLS on the Exchange server, or as complex as implementing a secure relay. To ensure consistent security, the financial institution should consider how their system will handle receiving email servers that are incapable of TLS. Regardless of your solution, you cannot achieve consistent and comprehensive email security without a full understanding of how email flows through your network. Financial institution IT staff should scour the network and compile a list of all devices and systems dispensing email to ensure that your email practices match your policies.