By Dustin Gray

A few months ago, Mimecast released "The State of Email Security 2020," this year's version of their yearly breakdown of email security. It had the same central finding as it did last year, and the year before, and every year going back for as long as it, or any other yearly cybersecurity report has: Year after year, email continues to be the largest and most exploited attack vector for organizations of any size, across nearly all industries and geographies. It has been for all of recent memory, and will be for the foreseeable future. That seems crazy, though; how could we have known about this for so long and not addressed it? With how widely email is used, and how prolific security services, appliances, and suites are, you would think someone, somewhere would have figured this out. You wouldn't be far from the mark (for the most part), but the story gets interesting quickly.

Over the next three blogs I'm going to take a dive into what it is about an email that makes it such a convenient target for cybercriminals, why securing it seems so convoluted, the current trends in email-borne security threats, and what promises new email hosting and security offerings hold for email. I'm going to start this blog with a background into an email, and introduce some of the concepts that are central to the conversation about email security.

Email Server Authentication and the Sordid History of Spam

Our story starts in the late 1970s when the Protocol Wars had been raging for over a decade. Engineers were battling over what systems would be used when communications were standardized, each fighting through the compromises it takes to make systems work together. Of the myriad messaging protocols, SMTP was emerging as the clear dominant standard for sending emails. SMTP is a robust and elegant protocol and would end up being the driving engine of email communications through to the modern era. Throughout the 1980s and into the 1990s, however, a considerable flaw in how SMTP handles the sending of email was waiting to wreak havoc on everyone's inbox.

You see, SMTP allows any computer to send email as any source domain or address; there is no built-in method to authenticate the sending server to ensure that it is actually associated with the domain or organization it is claiming to be from. During the 70s and 80s that was a relatively unnoticed side note. By the late 1990s, however, people had figured it out and spammers began abusing it to flood people with unwanted advertisements and emails. Did that email really come from @bankofamerica.com? This type of abuse (sending email from a domain you do not own) is called "spoofing." As 2000 came, spoofing was starting to be used more widely to gain trust with companies and compromise employee credentials and files. With SMTP spread too far to switch to anything else, and no built-in server authentication, engineers had to find an external way to prove what servers belonged with what domain, and stop the spoofing.

Sender Policy Framework (SPF), That’ll Stop ‘Em!

By the year 2000, spoofing was beginning to become a serious concern for businesses, and standards were coalescing around a DNS-based authentication method that would allow organizations to verify ownership of both their mail servers and domain. By 2004 the name "Sender Policy Framework" (almost always just "SPF") was settled on, and in 2006 it was published as an RFC (a standards document used by the internet at large).

SPF works on the idea that in order to make DNS changes to a public domain (like managedsolution.com) I have to first own that domain. If I own that domain, I can create a text list of servers allowed to send email from it, and publish it as a DNS 'text' record. Then, any server that receives email as my domain can check my text SPF record and make sure it's really from one of my servers; and just like that spam was defeated!

Except, as we all know, spam was very much not defeated. SPF requires knowledge of email infrastructure and DNS, and many organizations did not have the ability/knowledge to implement it. Additionally, SPF only protects the envelope of an email, and cunning cybercriminals are still able to "spoof" the sending address in the emails’ encoded headers. Additionally, a mistake in an SPF record can cause legitimate email to become undeliverable, which can cause huge headaches for any organization.

Independent groups began keeping public "blacklists" of senders who failed to secure their domains and were then used to send spam, which encouraged SPF adoption for many email administrators. As adoption grew, engineers were also tackling the problem of spoofed headers.

DomainKeys Identified Mail (DKIM) Rounds It Out

In 2004, competing efforts from Cisco and Yahoo to address header spoofing resulted in the creation of DomainKeys Identified Mail (almost always "DKIM"). DKIM works by having email-sending organizations encrypt outbound emails' headers, then provide a cryptographic key in their DNS that allows receiving organizations to decrypt them. Since only the sending organization can encrypt the emails for that key, it proves to the receiving organization that the email is actually from who it says. Additionally, since the emails' headers are encrypted while they are being sent, it proves that the emails were not intercepted or altered.

If that sounds more complicated than SPF, that's because it is. In addition to DNS and email infrastructure, DKIM requires an understanding of public-key encryption and the ability to implement key signing in your email organization. In the end, it suffers from the same thing SPF does: Because it is hard to understand and often complex to implement, it has had slow adoption.

There was another problem altogether, as well. SPF and DKIM aren't designed to work together, and there was no central protocol or policy in place to hold them together or provide centralized controls for how an organization’s messages would be treated if they passed one check, but not the other.

...and DMARC makes 3

In 2012, specifications for a new protocol that would link SPF and DKIM together, again via DNS, were announced. "Domain-based Message Authentication, Reporting and Conformance" (almost always "DMARC") allowed organizations to centrally set policy that was tailored for their environments. Finally, DNS authentication for emails covered envelope and header spoofing and had a centralized way to manage it.

DMARC, however, again ran into issues with complexity. Effectively using it required organizations to understand SPF and DKIM, then add another level of policy understanding for DMARC. Predictably, it has also had adoption issues.

Wait, What About All Those Spam Filters and Email Security Providers?

If we were to universally adopt SPF/DKIM/DMARC as an email-sending community, the avenues for nearly all spoofing and spam would be closed. However, as we've found several times, we aren't a perfect community and not everyone has the capacity and wherewithal to implement those security protocols. Even if we all did, there are email-born threats like malware and Business Email Compromise tactics that don't require domain spoofing at all. That's where spam filters and email security providers come in.

In this imperfect world of email security, these vendors use a combination of heuristic scanning, malware scanning, blacklist checking, and DNS checking to see if a message is legitimate or malicious.  Many now include AI in their offerings that can add behavioral analysis and conversation continuity, but at their core, they are attempting to both cover for the lack of universal SPF/DKIM/DMARC adoption, and prevent/mitigate non-spoofing-based attacks.

Well Thanks for Making Me Feel Unsafe, Where Do I Go from Here?

Mimecast’s “The State of Email Security 2020” report that I brought up earlier puts it pretty starkly when it shows that while 97% of IT decision-makers are aware of DMARC, only 28% have implemented it. That’s for a security mechanism that largely relies on community engagement.

The most effective weapons we have against email-born threats are action and education. By now you should have some idea of why email is hard to secure, the ways in which we attempt to secure it, and why you should do so. If you are interested in starting that journey now, talk with your IT provider or see some of the resources I’ve linked to below.

My next blog will cover common attacks and trends in email security. We’ll be diving more into “The State of Email Security 2020,” so I’m including a link to where you can download that. We’ll be looking at what these attacks are and what can be done to respond to them. Finally, I’ll be finishing the series out in a third installment with a look at some contemporary email services and how they are streamlining security.

Stay tuned next week for Part 2!

Resources

The SPF Project (please note that this site is insecure)

http://www.open-spf.org/

DKIM.org (please note that this site is insecure)

http://dkim.org/

DMARC.org

https://dmarc.org/