Go here to help fight against coronavirus abuse

A coalition of over 1,000 security experts, domain name providers and others have got together to help coordinate efforts to combat abusive coronavirus-related domains.

A workspace on the collaboration platform Slack has been growing steadily since it was created a week ago, enabling technology professionals to exchange information about the alarming number of sites currently trying to take advantage of the pandemic.

You can join the channel via this link. Thanks to Theo Geurts of RealtimeRegister.com for passing it along.

The collection of chat rooms appears to have been created by Joshua Saxe, chief scientist at security software firm Sophos, March 19. There are currently 1,104 members.

There’s a channel devoted to malicious domains, which is being used to share statistical data and lists of bad and good coronavirus-related domains, among other things.

Across the workspace, a broad cross-section of interested parties is represented. Current members appear to come from security companies, governments, law enforcement, registries, registrars, ICANN, healthcare providers, and others.

It seems like a pretty good way for the technical members of the domain name industry to keep track of what’s going on during the current crisis, potentially helping them to put a stop to threats using domains they manage as they emerge.

As it releases free download, DomainTools says 68,000 dangerous coronavirus domains have been registered

More than 68,000 coronavirus-related domain names have been registered so far in 2020, according to data released by DomainTools today.

The domain intelligence services company has started publishing a list of these domains, updated daily, for free on its web site. You have to submit your email address to get it.

The download comprises a CSV file with three columns: domain, reg date, and Domain Risk Score.

This final field is based on DomainTools’ in-house algorithms that estimate how likely domains are likely to be used in nefarious activities, based on criteria including the domain’s connection to other, known-bad domains.

Only domains with a score of 70 or above out of 100 — indicating they will likely be used for activities such as phishing, malware or spam — will be included on the list, the company said.

The list will be updated daily at 0000 UTC.

You can find out more and obtain today’s list here.

Hacking claims resurface as .hotel losers force ICANN to lawyer up again

The fight over .hotel has been escalated, with four unsuccessful applicants for the gTLD whacking ICANN with a second Independent Review Process appeal.
The complaint resurrects old claims that a former lead on the successful application, now belonging to Afilias, stole trade secrets from competing applicants via a glitched ICANN web site.
It also revives allegations that ICANN improperly colluded with the consultant hired to carry out reviews of “community” applications and then whitewashed an “independent” investigation into the same.
The four companies filing the complaint are new gTLD portfolio applicants MMX (Minds + Machines), Radix, Fegistry, and Domain Venture Partners (what we used to call Famous Four).
The IRP was filed November 18 and published by ICANN December 16, but I did not spot it until more recently. Sorry.
There’s a lot of back-story to the complaint, and it’s been a few years since I got into any depth on this topic, so I’m going to get into a loooong, repetitive, soporific, borderline unreadable recap here.
This post could quite easily be subtitled “How ICANN takes a decade to decide a gTLD’s fate”.
There were seven applicants for .hotel back in 2012, but only one of them purported to represent the “hotel community”. That applicant, HOTEL Top Level Domain, was mostly owned by Afilias.
HTLD had managed to get letters of support from a large number of hotel chains and trade groups, to create a semblance of a community that could help it win a Community Priority Evaluation, enabling it to skip to the finish line and avoid a potentially costly auction against its rival applicants.
CPEs were carried out by the Economist Intelligence Unit, an independent ICANN contractor.
Surprisingly to some (including yours truly), back in 2014 it actually managed to win its CPE, scoring 15 out of the 16 available points, surpassing the 14-point winning threshold and consigning its competing bidders’ applications to the scrap heap.
There would be no auction, and no redistribution of wealth between applicants that customarily follows a new gTLD auction.
Naturally, the remaining applicants were not happy about this, and started to fight back.
The first port of call was a Request for Reconsideration, which all six losers filed jointly in June 2014. It accused the EIU of failing to follow proper procedure when it evaluated the HTLD community application.
That RfR was rejected by ICANN, so a request for information under ICANN’s Documentary Information Disclosure Policy followed. The losing applicants reckoned the EIU evaluator had screwed up, perhaps due to poor training, and they wanted to see all the communications between ICANN and the EIU panel.
The DIDP was also rejected by ICANN on commercial confidentiality grounds, so the group of six filed another RfR, asking for the DIDP to be reconsidered.
Guess what? That got rejected too.
So the applicants then filed an IRP case, known as Despegar v ICANN, in March 2015. Despegar is one of the .hotel applicants, and the only one that directly plays in the hotel reservation space already.
The IRP claimed that ICANN shirked its duties by failing to properly oversee and verify the work of the EIU, failing to ensure the CPE criteria were being consistently applied between contention sets, and failing in its transparency obligations by failing to hand over information related to the CPE process.
While this IRP was in its very early stages, it emerged that one of HTLD’s principals and owners, Dirk Krischenowski, had accessed confidential information about the other applicants via an ICANN web site.
ICANN had misconfigured its applicant portal in such a way that any user could very access any attachment on any application belonging to any applicant. This meant sensitive corporate information, such as worst-case-scenario financial planning, was easily viewable via a simple search for over a year.
Krischenowski appears to have been the only person to have noticed this glitch and used it in earnest. ICANN told applicants in May 2015 that he had carried out 60 searches and accessed 200 records using the glitch.
Krischenowski has always denied any wrongdoing and told DI in 2016 that he had always “relied on the proper functioning of ICANN’s technical infrastructure while working with ICANN’s CSC portal.”
The applicants filed another DIDP, but no additional information about the data glitch was forthcoming.
When the first IRP concluded, in February 2016, ICANN prevailed, but the three-person IRP panel expressed concern that neither the EIU nor ICANN had any process in place to ensure that community evaluations carried out by different evaluators were consistently applying the CPE rules.
The IRP panel also expressed concern about the “very serious issues” raised by the ICANN portal glitch and Krischenowski’s data access.
But the loss of the IRP did not stop the six losing applicants from ploughing on. Their lawyer wrote to ICANN in March 2016 to denounce Krischenowski’s actions as “criminal acts” amounting to “HTLD stealing trade secrets of competing applicants”, and as such HTLD’s application for .hotel should be thrown out.
Again, to the best of my knowledge, Krischenowski has never been charged with, let alone convicted of, any criminal act.
Afilias wrote to ICANN not many weeks later, April 2016, to say that it had bought out Krischenowski’s 48.8% stake in HTLD and that he was no longer involved in the company or its .hotel application.
And ICANN’s board of directors decided in August 2016 that Krischenowski may well have accessed documents he was not supposed to, but that it would have happened after the .hotel CPE had been concluded, so there was no real advantage to HTLD.
A second, parallel battle against ICANN by an unrelated new gTLD applicant had been unfolding over the same period.
A company called Dot Registry had failed in its CPE efforts for the strings .llc, .llp and .inc, and in 2014 had filed its own IRP against ICANN, claiming that the EIU had “bungled” the community evaluations, applying “inconsistent” scoring criteria and “harassing” its supporters.
In July 2016, almost two years later, the IRP panel in that case ruled that Dot Registry had prevailed, and launched a withering attack on the transparency and fairness of the ICANN process.
The panel found that, far from being independent, the EIU had actually incorporated notes from ICANN staff into its CPE evaluations during drafting.
It was as a result of this IRP decision, and the ICANN board’s decision that Krischenowski’s actions could not have benefited HTLD, that the losing .hotel applicants filed yet another RfR.
This one lasted two and a half years before being resolved, because in the meantime ICANN launched a review of the CPE process.
It hired a company called FTI Consulting to dig through EIU and ICANN documentation, including thousands of emails that passed between the two, to see if there was any evidence of impropriety. It covered .hotel, .music, .gay and other gTLD contention sets, all of which were put on hold while FTI did its work.
FTI eventually concluded, at the end of 2017, that there was “no evidence that ICANN organization had any undue influence on the CPE reports or engaged in any impropriety in the CPE process”, which affected applicants promptly dismissed as a “whitewash”.
They began lobbying for more information, unsuccessfully, and hit ICANN with yet another RfR in April 2018. Guess what? That one was rejected too.
The .hotel applicants then entered into a Cooperative Engagement Process — basically pre-IRP talks — from October 2018 to November 2019, before this latest IRP was filed.
It’s tempting to characterize it as a bit of a fishing expedition, albeit not a baseless one — any allegations of ICANN’s wrongdoing pertaining the .hotel CPE are dwarfed by the applicants’ outraged claims that ICANN appears to be covering up both its interactions with the EIU and its probe of the Krischenowski incident, partly out of embarrassment.
The claimants want ICANN to be forced to hand over documentation refused them on previous occasions, relating to: “ICANN subversion of the .HOTEL CPE and first IRP (Despegar), ICANN subversion of FTI’s CPE Process Review, ICANN subversion of investigation into HTLD theft of trade secrets, and ICANN allowing a domain registry conglomerate to takeover the ‘community-based’ applicant HTLD.”
“The falsely ‘independent’ CPE processes were in fact subverted by ICANN in violation of Bylaws, HTLD stole trade secrets from at least one competing applicant, and Afilias is not a representative of the purported community,” the IRP states.
“HTLD’s application should be denied, or at least its purported Community Priority relinquished, as a consequence not only for HTLD’s spying on its competitors’ secret information, but also because HTLD is no longer the same company that applied for the .HOTEL TLD. It is now just a registry conglomerate with no ties to the purported, contrived ‘Community’ that it claims entitled to serve,” it goes on.
ICANN is yet to file its response to the complaint.
Whether the IRP will be successful is anyone’s guess, but what’s beyond doubt is that if it runs its course it’s going to add at least a year, probably closer to two, to the delay that .hotel has been languishing under since the applications were filed in 2012.
Potentially lengthening the duration of the case is the claimants’ demand that ICANN “appoint and train” a “Standing Panel” of at least seven IRP panelists from which each three-person IRP panel would be selected.
The standing panel is something that’s been talked about in ICANN’s bylaws for at least six or seven years, but ICANN has never quite got around to creating it.
ICANN pinged the community for comments on how it should go about creating this panel last year, but doesn’t seemed to have provided a progress report for the last nine months.
The .hotel applicants do not appear to be in any hurry to get this issue resolved. The goal is clearly to force the contention set to auction, which presumably could happen at Afilias’ unilateral whim. Time-to-market is only a relevant consideration for the winner.
With .hotel, and Afilias’ lawsuit attempting to block the .web sale to Verisign, the last round of new gTLD program, it seems, is going to take at least a decade from beginning to end.

AlpNames died months ago. Why is it still the “most-abused” registrar?

Despite going out of business, being terminated by ICANN, and losing all its domains several months ago, defunct AlpNames is still being listed as the world’s most-abused registrar by a leading spam-fighting organization.
SpamHaus currently ranks the Gibraltar-based company as #1 on its list of the “The 10 Most Abused Domain Registrars”, saying 98.7% of its domains are being used to send spam.
But AlpNames customers and regular DI readers will recall that AlpNames mysteriously went titsup in March, then got terminated by ICANN, then had its entire customer base migrated over to CentralNic in April.
So what’s this about?

I asked SpamHaus earlier this week, and it turns out that Whois query throttling is to blame.
It seems SpamHaus only pings Whois to update the registrar associated with a specific domain when the domain expires, or the name servers change, or where it’s a new registration with an unknown registrar.
I gather that when CentralNic took over AlpNames’ customer base, it did so with all the original name server information intact.
So, SpamHaus’ database still associates the domains with AlpNames even though it’s been out of business for the better part of a year.
A SpamHaus spokesperson said:

This is a very unusual situation, as a huge majority of the domains that contribute to the Top 10 list in question are created, abused, and burnt quickly; meaning a change of registrar is exceptionally rare. However, in the case of these particular domains registered with AlpNames we can only assume that the sheer volume of unused domains was too high for the owner to use in one single hit.

The actual number of “AlpNames” domains rated as spammy by SpamHaus is pretty low — 1,976 of the 2,002 domains it saw were rated as “bad”.
GMO, at #4 on the list, had over 40,000 “bad” domains, but a lower percentage given the larger number of total domains seen.

Web.com got pwned

Web.com, which owns top 20 registrars Network Solutions and Register.com, got itself and millions of its customers hacked a few months ago.
The company disclosed last week that malicious hackers broke into its network in late August, making off with customer account information.
The attack was not discovered until October 16.
The compromised data included “name, address, phone numbers, email address and information about the services that we offer to a given account holder”, Web.com said.
“We encrypt credit card numbers and no credit card data was compromised as a result of this incident,” it added.
Customers are being told to change their password next time they log in to their services.
It’s not clear how many registrants were affected. The NetSol accreditation has over seven million domains in the gTLDs alone, while Register.com has almost 1.8 million.
Web.com said it brought on a private security firm to investigate the attack, and informed US law enforcement.

Emoji domains get a 😟 after broad study

Domain names containing emojis are a security risk and not recommended, according to a pretty comprehensive review by an ICANN study group.
The Country-Code Names Supporting Organization has delivered the results of its 12-person, 18-month Emoji Study Group, which was tasked with looking into the problems emoji domains can cause, review current policy, and talk to ccTLD registries that currently permit emoji domains.
The ESG didn’t have a lot of power, and its recommendations are basically an exercise in can-kicking, but it’s easily the most comprehensive overview of the issues surrounding emoji domains that I’ve ever come across.
It’s 30 pages long, and you can read it here (pdf).
Emojis are currently banned in gTLDs, where ICANN has to approve new Unicode tables before they can be used by registries at the second level, under its internationalized domain name policy, IDNA 2008.
But ccTLDs, which are not contracted with ICANN, have a lot more flexibility. There are 15 ccTLDs — almost all representing small islands or low-penetration African nations — that currently permit emoji domains, the ESG found.
That’s about 6% of Latin-script ccTLDs out there today. These TLDs are .az, .cf, .fm, .je, .ga, .ge, .gg, .gq, .ml, .st, .to, .tk, .uz, .vu, and .ws.
Five of them, including .tk, are run by notorious freebie registry Freenom, but perhaps the best-known is .ws, where major brands such as Budweiser and Coca-Cola have run marketing campaigns in the past.
The main problem with emojis is the potential for confusing similarity, and the ESG report does a pretty good job of enumerating the ways confusability can arise. Take its comparison of multiple applications’ version of the exact same “grinning face” emoji, for example:

If you saw a domain containing one of those in marketing on one platform, would you be able to confidently navigate to the site on another? I doubt I would.
There’s also variations in how registrars handle emojis on their storefronts, the report found. On some you can search with an emoji, on others you’ll need to type out the xn-- prefixed Punycode translation longhand.
In terms of recommendations, the ESG basically just asked ICANN to keep an eye on the situation, to come to a better definition of what an emoji actually is, and to reach out for information to the ccTLDs accepting emojis, which apparently haven’t been keen on opening up so far.
Despite the lack of closure, it’s a pretty good read if you’re interested in this kind of thing.

Spam is not our problem, major domain firms say ahead of ICANN 66

Eleven of the largest domain name registries and registrars have denied that spam is something they should have to deal with, unless it’s used to proliferate other types of abuse such as phishing or malware.
In a newly published “Framework to Address Abuse” (pdf), the companies attempt to define the term “DNS abuse” narrowly to capture only five (arguably only four and a half) specific types of online threat.
That abuse comprises malware, phishing, botnets, pharming and spam.
The companies agree that these are activities which registrars and registries “must” act upon.
But the document notes that not all spam is its responsibility, stating:

While Spam alone is not DNS Abuse, we include it in the five key forms of DNS Abuse when it is used as a delivery mechanism for the other four forms of DNS Abuse. In other words, generic unsolicited e-mail alone does not constitute DNS Abuse, but it would constitute DNS Abuse if that e-mail is part of a phishing scheme.

In other words, registrars and registries should not feel responsible for the billions of spams sent every day using their domains, unless the spam runs further malware, phishing, pharming or botnet abuse.
The signatories of the framework are Public Interest Registry, GoDaddy, Donuts, Tucows, Amazon Registry Services, Blacknight, Afilias, Name.com, Amazon Registrar, Neustar, and Nominet UK.
It may seem like they’ve presented a surprisingly narrow definition, but it’s in line with what current ICANN contracts dictate.
Neither the standard Registry Agreement nor Registrar Accreditation Agreement mention spam at all. Six years ago, ICANN specifically said that spam is “outside of ICANN’s scope and authority”.
Under the RA, registries have to oblige their registrars to ban registrants from “distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law”.
They also have to maintain statistical reports on the amount of “pharming, phishing, malware, and botnets” in their zones, and provide those reports to ICANN upon demand. A recent audit found that 5% of registries, mainly dot-brands, were not doing this.
However, ICANN’s Domain Abuse Activity Reporting system, an effort to provide some transparency into how gTLDs are being abused, does in fact track spam. It does not track pharming, which is a fairly obscure and little-used form of DNS attack.
The DAAR report for September shows that spam constituted 73% of all tracked abuse.
The ICANN board of directors today identified DAAR as one of a few dozen priorities for the coming year.
Similarly, the cross-community working group known as the CCT Review Team, which was tasked with looking into how the new gTLD program has impacted competition and consumer trust, had harsh words for spam-friendly registries, and provided a definition of “DNS Security Abuse” that specifically included “high volume spam”.
The review recommended that ICANN introduce more measures to force contracted parties to deal with this type of abuse. This could include incentives for registries to clean up their zones and abuse volume thresholds that would automatically trigger compliance actions.
The new framework document comes in the context of an ongoing debate within the ICANN community about what “DNS abuse” is.
Two partners at Interisle, a security consultancy that often works for ICANN, recently guest-posted on DI to say that this term has become meaningless and should be abandoned in favor of “security threat”.
They argued that the definition should include not only spam, but also stuff like IP infringement, election interference, and terrorism.
But the main threat to contracted parties probably comes from the Governmental Advisory Committee, backed by law enforcement, which is pushing for stronger rules covering abusive content.
During a webinar last week, the US Federal Trade Commission, the FBI, and Europol argued that registries and registrars should be obliged to do more to combat abuse, specifically including spam.
“Whether or not you call it phishing or spam or whether it has a malware payload or not, ultimately it’s all email, and email remains the most common tool of cybercriminals to ensnare their victims, and that’s why we in law enforcement care about the domains used to send emails,” said Gabriel Andrews of the FBI’s Cyber Initiative Resource Fusion Unit, on the call.
Registries and registrars countered, using the same language found in the new framework, that generic spam is a content issue, and outside of their remit.
The two sides are set to clash again at ICANN’s annual general meeting in Montreal next month, in a November 6 face-to-face session.
While 11 entities signed the new framework, it’s arguably only nine companies. Name.com is owned by Donuts and both Amazon firms obviously have the same parent.
But it does include the two largest registrars, and registries responsible for running several hundred commercial gTLDs, dot-brands and ccTLDs.
While none of the signatories of the framework have a particular reputation for being spam-friendly, other companies in the industry — particularly some of the newest and cheapest new gTLDs — tend to attract spammers like flies to a turd.
Some of the signatories are perhaps surprising, given their past or ongoing behavior to tackle content-based abuse in their own zones.
Nominet, notably, takes down tens of thousands of domains ever year based on little more than police assurances that the domains are being used to sell counterfeit merchandise or infringe copyright.
The .uk registry also preemptively suspends domains based on algorithms that guess whether they’re likely to be seen as encouraging sexual violence or could be used in phishing attacks.
Donuts also has a trusted notifier relationship with the movie and music industries that has seen it take down dozens of names being used for mass copyright infringement.
PIR has previous endorsed, then unendorsed, the principal of a “UDRP for copyright”, a method of giving Big Content a way of going through due process to have domains taken or suspended.
Outside the spam issue, while the new registry-registrar framework says that registries and registrars should not get involved in matters related to web site content, it also says they nevertheless “should” (as opposed, one assumes based on the jargon usually found in internet standards, to “must”) suspend domains when they’re being used to distribute:

(1) child sexual abuse materials (“CSAM”); (2) illegal distribution of opioids online; (3) human trafficking; and (4) specific and credible incitements to violence.

These are exceptions because they constitute “the physical and often irreversible threat to human life”, the framework says.
Ultimately, this all boils down to a religious debate about where the line is drawn between “DNS” and “content”, it seems to me.
The contracted parties draw the line at threats to human life, whereas others want action on other forms of abuse largely because registries and registrars are in the best position to help.

Crunch time, again, for Whois access policy

Talks seeking to craft a new policy for allowing access to private Whois data have hit another nodal point, with the community now pressuring the ICANN board of directors for action.
The Whois working group has more or less decided that a centralized model for data access, with ICANN perhaps acting as a clearinghouse, is the best way forward, but it needs to know whether ICANN is prepared to take on this role and all the potential liabilities that come with it.
Acronym time! The group is known as the Whois EPDP WG (for Expedited Policy Development Process Working Group) and it’s come up with a rough Whois access framework it’s decided to call the Standardized System for Access and Disclosure (SSAD).
Its goal is to figure out a way to minimize the harms that Europe’s General Data Protection Regulation allegedly caused to law enforcement, IP owners, security researchers and others by hiding basically all gTLD registration data by default.
The SSAD, which is intended to be as automated as possible, is the working group’s proposed way of handling this.
The “hamburger model” the EPDP has come up with sees registries/registrars and data requestors as the top and bottom of the sandwich (or vice versa) with some yet-to-be-decided organizational patty filling acting as an interface between the two.
The patty would handle access control for the data requests and be responsible for credentialing requestors. It could either be ICANN acting alone, or ICANN coordinating several different interface bodies (the likes of WIPO have been suggested).
Should the burger be made only of mashed-up cow eyelids, or should it incorporate the eyelids of other species too? That’s now the question that ICANN’s board is essentially being posed.
Since this “phase two” work kicked off, it’s taken about five months, 24 two-hour teleconferences, and a three-day face-to-face meeting to get to this still pretty raw, uncooked state.
The problem the working group is facing now is that everyone wants ICANN to play a hands-on role in running a centralized SSAD system, but it has little idea just how much ICANN is prepared to get involved.
The cost of running such a system aside, legislation such as GDPR allows for pretty hefty fines in cases of privacy breaches, so there’s potentially a big liability ask of notoriously risk-averse ICANN.
So the WG has written to ICANN’s board of directors in an attempt to get a firm answer one way or the other.
If the board decided ICANN should steer clear, the WG may have to go back more or less to square one and focus on adapting the current Whois model, which is distributed among registrars and registries, for the post-GDPR world.
How much risk and responsibility ICANN is willing to absorb could also dictate which specific SSAD models the WG pursues in future.
There’s also a view that, with no clarity from ICANN, the chance of the WG reaching consensus is unlikely.
This will be a hot topic at ICANN 66 in Montreal next month.
Expect the Governmental Advisory Committee, which had asked for “considerable and demonstrable progress, if not completion” of the access model by Montreal, to be disappointed.

Sixty gTLD registries not monitoring security threats

Roughly 5% of gTLD registry operators have been doing no abuse monitoring, despite contractual requirements to do so, a recent ICANN audit has found.
ICANN checked with 1,207 registries — basically all gTLDs — between November 2018 and June, and found about 60 of them “were not performing any security threat monitoring, despite having domains registered in their gTLDs”.
A further 180 (15%) were not doing security checks, but had no registered domains, usually because they were unused dot-brands. ICANN told these companies that they had to do the checks anyway, to remain in compliance.
In all cases, ICANN said, the registries remediated their oversights during the audit to bring their gTLDs back into compliance.
ICANN does not name the non-compliant registries in the summary of the audit’s results, published yesterday (pdf).
Registries under the 2012 new gTLD base registry agreement all have to agree to this:

Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. Registry Operator will maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request.

It’s possible to keep tabs on abuse by monitoring domain blocklists such as SpamHaus, SURBL and PhishTank. Some such lists are freely available, others carry hefty licensing fees.
ICANN itself monitors these lists through its Domain Abuse Activity Reporting project, so it’s able to work out the differences between the levels of abuse registries report and what the empirical data suggests.
Registries typically either use these lists via in-house tools or license products provided by vendors such as Neustar, RegistryOffice, Knipp, CSC, DOTZON, Afnic, AusCERT, Shadowserver, Telefonica, Secure Domain Foundation and Netcraft, ICANN said.
Perhaps unsurprisingly, there’s a bit of disagreement between ICANN and some registries about how the somewhat vague obligations quote above are be interpreted.
ICANN thinks registries should have to provide information about specific domains that were identified as abusive and what remediation actions were taken, but some registries think they only have to provide aggregate statistical data (which would be my read of the language).
The contracts also don’t specify how frequently registries much carry out security reviews.
Of the 80% (965) of registries already in compliance, 80% (772) were doing daily abuse monitoring. Others were doing it weekly, monthly, or even quarterly, ICANN found, all of which appear to be in line with contractual requirements.

ICANN must do more to fight internet security threats [Guest Post]

ICANN and its contracted parties need to do more to tackle security threats, write Dave Piscitello and Lyman Chapin of Interisle Consulting.
The ICANN Registry and Registrar constituencies insist that ICANN’s role with respect to DNS abuse is limited by its Mission “to ensure the stable and secure operation of the internet’s unique identifier systems”, therefore limiting ICANN’s remit to abuse of the identifier systems themselves, and specifically excluding from the remit any harms that arise from the content to which the identifiers point.
In their view, if the harm arises not from the identifier, but from the thing identified, it is outside of ICANN’s remit.
This convenient formulation relieves ICANN and its constituencies of responsibility for the way in which identifiers are used to inflict harm on internet users. However convenient it may be, it is fundamentally wrong.
ICANN’s obligation to operate “for the benefit of the Internet community as a whole” (see Bylaws, “Commitments”) demands that its remit extend broadly to how a domain name (or other Internet identifier) is misused to point to or lure a user or application to content that is harmful, or to host content that is harmful.
Harmful content itself is not ICANN’s concern; the way in which internet identifiers are used to weaponize harmful content most certainly is.
Rather than confront these obligations, however, ICANN is conducting a distracting debate about the kinds of events that should be described as “DNS abuse”. This is tedious and pointless; the persistent overloading of the term “abuse” has rendered it meaningless, ensuring that any attempt to reach consensus on a definition will fail.
ICANN should stop using the term “DNS abuse” and instead use the term “security threat”.
The ICANN Domain Abuse Activity Reporting project and the Governmental Advisory Committee (GAC) use this term, which is also a term of reference for new TLD program obligations (Spec 11) and related reporting activities. It is also widely used in the operational and cybersecurity communities.
Most importantly, the GAC and the DAAR project currently identify and seek to measure an initial set of security threats that are a subset of a larger set of threats that are recognized as criminal acts in jurisdictions in which a majority of domain names are registered.
ICANN should acknowledge the GAC’s reassertion in its Hyderabad Communique that the set of security threats identified in its Beijing correspondence to the ICANN Board were not an exhaustive list but merely examples. The GAC smartly recognized that the threat landscape is constantly evolving.
ICANN should not attempt to artificially narrow the scope of the term “security threat” by crafting its own definition.
It should instead make use of an existing internationally recognized criminal justice treaty. The Council of Europe’s Convention on Cybercrime is a criminal justice treaty that ICANN could use as a reference for identifying security threats that the Treaty recognizes as criminal acts.
The Convention is recognized by countries in which a sufficiently large percentage domain names are registered that it can serve the community and Internet users more effectively and fairly than any definition that ICANN might concoct.
ICANN should also acknowledge that the set of threats that fall within its remit must include all security events (“realized security threats”) in which a domain name is used during the execution of an attack for purposes of deception, for infringement on copyrights, for attacks that threaten democracies, or for operation of criminal infrastructures that are operated for the purpose of launching attacks or facilitating criminal (often felony) acts.
What is that remit?
ICANN policy and contracts must ensure that contracted parties (registrars and registries) collaborate with public and private sector authorities to disrupt or mitigate:

• illegal interception or computer-related forgery,
• attacks against computer systems or devices,
• illegal access, data interference, or system interference,
• infringement of intellectual property and related rights,
• violation of laws to ensure fair and free elections or undermine democracies, and
• child abuse and human trafficking.

We note that the Convention on Cybercrime identifies or provides Guidance Notes for these most prevalently executed attacks or criminal acts:

• Spam,
• Fraud. The forms of fraud that use domain names in criminal messaging include, business email compromise, advance fee fraud, phishing or other identity thefts.
• Botnet operation,
• DDoS Attacks: in particular, redirection and amplification attacks that exploit the DNS
• Identity theft and phishing in relation to fraud,
• Attacks against critical infrastructures,
• Malware,
• Terrorism, and,
• Election interference.

In all these cases, the misuse of internet identifiers to pursue the attack or criminal activity is squarely within ICANN’s remit.
Registries or registrars should be contractually obliged to take actions that are necessary to mitigate these misuses, including suspension of name resolution, termination of domain name registrations, “unfiltered and unmasked” reporting of security threat activity for both registries and registrars, and publication or disclosure of information that is relevant to mitigating misuses or disrupting cyberattacks.
No one is asking ICANN to be the Internet Police.
The “ask” is to create policy and contractual obligations to ensure that registries and registrars collaborate in a timely and uniform manner. Simply put, the “ask” is to oblige all of the parties to play on the same team and to adhere to the same rules.
This is unachievable in the current self-regulating environment, in which a relatively small number of outlier registries and registrars are the persistent loci of extraordinary percentages of domain names associated with cyberattacks or cybercrimes and the current contracts offer no provisions to suspend or terminate their operations.
This is a guest editorial written by Dave Piscitello and Lyman Chapin, of security consultancy Interisle Consulting Group. Interisle has been an occasional ICANN security contractor, and Piscitello until last year was employed as vice president of security and ICT coordination on ICANN staff. The views expressed in this piece do not necessary reflect DI’s own.