Skip to main content
  • Cybersecurity

What to look for in DNS/domain block data to determine risk

By Rob Williamson
Marketing Manager

When looking at reports on threat blocking you need to know where to focus. What to investigate can jump right out at you. Take this CIRA DNS Firewall data from an organization, in this case, a municipality, with a few hundred network users and a modestly sized IT team (servicing tens of thousands of citizens). Not big, but not tiny. Large enough to have at least some budget for defensive layers for the network and the endpoint, one of which is the DNS to refuse queries to threats. 

DNS queries typically come from clicks on phishing emails, website visits by employees to risky locations, and from botnets. In this case, it isn’t an unmanageable number (trust me, some are huge!) and so an IT team can review the data rather than model it in an external tool like a SEIM. It is easy to spot if a spike occurs that suggests a targeted attack or a botnet infection. For example, if there is a particular domain with a lot of hits that may mean a phishing email got through the mail filters and the IT team can quickly assess they type of risk and alert the users.

But what happens when your organization is about 10x larger? What does a spike look like then? In the below instance, there are two obvious peaks, but others may be hidden in the data. It may suggest that individual teams are being targeted or that multiple users are impacted. Here is where you look for the domain being hit several times. Simply scanning the URLs can show an obvious spear-phish, or a trend that shows the frequency of specific domains or related domains. It also allows IT teams that segregate multiple networks to manage the risk across the user types. 

For a look at the day in the life of machine learning, we are now going to take it to CIRA-level. I am not talking about the AI used to look for anomalies in all DNS data globally, but in looking at the block data from Canadian customers. This is the kind of analysis that an IT security manager in a larger company may do in a SEIM that is aggregating data from many sources.  If that isn’t what you are doing, then the network-level lists are useful to see what networks you manage are seeing what threats. In our case, I am looking at the DNS block data across the firewall customers for a short segment of time. We aren’t going to pull out a single customer here because that gets too identifiable, but we will use CIRA’s aggregate data as an example. Across the network this is the kind of data we see:

These numbers are too high to do much with as a human interacting with the data (versus AI or machine learning). But that doesn’t mean that a human looking at the block data doesn’t have something of value to learn – and for this, there are two different metrics to look at. Query volume and the number of impacted users or networks. On the query volume side, the data is not very useful because it is heavily influenced by just a few infected machines. So sure, in the image below we have almost 4 million queries to a single malicious domain, but when we look at where they are coming from, they are a single IP address. Something for that customer to address for sure! But not an existential threat to Canadian networks.

The list is quite different when you look at the number of individual accounts that are attempting to visit malware sites. In the example below, you have hundreds of accounts attempting to visit potentially dangerous sites. Some could be overt threats, some perhaps unintentionally hosting malvertising, and sometimes we even see compromised sites that used to be legitimate. This can often include infected sites hitting smaller local businesses and even apps that our customers built themselves. Really, this is a reminder that “zero-trust” is the best way to think about security in most instances.

When we see a lot of accounts attempting to go to the same URL that is more concerning because it suggests something pervasive. In many cases, this is typo squatting, but in the past, we have seen spikes in things like drive-by bitcoin mining (a problem that has thankfully come under control somewhat). We have even had a customer that we spoke to see spikes going to a local golf course that had their site hacked shortly before a municipal golf tournament.

A few words on content filtering and reviewing that data

Content filtering can be a hot topic as it relates to individuals, but as it relates to business it is a commonly used tool for cybersecurity. Sure some organizations want to keep inappropriate content off the network (or consuming bandwidth) and can do that with policy and tools. Some operate public wifi where some content is possibly undesirable, and so discouraged. But it isn’t just about corporate censorship because there is a legitimate security need too. Certain types of content are just proven to house more threats. Moreover, many threats are housed in sites that look good. For instance, sites with downloadable activity and colouring book pages for kids (popular in the pandemic) are very often exploited as threat vectors. Online storage not approved by the IT team is also a threat because that is often how hackers distribute malicious content. And finally, anonymizers may be used by employees to do things that the IT team may not want them to do.

If you do content filtering, then reviewing the daily block report is not generally necessary or useful because it is almost guaranteed to be huge. From our experience, almost nobody does it outside of a SIEM context where they are looking to machine learning to spot behavioural changes. But this is a pretty extreme use of technology and only for well-funded IT security teams protecting really critical data. However, if you do choose to, make sure you understand the sensitivity of the issue.

To conclude, what are the core recommendations on evaluating DNS threat blocking? 

  1. Identify botnets that could be on your network fast because they could represent a back door.
  2. Don’t sweat the total number of blocks if that is the normal state – but look at the spikes. Are they single user-generated? Single department? Is the URL particularly targeted (i.e. a typo-squatted domain on a large supplier)?
  3. Address spear phishing or pervasive threats appropriately with a mix of education and technology.
  4. Content filtering is an important part of security – but use it wisely.

About the author
Rob Williamson

Rob brings over 20 years of experience in the technology industry writing, presenting and blogging on subjects as varied as software development tools, silicon reverse engineering, cyber-security and the DNS. An avid product marketer who takes the time to speak to IT professionals with the information and details they need for their jobs.