This is the second in a four-part blog series. You can find the first part here.

Part 2 – Architecture Review

While network security is not the focus of the GDPR, without it there would inevitably be security incidents and events, some of which would lead to data breaches. Many organisations are working through the legal and process aspects to data handling, along with the underlying IT controls and policies. Inevitably architectural decisions are being influenced by the GDPR and in some organisations security projects must be linked to the GDPR in order to go ahead.

As a result, the GDPR both represents an extra consideration and an opportunity when it comes to architecting network security. Data protection regulations have been around for many years, the intention of GDPR is to improve and unify the situation for EU residents—it is not suddenly a new thing. It does, however, tighten up regulation or place greater emphasis on certain aspects of network security.

The Forrester Report “You Need An Action Plan For The GDPR” ^{ref 1} has a couple of points relevant to this:

• #3 “Privacy-by-design will be the biggest challenge to address”
• #5 “Providing evidence of risk mitigation counts as much as securing data”

Most architecture diagrams in a GDPR context are focused (quite rightly) on data loss prevention. What seems to be missing is the DNS component. No one can doubt any longer that DNS is a threat vector involved in malware activity, ranging from communication with command and control centre(s) through to data exfiltration. Estimates are around 90% of malware activity involves DNS and there have been many widely published security incidents related to DNS in the mainstream media.

Budgets are not unlimited, and no organisation is going to implement every security measure that has a GDPR sticker on it. However, most organisations already have a DNS service today and many of them are reviewing its implementation and assessing its role in network security. Organisations need to take a view on the role of DNS and consciously rule in or out what they will do about it in a security context. This is where an architecture review comes in. As most network communication begins with a DNS lookup, DNS affects the entire network.

Below is an illustration of how DNS is exploited at the different stages of the “cyber kill chain”.

Review the above to determine if your network security “privacy by design” addresses each of these stages. You may have it covered (do test!) so add your considered risk assessment to your architecture design documentation. Check that you have evidence these known means of exploitation are monitored, for instance, syslog messages containing queries for domain names that are known indicators of compromise (IOCs).

This breaks down into the following Architecture Review checklist:

• Check if good DNS implementation practice is in place
  • The ability to control DNS communication – see below for further discussion
• Understand/Review how DNS is exploited:
  • Check DNS Registrar security around the authorisation of changes (is it two- factor?)
  • Do you have any DDoS mitigation?
  • Is there a process to deal with a malware “kill switch”?
  • Is there anything blocking malware C&C communication via DNS?
• Exfiltration of data via DNS
  • Test querying IOCs, such as domain names associated with current threats
  • Test (unauthorised) data exfiltration/tunneling via DNS (don’t assume you have this covered)
• Document review and DNS risk assessment

Regardless of the technology, you should have DNS implemented so that only your authorised (i.e. known and managed) DNS servers can communicate with the outside world. Specific steps you can take include:

1. Checking your firewall rules
2. Examining how DNS can act as a control point, providing security based on signature, reputation and behavioural techniques such as machine learning. This looks something like the illustration belowThe choke point gives you control and stops shadow IT DNS implementations. It can also act as a source of valuable security data.The choke point, and other internal DNS systems, can implement security based on:Signatures – Blocking malicious or malformed packets or even known DNS tunnel signatures. It can do this at volume before queries reach the DNS process itself. It will be done partially at a network level via firewall rules/ACLs and may be added to using the DNS server itself with a greater “protocol aware” ruleset.Reputation – Blocking queries to malicious domain names and/or IP addresses. DNS scales well with low processing impact and can be used to block millions of domain names, something firewalls can struggle with. By setting policies on a domain or IP address, during DNS resolution the good is allowed and the bad is blocked. This is called Response Policy Zones (RPZ); you can listen to a podcast by Cricket Liu and Paul Vixie^{ref 2} explaining how this works.

   Behaviour – Identifying malicious activity over multiple DNS queries. This is increasingly necessary rather than waiting for an indicator based on reputation or the format of a single packet. A newly registered domain, for instance, may have no reputation associated with it that can be inferred from a registrant or reverse engineered by analysing a Domain Generation Algorithm.

3. Lastly, but importantly, if the DMZ DNS service is the only one able to communicate with the outside world and the authorised internal DNS servers are the only ones able to send DNS queries to the DMZ, then you gain visibility of the endpoints making malicious queries. This enables you to identify potentially compromised systems, scan or quarantine them and determine the potential scope/impact of the malicious activity. This is applicable to all devices, whether traditional network attached hosts, virtual hosts or IoT stuff.

One thing to bear in mind is that the GDPR does not mandate breaking the bank, as Article 25 begins “Taking into account the state of the art, the cost of implementation…”. Reducing risk is better and less costly than fixing problems. Even without 802.1x access control, through a DHCP hack an organization could identify corporate devices and hence provide an IP address to valid hosts or log non-corporate devices as a security issue while denying them an IP address. Not foolproof, but security by design and default on a budget!

With GDPR in mind, the recommendation is to review architecture and consciously make risk-based decisions on where money should be invested or not. Document the decisions and the reasons behind them, you then have the paper trail if the worst happens.

If you want to understand more about DNS security or need assistance in architecture review or testing, Infoblox is here to help.

This blog is part of a four-part blog series. Please find the links to other parts below.

• Part 1 – Introduction – Introduce the implications of GDPR to network and security professionals
• Part 2 – Architecture review – Identify and reduce risk, focusing on DNS as a point of control and visibility.
• Part 3 – Support of security operations – Assess the impact of potential malicious network activity along with information sharing, enriching context and signaling between security tools.
• Part 4 – Governance around DDI data – DDI data really helps in terms of network security but some of it will fall under the GDPR as some DDI data relates to a person.