Overview
CIRCL is the CERT/CSIRT (Computer Emergency Response Team/Computer Security Incident Response Team) for the private sector, communes and non-governmental entities in Luxembourg.
In this context, one of the tasks of CIRCL is to protect the citizens, companies and all other types of organizations, within, but not limited to Luxembourg from malware, phishing and other digital threats.
In order to achieve this with maximum effect, CIRCL tries to make the malicious content inaccessible, while informing the responsible people about the compromised infrastructure at the same time.
World-wide, CIRCL has sent out and followed-up on almost 8.000 take-down requests in the last 4 years. This number was only achievable through automated look-ups of the corresponding responsible contacts, including abuse contacts.
The information that is processed is coming from the public WHOIS servers. According to RFC 3912 (the WHOIS Protocol Specification), WHOIS contains for instance “information about registered domain names”. This information is “intended to be accessible to everyone”. We, among other CERTs and computer security professionals use this information to contact manually or automatically victims of cyber crime, information leaks, or otherwise negatively affected people or organizations, including the notification of vulnerabilities in their infrastructure.
Should this method of automated look-ups one day be made unavailable or the access thereof altered to require additional manual work, CIRCL would not be able to continue its efforts with comparable efficiency. This, in turn, would leave malicious content accessible for much longer and result in damage, not only limited to the infrastructure in Luxembourg, but to everyone tricked into accessing those resources.
Currently, we expect the aforementioned threat through advise by ICANN and implementations related to GDPR.
FAQ
FAQ 1 - A lot of information within WHOIS records might be invalid, is it really useful for security?
Even if information in a WHOIS record is invalid, incorrect or even spoofed, it remains useful. This information can be used by the CERT/CSIRT to correlate information, pivot around the spoofed information provided by the adversaries (either manually or via automated spoofing techniques), or to find additional information about the tactics and techniques of the adversaries. In threat intelligence platforms such as MISP, the information from WHOIS records (valid or invalid) can be easily utilized by an analyst to find out more details about the conducted attacks.
FAQ 2 - Why do you think end-users or organizations should make personal details available in WHOIS?
Acquiring a domain name implies responsibilities including securing an infrastructure and responding to abuse notifications. This is made possible via the provided contact details during the acquisition and therefore consent to this data is implicit when a domain is purchased and operated. If the information is hidden from everyone, notifications to the domain owner about abuse, potential vulnerabilities or misconfigurations would be in most cases impossible. This creates an additional burden for the registries to handle indirect requests for information. It is obvious that time is of the essence when trying to solve or notify about security incidents. This is why the domain owners need to disclose specific points of contact for abuse handling.
FAQ 3 - Why do you think having publicly accessible records in WHOIS is compliant with the General Data Protection Regulation (GDPR)?
Security measures are an important safeguard in order to protect security at large. In the case of the WHOIS records, the purpose of handling data must be in accordance with the security objectives and more importantly, the scope described in recital 49 of the GDPR. If someone is abusing WHOIS records for other purposes than contacting for abuse handling or similar tasks, the processing of personal information is still subject to the GDPR and its enforcement.
FAQ 4 - Why do you need public access? Why won’t private, per-request access to the registry suffice?
The short answer is that it’s simply not practical. CIRCL and most CSIRTs do automatic lookups to facilitate rapid abuse handling (e.g. URLabuse) via automation. Adding an additional bureaucratic overhead on registries and CSIRTs will generate delays for processing take-down notifications, which in turn will boost opportunities for adversaries to harm more users.
FAQ 5 - What further impacts can a restriction on WHOIS database content have on third party organizations?
Under the GDPR, any organization acting as data controllers or data processors are requested to implement appropriate technical and organizational measures to ensure and to be able to demonstrate that data management is performed in accordance with this regulation. Among such obligations, recital 32 of the GDPR clearly states that the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. WHOIS records are an important if not essential part of such measures, either directly or through the use of third party services such as URLabuse. Any restrictions to the access of the WHOIS records therefore negalitively impacts one of the possibilities offered to data controllers and processors to ensure compliance with the GDPR.
References
- RFC 3912 - WHOIS Protocol Specification
- Security Considerations
The WHOIS protocol has no provisions for strong security. WHOIS lacks mechanisms for access control, integrity, and confidentiality. Accordingly, WHOIS-based services should only be used for information which is non-sensitive and intended to be accessible to everyone.
- URLabuse is a back-end, public service and mechanism of automatically looking up email contacts of responsible people for a domain/IP address.
- CERT NZ Statement about WHOIS and GDPR
- Statement from SWITCH: The GDPR and WHOIS privacy
- An open letter by Chairman Thomas Schreck of FIRST to ICANN
Classification of this document
TLP:WHITE information may be distributed without restriction, subject to copyright controls.
Revision
- Version 1.0 20180412
- Version 1.1 20180416