Changes

DNS Abuse Responses (view source)

Revision as of 19:42, 24 October 2022

12,788 bytes added , 1 year ago

→‎ICANN Community

Line 16: Line 16:

* [[DNS Abuse Framework]]

* Terms of Service (ToS) notice-and-takedown regimes for use/content abuse

−

* [[Framework on Domain Generating Algorithms Associated with Malware and Botnets]]

+

* [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]

===Cotemporal Mitigation===

Line 26: Line 26:

* [[DNSSEC]]

* [[MITRE ATT&CK]]

−

* [[Cybersecurity Maturity Model Certification]]

+

* [https://www.acq.osd.mil/cmmc/ Cybersecurity Maturity Model Certification]

* [[Cyber Kill Chain]]

+

* [https://www.centr.org/news/blog/nis2-costs.html NIS 2]

===Intentional Inaction & Evidentiary Collection===

Line 36: Line 37:

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.

−

===~~Social Scientists~~===

+

===Academics===

−

[https://apo.org.au/sites/default/files/resource-files/2018-04/apo-nid142116.pdf Criminologists] feel the capacity to regulate DNS abuse is very limited because:

+

:*[[COMAR]]

+

:*[https://apo.org.au/sites/default/files/resource-files/2018-04/apo-nid142116.pdf 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;

Line 43: Line 45:

# regulation will continue to be reserved for the most egregious infringements.

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===

Line 52: Line 55:

* [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]]

+

======EC DNS Abuse Study Recommendations======

+

The [[EC]] conducted a study on DNS abuse, which generated the following recommendations for all actors in the DNS ecosystem.<ref>[https://op.europa.eu/en/publication-detail/-/publication/d9804355-7f22-11ec-8c40-01aa75ed71a1/language-en/format-PDF/source-search Study on DNS Abuse Technical Report Appendix 1, Directorate-General for Communications Networks, Content and Technology (European Commission), Fasano Paulovics Società tra Avvocati, Grenoble INP-UGA Institute of Engineering 2022-01-31]</ref>

+

{| class="wikitable"

+

! A. Better DNS Metadata for identifying resources and their attribution to intermediaries !! B. Contact Information and Abuse Reporting !! C. Improved Prevention, Detection, and Mitigation of DNS Abuse via maliciously registered domain names !! D. Improved Detection and Mitigation of (compromised) domain names distributing malicious content !! E. Better Protection of the DNS Operation and Preventing Abuse of the DNS !! F. DNS Abuse Awareness, Knowledge Building, and Mitigation Collaboration

+

|-

+

| 1. ccTLDs registries should provide a scalable, unified way of accessing complete registration data in compliance with data protection laws, using [[RDAP]] || 3. Registrants' and domain name administrators' email addresses that are not visible in the public WHOIS should be displayed as anonymized email addresses || 8. TLD registries, registrars, and resellers should verify domain registration data [[accuracy]]; implement harmonized Know Your Business Customer procedures or eID authentication in accordance with the eIDAS Regulation, using cross-checks in other publicly available and reputed databases || 15. the abuse rates of hosting providers should always be monitored by independent researchers with institutions and regulatory bodies; abuse rates should not exceed predetermined thresholds; incentive structures should be studied to induce hosting providers || 17. ccTLDs should be required to sign TLD zone files with [[DNSSEC]] and facilitate its deployment according to good practices || 24. EU ccTLDs should harmonize practices and adopt good practices

+

|-

+

| 2. ccTLDs registries should publish DNS zone file data through DNS zone transfer or a system similar to the Centralized Zone Data Service || 4. domain name administrators should maintain RFC 2142 specific email aliases for domain names (e.g., abuse, hostmaster, webmaster) and an email in the DNS SOA record || 9. registries should develop/improve search tools or surveillance services to enable third parties to identify names that could potentially infringe their rights || 16. operators of free services should employ advanced prevention and remediation solutions to curb abuses of subdomain names and hosting infrastructure; should proactively detect suspicious domain names containing keywords of the most frequently targeted brands and names; and work with heavily attacked companies and develop [[Trusted Notifier]] programs || 18. registrants should have easy access to DNSSEC signing within the TLD; registries should require their registrars to support DNSSEC signing for registrants || 25. DNS service providers should collaborate with EU and Member States’ institutions, law enforcement authorities, and [[Trusted Notifier]]s or trusted flaggers; formalize informal collaborations

+

|-

+

| || 5. A standardized (and potentially centralized) system for access to registration data (WHOIS data) should be set up, identifying the minimum information necessary to process disclosure requests. The reaction time to such requests shall be clearly defined || 10. registries should offer, directly or through the registrars/resellers, services allowing intellectual property rights holders to block infringing domain name registrations || || 19. registries could offer discounts for DNSSEC-signed domain names || 26. consumers and IPR holders should be made aware of measures to tackle DNS abuse.

+

|-

+

| || 6. The study also recommends setting up a standardized (and potentially centralized) system for abuse reporting, identifying the minimum information necessary to process such reports. The receipt of abuse reports is to be acknowledged. The reaction time to such reports shall be clearly defined and the abuse reporter should be provided with information on the actions taken. The DNS service providers shall provide for an appeal proceeding against their decisions to a third neutral party || 11. registries and registrars should use predictive algorithms to prevent abusive registrations || || 20. Internet Service Providers operating DNS resolvers should configure DNSSEC validation to protect end users from cache poisoning attacks || 27. all intermediaries and stakeholders should share knowledge and do capacity building in the fight against DNS abuse

+

|-

+

| || 7. We encourage the exchange of information on threats between parties involved (e.g., CERTs, security organizations) using collaborative platforms such as Malware Information Sharing Platform (MISP) to report and mitigate abuse in a more effective and timely way. || 12. Registries' and registrars' abuse rates should always be monitored by independent researchers with institutions and regulatory bodies; their abuse rates should not exceed predetermined thresholds; if they exceed the thresholds and do not improve, [[Registrar Accreditation Agreement|accreditation]] could be revoked || || 21. National CERT teams should subscribe to data sources that identify open DNS resolvers; should intensify notification efforts to reduce the number of open DNS resolvers, the root cause of distributed reflective (DR)[[DoS Attack]]s ||

+

|-

+

| || || 13. registries and registrars with lower abuse rates could be financially rewarded, through a reduction in domain registration fees || || 22. The [[Cybersecurity]] community should continuously measure the adoption of SPF and DMARC protocols, especially for high-risk domain names; raise awareness of domain spoofing among domain owners and email service providers; and correct and toughen SPF and DMARC rules to mitigate email spoofing/Business Email Compromise scams ||

+

|-

+

| || || 14. registries should maintain access to [[RBL]]s, identify their registrars with the highest and lowest concentrations and rates of DNS abuse, propose incentive structures to encourage their registrars to prevent and mitigate malicious registrations || || 23. Network operators should deploy IP Source Address Validation for all traffic at the edge of a network to protect closed DNS resolvers from different external attacks against DNS infrastructure, including possible zero-day vulnerabilities within the DNS server software

+

|}

=====Pro-[[Data Privacy|privacy]]=====

*Pro-privacy legislation, such as the [[GDPR]] and the [[California Consumer Privacy Act|CCPA]], limits access to natural persons' data.

Line 59: Line 81:

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=====

−

======Federal======

+

======U.S. Federal======

−

~~In the U.S.,~~ 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~~|The Federal Information Security Management Act of~~ 2002]]

+

* [[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)]]

* [[Cybersecurity and Infrastructure Security Agency#History|The Cybersecurity and Infrastructure Security Agency Act of 2018]]

+

======State======

* [https://www.ncsl.org/research/telecommunications-and-information-technology/cybersecurity-legislation-2021.aspx Statewide Cybersecurity Legislation]

Line 74: Line 97:

=====DOD=====

−

* [[Cybersecurity Maturity Model Certification]]

+

* [[https://www.acq.osd.mil/cmmc/ Cybersecurity Maturity Model Certification]

=====NIST=====

Line 83: Line 106:

* [[NIST#Cybersecurity Framework|Cybersecurity Framework]]

−

=====Responding to State-Sponsored Cyberattacks=====

+

=====Responding to [[Threat Actor|State-Sponsored Cyberattacks]]=====

======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 ~~breaching~~ 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>

+

* [[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===

Line 95: Line 118:

====ICANN====

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.<ref>[https://www.icann.org/en/blogs/details/update-on-icanns-dns-security-threat-mitigation-program-19-7-2021-en Update on DNS Security Threats, ICANN Org]</ref> 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 ~~Org~~, [[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>

+

=====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

−

~~:*[[SSAC]] advises on the stability and security of the DNS, and~~

+

:*[[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]] ~~is not beholden to the DNS Abuse Framework; instead, the office can reprimand~~ 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.

:*[[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/>

:*[[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 [[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:

−

:*~~The~~ [[~~ISPCP~~]]

+

:**require TLD registries, registrars, privacy or proxy providers and resellers to verify the accuracy of domain registration (WHOIS) data;

−

:*The [[~~ALAC~~]]

+

:**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 [[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

+

======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====

+

====DNS Abuse Institute====

−

~~Currently, this~~ newcomer is entirely focused on creating an interoperable framework to reduce DNS abuse. The DNSAI acknowledges there are two options for reducing security threats: proactive and reactive methods. The institute is currently putting more of its energy into developing ''reactive tools'' because they can be used by anti-abuse or compliance personnel without requiring integration in registration platforms and thus, broad buy-in should be easier to secure.<ref>[https://dnsabuseinstitute.org/wp-content/uploads/2021/06/DNS-Abuse-Institute-Roadmap.pdf DNSAI Roadmap pg. 9]</ref>

+

This newcomer is entirely focused on creating an interoperable framework to reduce DNS abuse. The [[DNS Abuse Institute|DNSAI]] acknowledges there are two options for reducing security threats: proactive and reactive methods. The institute is currently putting more of its energy into developing ''reactive tools'' because they can be used by anti-abuse or compliance personnel without requiring integration in registration platforms and thus, broad buy-in should be easier to secure.<ref>[https://dnsabuseinstitute.org/wp-content/uploads/2021/06/DNS-Abuse-Institute-Roadmap.pdf DNSAI Roadmap pg. 9]</ref>

+

* [[NetBeacon]]

===Private Sector===

====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>

−

====Registries and ~~Registars~~====

+

* [[CleanDNS]]

−

=~~====European ccTLD Registries=====~~

+

* [[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]]=====

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 138: Line 194:

# Reserve the domains or

# create the domains in order to suspend or [[DNS sinkholing|sinkhole]] the domains for victim identification

−

~~====IP====~~

−

~~Intellectual property lawyers~~

====Reputation Industry====

+

Commercial service providers, researchers, and non-profit organizations operate the most prominent [[RBL]]s that detect or receive notifications of security threats. Some key players include:

+

* [[Spamhaus]],

+

* Cisco’s [https://talosintelligence.com/reputation_center Talos] email reputation system,

+

* [https://apwg.org/ the Anti-Phishing Working Group's RBL],

+

* [https://safebrowsing.google.com/ Google Safe Browsing],

+

* [http://www.surbl.org/ SURBL], and

+

* [https://www.threatstop.com/ ThreatStop].

====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>

Line 146: Line 207:

==References==

−

~~==References==~~

−

[[Category:~~Glossary~~]]

+

[[Category:Cybersecurity]]

Jessica

Bureaucrats, Check users, lookupuser, Administrators, translator

14,927

edits

Changes

DNS Abuse Responses (view source)

Revision as of 19:42, 24 October 2022

Navigation menu

Search