How DNS firewalls can burn security teams
It’s easy to see how DNS firewalls could have thwarted 33% of data breaches. For most IT and security teams, DNS has been an afterthought. Or, worse, not even that. The research, conducted by the Global Cyber Alliance, was absolutely still worth doing.
On the surface, this research is good news. It suggests there is a low-hanging fruit in the cybersecurity space. But it also suggests that a DNS firewall is the logical next step to improved security. It’s not — at least not on its own.
If, as a technology leader, you want to proactively protect your organization, you need to be leveraging DNS in a more intelligent way.
First, some credit to DNS firewalls (as they’re typically set up)
Most DNS firewalls sit along the network boundary. I distinctly call these external-facing DNS firewalls, and you’ll see why soon. Their purpose, like any other firewall, is to block predefined behaviour like traffic to websites associated with malware.
They’re efficient because they can take action on traffic based on a relatively small-sized DNS message and very scalable DNS protocol. DNS queries also precede more expensive operations to already overtaxed infrastructure, such as web proxies or firewalls.
External-facing DNS firewalls are also an excellent source of intelligence, because they have insight into a broad range of network traffic. Every query that resolves out to the internet has to pass through one (assuming an appropriately architected DNS deployment). This provides an opportunity to interrogate each of these queries and make a judgement on whether or not to get an answer, and then whether or not to pass that answer to the client.
Yet this functionality represents only a small piece of what DNS firewalls could be truly capable of. Due to their location on the network, external-facing DNS firewalls are unable to see which device made a particular query. In other words, the actual device on the network is unattributed; external-facing DNS firewalls can only scratch the surface of potential value. They can block what is “bad for everyone” but fail to apply the context that DNS can bring to the table.
Turn DNS data collection and control inwards
The organizations I work with manage between tens of thousands and 3-4 million “things” on their networks. These “things” can be traditional, like user driven devices (laptops, phones, tablets, etc) and single purpose devices (printers, voip phones, etc). They can be physical servers in the data centers and cloud. They can also be special purpose devices, like Point of Sale machines, medical devices, sensors, smart TVs, and other IoT devices. And as of late, they can represent a new class of things – ephemeral compute, by way of containerized applications and services.
If I were to look at the DNS queries coming directly from any one of these things, I’d be able to tell you which is which. That’s because medical devices have an identifiable pattern of queries they send, as do printers and user laptops. It’s also because I look at a ridiculous number of DNS queries.
The network territory where I glean this hot-off-the-press, attributable data is called the edge of the network, or the first hop. It’s the space between a device and the first DNS resolver, before DNS queries start hopping through the DNS infrastructure on their way to finding answers (which means before correlatable information like device profile and source IP fall away).
Turning DNS data gathering inwards, towards the edge, will allow you to examine the contextual data you need to shut down malicious activity long before it attempts to smuggle data out of the network.
By collecting correlatable information like (but not limited to) device profile, source IP, and response data, your organization’s threat hunters will have more of what they need to catch a network threat earlier along the cyber kill chain. That means fewer close calls for everyone.
They’ll be able to know not only which device made a query and what the query was, but also see information like the response that query received. Imagine not having to worry about your office’s fancy new smart fish tank being a liability anymore. Imagine being able to stop a threat on the spot, with DNS as part of your control plane.
Why look inwards?
Compromised devices can, and often do, act locally to perform reconnaissance or hoover up data before communicating out. These internal queries, to private DNS, are not seen at all by most external facing DNS firewalls.
Visibility into contextual insights–which can only be won at the edge–enables a powerful new kind of context-based policy action that today’s attackers require. If I know the end device is a special purpose device, like a Point of Sale machine, I now have the context I need to obtain much more sophisticated control. I can limit what a specific device, or group of devices, can access, as opposed to treating it like it a user’s smartphone.
Further, by having device attribution of this data, I can spot patterns that are difficult or impossible to find among a firehose of data that doesn’t have originating device attribution.
This increased signal-to-noise ratio, enabled by device attribution, improves a security team’s ability to spot and stop anomalies. I guide the organizations we work with to leverage this every chance I get.
If systems have been compromised, having device identity allows DNS to become a powerful tool for forensics. Without having to manually correlate across multiple systems and data points.
My advice may not be for you
DNS and relevant information, like IP data and device profiles, wasn’t traditionally easy to wrangle. But a decade ago, there was less of it to wrangle. That’s the assumption many of today’s largest networks were built on, and it’s beginning to show.
You’d be alarmed at how many enterprises still have IT teams disparately patching data together with spreadsheets just for operations’ sake, let alone cybersecurity. They couldn’t, in their current state, handle introspective DNS data and action at the scale they need to do what I’m talking about.
Being able to strategically leverage DNS will require treating DNS-related decisions more strategically, too. As organizations approach their DNS’ complexity threshold, technology leaders like you will need to choose sustainable, adaptive systems to enable that. Remember that the next time you make a DNS-related decision.