Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Operations

6/22/2018
10:30 AM
E.J. Whaley
E.J. Whaley
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

White House Email Security Faux Pas?

The Executive Office of the President isn't complying with the DMARC protocol, but that has fewer implications than some headlines would suggest.

This year, US agencies rushed to implement Domain-based Message, Authentication, Reporting and Conformance (DMARC) protocols by a deadline mandated by the Department of Homeland Security. So, when the Global Cyber Alliance published research that 18 email domains managed by the Executive Office of the President were not using DMARC after that deadline had passed, the reaction was to lament the slow-moving agencies and criticize them for leaving their employees vulnerable to phishing attacks.

However, the fact that the federal government hasn't been implementing DMARC as it should be has far fewer implications for data privacy and the overall national security of the United States than the report and ensuing headlines would let on —  although that doesn't mean securing email shouldn't be taken seriously.

It's important to first understand DMARC's functionality within email security. Simply put, DMARC checks for alignment between the apparent sender of a message and its DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) headers, and then provides instructions to recipients on handling messages that display misalignment. This presupposes that recipients are checking DMARC records, and that senders are providing accurate information to check against. Although proper implementation and enforcement of DMARC can be helpful for preventing phishing attacks where your organization's brand is impersonated to consumers and business partners, it does very little to protect against inbound spear-phishing attacks.

The reason is largely due to what DMARC was designed to accomplish. DMARC effectively serves as a means for the recipient to verify that the sender is who they purport to be. But other than protecting one's own brand against such impersonation, the purported sending organization (in this case, the federal government) is not much further protected from phishing and social engineering attacks intended to steal credentials, personally identifiable information, or other information. There are many highly accessible avenues for these threat actors interested in targeting the government.

For example, many attacks do not impersonate someone at the target's organization with their exact email address. Spoofing attacks may instead employ subtle tricks that go unnoticed by an overworked government employee—whether by using a domain similar to a trusted vendor or partner or impersonating a citizen. Just think about the sheer number of people these organizations interact with and how many "I am Jane Q, please review my document to see how you can help me with my pet project" emails they receive on a daily basis.

This is not to entirely write off DMARC. But although it is true that it would be significantly more difficult for phishers to effectively spoof a domain if every organization implemented DMARC, that goal is not attainable in the short-term, nor would it completely safeguard email users.

Even in a world where proper DMARC implementation is scoped to only the federal agencies in question, the organizations would still be exposed to attacks impersonating potentially any organization that has not implemented DMARC and could even potentially still have exposure to attacks impersonating organizations that do have DMARC implemented. This also says nothing of attacks originating from Gmail, Yahoo, and other email service providers, as well as mail being sent from various other domains. DMARC is only as strong as the sum of its parts, and some of those parts are entirely outside of the purview of the federal government.

This is important as it relates to DMARC and organizations the federal government works with, because it's no secret that external partners have been a major source of data leaks from the government. This means that sensitive government information is only as secure as the security practices used by federal IT contractors. A recent study showed that 49 of the top 50 government IT contractors are also not using DMARC, which puts the government at risk for responding to emails purportedly from those contractors.

The disproportionate focus on DMARC camouflages the fact that there are other core risk factors the government should be addressing if they're serious about improving their email security. In fact, the sophisticated spoofing attacks DMARC is intended to stop represent a relatively small percentage of overall phishing attacks that rely on other, simpler (yet equally effective), vectors. 

Instead, every SMTP communication contains a number of data points: correlation of sending domain and return path, reply-to and IP address(es), sender relationship, and a variety of others that are available for analysis. Malicious or suspicious communications can and should be identified by these types of factors rather than relying entirely on the enforcement of DMARC.

The federal government is similar to many enterprises in that it faces challenges in both expertise and resources. The average business receives approximately 3,680 emails with threat characteristics per week – most of which are unaffected by DMARC protocols. In addition to DMARC, government agencies need to implement automated policies that reduce the organization's reliance on their employees having to proactively identify phishing techniques.

It's not surprising agencies are operating slowly to adopt new standards, but it is encouraging to see the government make email security a priority as it is the most prevalent, and arguably most effective, tool within the arsenal of cybercriminals. While the implementation of DMARC is important, its immediate implementation does little to either increase or decrease the government's susceptibility to cyber espionage. 

Related Content:

Why Cybercriminals Attack: A DARK READING VIRTUAL EVENT Wednesday, June 27. Industry experts will offer a range of information and insight on who the bad guys are – and why they might be targeting your enterprise. Go here for more information on this free event.

E.J. Whaley is a Solutions Engineer at GreatHorn. In his current role, he advises CISOs and other information security professionals on their email security strategy and architecture, particularly as they migrate to cloud-based email environments. Drawing on this experience, ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
6/24/2018 | 10:48:58 PM
Fed InfoSec
@EJ: Thanks for this sobering bit of temperance.

Of course, regardless of DMARC's importance, it's worth noting that the federal government has quite a poor track record indeed -- across multiple administrations on both sides of the aisle -- on keeping InfoSec and other IT solutions up to date (even where their own deadlines are concerned).
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-36289
PUBLISHED: 2021-05-12
Affected versions of Atlassian Jira Server and Data Center allow an unauthenticated user to enumerate users via an Information Disclosure vulnerability in the QueryComponentRendererValue!Default.jspa endpoint. The affected versions are before version 8.5.13, from version 8.6.0 before 8.13.5, and fro...
CVE-2021-32606
PUBLISHED: 2021-05-11
In the Linux kernel 5.11 through 5.12.2, isotp_setsockopt in net/can/isotp.c allows privilege escalation to root by leveraging a use-after-free. (This does not affect earlier versions that lack CAN ISOTP SF_BROADCAST support.)
CVE-2021-3504
PUBLISHED: 2021-05-11
A flaw was found in the hivex library in versions before 1.3.20. It is caused due to a lack of bounds check within the hivex_open function. An attacker could input a specially crafted Windows Registry (hive) file which would cause hivex to read memory beyond its normal bounds or cause the program to...
CVE-2021-20309
PUBLISHED: 2021-05-11
A flaw was found in ImageMagick in versions before 7.0.11 and before 6.9.12, where a division by zero in WaveImage() of MagickCore/visual-effects.c may trigger undefined behavior via a crafted image file submitted to an application using ImageMagick. The highest threat from this vulnerability is to ...
CVE-2021-20310
PUBLISHED: 2021-05-11
A flaw was found in ImageMagick in versions before 7.0.11, where a division by zero ConvertXYZToJzazbz() of MagickCore/colorspace.c may trigger undefined behavior via a crafted image file that is submitted by an attacker and processed by an application using ImageMagick. The highest threat from this...