|
|
| (10 intermediate revisions by one other user not shown) |
| Line 12: |
Line 12: |
|
| |
|
| ==Response Options== | | ==Response Options== |
| ===Reactionary Removal=== | | ===Removal & Mitigation=== |
| * [[SAC115]]
| | ====Frameworks & Guides==== |
| * [[DNS Abuse Framework]]
| | # 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. |
| * Terms of Service (ToS) notice-and-takedown regimes for use/content abuse
| | # 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. |
| * [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]
| | # 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] |
| ===Cotemporal Mitigation===
| | # [[SAC115]] |
| * [[DNS Abuse Institute|DNS Abuse Institute Roadmap]]
| | # Terms of Service (ToS) notice-and-takedown regimes for use/content abuse |
| * [[Budapest Convention]]
| | # [[DNS Abuse Institute|DNS Abuse Institute Roadmap]] |
| * The [[CISA#Continuous Diagnostics and Mitigation Program|CDM Program]] offers Automation in IT Security
| | # [[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] |
|
| |
|
| ===Intentional Inaction & Evidentiary Collection=== | | ===Evidentiary Collection=== |
| * [[FBI#IC3|IC3]] | | * [[FBI#IC3|IC3]] |
| * [[FBI#NCIJTF|NCIJTF]] | | * [[FBI#NCIJTF|NCIJTF]] |
| | * [[DNSAI]] Compass |
| | * [[DAAR]] |
|
| |
|
| ==Points of View== | | ==Points of View== |
| Line 38: |
Line 41: |
| | | |
| ===Academics=== | | ===Academics=== |
| :*[[COMAR]] | | *[https://korlabs.io/ KOR Labs] |
| :*[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]] |
| # no single global entity is responsible for the regulation of all its aspects; | | *[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: |
| # the [[Multistakeholder Model]] of governance and the distributed administration model allows disagreements and discrepancies; | | *# no single global entity is responsible for the regulation of all its aspects; |
| # much of what happens on the Internet is beyond the jurisdictional reach of the criminal law of individual nations; and | | *# the [[Multistakeholder Model]] of governance and the distributed administration model allows disagreements and discrepancies; |
| # regulation will continue to be reserved for the most egregious infringements. | | *# much of what happens on the Internet is beyond the jurisdictional reach of the criminal law of individual nations; and |
| 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>
| | *# 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
| | *[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 55: |
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]] |
| ======EC DNS Abuse Study Recommendations======
| | * 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: |
| 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>
| | *# 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 |
|
| |
|
| {| 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-[[Data Privacy|privacy]]===== |
| *Pro-privacy legislation, such as the [[GDPR]] and the [[California Consumer Privacy Act|CCPA]], limits access to natural persons' data. | | *Pro-privacy legislation, such as the [[GDPR]] and the [[California Consumer Privacy Act|CCPA]], limits access to natural persons' data. |
| Line 143: |
Line 134: |
| :**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> | | :**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 [[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====== | | ======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 |
| Line 151: |
Line 143: |
| :*The [[SSAC]] has published several documents on DNS Abuse measurement and mitigation | | :*The [[SSAC]] has published several documents on DNS Abuse measurement and mitigation |
| ======ALAC====== | | ======ALAC====== |
| :*At [[ICANN 74]], the [[ALAC]] held a session discussing end users' perspective and the role of [[RALO]]s in responding to DNS Abuse | | :*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==== |
|
| |
|
| ====DNS Abuse Institute==== | | ====NetBeacon Institute==== |
| 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>
| | 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]] | | * [[NetBeacon]] |
| | |
| ===Private Sector=== | | ===Private Sector=== |
| ====Cybersecurity Providers==== | | ====Cybersecurity Providers==== |
| Line 167: |
Line 160: |
| * [[Cyber Risk Aware]] | | * [[Cyber Risk Aware]] |
| * [[KnowBe4]] (MediaPRO) | | * [[KnowBe4]] (MediaPRO) |
| * [[SANS Institute]]. | | * [[SANS Institute]] |
| * [[Inspired eLearning]] | | * [[Inspired eLearning]] |
|
| |
|