The General Data Protection Regulation (GDPR) is responsible for a lot of changes to privacy policies and standards, leaving everyone rushing to be ready for GDPR day on May 25, 2018. The Internet Engineering Task Force (IETF) has also been busy recently updating some of its standards in response to the GDPR.

One change that has come to our attention is the update to RFC6302, which describes recommended standards for internet-facing server logging. Logging is enabled primarily to permit organizations to maintain audit trails of the traffic received by internet-facing servers. This allows fault identification, service improvement and, more crucially, the ability to properly investigate a security breach.

A draft recommendation was published at the end of April that advises several changes to RFC6302 to align to the overarching principles in GDPR. While a lot of the standard is sensible and advocates data minimization and protection of logging files from unauthorized modification, we view the core proposals on data that should be removed from logging files as misguided and dangerous to the ability of an ISP to properly identify events during an investigation of a security breach.

We have issue specifically with the following:

  1. Proposal to only store incoming IP address while the service is provided to the user. While this point seems to represent the general principle within GDPR, aimed at retaining data only if it is necessary for business purposes, there are several issues with the definition here that ISPs will find difficult to follow. Does the service end when the content is served up to the user (which could be very short in terms of seconds or minutes), for example, or for the entire duration that the user is a customer (generally much longer) if using a paid-for service? While the broad principle of retention only while it serves a business purpose is sound, there is a serious issue with what this means in practice that needs to be addressed in order to make this a usable recommendation by ISPs.
  2. Removal of identifying octets of sending IP addresses (first two octets are retained in IPv4 and the first three in IPv6). Removing the final octets impairs any ability to identify in a subsequent investigation the source of a malicious attack attempted on the internet-facing server. This contradicts the GDPR requirement to be able to fully investigate a breach by removing the utility of the information to such an extent that it is much less useful to log it at all.
  3. Removal of port numbers, timestamps, and transport protocol numbers. This is a high bar to set for something that brings questionable value from a privacy perspective. A cursory understanding of how network connections happen, specifically how ports are determined for a connection, would indicate that this information isn’t an identifier even when used collectively. And yet documenting all of this risks making it a useless best practice that may make an organization’s compliance with this recommendation a matter in litigation.
  4. Storage of logs within incoming IP addresses for three days only. Storage of logs for three days is not likely to be sufficient to support ongoing investigations or any forensic investigation efforts, should that be required. In our experience, log retention is required for much longer periods of time, especially when trying to do root cause analysis and understand the scope of a breach.

We are concerned primarily because one of the key drivers for GDPR is to improve the ability of organizations to detect and notify consumers of any breaches of the privacy of their information. The technical proposals within this RFC make this harder by taking the principle of data minimization so far that the data loses any utility to allow protection of privacy in a breach scenario. We do not see how removal of this data particularly enhances user privacy and believe that it can damage it by removing data that is critical to understand during an incident investigation.

While we support the general principles contained in the update, we would recommend a risk-based approach to making decisions about logging for internet-facing servers. This standard should be amended to advocate such an approach rather than being proscriptive about removing data at this level of granularity. This would provide ISPs with the flexibility to make updates to their internet-facing infrastructure based on the types of services that they provide and the privacy risks to customers specifically.