We’re a little less than a month away from the arbitrary October deadline established by the U.S. Department of Homeland Security (DHS) for all federal departments and agencies, as well as the executive branch, to implement the Domain-based Message Authentication, Reporting & Conformance protocol, known as DMARC. The Binding Operational Directive (BOD) issued nearly 12 months ago is part of a broader initiative to harden both email and web security of government organizations, many of which are under increased threats from hackers, hactivists and nation-states with various motives.
As of mid-July, it had been reported that only half of the organizations mandated to implement DMARC had successfully done so. The frequently reported challenges associated with implementation and maintenance of DMARC have no doubt stalled efforts; it will be interesting to see how close DHS comes to achieving its goal in the next few weeks.
We’ve previously written a lot about DMARC, and despite the protocol having been in existence since 2011, it really did not enter into the spotlight as a mainstream email security solution until DHS jumped on the bandwagon late last year.
Perhaps the primary reason that the protocol had been relatively unknown to the masses is that many in the security community recognize that it serves only one purpose: to validate exact domains in order to prevent domain spoofing attacks. It is important to distinguish that DMARC does not protect against business email compromise (BEC) attack techniques other than exact domain spoofing. Thus, popular BEC attacks, such as display name spoofing and domain impersonation, which occur far more frequently than exact domain spoofs, are immune to DMARC controls.
As such, DMARC represents just one small piece to the very complex email security puzzle.
The Emergence of Brand Spoofing Propels Interest in DMARC
A complex type of email phishing, brand spoofing, is a technique used by cyber criminals to trick someone into performing a nefarious act. According to Verizon’s 2018 Data Breach Investigations Report (DBIR) phishing represents 98% of social incidents and 93% of breaches; with email the most common vector (96%.)
Email threats in general date back to the early 2000s; everyone with a mailbox has received such messages. But the proliferation of advanced brand spoofing attacks is relatively new and not readily detectable by traditional email security tools, such as secure email gateways (SEGs). This has left many public and private sector organizations not just vulnerable to brand spoofs, but also unable to implement the phishing protection needed for mitigation, leaving humans as the only difference between detonation or neutralization.
In response to the growth of brand spoofing as an attack technique, organizations have begun to adopt DMARC as an outbound layer of email security to help authenticate senders, although 99 percent of domains remain unprotected by DMARC. In addition to DHS, the UK’s National Cyber Security Centre (NCSC) has also been directed to adopt the protocol.
But the increased emphasis on DMARC has many in the cybersecurity community scratching their heads. That’s because DMARC does effectively nothing to help prevent, detect and respond to any type of social engineering techniques, such as spear-phishing, pretexting and whaling, nor does it protect against impersonation attacks, such as display name spoofing and cousin domains (e.g. domain look-alikes); all of which occur far more frequently than the expensive and time-consuming domain spoofing attacks that DMARC is designed to stop.
- Display Name Spoofing: Eyal Benishti, <email@example.com>
- Cousin Domain (Domain Look alike): Eyal Benishti, <firstname.lastname@example.org>
In this three-part blog series, we’ll dissect and explore DMARC; emphasize what it is and what it isn’t, highlight its benefits and debunk some of the exaggerations propagating as a result of increased awareness and savvy vendor messaging.
Understanding the Acronyms – An Initial Overview of DMARC, SPF & DKIM
DMARC builds on the existing Simple Mail Transfer Protocol (SPF) and DomainKeys Identified Message (DKIM) compliance.
Here’s what you need to know:
- SPF works at the Simple Mail Transfer Protocol (SMTP) level.
When a message is received, it performs a basic check against the Domain Name System (DNS) to determine if the sending Internet protocol (IP) address is authorized to send emails.
- DKIM verifies the domain and where the email was sent from, instead of simply checking the IP address.
A public key is published in the senders DNS record, and a private key is assigned to all outbound messages.
When received, the keys are checked to make sure that they match, confirming that the message was sent by the domain and that it has not been tampered with in transit.
Rules can be set for received messages that, should an SPF or DKIM check fail, the message is automatically marked as Spam and not passed through the gateway and to the mailbox.
DMARC builds on SPF and DKIM with the aim to protect both senders and receivers by preventing phishers from performing direct domain name spoofing, such as email@example.com
An organization can indicate that all its messages are protected by SPF and/or DKIM and stipulate what should happen should an authentication fail – for example forward to a ‘spam’ folder or reject the message outright. In addition, the organization can ask that the receiver report messages that fail the DMARC Check.
The underlying responsibility of DMARC is policy enforcement. Therefore, if SPF and DKIM are not properly implemented by both sender and receiver, then DMARC cannot be effective at limiting domain spoofing attacks. With this in mind, spoofs of agency to agency communications within the U.S. government might be reduced through DMARC adoption, but communications to any private sectors organizations not adhering to DMARC remain vulnerable to all types of email phishing attacks. Just ask former Hilary Clinton campaign John Podesta, who fell victim to a complex nation-state spear-phishing campaign that DMARC would not have been prepared to stop.
In part two of this blog series, we’ll look at the interdependencies of SPF, DKIM and DMARC, explore the limitations and vulnerabilities of each, and identify the unintended consequences of DMARC adoption.