GDPR: Don’t Get Caught Out By Your Logfiles
With all the focus on the more visible elements of GDPR compliance ahead of the Regulation’s introduction of May 25th, one EU Working group is warning businesses not to forget what’s stored in the logfiles of their Internet-facing servers.
What Are Logfiles and Why Should We Care?
Logfiles record either events that occur in an operating system or other software, or messages between different users of communication software.
As well as being useful to an organisation e.g. for providing clues about hostile activity affecting the network from within and without, and providing information for identifying and troubleshooting equipment problems, logfiles on Internet-facing computers can also potentially provide information to hackers and cyber-criminals that could compromise your system and data security.
Report Suggestions
A draft report by the Internet Engineering Task Force’s Internet Area Working Group (IETF’s INTAREA) says that changing data regulations have meant that what were established best practices have now become poor practices. The draft, therefore, offers a checklist as a set of updates to RFC6302 designed to help plug this potential GDPR compliance black spot. The “Recommendations for Internet-Facing Servers” draft suggests that sysadmins adopt a data minimisation approach to configuring their server logs, and suggestions include:
- Full IP addresses should only be stored for as long as they are needed to provide a service;
- Logs should only include the first two octets of IPv4 addresses, or first three octets of IPv6 addresses.
- Inbound IP address logs shouldn’t last longer than three days, because that lets logging cover a weekend before it’s flushed.
- Unnecessary identifiers should not be logged e.g. source port number, timestamps, transport protocol numbers, and destination port numbers,
- The logs should be protected against unauthorised access.
It should be said that any legally-mandated logging e.g. to comply with local telecommunications data retention laws, isn’t covered by the draft.
Cookie Consent Pop-Ups
We are all used to seeing cookie consent pop-ups when we arrive at websites, but the “implied consent” website owners have assumed existed once people clicked “I Agree” to cookies may no longer apply under GDPR. This is because GDPR is consent specific, and there is no way “implied consent” can get you water-tight compliance. What this means is that cookie consent pop-ups may soon be on legally shaky ground when it comes to GDPR compliance.
What makes this issue more complicated is the fact that the EU had intended to publish an updated ePrivacy Regulation, with the commencement of GDPR, to relax the cookie popup requirements, but didn’t do so. This means that data privacy rules on this matter will be governed by the old ePrivacy Directive and GDPR at the same time, with GDPR having the precedence.
What Does This Mean For Your Business?
This story shows that with GDPR just around the corner, some of the finer areas of compliance are starting to come under the spotlight. Yes, data protection, data security and privacy are the responsibility of all of us, not just the ‘technical people’, but when it comes to having to deal with server-logs, there clearly is a need for a technical focus to ensure all-round general compliance. Hackers, by nature, are generally technically proficient, and can employ multi-level and sophisticated attack techniques. It makes sense, therefore, that companies make attempts to plug known technical weak-spots such as those highlighted in this draft.
The cookie consent pop-up issue highlights the complicated area of consent that many companies have anticipated with the introduction of GDPR. The important point to remember is that GDPR is consent specific. Consent can’t simply be implied, and consent must also be unambiguous, informed, a statement or clear affirmative action, and freely given. Also, under GDPR, a data subject has the right to withdraw their consent at any time.
