With enough data, any problem can be understood. Solving it is another matter.
I’ve used that phrase a few times, and it continues to ring true. The challenge to this bit of wisdom comes from my security industry colleagues in the form of a complaint that we simply don’t have enough data. We see this thinking in the “log everything” mandates going out from information security departments, and the fact that almost every security organization I’ve met in the last six months is evaluating various threat intelligence and other data feeds for their already overloaded SIEM platforms.
With all the available internal data from logs across the hundreds or thousands (or tens of thousands and so on) of endpoints you likely own, there is a virtual deluge of information available. It’s like trying to squeeze a hippopotamus through a doggy door. In many cases enterprise security is not even taking advantage of two key pieces of data that already should be available to them. I say should because there are a few exceptions here.
What, pray tell, are these two key pieces of information? Simple! Your DNS query records and your IP address information from your DHCP infrastructure. I realize DNS was a big buzz a few years ago and has faded back into obscurity, but it’s time to realize what we’ve got here. Additionally, many of you won’t ever have the occasion to look at your DHCP logs primarily because they’re managed by either network infrastructure or systems teams, and you won’t have access. Such a shame.
These two key pieces of data from your network infrastructure are invaluable to your security analysis – yet you likely don’t ever look at it, you most certainly don’t have access to it and you probably wouldn’t be able to make sense of it if you had it. Again, such a shame.
So let’s talk about what having this information means and why you must get it right now.
First, let’s start with DNS. Today’s adversaries know you can block an IP address pretty quickly. Therefore, if they design their malware to communicate with specific IP addresses someone will find those through either reverse engineering or monitoring and, as a result, be able to block them. So rather than hard-coding IP addresses into malware, authors have relied on domain-generation algorithms to generate potentially thousands of DNS host names that to which their bugs will attempt to connect. They then can cycle those domain records quickly to point to different IP blocks and even generate entirely different domains/subdomains when the ones to which they’re connecting go dark. Your defense here is your DNS infrastructure.
I hope that, by now, you’re not letting each endpoint go out to the internet to resolve their own DNS records. That’s just lunacy! However, if you’re aggregating and forwarding (through a DNS forwarder) all internal DNS records through a set of servers you’re likely running BIND or Microsoft DNS. Your decision largely depends on whether you’re on Linux or Windows shop for servers. Either way, you’re likely throwing way the treasure trove this affords you.
Likewise, you probably manage the distribution of your IP addresses through a Windows or Linux DHCP server. There are strikingly few options for effectively managing and distributing IP addresses on an enterprise network. Once again, if you’re not mining this information from a security perspective you’re missing out—big.
Here’s why these two are so critical to your enterprise security. There are three things having solid DNS and IP Address Management (IPAM) will get you. Through centralizing and aggregating DNS and IPAM data your security organization can:
• detect and identify malicious activity faster
• contain threats more effectively
• respond to threats more completely
The detection and identification of malicious activity is faster because you can compare it against not just known bad target IP addresses but also against known bad domain and host names. Also, anomalies in the way that DNS queries are made could mean that an attacker is exfiltrating sensitive information from your network over legitimate DNS packets. There is a small likelihood of security teams accidentally stumbling upon this if there aren’t tools looking for it. The fact is, the more complete your understanding of what DNS hostnames for which your endpoints are asking, the better your understanding will be of the threats that face you.
You can contain threats more effectively by quickly identifying malicious endpoints then removing their ability to talk on your network. You can automate this by simply implementing a lookup in a switch’s CAM table against the MAC address that holds a particular malicious IP address, then turn off that port. This effectively removes the threat from the network. You have not eliminated the threat, but you have contained it to a single endpoint or group of endpoints rather than allowing it to roam free. You can deny IP addresses on the network (DHCP reject) to endpoints that don’t meet requirements or have specific attributes. Or, if that doesn’t work, you can turn down the switch port as in the previous example.
By having a more complete picture of what your endpoints do, who is at them and to where they talk, it’s possible to have a more complete incident response process. By tying a DNS query which is deemed suspect to an IP address and to a series of attributes such as who is currently logged in, the patch level of that endpoint (and so on) provides a wealth of information that can help triage an incident or identify a false-positive quicker and more accurately.
This all leads me to the most basic question: with this tremendous gain in security from DNS and IPAM visibility, is your security organization benefitting? Meaning, are you getting the added control and wealth of information you should be. If the answer is no, perhaps it’s time to start. Centralize your DNS infrastructure, define the right degree of logging for your organization and start collecting information. Likewise, define an IPAM strategy. There are inexpensive many tools available which execute these functions discussed here, but step one is to define a strategy.
Get better visibility, improve containment and incident response. Use data you’re already generating and get a better grip on security from the core services your IT infrastructure already delivers to your endpoints today.
Related Reading: Don’t Forget DNS Server Security
Related Reading: Do You Know What your DNS Resolver is Doing Right Now?
Related Reading: Incident Response – Focus on Big Value, Not Big Data
Related Reading: Nearly 50% of Organizations Hit With DNS Attack in Last 12 Months