TECHNICAL INSIGHTS: STOPPING MAIL INSECURITY

EMAIL AND TRUST

Even in a world where businesses of all sizes look to Slack, Microsoft Teams and other enterprise social collaboration tools to improve the lines of communication between teams, it’s still going to be a long time before we see a true decline in the use of email. One of the core advantages of these new tools is the ability to prove that the person at the other end of the communication is truly who they say they are – each of these ‘modern’ communication methods require authentication and deliver a secure end-to-end channel.

On the other hand email was designed for another era where authentication and trust were not the first thought in designing a service; whilst you need to authenticate to your email server to be able to send a message there are a great number of (and easy to access) services out there which will allow bad actors to spoof the sending/return path address. Aided by the simplicity of this ability to exploit, bad actors can impersonate organisations of all sizes with the potential to bring about a loss of data, revenue and ultimately reputation.

However over the past few years SPF, DKIM and DMARC have emerged as technologies which can mitigate these threats by allowing the receiving party to conduct tests to verify the identity of the sender while also informing the owner of a domain if an attempt to spoof them is made.

THE TECHNOLOGY

Sender Policy Framework (SPF)

The idea of SPF has been around since the early 2000s but has only recently (RFC7208 being published in 2014) seen wider adoption. The premise of SPF is that the owner of a sending domain publishes a list of the authorised outgoing mail servers. In turn a receiving mail server can check this list and combined with information from anti-spam services, and either increase or decrease the spam confidence level of each individual message.

While this may seem like a ‘quick win’, organisations must consider any third party services (e.g. a help-desk or bulk mail service) when configuring this DNS entry to prevent the blocking of these otherwise legitimate messages.

A big failing in deploying SPF alone is that there is no way for the owner of the sending domain to easily identify these trusted third parties and equally so receive reporting on the success of their configuration.

DomainKeys Identified Mail

While SPF verifies that the sending server is authorised, DKIM provides trust that the sender is who they claim to be with the added benefit of also proving that the content of the message has not been altered in transit. Here the administrator of the sending domain generates a public/private key pair which is used to sign outgoing messages. With the public key then published in DNS the receiving server can check the signature of the incoming email and cryptographically prove that the chain of trust has not been broken.

While DKIM was first described in RFC6376 in 2011 (3 years before SPF), due to the added complexity of the key pair and no native support in the on premise editions of Microsoft Exchange, adoption has been slow. However email security vendors have picked up the slack and are now integrating DKIM signing into their appliances and services – note that administrators are still required to publish the DNS entry as well.

BRINGING IT ALL TOGETHER WITH DOMAIN-BASED MESSAGE AUTHENTICATION, REPORTING AND CONFORMANCE (DMARC)

Even with SPF and DKIM deployed the administrator of the sending mail server is still lacking the ability to enforce policy and gain insights into the successes and failures of that policy. DMARC solves these issues through the configuration of an additional DNS entry which sets a policy of either none accept all messages regardless of SPF/DKIM status, quarantine messages if the sender fails SPF/DKIM or outright reject messages that fail SPF/DKIM checks.

In addition DMARC provides a channel (using XML reports attached to emails) for the receiving mail server to report on the compliance of the messages with the domain owner’s policy. This reporting process combined with a service which can parse the XML reports, gives the domain owner a powerful set of tools to detect misconfiguration and discover attempted abuse while ultimately protecting the trust level of their domain.

How Does It Look?

For the inquisitive user or administrator the result of these technologies can be seen in the email headers. Shown below is an email sent through our email security appliance where you can see that the receiving mail server has processed SPF/DKIM and DMARC with a pass at each stage.

HOW A DEPLOYMENT MIGHT LOOK?

In a typical deployment of SPF/DKIM/DMARC the policy action would first be set to none; in this ‘listen only’ mode the configuration of the DNS entries and public/private key pair can be verified whilst also allowing the administrator to detect any other (legitimate or otherwise) services that might be identifying themselves as coming from the administrator’s domain.

As the report data flows in the administrator can then apply a higher policy level, perhaps first setting the policy to quarantine to request that messages which fail SPF/DKIM end up in the recipient’s junk mail folder before finally adopting a reject policy to prevent the delivery of illegitimate email.

NEXT STEPS…

Please reach out to us or get in touch with your account manager if you require assistance in configuring these services or are looking to review your stance on email security.

Written by James Preston, Security Architect for ANSecurity