Infoblox for the Security Analyst Part 1: Why INTERNAL DNS Matters to the Security Analyst

MichaelKatz

by Michael Katz, Security Sales Specialist at Infoblox

 

This post stems from the many discussions I have had with the information security teams at Infoblox, customers, and prospects.  The Infoblox Grid is an incredible tool for Information Security teams, but with so many shiny security products, it’s easy to miss the straightforward value Infoblox provides the security analyst.   This is partially because, despite the prevalence of Infoblox in enterprise computing stacks, many information security teams don’t know what Infoblox does, nor do they have API or GUI access to the platform.  The fact is that the Infoblox grid is a goldmine for security analysts and should be the first stop in investigating and solving security challenges.  Here are a few reasons why Infoblox matters to information security teams.

 

Infoblox runs foundational DNS, DHCP, and IPAM services for over 9,000 companies, chances are your organization is running Infoblox for some or all of these services within your company.  While the name service is typically run by network teams, security teams that use the data, visibility and control Infoblox provides in the course of running foundational services have a tremendous security asset. Whether you’re an incident responder, cyber threat intel analyst, security automation architect, SOC engineer or CISO, there is significant value to a foundational security model.

 

Note: I will interchange DNS (Domain Name Service) with the phrase name service.  This is intentional.  DNS is a protocol, the name service runs on top of the DNS protocol, each requires a different approach to security.  There are three distinct name services – external, recursive and internal. Each name service has different risks, but we will focus on the most important DNS service to the IS team, the internal name service.  

 

It’s important to separate the name service from the data, visibility and control the name service offers to the information security team.  The DNS protocol can be used just like HTTP to carry any data.  The DNS protocol has an entirely different set of risks than the name service, just like HTTP has different risks than a web service.  DNS protocol security is generally an Information Security focus, just as it is for http traffic, where the server team runs the web service.

 

Slightly off-topic rant – Cyber Threat Intelligence and Internal DNS

 

The best way to improve your security posture today is to enable cyber threat intel checks on the internal name service (Internal DNS).  If you’ve already done this, you can skip the rant.  For the rest of you, please read twice.  The internal name service is the most important place to run cyber threat intel in your entire organization.  Why? The internal name service runs your day to day business.  Activating threat-intel checks puts the name service to work for you, as opposed to a being a dumb, massively insecure utility service.  Internal DNS without threat intel checks like using an old Sendmail SMTP relay with no virus, spam, rbl or security checks. You stopped using insecure SMTP relays in 2001, yet most internal DNS is wide open to malware while the security risks are similar to email.  Your goal is to stop threats as soon as possible, why not stop threats before they use your network? 

 

The name service initiates most network conversations, controls access to your network and should be your first-line network defense.  When threat intel checks are enabled, every name query is checked against threat data.  Additionally, even if you don’t use tons of the threat data, when threat intel checks are enabled DNS logs are enriched. A single log will provide the query, source host and response.  The main benefit is that when there’s an IOC hit, you can instantly find the true source address, URI and location of the offender.

 

It makes no sense to let malware use your network to spread laterally and venture into a recursive DNS cloud service. Why waste resources on your firewalls, routers, IDS and analytics systems checking connections against threat intel, when you can stop the majority of malware right from the internal name query.  Checking for malware on recursive DNS is a good secondary level of security, but recursive DNS security is no replacement for internal DNS threat intel checks.   You are giving malware a running start by letting them run around the internal network without CTI checks.  Threat intel on the external DNS is also extremely valuable, but that’s for another discussion.

 

Response Policy Zones are the underlying tech activating threat intel checks on DNS.  RPZ enables custom DNS responses, which enables quite a bit of functionality. Though Infoblox has greatly enhanced generic RPZ, all of the key elements in the standard still apply.  DNS is the only critical network service with a built-in, low-impact method for real-time intel checks.  RPZ was built by some of the smartest guys of the Internet age and it works extremely well.

 

There is no reason to NOT deploy threat intel on your internal DNS system. One of the smartest people who created the Internet as we know it, Paul Vixie, helped figure out how to run IOC (Indicators of Compromise) checks just like another DNS zone.  A zone is a long list of names, an IOC list is a long list of names – threat intel is a natural fit for real-time CTI checks.  There is no parallel in security where you run internal systems wide open, flapping in the wind while leaving security to perimeter gateways and external cloud services.   You’ve moved from FTP to SFTP, Sendmail to Exchange, Telnet to SSH, HTTP to HTTPS, encryption in transit to encryption at rest.   Bottom line, don’t spend a nickel on recursive DNS security until you’ve secured the internal name service. 

 

End of Rant

 

So back to the main point, what can a security analyst get from the Infoblox Grid?

 

Accessing the Infoblox Grid

Security Analysts should have read-only access to the Infoblox web GUI and an API access key. The first stop in a threat investigation should be the Infoblox grid to see the history, movement, connections, detailed host data, location, and more. The Infoblox Grid has intuitive global search tools for real-time and historical incident data by IP, host, domain, MAC address, FQDN, IOC match, connection destination, connection source, DHCP fingerprint (asset class), login name and lots more.  All search tools are available via an API that is well documented within the Infoblox GUI and on community.infoblox.com. 

 

SOC Analysts should take a look at the DNS health dashboards, and additional dashboards available if the reporting tool is online.  The reporting server has many pre-built reports and dashboards that can track malware events, internal and external traffic patterns, IPAM activity, NXDOMAIN activity, DNS health, tunnel and exfiltration activity and much more.   

 

SOC teams should definitely think about the automation opportunities the grid provides.  Since Infoblox has inbound AND outbound APIs, the grid can be both an enforcement point and trigger in automation workflows.  A malware hit on internal DNS can trigger a ticket in Service Now, vulnerability scan or NAC event.  A new DHCP host can trigger a NAC or vulnerability action, a malware hit from an APT tool can trigger a block in Infoblox, etc.  The possibilities are limitless once you think of the DNS, DHCP, and IPAM as automation trigger and enforcement points.

 

If you are using the Infoblox recursive DNS security service, BloxOne Threat Defense, Infoblox provides a unified reporting and log interface for both cloud and on-prem services.  The ATC GUI has additional dashboards and APIs to access the data.  Many of the behavioral analytics models Infoblox created for DGA, data exfiltration and tunnel detection, fast flux, and more, function in a hybrid cloud-on prem model. 

 

IP Address Management Database

The IPAM database has a vast amount of information for the security analyst.  IPAM data can quickly correlate IPs from security alerts to mac address, asset, asset class, login, exact network location and more.  The IPAM database stores detailed information about each system down to the switch port level and tracks all past movements of a host.  DHCP logs have very important security data and should be a high priority in your log capture strategy.

 

Simply putting an IP in the top right global search box will yield useful artifacts, which can be tailored in advanced searches.  Once you have the search you want in the GUI, you can easily transform the query to REST API and bring the data into your investigations platform.

 

Infoblox enriches IPAM data with a unique DHCP fingerprint.  This makes it easy to find groups of like systems and to track mobile hosts.  You can even create your own fingerprints.  Extensible Attributes provide free form tags, with inheritance, that have many practical applications.  

 

Since Infoblox provides a full IP Address Management system, discovery is a critical part of the solution.  The Infoblox discovery engine, Network Insight, and it’s big brother, NetMRI, are optional components of the grid.  They share the same discovery engine.  If active on your grid, these time-tested tools will discover all assets on the network.  The Infoblox discovery engine works with switches, firewalls, and routers to ensure we catalog every device, irrespective of DHCP configuration.  The discovery tools also add network location information to each IPAM entry.  Having a single source of IPAM truth is a critical security goal, discovery should be a part of your grid.

 

DNS Data

The Infoblox Grid can show the query history for an IP, domain or host.  The best DNS data comes from the first hop DNS responder. Once a query is recursed to the Internet, the true source address is gone.  This is one of the principal reasons recursive DNS malware checks are not as useful as they appear.  When Response Policy Zones are turned on, the first hop DNS log is an extremely powerful tool.  It will show you the complete URI string and the source address of a query.   If you activate threat intel on the internal DNS, you will have an instant correlation of infected host, source, and URI string on any IOC match.   This is one of the most useful log messages a security analyst can have. 

 

Activating threat Intel on Internal DNS

Infoblox BloxOne Threat Defense gives you all the tools you need to secure internal DNS.  The Infoblox Cyber Intel Unit creates DNS focused intel – IOCs, signatures and behavioral models.  Infoblox models for real-time tunneling, exfiltration and DGA detection are publicly presented at IEEE and other research forums, and some are patented.  The IOC data we create can be shared throughout your security architecture with TIDE, Threat Intel Data Exchange.  TIDE is a threat intel sharing platform included with BloxOne Threat Defense.   TIDE can also combine other threat data like ISAC data and partner intel providers like FarSight, CrowdStrike, and others.  

 

Query-Response Logs

Query Responses are the most useful DNS log, and they are much more useful with threat intel checks enabled.  It’s critical to log internal DNS queries to the Infoblox reporting server or an equivalent system.  That being said, you don’t have to choose where to send our logs.  The Dataconnector appliance is a VM that can be deployed to hold, batch, or pass logs to other external systems, like Amazon S3.  If your SIEM is too overwhelmed for DNS logs, use the Infoblox tools so the security team has insights into DNS data.

 

Threat Enrichment

If your company has a BloxOne Threat Defense subscription, you have access to the Dossier Threat Research engine.  Like all Infoblox tools, Dossier can be accessed via GUI or API.  Dossier is a thorough threat research tool that can enrich investigations, SIEM, SOAR or SOC workflows.  You can try the Dossier threat research tool for free.

 

Summary

Hopefully, this article will spawn many read-only access requests to the Infoblox Grid from security analysts and even more requests for API tokens.  There is no associative cost to log into the grid, the data is there whether you use it or not.  Many security analytics companies have figured out the value of internal DNS and DHCP data and they happily sell your data back to you.  Why not take advantage of all the data an inside-out, foundational security approach can bring?  The Infoblox Grid is a tremendous security asset that will make many security analyst jobs easier.  And the last word – secure the internal DNS, you can’t put it off any longer.

 

 

For Further Reference:

https://tools.ietf.org/id/draft-vixie-dnsop-dns-rpz-00.html