Over recent months the GDPR has given extra weight to concerns – originally expressed by regulators fifteen years ago – about public access to information about individual registrants of DNS domains. This article considers the use of this WHOIS data by those handling information security incidents, and why this represents a benefit, rather than a risk, to the objectives of data protection law.

Dealing with Information Security Incidents

As has been repeatedly recognised by legislators and regulators, the prompt detection and remediation of information security incidents is an essential part of keeping personal data secure. The processing of personal data necessary to do this is declared a legitimate interest in Recital 49 of the General Data Protection Regulation (GDPR); on page 6 of their Guidelines on Breach Notification the Article 29 Working Party recommended that all data controllers and processors should conduct such activities. The compatibility of the GDPR’s requirements with current incident response practice is discussed in Cormack (2016).

Examples of WHOIS use

Incident responders use WHOIS contact details in a number of different ways to respond to, and prevent, information security incidents. For example:

1. When a website is reported as being involved in phishing, or installing malicious code on its visitors’ computers, WHOIS data may be the only trustworthy way to contact the site’s owners and alert them of the need to protect their visitors. WHOIS contact data may also provide an indication whether this is a legitimate site that has been taken over by criminals, or one that was created with malicious intent. Without WHOIS information it is likely to take longer, and may be impossible, to report the malicious activity, particularly in generic Top Level Domains where it may not even be possible to determine which country’s incident responders to contact. WHOIS is the only way of directly reaching out to the web site owner. Engaging through intermediaries such as upstream providers adds significant delay and uncertainty and removes agency from the web site owner to take action on a web site compromise.
2. When domains are registered for the purpose of cyber-attacks, WHOIS data may allow incident responders to prevent incidents, as well as mitigate them. This is because criminals often register large numbers of domains using the same contact details. When the first of a group of such domains is reported, incident responders can check for other domains with the same contact details and proactively filter or block traffic to or from those before they are used. Without WHOIS data, each malicious domain must be dealt with individually, after it has already caused harm. This technique can be used to mitigate attacks from botnets, malware, phishing and spam, among others.

Risks of WHOIS data

In 2017 the International Working Group on Data Protection in Telecommunications (the “Berlin Group”) discussed privacy and data protection concerns about the collection and use of WHOIS data. The following section demonstrates how access by incident response teams can satisfy their recommendations.

1. The legitimate purposes of the processing of registrant data and of the disclosure in the public directory need to be defined. These legitimate purposes need to be limited to the narrow remit of ICANN, which is to manage the assignment of names and numbers in a manner that assures the security and stability of the Internet.

Responding to on-line information security incidents is clearly within both the remit of ICANN and of Data Protection law.

2. The personal data collected from and about registrants must be limited to that which is necessary for the purposes as described in recommendation No. 1 of this Working Paper. This includes the processing of data necessary for the registration of the domain name. Also, the personal data disclosed in the public directory must be limited to that which is necessary for assuring contactability of registrants in the event that there are technical issues related to the name registered.

As example 1 above highlights, incident response is precisely dealing with a “technical issue[] related to the name registered”. No additional information is required for the use case in example 2, though it does require the ability to search actual contact details, rather than the ability to contact via a pseudonymising service.

3. (relating to Law Enforcement access) Access to personal data must be as provided for by law. Such law needs to be transparent, foreseeable and proportionate to the legitimate aim pursued in a democratic society.

Although this relates only to law enforcement, it should be noted that, as discussed above, incident response is both provided for by law and recommended by Regulators. Indeed for network operators, it is a legal requirement under Article 4 of the ePrivacy Directive (2002/58/EC).

4. There are two data retention requirements in the 2013 RAA19 which are problematic in terms of data protection law. ICANN should reexamine them and ensure compliance with applicable law.

The incident response examples given above do not require data to be retained after the domain is de-registered. If historic data continues to be available then patterns can be used to identify and prioritise incidents likely to cause significant harm: for example if a domain was previously held by a legitimate entity but is now registered to an unknown person this suggests a takeover with hostile intent; or if a domain referring to a bank in one country is held by an individual in another part of the world this is likely to indicate preparations for a phishing attack. Here the small risk to legitimate registrants of retaining historic information is likely to provide a much greater benefit to them and their customers when malicious activity can be detected and stopped.

5. Any new Registration Data Service should investigate means of restricting searches to those related to the purpose of the processing of the data.

Such policy restrictions already exist in the membership rules of several incident response associations (See below)

6. ICANN should explicitly address the issue of transborder dataflow in its policies, and ensure that data transfers ensure adequate data protection is maintained.

Cross-border flows of WHOIS data may occur whenever an incident responder identifies a domain as being involved in an information security incident. Whether a responder within Europe is notifying a non-European registrant of an incident, or a non-European team is notifying a European registrant, the responder, the registrant and any data subjects of the registrant’s systems all have a strong legitimate interest in that flow being permitted by law.

7. Commercial data which may be disclosed must not include personal data.

This appears to refer to situations where commercial data are assumed to be non-personal, and therefore not subject to data protection law. This distinction is not necessary for incident response purposes, since these can be achieved while processing all disclosed data in accordance with personal data law.

8. The IWGDPT recommends that ICANN develop a data processing policy that is in line with the requirements of existing privacy legislation and internationally recognized data protection and privacy principles and standards.

This paper demonstrates how the use of WHOIS data is, indeed, in line with those requirements.

Incident Response Associations

Various associations of incident responders bind their members to policies that support the beneficial use of WHOIS data, as described above. The following also have existing authentication systems that could be used as a basis for enhanced access to WHOIS data by their members who are bound by those policies:

• FIRST – https://first.org/membership/process
• TF-CSIRT – https://tf-csirt.org/membership/