The Zero Trust security model isn’t entirely new, but it’s becoming more important as network perimeters disappear and applications and data are more distributed. Zero Trust assumes that threats can arise anywhere, inside or outside the network, and that every component of the network where data, assets, applications, and services reside must be validated and secured.
By Chris Buijs, Field CTO, NS1
For Zero Trust to be truly effective, organizations adopting these principles must extend the framework to all parts of their infrastructure. DDI can be an important first step in implementing Zero Trust, but so far, few people have recognized the value of this proposition.
DDI is a collective reference term that covers Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), and IP Address Management (IPAM). These three components comprise the foundation of core network services that enable all communications over an IP-based network. In fact, nothing can happen on a network without these critical services, which is how DDI plays into the notion of Zero Trust.
Traditional Implementation of a Zero Trust Architecture
The traditional concept of a Zero Trust Architecture follows a pattern:
A user wanting to connect to a resource initiates a secure connection and authenticates to a Zero Trust broker. The broker applies security policies according to the user’s identity and device attributes. Access is granted to a specific resource or set of resources only after the user and his or her device have met the requirements of the security policy. A secure session providing connectivity to the resource is then established and continuously monitored for potentially malicious behavior. If suspicious activity is identified, the user’s session can be isolated or dropped to prevent a breach.
That’s a lot of steps, a lot of security infrastructure, and a lot of network activity required to establish a trusted connection between a user and a resource. But much of this effort may not even be necessary if the DDI infrastructure is used first to evaluate the requested connection. In particular, DNS and DHCP offer many opportunities to enrich Zero Trust by including the underlay of the network as part of the process.
What the DDI Services Do
Enterprises use private DNS servers to store the names and IP addresses of internal file servers, mail servers, domain controllers, database servers, application servers, and the like. So, for example, if a user requests to connect to the Zero Trust broker, the internal DNS system will know the address where the broker service can be found before the user’s actual connection ever takes place.
DHCP simplifies the management of IP addresses on networks. No two hosts can have the same IP address, and configuring them manually would likely lead to errors. Also, some IP addresses, such as those for containers, virtual servers, and mobile devices, are needed on a non-permanent basis. Thus, a DHCP server is a network server that automatically provides and assigns IP addresses and other network parameters to client devices and other services.
IPAM is the administration of DNS and DHCP. It provides the means for planning, tracking, and managing the IP address space used in a network.
Using DDI to Enable Zero Trust
Together, DNS, DHCP, and IPAM are important factors in securing a network because these services enable everything on the network, and they get addressed before any application transaction happens. Think of it this way: If there is no IP address, there can be no connection or communication on the network. Thus, before any application connects to an endpoint, server, cloud entity, or whatever, there are first some network calls that must happen through these DDI services. This provides great leverage for security and influence on how an application is going to act.
Consider a network that doesn’t permit external access to YouTube for whatever reason. What happens if an app on the network wants to execute a link to YouTube? The first thing that happens is a DNS call that asks, “Where is YouTube on the Internet?” At this point, a rule on the DNS server can step in and say, “You’re on a private network, and YouTube isn’t allowed.” Consequently, the app is denied its DNS request, and no external communication ever takes place. Because this is all “built-in” to the DNS function, nothing else is required. As a bonus, because there is no network traffic, no bandwidth is consumed.
The good news is that DNS is already built into every application, so there’s no need to install anything to get the metrics or the data that can be used for security purposes. It’s all there, but it’s often overlooked. It’s time to put this facility to work to enable and enforce Zero Trust to protect data and applications.
About the Author
Chris Buijs is an evangelist and network and security specialist with more than 20 years of experience focusing on DDI (DNS, DHCP, and IPAM). He has held various leadership roles and capacities at vendors, and resellers. Chris has a rich background as a lobbyist for various issues to create awareness on tech-forward topics, including IPv6 and DNSSEC, and turns organizations into forward-thinking entities.
Views expressed in this article are personal. The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.