ICANN Spec 11.3b explained

The annual compliance audit by ICANN has kicked off, with this year's focus squarely on Registries.

Customers of ours who use iQ Abuse Manager and our Managed Abuse service will be familiar with the reporting that's required but we thought an explainer might be useful to our wider audience.

What is it?

The New gTLD Registry Agreement contains a section (Section 3(b)) of Specification 11 (typically referred to as "Spec 11 (3)(b)"), which states:

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.

What does that mean?

In short, it means that Registry Operators must keep records of any security threats they have identified in their zone and provide these to ICANN on request. The security threats referenced in Spec 11 (3)(b) include, among others:

• pharming
• phishing
• malware
• botnets
• and other types of security threats.

How often do I need to do this?

Registry Operators (RO) should conduct their analyses as frequently as needed, but no less frequently than every month. ICANN recommends analysing daily, to allow for the prompt detection of any security threats on newly created domain names.

Why do we need to do this?

Purely from a legal standpoint, because you have to.

Specification 11, covers what ICANN terms " Public Interest Commitments". Section 3, which includes clause (b), states amongst others that :

"Registry Operator agrees to perform the following specific public interest commitments, which commitments shall be enforceable by ICANN and through the Public Interest Commitment Dispute Resolution Process established by ICANN.... "

But of course, it's more than that. Like the cities and towns we live in, we all want and need the Internet to be as safe as possible. This requirement is part of the bigger picture of everyone working together to ensure this. A "civic duty", so to speak.

We would not tolerate someone undertaking criminal acts on our friends and family in everyday life. So it shouldn't be any different online.

How should the technical analysis be conducted?

This Advisory from ICANN notes that

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.

It further explains that

A 'technical analysis' may constitute steps taken to identify Security Threats in a TLD(s) by:

• reviewing data feeds; and/or

• conducting automated analyses that provide data at least equivalent to that provided by Domain Reputation Service Providers.

As long as it's undertaken within the suggested frequency and for the aforementioned security threats, in essence, they are leaving the technical implementation up to the RO. Whether it's manual, automated or a combination of both.

What is the format of the report?

Statistical reports most commonly include the following:

• Number of domain names reviewed during analysis;
• List of domain names with potential threats;
• Type of threat identified, such as malware and botnets;
• Type of actions taken in response to threats, such as suspension;
• Status (open/pending/closed) of threat and statistics on actions taken;
• Additional details on threats such as IP address, geographic location, and registrant information; and
• Trends and alerts.

As alluded to at the start, this year's audit is focused on Registries. But Registrars are not excluded from this process. If you'd like to understand the methodology behind the audit process, ICANN has an explainer here.

‍