Derran Kyle, Author at 7 Elements

Introduction

While imitation may be the sincerest form of flattery, email impersonation and spoofing has proven to be a serious risk to organisations and their staff.

An email sent from an attacker that is convincing enough to fool the recipient into believing it is legitimate can have major consequences to the security of organisation’s infrastructure, as well as the data they possess. All it can take is one email carrying a document containing malicious code for an attacker to gain a foothold into a network (see our blog on Ryuk Ransomware for more information). As a result, email security is paramount when designing robust security controls. This guidance document will take a high-level look at three core controls areas, Sender Policy Framework, DomainKeys Identified Mail and Domain-based Message Authentication, Reporting and Conformance. Links to Microsoft and Google configuration guidance is included at the end of this document.

Email 101

Email works in a way akin to traditional physical mail. the email server sends a message to the recipient address containing an array of data, most notably the sender user and domain, recipient and the message body. One significant flaw within the email process is due to the server or client receiving the email typically trusting the validity and authenticity of both the sender and the information received without question and handling it accordingly. No matter the sending mail server, all mail servers are treated equally. In reality, it can be a fairly trivial process for an attacker to host their own malicious mail server designed to spoof email content and sender details. To address this risk, there are a number of additional controls that can be utilised to enhance email security.

Sender Policy Framework (SPF)

Sender Policy Framework is a method used to verify that an email is coming from a server authorised to send mail on behalf of the domain. This is achieved through use of DNS records which are publicly accessible tables regarding a domain which link domains and IP addresses for routing. SPF can be added to the DNS records of a domain which then provides a publicly accessible list of the authorised places where email can come from. This list is then checked once the recipient email server receives a message. The receiving mail server cross references the DNS records from ‘mail@example.com’ and the sending IP address that the email originated from in order to determine if the IP is on the list of authorised senders. If yes, then the email proceeds to the regular inbox. If the sending IP is not listed on the SPF DNS records, then it is used as a spam indicator.

While SPF is not a bulletproof solution as it only verifies servers used to send emails not user accounts it does typically enhance mail security and is one of the easier headers to implement properly.

DomainKeys Identified Mail (DKIM)

One area that SPF is not intended to provide assurance of is the integrity and authenticity of the contents of the email’s sender and message. This is of particular concern in the event that the message can be intercepted and modified in transit between the sender and recipient. To guard against this, a standard was developed known as DomainKeys Identified Mail (DKIM) it employs public-key cryptography to generate a hash value which is then signed using a private key, this is then appended as a header value to the email together with a number of other values needed for DKIM (such as information needed to retrieve a public key from DNS).

Upon receipt of the email, the recipient can use the corresponding public key (obtained from the sending domains DNS) to validate the hash value received. The recipient server will then it will generate its own hash value to compare against the received hash value to validate the email.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Domain-based Message Authentication, Reporting and Conformance (DMARC) is a method used to inform mail recipient servers of what should happen to an email if SPF and/or DKIM fail to validate. This removes the need for the recipient to make a judgement call (i.e Gmail will not mark an email as SPAM just because it fails SPF, without DMARC telling them to), providing further protection against phishing and other business email compromise attacks.

A DNS record entry is published by the sender containing instructions that typically include if SPF/DKIM should be validated and if so to what level. It will also tell the recipient what to do if either fail validation. Typically this may lead to emails that failed authentication being quarantined automatically or deleted but it’s possible to also request that failures are reported back to a business making it possible to evaluate if a failure is down to a technical problem or someone trying to spoof emails from the domain.

A Layered Approach

While any of these measures can be used in isolation or combination, using all three measures provides a defence in depth approach to email security that can assist with protecting against many common attack vectors. Most enterprise email service providers offer their ow client or resource to implement and configure email security records and DMARC rulesets. Their tools will typically allow you to generate a domain key, associate the public key with the mail server’s DNS record and apply the relevant ruleset to the record for all outbound messages.

Conclusion

Out of the box, email and especially cloud based email services require additional hardening to protect against common attacks (such as spoofing). This guidance document has introduced at a high-level three core control areas that as individual components, combined or all together can provide a more robust email security posture. However, they are by no means a guarantee that future security vulnerabilities wont find away to work around those controls and result in trivial email spoofing. As such, a more in-depth approach to email security is required, and one that takes into account both technical controls such as those discussed, along with multi-factor authentication, and combine with more human elements such as phishing awareness training.