Protecting Your Brand’s Email Channel

Despite the rise of social media and the advent of single-platform communications such as Facebook Messenger and Twitter, email remains the most ubiquitous form of electronic communication with an estimated 235 billion emails being sent every day.[1] However, email-borne threats such as malware, phishing and spam have eroded consumer trust in the email channel and by extension have damaged the ability of financial service firms to reliably communicate with customers through this critical channel.

The email protocol was first published in 1982 and like many of the original internet services designed before the dotcom era, security wasn’t on the engineering radar. Fast forward to today, we have seen over 20 years of social hacking to abuse loopholes in the protocol by impersonating senders[2] or accessing unprotected email in-transit[3], with the Business Email Compromise[4] being the latest successful twist on these old techniques.

Fortunately, motivated internet engineers have responded to these threats and have devised new methodologies to help mitigate them and allow domain owners, like those in .BANK and .INSURANCE, to regain and maintain control of their domain’s (and their brand’s) email reputation. This is accomplished by deploying two critical and interoperable technologies: Transport Layer Security (TLS)-based encryption and email authentication.

fTLD’s Security Requirements mandate .BANK and .INSURANCE registrants deploy both of these technologies for their domains to provide a more secure email environment throughout the domain space. fTLD monitors and ensures compliance to provide consumer confidence in .BANK and .INSURANCE emails.

 Encrypted Email

.BANK and .INSURANCE were established as HTTPS-only communities, where all web traffic must be encrypted. Using the same TLS (successor to SSL) technology which secures web browsers, email servers may establish a secure communication to other TLS enabled email servers. By enabling TLS on email servers when both sending and receiving, emails in-transit are hardened against integrity and confidentiality attacks that can be prevalent on the internet.

Modern email servers generally support TLS. Currently TLS 1.2 is the most secure level of the technology, but Opportunistic TLS[5] is a prevalent option that allows emails to be sent using encryption that supports a default to clear text when a secure TLS connection cannot be established with both the sending and receiving servers.

fTLD’s Security Requirements mandate .BANK and .INSURANCE registrants deploy TLS 1.1 or greater using known-good cipher suites. However, work is underway to consider an option to allow Opportunistic TLS support on sending and receiving email servers as a last best effort to process emails. 

 Anti-Phishing Standards

One of the biggest problems with the original email protocol was receiving servers always trusted the sender of an email to accurately declare the origination of an email. Unfortunately, this left the door open to abuse and a variety of threat actors, including hackers[6], especially organized crime, were quick to figure out how to socially engineer emails and trick people into installing malware or giving up their credentials (or worse!) using impersonation scams known as phishing.

To combat these attacks, domain owners can deploy three complimentary protocols which essentially describe to the internet how a domain sends email thereby allowing receiving domains to automatically authenticate and enforce specific domain email policies. These three protocols publish the following specific configuration details of each domain in the Domain Name System (DNS).

• Sender Policy Framework (SPF) – A whitelist of IP addresses corresponding to authorized sending email servers. This allows the receiving domain to check the sending server’s originating IP against the domain’s whitelist prior to delivery.
• DomainKeys Identified Mail (DKIM) – Enables a domain to associate itself with an authorized email message by publishing a public key certificate in the DNS. The authorized emails must then affix a corresponding digital signature. This allows the receiving domain to verify the email’s signature against the public key certificate prior to delivery.
• Domain-based Message Authentication, Reporting and Conformance (DMARC) – While SPF and DKIM provide two independent ways of authenticating emails, DMARC solves two key problems:
  • DMARC allows senders to indicate whether their emails are sent with SPF and/or DKIM and provides a policy to receivers on what to do if either authentication method fails.
  • DMARC provides a reporting mechanism so that receivers can tell senders what they are seeing coming from the sending domain. With this capability, senders can be confident DKIM and SPF are configured appropriately and that authorized mail is being delivered and unauthorized mail is being appropriately handled per the sender’s failure policy.

Unlike TLS, these three anti-phishing solutions require additional set-up and ongoing maintenance when establishing a domain’s email. Keeping track of authorized sending servers (including authorized third parties), making configuration changes, rotating DKIM public key certificates and validating the enforcement of DMARC policies is an ongoing responsibility, but one that is well worth the investment in today’s threat environment. Organizations that have a large number of email addresses and/or a high volume of email may choose to work with vendors such as Agari, dmarcian, Proofpoint, Return Path or ValiMail, and some domain registrars may also provide email authentication services.

For domains (and subdomains) that are not used to send email, creating a DMARC record stating so requires little effort and there is no ongoing maintenance; SPF and DKIM are not required.

fTLD’s Security Requirements mandate .BANK and .INSURANCE deploy DMARC for all (sub)domains and to deploy SPF and/or DKIM for any (sub)domain that sends email; however it is recommended to deploy both SPF and DKIM to minimize any deliverability risks. DMARC must be configured to reject unauthorized email (p=reject) within 90 days of deployment.

Conclusion

Many current email-borne threats can be mitigated through the appropriate use of mature encryption and email authentication standards and technologies. Although some of these technologies require an initial resource investment and ongoing maintenance, the benefits of ensuring the confidentiality and integrity of your email channel to prevent malicious actors from eroding your brand and maintaining the trust of your customers is invaluable.

In its ongoing effort to ensure the Security Requirements for .BANK and .INSURANCE continue to meet the changing needs in domain security and serve its communities, fTLD is committed to periodically reviewing them and making updates if needed.

By Andrew Kennedy, Financial Services Roundtable/BITS Cybersecurity Advisor to fTLD

Additional Resources:

• Guides to Leveraging an fTLD Domain
• Resources to Review Domain Name Compliance
• BITS Email Authentication Policy and Deployment Strategy for Financial Services Firms

[1] See http://www.radicati.com/wp/wp-content/uploads/2015/02/Email-Statistics-Report-2015-2019-Executive-Summary.pdf

[2] See https://en.wikipedia.org/wiki/Phishing

[3] See http://ask-leo.com/just_how_easy_is_it_to_sniff_network_traffic.html

[4] See https://www.fbi.gov/news/stories/business-e-mail-compromise

[5] See http://dyn.com/blog/opportunistic-tls-for-email-security/

[6] See https://www.whitehatsec.com/wp-content/uploads/2016/06/WhiteHatSecurity_Hacker_10may_2016.jpg