[Part 4/4] Practical Advice to Network and Security Operations Pros Regarding GDPR Compliance

[#1]

This is the final part of a four-part blog series. Check out Part 1 – Introduction, Part 2 – Architecture Review, and Part 3 – Security Operations. 

Part 4 - DDI Data & GDPR

So is DDI data personal information and hence should be handled according to the GDPR? The short answer is "it depends". If it can be attributed or identified to a data subject, either on its own or in conjunction with other data, then it is within the GDPR.

What would affect a data subject in the context of DDI? Activity from an IP address that can be attributed to an individual. For instance, if an ISP records that a particular public IP is allocated to Jim and Jim uses the ISP's DNS servers, then if the ISP logs Jim's DNS queries it must get Jim's active consent. The DNS queries Jim makes could have an impact on him if exposed; these would show what bank Jim uses, for example.

As the "controller" who "determines the purposes and means of the processing of personal data" in GDPR terms you are responsible for use of that data, even if you use a third party as a processor. So, you need to conduct a data inventory of the DDI information you hold in order to determine what would fall under the GDPR. 

Use Cases

This is easier to consider by example as the GDPR is not clear on this and the boundaries haven’t been tested. Certainly, a MAC address would be identifiable and possibly an IP address in some cases. Below are two examples to assess whether DDI information constitutes personal data under the GDPR. This isn’t legal advice—be sure to consider the circumstances of your particular network and use of data, and seek counsel in determining the application of GDPR to your organization

For a guest wireless network user, you collect the following data: 

• No traffic is monitored (the network just provides DHCP & DNS caching services + basic firewall and bandwidth).
• A device MAC address is only used for the purposes of providing connectivity (via DHCP) and only while connected.
• IPs given to users are from RFC1918 address space and any traffic from the guest network is NATed. Hence there is no public IP address that can be identified with an individual.
• DNS queries are not logged and hence there is no way to correlate queries to an IP and MAC and hence an individual data subject.

This would not appear to fall under GDPR.

For internal DDI for employees you keep the following data:

• IP addresses and the IPAM, DNS and DHCP data associated with them.
• Username associated with an IP from AD authentication events.
MAC from DHCP.Location (from IPAM).DNS query logs. Your organisation can correlate this with who had what IP address at what time. Historical information for security forensics, e.g. what device had this IP address at what time and what individual is it associated with. 

That’s personal! It is okay to capture this data, but your use must be GDPR compliant. You’ll need to state the reasons you keep this data (IT security) and only use the information for this purpose. The DDI data, in this case, should be stored securely and you should be able to selectively delete any archived data. Also, note that data privacy statements may also be required before collection of any personal data. 

Retaining DNS Query Data

DNS query data is very useful for network security. In fact, the GDPR states in Article 6 section 1(d) that one of the reasons personal data can be processed is if “processing is necessary in order to protect the vital interests of the data subject or of another natural person”. Maintaining a secure network is certainly in everyone’s interests who works within an organisation, and its customers’ interests.

Why keep DNS query data? Let’s take a scenario to help with assessment, security forensics, and notification. This is the “we don’t know what we don’t know” problem of security evident in the “arms race” of security tools vs. vulnerabilities and hacking techniques.

In order to find out what we don’t know DNS can provide some valuable clues and this is one of the reasons for keeping query data. Suppose we do the following:

1. Capture DNS query logs
2. Strip out internal domains
3. Strip out the top public domains (e.g. use Alexa top domains)
4. Look at the top/bottom of what's left

The top of the what remains could be shadow IT or trusted third parties. These can be blocked if the former or added to the top public domains to ignore in the report if it is the latter. Working from the bottom up of what remains may lead you to think “Why are my employees resolving queries for .ru when we have no customers nor business partners there—is this malware?”. At this point you hopefully have authoritative DDI data to find out the “who?” within your organisation, the threat intelligence to assess/prioritise and then you can ask the person the “why?”. You may even block/redirect the domain and see who shouts or what appears in your honeypot. If the query is for a malicious domain name having historical query logs will help determine other devices that have also attempted the same query.

This may be personal data and hence cannot be kept indefinitely unless pseudonymised (relaxed GDPR requirements) or anonymised (outside the scope of GDPR). Remember you can keep data for a legitimate use and only use it for that specific purpose, as outlined in the GDPR. You should though be prepared for selective deletion.

Is this scenario valid? In short yes, security vendors use what is known as passive DNS data for research purposes. For use within an organisation it is a clue to help keep up with the arms race and watch out for the unknown. 

DDI Data Checklist

This is a checklist for the DDI data your organisation keeps:

• Data inventory
  • Review DDI data as part of your GDPR data inventory process.
  • What is personal on its own or in combination with other data managed by your organisation?
• Policy for DDI data
  • Issue data privacy statements before collection of personal data, where applicable.
  • Data retained (and only used) for network security purposes 

Summary

Returning to the Forrester report titled "You Need An Action Plan for The GDPR" and what we know based on experience and our problem domain, here is a summary under three of their five core rules requiring attention.

#2 “The Data Breach Notification requirement will be a game-changer”

Incident response is more critical and difficult, there is also an increase in urgency. Better foundational information about “what?”, “who?”, and “where?” on the network, management processes and automation based on DDI will help. This is not only to assist with any assessment, but as a part of mitigating any risk of a breach in the first place.

Using threat intelligence data and tools will help network security, whether this is deployed on a DNS choke point, firewalls, web proxies or email relays. The same data can be used to help security assessment, whether this is manual or automated, and in responding appropriately within 72 hours.

#3 “Privacy-by-design will be the biggest challenge to address”

#5 “Providing evidence of risk mitigation counts as much as securing data”

Perform an architecture review and take a risk-based decision on how you will secure the known risks around DNS. Network communication, including malware, starts with DNS.

Consider whether automated compliance checking against standards such as PCI will help demonstrate “state of the art” as the GDPR terms it and provide the audit records to show privacy is built in by design and by default.

Questions or comments? Want Infoblox to help with assessing your DNS security?

References

1 - Forrester Report - You Need An Action Plan for The GDPR by Enza Iannopollo https://www.forrester.com/report/Brief+You+Need+An+Action+Plan+For+The+GDPR/-/E-RES136242

2 - Cricket Liu and Paul Vixie Take a Deeper Dive on DNS and RPZ https://community.infoblox.com/t5/Security-Blog/Podcast-Cricket-Liu-and-Paul-Vixie-Take-a-Deeper-Div...

3 - “Delivering on the Promise of Modern Data Centers: A focus on DNS and IPv6” by Tom Coffeen https://lnkd.in/gYjWPFA