The Security Skeptic

ICANN has released a January 2019 domain abuse report generated from the Domain Abuse Activity Reporting system (DAAR). DAAR is a system for studying and reporting on domain name registration and security threat (domain abuse) behavior across top-level domain (TLD) registries and registrars. While at ICANN, I was actively involved with DAAR from inception to early production, and I’m pleased that ICANN has begun monthly reporting.  

According to ICANN’s DAAR project page, one purpose of the project is to “provide the ICANN community with a reliable, persistent, and reproducible set of data from which security threat (abuse) analyses could be performed.” The January 2019 report provides a distribution of domains identified as security threats and a breakdown of security threats by class: phishing, botnet command-control, spam, and malware hosting. It does so for all new and legacy registries for which the DAAR project can collect TLD zone data. 

The report is promising in the sense that ICANN has finally begun reporting abuse, so we should celebrate this landmark publication.

The report is disappointing for several reasons.

Top-level Domain Reporting Tells a Partial Story

The report provides only summary statistics for the new and legacy Top-level Domains (TLDs), in pie-chart format, and thus provide the operational community with “findings” that are not actionable. Most importantly, the data tell a largely misleading story. To explain further, I’ve reproduced two pie charts from the report, side by side:

Together, these charts say the following:

Over one-half of the domains identified as security threats are
registered in one-eighth of the generic TLD name space.

This is an actionable conclusion.

Let’s assume that you wear a network or email administrator’s blocking policy hat. An important part of your role is to mitigate risk for your organization in the most straightforward and expeditious manner. Your pragmatic conclusion from this finding may well be…

Administrators can reduce an organization’s exposure to over one-half
of domain-related security threats by BLOCKING ALL new TLDs.

Administrators can implement this security policy at firewalls, mail servers, proxies, or DNS resolvers. It is an appropriate blocking rule based on the limited insights that ICANN’s report offers.

Conservative reporting in this case does more harm than good. By failing to be open and transparent about the high levels of abuse in new TLDs, ICANN actively frustrates efforts to promote Universal Acceptance of domain names and email addresses and calls future new TLD delegations into question.

An Opportunity Lost

Later in the report, ICANN could have helped administrators refine blocking policies, where it reports that

“of the 781,795 domains identified as security threats reported in
 341 new gTLDs:
• 35 percent were in the 5 most-exploited new gTLDs.
• 52 percent were in the 10 most-exploited new gTLDs.
• 88 percent were in the 25 most-exploited new gTLDs.
• 98 percent were in the 50 most-exploited new gTLDs.”

Administrators now know only 341 new TLDs have abuse domains reported. That’s less approximately one-third of the generic TLDs. They also now know that 98% of the new gTLD security threats are concentrated in 50 of new gTLDs, so they can refine the above rule:

Administrators can reduce an organization’s exposure to nearly one-half
of domain-related security threats by BLOCKING 50 new TLDs.

Except… ICANN does not publish the names of TLDs in the report.

With only the findings that ICANN’s report publishes, the most risk-averse blocking rule we can compose throws nearly the entire new TLD program under the bus.

The Truth is Out There

ICANN’s Context Document for the January 2019 report lists the reputation feeds that DAAR employs. The largest and most popularly used among these are the Spamhaus and SURBL data. With some work, you can make use of the statistics published at Spamhaus World’s Most Abused TLDs or SURBL’s Most Abused TLDs page to approximate the 10, 20, or 50 new TLDs that DAAR reports as concentrations of abuse domains. But you have to ask, “Why would an administrator go through this effort if the governance body for domain names is unwilling to commit itself to publishing actionable data or at least data that can inform its own policy community where the problems lie?”

Naming may be shaming, but it can also be enlightening. It’s been my experience that some TLD operators do not actively investigate abuse. Some TLDs have had high badness indexes for years.  Public disclosure might be the forcing function that instigates change in abuse mitigation.

To illustrate a use case for naming to enlighten, I’ve reproduced recent values for the Spamhaus “badness index” for the city TLDs delegated as new TLDs:

Using TLD data only, several Japanese cities appears to be loci of abuse. Like or not, many organizations use Spamhaus or SURBL data and may choose to block all of the domain names delegated from these TLDs.

But again, you’re only seeing part of the story. Ask any operational security investigator or reputation feed operator and they will tell you that Attackers and criminals are TLD agnostic or opportunistic. Sponsoring registrar data often reveals more about the loci of abuse than TLD data.

No Data on Registrar Abuse

For reasons that only ICANN can provide, the January 2019 report does not contain registrar data. Again, the Truth is Out There. Spamhaus also publishes a Top 10 Most Abused Registrars List, where you can observe that Asia-Pacific is a geo-locus of registrars with extraordinarily high badness indexes. If ICANN were to publish registrar data, administrators might be able to learn more about the interrelationships between TLDs and registrar abuse, and refine blocking policies accordingly; more importantly, ICANN community would have data that could influence future registrar accreditation agreement deliberations.  

Urge ICANN to Meet Commitments

The ICANN community harps about the need for ICANN organization to operate transparenly and accountably. The community, especially the contracted TLD and registrar parties, should be held to the same standards. Urge ICANN to publish data that identify the outliers. Urge ICANN, too, to publish registrar data. These data are essential if ICANN organization and community intend to meet the commitment to “provide the community with a reliable, persistent, and reproducible set of data from which security threat (abuse) analyses could be performed.”