When the European Union's General Data Protection Regulation (GDPR) takes full effect on May 25, 2018, organizations collecting and maintaining personal data of residents of the European Union have a new set of obligations. As a result, a long-standing debate about data protection and privacy in WHOIS, and the potential impact of the GDPR to personal data that is collected, displayed, and processed for gTLDs under ICANN contracts and policies has a new sense of urgency.
On May 17, the Board of Directors of the Internet Corporation for Assigned Names and Numbers (ICANN) approved, for the first time in its history, an emergency temporary policy (referred to as a ‘Temporary Specification’) effective for a 90-day period beginning May 25 to “maintain the stability or security of Registrar Services, Registry Services, or the DNS or the Internet.” The Board will reaffirm its temporary adoption every 90 calendar days for a total period not to exceed a one-year policy development process. (Some ccTLD WHOIS database operators will follow the Temporary Specification in certain material respects, but there will of, course, continue to be discrepancies between what is available across ccTLDs.)
The Temporary Specification restricts most personal data to layered/tiered access, which means only users with a legitimate and proportionate purpose for accessing the non-public personal data will be able to request such access through registrars and registry operators— as long as it is not overridden by the fundamental rights and freedoms of individuals whose personal data is included.
The public will still maintain the ability to contact the registrant, administrative, and technical contacts for gTLDs through an anonymized email or web form. This approach is designed to minimize the intrusiveness of using the personal data, while still providing a means for the public to contact, but not identify, the registrant, administrative, and/or technical contact. This may be implemented beyond the European Economic Area (EEA), possibly on a global basis depending on the commercial set up at the registry/registrar, and what is technically feasible or otherwise commercially reasonable taking into account the extra-territorial application of the GDPR.
The Temporary Specification does not fully distinguish domains registered to legal or natural persons, which would allow for public access to all WHOIS data of legal entities outside the remit of GDPR. However, the registrant organization field (not the name of the person associated with the legal entity) should continue to appear in the public data set.
Furthermore, the sponsoring Registrar, status of the registration, and creation and expiration dates for each registration will still show up for all domains in public WHOIS.
Also, registrars will still return full public WHOIS data for domains already masked with proxy services.
Some registrants will consent to have their contact information published, so even for registrars subject to GDPR, there will be some records with more complete contact information, but otherwise the name, street, city, postal code, phone and fax of the registrant, admin and technical contacts will be redacted for privacy in the public WHOIS. For now, the fields may be missing altogether, or one will see a notation that the field has been redacted for privacy.
Unless specifically addressed and modified by the Temporary Specification, all requirements and obligations within Registry Operator's Registry Agreement and Registrar's Registrar Accreditation Agreement and consensus policies remain applicable and in force. This includes maintaining Port 43 access, but that does not mean it will necessarily be easy to differentiate discrepancies between what is available in Port 43 versus through the Web WHOIS interface. For example, if a domain is registered to an individual in PRC, Port 43 may just end up showing the Registrant Org field as blank, but then in Web WHOIS, you may be able to see the personal email and name of the living person if the specific registrar at issue doesn’t apply GDPR to people outside of the EEA.
We seek to ensure ICANN lives up to its role as a guardian of the DNS at the core of the Internet, especially after the two-decades-long process by the U.S. Department of Commerce that transitioned the coordination and management of the DNS to the private sector in 2016. What this means for us right now is making sure to mitigate potential harm from the Temporary Specification.
We sent a detailed letter to the ICANN Board in this respect on May 11 to encourage a Temporary Specification that is proactive and ensures the system will actually operate to mitigate risk by holding its contracted parties accountable. Similarly, on May 17, before the Temporary Specification was published, the European Commission emphasized to ICANN that there is a need for a genuine commitment to the spirit of the GDPR, and for ICANN to be proactive--ensuring that the Temporary Specification actually operates to mitigate risks of potential or actual harm to people and the security and stability of the Internet, which is a core part of ICANN's mission.
In our view, ICANN's Board failed to live up to its commitment of ensuring there will be no unnecessary potential harm to the public interest in a safe and open Internet, but no actual harm has yet materialized to our knowledge. ICANN’s Board refused to specify any level of accountability in its contracts for ensuring legitimate access. We know the contracted gTLD WHOIS database operators have to provide reasonable access that takes privacy into account (which of course means not otherwise prohibited by applicable local law), and that this is not a question alone of whether it is commercially feasible or profitable to do so. But by not specifying certain expectations of what is actually required of the registrars (e.g., whether they must having staff available with the competency to handle the requests), means ICANN decides what constitutes “reasonable” access on an ad-hoc basis. We think the Board could have done better, but give it credit that at least the expectation of its WHOIS database operators is more than just doing what is “commercially reasonable.”
To put this in context, there are a variety of “efforts” terms used in contracts, and the Temporary Specification uses both “reasonable” and “commercially reasonable” efforts clauses, which means these clauses should be understood to have different meanings. For example, as expressly recognized in Section 4.3 of the Temporary Specification, ICANN is required by Section 4.6(e) of the Bylaws to use “commercially reasonable efforts” to enforce its policies in certain respects, but with respect to duly accommodating legitimate access requests, “reasonable” efforts are required, which arguably is somewhat less demanding than best efforts, but typically understood to be more demanding than a “commercially reasonable” efforts standard. We had suggested to the Board that as long as the request is not illegal, it should be accommodated for legitimate interests recognized by GDPR, provided privacy was duly taken into account, but the Board rejected this proposed carve-out for illegal activity as part of a definition specifying the kind of efforts a registrar is, and is not, obligated to take.
We believe in practice that the GDPR itself, as well as further inputs from data protection authorities or the European Data Protection Board, provides underlying objective guidance and criteria against which to measure the efforts of ICANN’s registrars in providing tiered access. Furthermore, some of the relevant factors that ICANN Contractual Compliance will need to consider in deciding whether a registrar appropriately responded to a legitimate access request is whether the registrar acted in good faith in light of its own capabilities, recognizing that registrars do have the right to rely on their good faith business judgment, but also requiring the registrar to act diligently within the bounds of reasonableness to fulfill its obligations, which will be a fact-intensive inquiry.
It is potentially harmful to take a “wait and see” approach and not put resources into Contractual Compliance in advance, and it is potentially harmful in the Temporary Specification not to insist gTLD WHOIS database operators have the staff and competency to respond and duly accommodate legitimate requests for tiered access appropriately. Therefore, it is essential that Damage Reports be collected if this potential harm materializes, so that the Temporary Specification may be modified if needed in this regard.
What this Means for Our Platform / Services
RiskIQ is committed to the spirit of GDPR. For the platform and across our products, what this means is that depending on your needs and level of access, some personal data contained in WHOIS records from RiskIQ PassiveTotal will not necessarily be available to inspect. In some cases, you will eventually have the ability to pivot from a hashed phone number or email address, but you may not need to see the actual phone number or email address in every investigation, on all occasions. When the unmasked data is needed, we intend for this information to be available, subject to certain safeguards and controls. In other words, we see no necessary conflict between privacy by design principles and effective digital threat management.
For organizational gTLDs, the registrant org field should remain in the public data set. This would assist in analyzing your digital footprint with RiskIQ Digital Footprint. We may be continuously requesting information as needed from the registrars or registry operators necessary for a customer's digital footprint. We intend to assist our clients in making these requests from relevant WHOIS database operators to supplement what's available from public WHOIS.
Customers using RiskIQ External Threats that need to contact the registrant for mitigation purposes may need to use the anonymized email address or a web form to facilitate email communication--similar to what exists already concerning privacy/proxy domains. Documenting communications will be essential. This may be doable by sending the notice to the anonymized email address much the same way that some communications are being sent today. Where a web-form is offered, it will be important to try and have a copy of the email sent to the workspace if the option is available. Some of these web forms will have constraints (e.g., 240 characters, and no attachments). An internal policy and procedure to handle these constraints will be addressed.
If there is a need for specific personal Whois data that is not published, an access request may be sent to the registrar and/or registry explaining the basis of the request, and why the need for the data outweighs the interests of the natural data subject. We will be making these requests on behalf of our MSS customers on an as-needed basis, and will roll-out templates for non-MSS customers to adapt and benefit from. When legitimate access requests are not appropriately responded to or investigated by a registrar, we will request ICANN Compliance to intervene for our MSS customers and provide guidance for non-MSS customers to do so as well.
We will also be making a “damage scorecard” available to track whether the Board’s Temporary Specification causes actual harm.
We also intend to readily utilize our dispute resolution proceedings (DRPs) as part of digital threat management, including how to properly leverage the UDRP and other mechanisms for threat intelligence needed to cost-effectively and efficiently mitigate digital threats in that context. We expect in many cases to have better cooperation through DRPs as the Temporary Specification ensures the personal data will be disclosed as needed in that context. RiskIQ has extensive experience using infrastructure analysis in the DRP context to go after criminal networks masking their activities with a combination of proxy, false, and fictitious identities.
We are actively involved in the policy-development process not only at ICANN but more importantly, within the broader security, Internet governance, and privacy-mindful relevant working groups. We remain committed to both privacy and security.
This is an excellent time for RiskIQ clients and subscribers to really understand the value of our Internet datasets offered via RiskIQ Security Intelligence Services, as well as understanding how to conduct better threat infrastructure analysis as part of your digital threat management program using Infrastructure Chaining, leveraging other data sets including through RiskIQ PassiveTotal, such as Passive DNS, SSL Certificates, Analytical Trackers, Host Pairs, Web Components, Cookies, and Open source intelligence (OSINT). To understand how RiskIQ PassiveTotal Trackers work, learn about our A-List. Explore as endpoints our Blacklist and Host Attributes, as well as RiskIQ's DNSIQ® for passive DNS resource record sets. Use Trackers in RiskIQ PassiveTotal to your advantage!
For preemptively detecting and mitigating malicious registrations, we recommend leveraging RiskIQ Newly Observed Domains data set to systematically block domains for a set amount of time after they are first observed. While legitimate access to WHOIS may be needed to amplify and corroborate, other RiskIQ data sets are available to address a wide range of incident classifications from network security to intellectual property theft.
Considering that RiskIQ offers managed security services for digital threats ranging from phishing and malware to intellectual property theft, this may be a good time to consider a managed security solution for digital threats that incorporates infrastructure chaining, ICANN compliance advocacy, tiered access requests that take both privacy and security into account, complex DRPs, and all other relevant tools that should be used as part of a digital threat management program.
Finally, we will be gathering metrics against those WHOIS database operators that do not appropriately respond to or investigate legitimate access requests. We will consider how these metrics should be taken into account in DNS firewalls for blocking domains coming from these operators.
The RiskIQ Intelligence Connector for Microsoft Azure Sentinel Is the Context-Rich Force Multiplier Security Teams Need
Digital initiatives have changed the enterprise attack surface and how organizations appear online, both to users and malicious actors. Meanwhile, the threat landscape has evo...