DNS Abuse Responses: Difference between revisions
Christiane (talk | contribs) |
|||
(25 intermediate revisions by one other user not shown) | |||
Line 12: | Line 12: | ||
==Response Options== | ==Response Options== | ||
=== | ===Removal & Mitigation=== | ||
====Frameworks & Guides==== | |||
# The [https://www.icann.org/resources/pages/framework-registry-operator-respond-security-threats-2017-10-20-en Framework for Registry Operator to Respond to Security Threats] was jointly published between the Public Safety Working Group (a consortium of law enforcement agencies from around the world) and gTLD registries in 2017. It describes what different actions a registry operator can take when it has identified a security threat. It also delineates an implicit hierarchy of notifiers where, for instance, a particular law enforcement agency might have a particularized expertise and set expected communications between law enforcement and registries when a security threat has been identified. | |||
# The [https://dnsabuseframework.org/media/files/2020-05-29_DNSAbuseFramework.pdf Framework to Address Abuse] was developed by gTLD and ccTLD registry operators and registrars. It defines DNS Abuse and sets forth when a registry or registrar must take action, as well as those limited and egregious categories of website content abuse when a registry or registrar should take action. | |||
# The [https://www.internetjurisdiction.net/uploads/pdfs/Internet-Jurisdiction-Policy-Network-20-108-Guide-Technical-Abuse.pdf DNS Operators’ Decision-Making Guide to Address Technical Abuse] | |||
# The [https://www.rysg.info/wp-content/uploads/assets/Framework-on-Domain-Generating-Algorithms-DGAs-Associated-with-Malware-and-Botnets.pdfFramework on Domain Generating Algorithms Associated with Malware and Botnets] | |||
# [[SAC115]] | |||
# Terms of Service (ToS) notice-and-takedown regimes for use/content abuse | |||
# [[DNS Abuse Institute|DNS Abuse Institute Roadmap]] | |||
# [[Budapest Convention]] | |||
# The [[CISA#Continuous Diagnostics and Mitigation Program|CDM Program]] offers Automation in IT Security | |||
===Prevention=== | ===Prevention=== | ||
Line 30: | Line 31: | ||
* [https://www.centr.org/news/blog/nis2-costs.html NIS 2] | * [https://www.centr.org/news/blog/nis2-costs.html NIS 2] | ||
=== | ===Evidentiary Collection=== | ||
* [[FBI#IC3|IC3]] | * [[FBI#IC3|IC3]] | ||
* [[FBI#NCIJTF|NCIJTF]] | * [[FBI#NCIJTF|NCIJTF]] | ||
* [[DNSAI]] Compass | |||
* [[DAAR]] | |||
==Points of View== | ==Points of View== | ||
Every type of Internet user has worries over DNS Abuse and the responses to it. For instance, there is an ongoing multistakeholder debate over where to draw the line between technical abuse and content abuse. Moreover, there are technical limits on what each type of stakeholder can do to stop abuse. | Every type of Internet user has worries over DNS Abuse and the responses to it. For instance, there is an ongoing multistakeholder debate over where to draw the line between technical abuse and content abuse. Moreover, there are technical limits on what each type of stakeholder can do to stop abuse. | ||
=== | ===Academics=== | ||
[https://apo.org.au/sites/default/files/resource-files/2018-04/apo-nid142116.pdf | *[https://korlabs.io/ KOR Labs] | ||
# no single global entity is responsible for the regulation of all its aspects; | *[[COMAR]] | ||
# the [[Multistakeholder Model]] of governance and the distributed administration model allows disagreements and discrepancies; | *[https://apo.org.au/sites/default/files/resource-files/2018-04/apo-nid142116.pdf Some criminologists] feel the capacity to regulate DNS abuse is very limited because: | ||
# much of what happens on the Internet is beyond the jurisdictional reach of the criminal law of individual nations; and | *# no single global entity is responsible for the regulation of all its aspects; | ||
# regulation will continue to be reserved for the most egregious infringements. | *# the [[Multistakeholder Model]] of governance and the distributed administration model allows disagreements and discrepancies; | ||
*# much of what happens on the Internet is beyond the jurisdictional reach of the criminal law of individual nations; and | |||
*# regulation will continue to be reserved for the most egregious infringements. And so regulation will remain limited until a uniform set of policies to prevent abuse before it happens is enacted.<ref>[https://apo.org.au/sites/default/files/resource-files/2018-04/apo-nid142116.pdf Criminal misuse of the Domain Name System, Australian Institute of Criminology, 2018, pg 13]</ref> | |||
*[https://www.internetgovernance.org/category/cybersecurity/ The Internet Governance Project at GA Tech] focuses on privacy concerns and [[Internet Fragmentation]] in relation to IGO and governmental attempts to manage and mitigate [[cybercrime]] as well as content and technical abuse | |||
===Intergovernmental Organizations=== | ===Intergovernmental Organizations=== | ||
Line 53: | Line 58: | ||
* [https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/digital-markets-act-ensuring-fair-and-open-digital-markets_en the Digital Markets Act] | * [https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/digital-markets-act-ensuring-fair-and-open-digital-markets_en the Digital Markets Act] | ||
* [[Budapest Convention]] | * [[Budapest Convention]] | ||
* In 2022, the European Commission published a [[European Commission Study on DNS Abuse|study on DNS abuse]], the results of which included several fundamental recommendations: | |||
*# More DNS Metadata for identifying resources and their attribution to intermediaries | |||
*# Improve Contact Information and Abuse Reporting | |||
*# Improve Prevention, Detection, and Mitigation of DNS Abuse via maliciously registered domain names | |||
*# Improve Detection and Mitigation of compromised domain names | |||
*# Increase the Protection of the DNS Operation | |||
*# Raise DNS Abuse Awareness, Knowledge Building, and Mitigation Collaboration | |||
=====Pro-[[Data Privacy|privacy]]===== | =====Pro-[[Data Privacy|privacy]]===== | ||
Line 62: | Line 74: | ||
======U.S. Federal====== | ======U.S. Federal====== | ||
American cybersecurity legislation thus far has focused on standardizing and formalizing preventative measures.<ref>[https://www.congress.gov/bill/115th-congress/house-bill/3359 CISA Act of 2018]</ref> Congress passed | American cybersecurity legislation thus far has focused on standardizing and formalizing preventative measures.<ref>[https://www.congress.gov/bill/115th-congress/house-bill/3359 CISA Act of 2018]</ref> Congress passed | ||
* [[FISMA]] | * [[FISMA]]<ref>[https://www.gsa.gov/reference/reports/budget-performance/annual-reports/agency-financial-report-2012/managements-discussion-and-analysis/gsa-management-assurances/federal-information-security-management-act FISMA 2002, GSA]</ref><ref>[https://www.cisa.gov/federal-information-security-modernization-act FISMA 2014, CISA]</ref> | ||
* [[National Institute for Standards and Technology#Cybersecurity Framework|The Cybersecurity Enhancement Act of 2014 (CEA)]] | * [[National Institute for Standards and Technology#Cybersecurity Framework|The Cybersecurity Enhancement Act of 2014 (CEA)]] | ||
* [[Cybersecurity and Infrastructure Security Agency#History|The Cybersecurity and Infrastructure Security Agency Act of 2018]] | * [[Cybersecurity and Infrastructure Security Agency#History|The Cybersecurity and Infrastructure Security Agency Act of 2018]] | ||
Line 76: | Line 88: | ||
=====DOD===== | =====DOD===== | ||
* [[Cybersecurity Maturity Model Certification | * [[https://www.acq.osd.mil/cmmc/ Cybersecurity Maturity Model Certification] | ||
=====NIST===== | =====NIST===== | ||
Line 85: | Line 97: | ||
* [[NIST#Cybersecurity Framework|Cybersecurity Framework]] | * [[NIST#Cybersecurity Framework|Cybersecurity Framework]] | ||
=====Responding to State-Sponsored Cyberattacks===== | =====Responding to [[Threat Actor|State-Sponsored Cyberattacks]]===== | ||
======Sanctions/Condemnations====== | ======Sanctions/Condemnations====== | ||
* [[SolarWinds#Hacking Attack|SolarWinds Hacking Attack]]: In an executive order issued April 15, 2021, President Biden levied economic sanctions against Russian financial institutions, technology companies, and individuals that participated in this series of hacks that infiltrated nine federal agencies and over 100 private companies.<ref>[https://www.vox.com/recode/22385555/biden-solarwinds-hack-russia-sanctions Biden's SolarWinds Executive Order, Vox]</ref> | * [[SolarWinds#Hacking Attack|SolarWinds Hacking Attack]]: In an executive order issued on April 15, 2021, President Biden levied economic sanctions against Russian financial institutions, technology companies, and individuals that participated in this series of hacks that infiltrated nine federal agencies and over 100 private companies.<ref>[https://www.vox.com/recode/22385555/biden-solarwinds-hack-russia-sanctions Biden's SolarWinds Executive Order, Vox]</ref> | ||
* [[Microsoft#Email Systems Hacking Attack|Microsoft Email Systems Hacking Attack]]: On July 19, 2021, the Biden administration formally condemned but did not inflict sanctions against the Chinese government for working with hackers to | * [[Microsoft#Email Systems Hacking Attack|Microsoft Email Systems Hacking Attack]]: On July 19, 2021, the Biden administration formally condemned but did not inflict sanctions against the Chinese government for working with hackers to breach Microsoft email systems.<ref>[https://www.nytimes.com/2021/07/19/us/politics/microsoft-hacking-china-biden.html?action=click&module=Spotlight&pgtype=Homepage US Govt Accuses China of Hacking Microsoft, NY Times]</ref> | ||
===Technical Community=== | ===Technical Community=== | ||
Line 99: | Line 111: | ||
Parts of [[ICANN Organization]], [[ICANN Board|Board]], and [[ICANN Community|Community]] that are dedicated to resolving DNS Abuse issues: | Parts of [[ICANN Organization]], [[ICANN Board|Board]], and [[ICANN Community|Community]] that are dedicated to resolving DNS Abuse issues: | ||
:*[[GDD|GDD Accounts and Services]] and [[OCTO]] have come to an agreement with [[RySG]] to change the Base gTLD Registry Agreement to enable ICANN org to use existing data provided by registries for research purposes such as [[DAAR]].<ref>[https://www.icann.org/en/blogs/details/icann-makes-progress-toward-a-more-comprehensive-dns-security-threat-analysis-28-10-2021-en ICANN Makes Progress on DNS Security Threat Analysis, ICANN Blogs]</ref> | :*[[GDD|GDD Accounts and Services]] and [[OCTO]] have come to an agreement with [[RySG]] to change the Base gTLD Registry Agreement to enable ICANN org to use existing data provided by registries for research purposes such as [[DAAR]].<ref>[https://www.icann.org/en/blogs/details/icann-makes-progress-toward-a-more-comprehensive-dns-security-threat-analysis-28-10-2021-en ICANN Makes Progress on DNS Security Threat Analysis, ICANN Blogs]</ref> | ||
=====ICANN Organization===== | |||
:*[[Goran Marby]] formed the DNS Security Facilitation - Technical Study Group ([[DSFI-TSG]]) to investigate and determine what ICANN should and should not do based on the technical landscape about security threats and attack vectors, including the DNS, and its final report recommendations are now under review for implementation by the ICANN Org. | |||
:*[[OCTO]] monitors gTLD zone files and runs | :*[[OCTO]] monitors gTLD zone files and runs | ||
:*[[Contractual Compliance]] reprimands registrars or registries that do not maintain abuse contacts (or a webform) to receive abuse complaints or promptly investigate allegations of DNS Abuse in good faith and conducts audits. | |||
:*[[Contractual Compliance]] | |||
:*[[Domain Abuse Activity Reporting|DAAR]] | :*[[Domain Abuse Activity Reporting|DAAR]] | ||
:*[[Domain Name Security Threat Information Collection and Reporting Project]] (DNSTICR)<ref>[https://www.icann.org/en/announcements/details/adding-linguistic-diversity-to-the-domain-name-security-threat-information-collection-and-reporting-project-14-6-2021-en Adding Linguistic Diversity to the DNSTICR project, ICANN Announcements]</ref> <br/> | :*[[Domain Name Security Threat Information Collection and Reporting Project]] (DNSTICR)<ref>[https://www.icann.org/en/announcements/details/adding-linguistic-diversity-to-the-domain-name-security-threat-information-collection-and-reporting-project-14-6-2021-en Adding Linguistic Diversity to the DNSTICR project, ICANN Announcements]</ref> <br/> | ||
:*[[ICANN Organization]] has developed an internal [[DNS Security Threat Mitigation Program]],<ref>[https://www.icann.org/en/system/files/files/presentation-dns-security-threat-mitigation-program-update-22jul21-en.pdf DNS Security Threat Mitigation Program Update, ICANN Presentation, July 2021]</ref> which seeks to realize ICANN organization-wide coordination & collaboration on DNS abuse responses and, thus, acts as a hub for DAAR and DNSTICR, Compliance Audits and Abuse Complaints, Working with Contracted Parties, and Leading Educational Outreach. | :*[[ICANN Organization]] has developed an internal [[DNS Security Threat Mitigation Program]],<ref>[https://www.icann.org/en/system/files/files/presentation-dns-security-threat-mitigation-program-update-22jul21-en.pdf DNS Security Threat Mitigation Program Update, ICANN Presentation, July 2021]</ref> which seeks to realize ICANN organization-wide coordination & collaboration on DNS abuse responses and, thus, acts as a hub for DAAR and DNSTICR, Compliance Audits and Abuse Complaints, Working with Contracted Parties, and Leading Educational Outreach. | ||
=====ICANN Community===== | |||
======GNSO====== | |||
The GNSO Council formed a "Small Team on DNS Abuse," to which the [[DNS Abuse Institute|DNSAI]] sent a [https://dnsabuseinstitute.org/dnsai-response-gnso-small-team-dns-abuse/ letter] offering advice on how to respond to DNS Abuse in a way that is clearly within ICANN's remit.<ref>[https://gnso.icann.org/en/council/correspondence/2022 Responses to GNSO DNS Abuse Small Team Request for Input, GNSO Council Correspondence April 2022]</ref> [[Graeme Bunton]] explained that there is | |||
<blockquote>near universal agreement...that malicious registrations used for the distribution of malware, phishing, or the operation of botnets are appropriately and reasonably addressed by registrars and registries...which means there is an opportunity to focus on this issue at the outset and make meaningful progress on abuse. ICANN’s [[https://icannwiki.org/Policy_Development_Process_to_Review_the_Transfer_Policy|current work]] on [[Inter-Registrar Transfer Policy]] provides a model for an approach. I would propose three separate, sequential efforts, either narrowly scoped efforts or [[PDP]]s, for mitigating malicious registrations: | |||
* Malicious Registrations used for the distribution of Malware; | |||
* Malicious Registrations used for Phishing; | |||
* Malicious Registrations used for the operation of Botnet command and control systems. | |||
By restricting the work to malicious registrations...avoids actors outside of ICANN’s contractual regime, like hosting companies and content distribution networks and targets bad actors, and the impacts on legitimate registrants are correspondingly minimized.</blockquote> | |||
Bunton also hopes that taking the "micro-PDP" approach will result in short, simple, easy to implement requirements. | |||
:*The [[CPH]] has developed a [https://www.rysg.info/wp-content/uploads/archive/Final-CPH-Notifier-Framework-6-October-2021.pdf Trusted Notifier Framework] | :*The [[CPH]] has developed a [https://www.rysg.info/wp-content/uploads/archive/Final-CPH-Notifier-Framework-6-October-2021.pdf Trusted Notifier Framework] | ||
:**The [[RrSG]] offers guidance on [https://rrsg.org/wp-content/uploads/2021/10/Appeal-Mechanisms-following-DNS-Abuse-Mitigation-22-October-2021-.pdf Appeal Mechanisms for DNS Abuse Mitigation], [https://rrsg.org/wp-content/uploads/2021/10/RrSG-Approaches-to-BEC-Scams-22-Oct-2021.pdf managing BEC Scams], [https://rrsg.org/wp-content/uploads/2020/03/Guide-to-Registrar-Abuse-Reporting-v1.8.pdf Registrar Abuse Reporting], and [https://rrsg.org/wp-content/uploads/2020/10/CPH-Minimum-Required-Information-for-a-Whois-Data-Requests.docx.pdf Minimum requirements for WHOIS data requests]. | :**The [[RrSG]] offers guidance on [https://rrsg.org/wp-content/uploads/2021/10/Appeal-Mechanisms-following-DNS-Abuse-Mitigation-22-October-2021-.pdf Appeal Mechanisms for DNS Abuse Mitigation], [https://rrsg.org/wp-content/uploads/2021/10/RrSG-Approaches-to-BEC-Scams-22-Oct-2021.pdf managing BEC Scams], [https://rrsg.org/wp-content/uploads/2020/03/Guide-to-Registrar-Abuse-Reporting-v1.8.pdf Registrar Abuse Reporting], and [https://rrsg.org/wp-content/uploads/2020/10/CPH-Minimum-Required-Information-for-a-Whois-Data-Requests.docx.pdf Minimum requirements for WHOIS data requests]. | ||
:*The [[BC]] is limited to removing content and sharing evidence with [[registries]] to suspend or take down sites. | :*The [[BC]] is limited to removing content and sharing evidence with [[registries]] to suspend or take down sites. The BC also seeks to: | ||
:* | :**require TLD registries, registrars, privacy or proxy providers and resellers to verify the accuracy of domain registration (WHOIS) data; | ||
:*The [[ | :**encourage these same entities to develop and deploy new tools to identify domain names that could potentially infringe on their rights; and | ||
:**encourage these same entities to offer services allowing [[IP|Intellectual Property]] rights holders to preventively block infringing domain name registrations.<ref>[https://domainnamewire.com/2022/03/30/business-constituency-weighs-in-on-dns-abuse/ BC weighs in on DNS Abuse, Domain Name Wire]</ref> | |||
:*The [[IPC]] is concerned with the year-on-year growth of online fraud recently due in large part to the Covid pandemic and with trust in the Internet | |||
:*The Registrar Stakeholder Group (RrSG) offers the [https://acidtool.com/ acidtool] free of charge to anyone trying to identify the appropriate party to report abuse to. This tool relies on public data provided by third parties and is provided for informational purposes only. | |||
======GAC====== | |||
:*The [[GAC]] wants to help law enforcement and regulatory bodies gain access to the contact information of victims as well as bad actors | :*The [[GAC]] wants to help law enforcement and regulatory bodies gain access to the contact information of victims as well as bad actors | ||
:**The [[PSWG] (within GAC) developed the Framework on DGAs Associated with Malware and Botnets in collaboration with the [[RySG]]<ref>[https://www.rysg.info/wp-content/uploads/assets/Framework-on-Domain-Generating-Algorithms-DGAs-Associated-with-Malware-and-Botnets.pdf DGAs, Malware, and Botnets Framework, RySG]</ref> | :**The [[PSWG] (within GAC) developed the Framework on DGAs Associated with Malware and Botnets in collaboration with the [[RySG]]<ref>[https://www.rysg.info/wp-content/uploads/assets/Framework-on-Domain-Generating-Algorithms-DGAs-Associated-with-Malware-and-Botnets.pdf DGAs, Malware, and Botnets Framework, RySG]</ref> | ||
======ccNSO====== | |||
:*The [[ccNSO]] has begun exploring its role in mitigating DNS Abuse, as it has limited remit but many attacks happen via [[ccTLD]]s | :*The [[ccNSO]] has begun exploring its role in mitigating DNS Abuse, as it has limited remit but many attacks happen via [[ccTLD]]s | ||
:*The [[ | ======SSAC====== | ||
:*The [[SSAC]] has published several documents on DNS Abuse measurement and mitigation | |||
======ALAC====== | |||
:*At [[ICANN 74]], the [[ALAC]] held a session discussing end users' perspective and the role of [[RALO]]s in responding to DNS Abuse | |||
====IGF==== | ====IGF==== | ||
==== | |||
====NetBeacon Institute==== | |||
The [[NetBeacon Institute]] (formerly DNS Abuse Institute) is focused on helping simplify and enhance DNS Abuse reporting while helping the Internet community better understand, measure, and, ultimately, mitigate abuse across the DNS by providing free resources and tools, establishing best practices, funding DNS research, and sharing data in an effort to create a safer Internet for all.<ref>https://netbeacon.org/</ref> | |||
* [[NetBeacon]] | |||
===Private Sector=== | ===Private Sector=== | ||
====Cybersecurity Providers==== | ====Cybersecurity Providers==== | ||
The [[:Category:Cybersecurity Providers|cybersecurity]] industry is booming and is trying various [[cybersecurity|approaches]] to protect networks and supply chains from data breaches and [[ransomware]] attacks. For instance, [[Prevailion]]'s strategy is to hack the hackers, while [[McAfee]] remains the revenue leader by continuing to churn out cybersecurity software.<ref>[https://www.thesoftwarereport.com/the-top-25-cybersecurity-companies-of-2020/ Top 25 Cybersecurity Companies of 2020, The Software Report]</ref> | The [[:Category:Cybersecurity Providers|cybersecurity]] industry is booming and is trying various [[cybersecurity|approaches]] to protect networks and supply chains from data breaches and [[ransomware]] attacks. For instance, [[Prevailion]]'s strategy is to hack the hackers, while [[McAfee]] remains the revenue leader by continuing to churn out cybersecurity software.<ref>[https://www.thesoftwarereport.com/the-top-25-cybersecurity-companies-of-2020/ Top 25 Cybersecurity Companies of 2020, The Software Report]</ref> | ||
====Registries and | * [[CleanDNS]] | ||
= | * [[PhishLabs]] | ||
Sebastian Felix Schwemer's 2020 analysis of 30 European ccTLD terms of services (ToS) showed several responses to use/content-related domain name abuse, including no related reservations, reactions to severe cases, and proactive screening.<ref>[https://policyreview.info/articles/analysis/regulation-abusive-activity-content-study-registries-terms-service Schwemer, The regulation of abusive activity and content: a study of registries’ terms of service]</ref> Some ToSes do ''not'' contractually reserve to take down a domain name due to use or content, while others ''do'' reserve the right to take down a domain name but only in severe situations. Others have established "takedown regimes" akin to that of site operators, hosting providers, and registrants (per Article 14 of the [https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32000L0031 E-Commerce Directive]. [[EURid]], [[.be]], and [[SIDN]] have begun to screen abusive use by crawling content, using fuzzy hashes, or HTML structural similarity analysis; they are also working on early warning systems. Schwemer found that only 1/3 of ccTLD ToSes contained content/use provisions and that the discretion for registrars to take down domain names via a morality clause was higher than it was for ccTLD registries. This analysis also revealed the emergence of ccTLD registries' use of data validation in a new way. Registries have noticed a correlation between domain names engaging in unlawful activities and the provision of poor registration data. Because ToSes can reserve the right to terminate registrations based on wrong or inaccurate information, some ccTLD registries are using this term as a workaround.<ref>[https://policyreview.info/articles/analysis/regulation-abusive-activity-content-study-registries-terms-service Schwemer, The regulation of abusive activity and content: a study of registries’ terms of service]</ref> | * [[KnowBe4]] | ||
* [[Cofense]] | |||
* [[Cyber Risk Aware]] | |||
* [[KnowBe4]] (MediaPRO) | |||
* [[SANS Institute]] | |||
* [[Inspired eLearning]] | |||
====[[Registries]] and [[Registrar]]s==== | |||
* In March 2022, [[TWNIC]] and [[DotAsia]] signed an MOU of bilateral collaboration of information exchange and mutual recognition as [[Trusted Notifier]]s. When either TWNIC or DotAsia receives a notification via the Fast Track mechanism that they created, it will be able to immediately take appropriate actions under the domain name registration agreement to reduce the [[cybercrime]] impact.<ref>[https://www.digitimes.com/news/a20220329PR200.html?chid=9 TWNIC and DotAsia establish fast track mechanism to fight DNS abuse, Digitimes]</ref> | |||
* Sebastian Felix Schwemer's 2020 analysis of 30 European ccTLD terms of services (ToS) showed several responses to use/content-related domain name abuse, including no related reservations, reactions to severe cases, and proactive screening.<ref>[https://policyreview.info/articles/analysis/regulation-abusive-activity-content-study-registries-terms-service Schwemer, The regulation of abusive activity and content: a study of registries’ terms of service]</ref> Some ToSes do ''not'' contractually reserve to take down a domain name due to use or content, while others ''do'' reserve the right to take down a domain name but only in severe situations. Others have established "takedown regimes" akin to that of site operators, hosting providers, and registrants (per Article 14 of the [https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32000L0031 E-Commerce Directive]. [[EURid]], [[.be]], and [[SIDN]] have begun to screen abusive use by crawling content, using fuzzy hashes, or HTML structural similarity analysis; they are also working on early warning systems. Schwemer found that only 1/3 of ccTLD ToSes contained content/use provisions and that the discretion for registrars to take down domain names via a morality clause was higher than it was for ccTLD registries. This analysis also revealed the emergence of ccTLD registries' use of data validation in a new way. Registries have noticed a correlation between domain names engaging in unlawful activities and the provision of poor registration data. Because ToSes can reserve the right to terminate registrations based on wrong or inaccurate information, some ccTLD registries are using this term as a workaround.<ref>[https://policyreview.info/articles/analysis/regulation-abusive-activity-content-study-registries-terms-service Schwemer, The regulation of abusive activity and content: a study of registries’ terms of service]</ref> | |||
=====[[DNS Abuse Framework]]===== | =====[[DNS Abuse Framework]]===== | ||
This framework was developed by registries and registrars. The framework discourages a registry or registrar from taking action against domains, except in certain types of Website Content Abuse: | This framework was developed by registries and registrars. The framework discourages a registry or registrar from taking action against domains, except in certain types of Website Content Abuse: | ||
Line 152: | Line 194: | ||
* [http://www.surbl.org/ SURBL], and | * [http://www.surbl.org/ SURBL], and | ||
* [https://www.threatstop.com/ ThreatStop]. | * [https://www.threatstop.com/ ThreatStop]. | ||
====End Users==== | ====End Users==== | ||
End users, even those who work in the DNS industry, need help managing DNS Abuse mainly because of the timeless effectiveness of [[Social Engineering Attacks]]. For instance, at the end of 2020, [[GoDaddy]] notoriously tested its workers to see if they would share sensitive information after clicking on dubious links from a spoofed email.<ref> [http://domainincite.com/26143-godaddy-pranks-employees-with-insensitive-phishing-test GoDaddy Pranks Employees, DomainIncite]</ref> | End users, even those who work in the DNS industry, need help managing DNS Abuse mainly because of the timeless effectiveness of [[Social Engineering Attacks]]. For instance, at the end of 2020, [[GoDaddy]] notoriously tested its workers to see if they would share sensitive information after clicking on dubious links from a spoofed email.<ref> [http://domainincite.com/26143-godaddy-pranks-employees-with-insensitive-phishing-test GoDaddy Pranks Employees, DomainIncite]</ref> | ||
==References== | ==References== |
Latest revision as of 17:54, 6 June 2024
DNS Abuse Responses are the various tools, methods, collaboration, and philosophies spawning from DNS Abuse itself.
Overview[edit | edit source]
There are four time-related categories of responses to DNS Abuse:
- reactionary detection and removal of sources of abuse (necessarily after the fact),
- cotemporal efforts to mitigate the amount and likelihood of abuse or its impact,
- future-focused work on stopping abuse before it can happen, and
- ongoing allowance of abuse for ideological or jurisdictional reasons.
Response Options[edit | edit source]
Removal & Mitigation[edit | edit source]
Frameworks & Guides[edit | edit source]
- The Framework for Registry Operator to Respond to Security Threats was jointly published between the Public Safety Working Group (a consortium of law enforcement agencies from around the world) and gTLD registries in 2017. It describes what different actions a registry operator can take when it has identified a security threat. It also delineates an implicit hierarchy of notifiers where, for instance, a particular law enforcement agency might have a particularized expertise and set expected communications between law enforcement and registries when a security threat has been identified.
- The Framework to Address Abuse was developed by gTLD and ccTLD registry operators and registrars. It defines DNS Abuse and sets forth when a registry or registrar must take action, as well as those limited and egregious categories of website content abuse when a registry or registrar should take action.
- The DNS Operators’ Decision-Making Guide to Address Technical Abuse
- The on Domain Generating Algorithms Associated with Malware and Botnets
- SAC115
- Terms of Service (ToS) notice-and-takedown regimes for use/content abuse
- DNS Abuse Institute Roadmap
- Budapest Convention
- The CDM Program offers Automation in IT Security
Prevention[edit | edit source]
Evidentiary Collection[edit | edit source]
Points of View[edit | edit source]
Every type of Internet user has worries over DNS Abuse and the responses to it. For instance, there is an ongoing multistakeholder debate over where to draw the line between technical abuse and content abuse. Moreover, there are technical limits on what each type of stakeholder can do to stop abuse.
Academics[edit | edit source]
- KOR Labs
- COMAR
- Some criminologists feel the capacity to regulate DNS abuse is very limited because:
- no single global entity is responsible for the regulation of all its aspects;
- the Multistakeholder Model of governance and the distributed administration model allows disagreements and discrepancies;
- much of what happens on the Internet is beyond the jurisdictional reach of the criminal law of individual nations; and
- regulation will continue to be reserved for the most egregious infringements. And so regulation will remain limited until a uniform set of policies to prevent abuse before it happens is enacted.[1]
- The Internet Governance Project at GA Tech focuses on privacy concerns and Internet Fragmentation in relation to IGO and governmental attempts to manage and mitigate cybercrime as well as content and technical abuse
Intergovernmental Organizations[edit | edit source]
IGO responses generally treat DNS Abuse as a facet of Cybercrime.
Objectives[edit | edit source]
Pro-Mitigation[edit | edit source]
- E-Commerce Directive
- The Digital Services Act (DSA)
- the Digital Markets Act
- Budapest Convention
- In 2022, the European Commission published a study on DNS abuse, the results of which included several fundamental recommendations:
- More DNS Metadata for identifying resources and their attribution to intermediaries
- Improve Contact Information and Abuse Reporting
- Improve Prevention, Detection, and Mitigation of DNS Abuse via maliciously registered domain names
- Improve Detection and Mitigation of compromised domain names
- Increase the Protection of the DNS Operation
- Raise DNS Abuse Awareness, Knowledge Building, and Mitigation Collaboration
Pro-privacy[edit | edit source]
Government Responses[edit | edit source]
Government responses tend to focus on what can be adjudicated; include content abuse, such as child pornography; and outline how and when electronic evidence can be collected.
Domestic Legislation[edit | edit source]
U.S. Federal[edit | edit source]
American cybersecurity legislation thus far has focused on standardizing and formalizing preventative measures.[2] Congress passed
- FISMA[3][4]
- The Cybersecurity Enhancement Act of 2014 (CEA)
- The Cybersecurity and Infrastructure Security Agency Act of 2018
State[edit | edit source]
CISA[edit | edit source]
The CISA seeks to prevent future cyberattacks on critical infrastructure. Its CDM Program is a dynamic approach to fortifying the cybersecurity of civilian government networks and systems. Its Stop Ransomware Website is a one-stop shop for preparing for ransomware attacks among other forms of malware.
FBI[edit | edit source]
The FBI leads the National Cyber Investigative Joint Task Force (NCIJTF) and runs the public-facing Internet Crime Complaint Center (IC3) to collect cybercrime and electronic evidence of other types of crimes.
DOD[edit | edit source]
NIST[edit | edit source]
- NCCoE
- NICE
Responding to State-Sponsored Cyberattacks[edit | edit source]
Sanctions/Condemnations[edit | edit source]
- SolarWinds Hacking Attack: In an executive order issued on April 15, 2021, President Biden levied economic sanctions against Russian financial institutions, technology companies, and individuals that participated in this series of hacks that infiltrated nine federal agencies and over 100 private companies.[5]
- Microsoft Email Systems Hacking Attack: On July 19, 2021, the Biden administration formally condemned but did not inflict sanctions against the Chinese government for working with hackers to breach Microsoft email systems.[6]
Technical Community[edit | edit source]
Internet Governance Organizations[edit | edit source]
ICANN[edit | edit source]
ICANN has been steadfast in its focus on technical DNS abuse, what it calls "DNS security threats," and avoidance of policymaking around content abuse. ICANN has two missions related to DNS Abuse: maintaining the SSR of the DNS and engendering trust in the domain name industry. ICANN's determination of the org's definition for DNS Abuse is based on the work product of GAC and the base gTLD Registry Agreement. Thus, ICANN considers DNS security threats to be limited to attacks involving phishing, malware, botnet command and control, pharming, and spam as a vector.[7] As recently as ICANN 71, the ICANN board was criticized by members of the ALAC, the BC, and other Internet Governance bodies for not doing enough to steward contracted parties and non-contracted parties toward involvement in reducing abuse. However, ICANN and SSAC, in particular, have begun pointing to SAC115 and DAAR as evidence of their work on addressing DNS abuse. Parts of ICANN Organization, Board, and Community that are dedicated to resolving DNS Abuse issues:
- GDD Accounts and Services and OCTO have come to an agreement with RySG to change the Base gTLD Registry Agreement to enable ICANN org to use existing data provided by registries for research purposes such as DAAR.[8]
ICANN Organization[edit | edit source]
- Goran Marby formed the DNS Security Facilitation - Technical Study Group (DSFI-TSG) to investigate and determine what ICANN should and should not do based on the technical landscape about security threats and attack vectors, including the DNS, and its final report recommendations are now under review for implementation by the ICANN Org.
- OCTO monitors gTLD zone files and runs
- Contractual Compliance reprimands registrars or registries that do not maintain abuse contacts (or a webform) to receive abuse complaints or promptly investigate allegations of DNS Abuse in good faith and conducts audits.
- DAAR
- Domain Name Security Threat Information Collection and Reporting Project (DNSTICR)[9]
- ICANN Organization has developed an internal DNS Security Threat Mitigation Program,[10] which seeks to realize ICANN organization-wide coordination & collaboration on DNS abuse responses and, thus, acts as a hub for DAAR and DNSTICR, Compliance Audits and Abuse Complaints, Working with Contracted Parties, and Leading Educational Outreach.
ICANN Community[edit | edit source]
GNSO[edit | edit source]
The GNSO Council formed a "Small Team on DNS Abuse," to which the DNSAI sent a letter offering advice on how to respond to DNS Abuse in a way that is clearly within ICANN's remit.[11] Graeme Bunton explained that there is
near universal agreement...that malicious registrations used for the distribution of malware, phishing, or the operation of botnets are appropriately and reasonably addressed by registrars and registries...which means there is an opportunity to focus on this issue at the outset and make meaningful progress on abuse. ICANN’s [work] on Inter-Registrar Transfer Policy provides a model for an approach. I would propose three separate, sequential efforts, either narrowly scoped efforts or PDPs, for mitigating malicious registrations:
- Malicious Registrations used for the distribution of Malware;
- Malicious Registrations used for Phishing;
- Malicious Registrations used for the operation of Botnet command and control systems.
By restricting the work to malicious registrations...avoids actors outside of ICANN’s contractual regime, like hosting companies and content distribution networks and targets bad actors, and the impacts on legitimate registrants are correspondingly minimized.
Bunton also hopes that taking the "micro-PDP" approach will result in short, simple, easy to implement requirements.
- The CPH has developed a Trusted Notifier Framework
- The RrSG offers guidance on Appeal Mechanisms for DNS Abuse Mitigation, managing BEC Scams, Registrar Abuse Reporting, and Minimum requirements for WHOIS data requests.
- The BC is limited to removing content and sharing evidence with registries to suspend or take down sites. The BC also seeks to:
- require TLD registries, registrars, privacy or proxy providers and resellers to verify the accuracy of domain registration (WHOIS) data;
- encourage these same entities to develop and deploy new tools to identify domain names that could potentially infringe on their rights; and
- encourage these same entities to offer services allowing Intellectual Property rights holders to preventively block infringing domain name registrations.[12]
- The IPC is concerned with the year-on-year growth of online fraud recently due in large part to the Covid pandemic and with trust in the Internet
- The Registrar Stakeholder Group (RrSG) offers the acidtool free of charge to anyone trying to identify the appropriate party to report abuse to. This tool relies on public data provided by third parties and is provided for informational purposes only.
- The CPH has developed a Trusted Notifier Framework
GAC[edit | edit source]
ccNSO[edit | edit source]
SSAC[edit | edit source]
- The SSAC has published several documents on DNS Abuse measurement and mitigation
ALAC[edit | edit source]
IGF[edit | edit source]
NetBeacon Institute[edit | edit source]
The NetBeacon Institute (formerly DNS Abuse Institute) is focused on helping simplify and enhance DNS Abuse reporting while helping the Internet community better understand, measure, and, ultimately, mitigate abuse across the DNS by providing free resources and tools, establishing best practices, funding DNS research, and sharing data in an effort to create a safer Internet for all.[14]
Private Sector[edit | edit source]
Cybersecurity Providers[edit | edit source]
The cybersecurity industry is booming and is trying various approaches to protect networks and supply chains from data breaches and ransomware attacks. For instance, Prevailion's strategy is to hack the hackers, while McAfee remains the revenue leader by continuing to churn out cybersecurity software.[15]
- CleanDNS
- PhishLabs
- KnowBe4
- Cofense
- Cyber Risk Aware
- KnowBe4 (MediaPRO)
- SANS Institute
- Inspired eLearning
Registries and Registrars[edit | edit source]
- In March 2022, TWNIC and DotAsia signed an MOU of bilateral collaboration of information exchange and mutual recognition as Trusted Notifiers. When either TWNIC or DotAsia receives a notification via the Fast Track mechanism that they created, it will be able to immediately take appropriate actions under the domain name registration agreement to reduce the cybercrime impact.[16]
- Sebastian Felix Schwemer's 2020 analysis of 30 European ccTLD terms of services (ToS) showed several responses to use/content-related domain name abuse, including no related reservations, reactions to severe cases, and proactive screening.[17] Some ToSes do not contractually reserve to take down a domain name due to use or content, while others do reserve the right to take down a domain name but only in severe situations. Others have established "takedown regimes" akin to that of site operators, hosting providers, and registrants (per Article 14 of the E-Commerce Directive. EURid, .be, and SIDN have begun to screen abusive use by crawling content, using fuzzy hashes, or HTML structural similarity analysis; they are also working on early warning systems. Schwemer found that only 1/3 of ccTLD ToSes contained content/use provisions and that the discretion for registrars to take down domain names via a morality clause was higher than it was for ccTLD registries. This analysis also revealed the emergence of ccTLD registries' use of data validation in a new way. Registries have noticed a correlation between domain names engaging in unlawful activities and the provision of poor registration data. Because ToSes can reserve the right to terminate registrations based on wrong or inaccurate information, some ccTLD registries are using this term as a workaround.[18]
DNS Abuse Framework[edit | edit source]
This framework was developed by registries and registrars. The framework discourages a registry or registrar from taking action against domains, except in certain types of Website Content Abuse:
- child sexual abuse materials,
- illegal distribution of opioids online,
- human trafficking, or
- specific, credible incitements to violence
- Registrars and registry operators can
- include their own acceptable use policies or terms of use to set forth provisions to cover Website Content Abuses,
- contract Trusted Notifiers to monitor content and report abuse
- Registry Operators
- Have to determine whether the domain in question was maliciously registered or if the domain has been compromised. Registries cannot generally directly remediate a compromised domain; instead, it is up to the sponsoring registrar.[19] Conversely, if a domain has been maliciously registered, the registry has six options:
- Suspend the domain (most common)
- Refer to the sponsoring registrar
- Lock the domain
- Redirect a domain by changing the name servers
- Transfer the domain
- Delete the domain (generally considered an ineffective and extreme response)
- If a registry encounters unregistered domain names resulting from an automatic Domain Generation Algorithm (DGA), the operator can:
- Reserve the domains or
- create the domains in order to suspend or sinkhole the domains for victim identification
Reputation Industry[edit | edit source]
Commercial service providers, researchers, and non-profit organizations operate the most prominent RBLs that detect or receive notifications of security threats. Some key players include:
- Spamhaus,
- Cisco’s Talos email reputation system,
- the Anti-Phishing Working Group's RBL,
- Google Safe Browsing,
- SURBL, and
- ThreatStop.
End Users[edit | edit source]
End users, even those who work in the DNS industry, need help managing DNS Abuse mainly because of the timeless effectiveness of Social Engineering Attacks. For instance, at the end of 2020, GoDaddy notoriously tested its workers to see if they would share sensitive information after clicking on dubious links from a spoofed email.[20]
References[edit | edit source]
- ↑ Criminal misuse of the Domain Name System, Australian Institute of Criminology, 2018, pg 13
- ↑ CISA Act of 2018
- ↑ FISMA 2002, GSA
- ↑ FISMA 2014, CISA
- ↑ Biden's SolarWinds Executive Order, Vox
- ↑ US Govt Accuses China of Hacking Microsoft, NY Times
- ↑ Update on DNS Security Threats, ICANN Org
- ↑ ICANN Makes Progress on DNS Security Threat Analysis, ICANN Blogs
- ↑ Adding Linguistic Diversity to the DNSTICR project, ICANN Announcements
- ↑ DNS Security Threat Mitigation Program Update, ICANN Presentation, July 2021
- ↑ Responses to GNSO DNS Abuse Small Team Request for Input, GNSO Council Correspondence April 2022
- ↑ BC weighs in on DNS Abuse, Domain Name Wire
- ↑ DGAs, Malware, and Botnets Framework, RySG
- ↑ https://netbeacon.org/
- ↑ Top 25 Cybersecurity Companies of 2020, The Software Report
- ↑ TWNIC and DotAsia establish fast track mechanism to fight DNS abuse, Digitimes
- ↑ Schwemer, The regulation of abusive activity and content: a study of registries’ terms of service
- ↑ Schwemer, The regulation of abusive activity and content: a study of registries’ terms of service
- ↑ RySG recommended options for registries
- ↑ GoDaddy Pranks Employees, DomainIncite