We were delighted to learn recently about a free service offered by the National Security Agency (NSA) to DoD contractors: Protective Domain Name System (PDNS), also known as DNS filtering. As a small business DoD contractor strapped for resources, it’s unlikely you will ever hear us complaining about a free service. After being introduced to PDNS and getting it going in our environment, we knew that we needed to tell our fellow Defense Industrial Base (DIB) members about it. In this post, we will describe our experiences with PDNS, from setup to continuous monitoring, and we will identify how DNS filtering can come in handy for those of us pursuing Cybersecurity Maturity Model Certification (CMMC).
What is DNS filtering?
When you want to visit a webpage, you enter the domain name (e.g., totem.tech) into your browser’s search utility, and you hit “go”. Although humans can communicate and understand domain names, computers cannot; they need the equivalent Internet Protocol (IP) address for that given domain in order to connect you there. It would be incredibly burdensome for humans to have to memorize every public IP address of every site they want to visit, which is why the Domain Name System (DNS) was created. It serves as a sort of “address book”, linking IP addresses with their domains.
When you attempt to connect to totem.tech, your machine sends a “query” to a DNS server on your local network or on the Internet, which then replies to that query with the IP address for totem.tech. Once your machine receives the reply it can then connect to that IP address. We refer to this back-and-forth process as domain name “resolution”. Your company can actually configure which DNS server your machine uses for resolution. By default, endpoint machines send queries to a default gateway, typically a firewall or WiFi router, but this can (and should) be changed.
Not all DNS queries are the result of a user intently searching for a webpage. Many — if not most — DNS queries are in fact made by background processes or software applications running on a machine. These application-initiated DNS queries are part of what powers our modern app-centric world. However, some of these apps may be undesirable, and some may be downright malicious. In some cases, DNS queries could signal a malware infestation, which may allow an adversary to successfully gain access to Controlled Unclassified Information (CUI).
Additionally, occasionally, your users may accidentally browse or be redirected to a malicious domain, perhaps by clicking on a link in a phishing email. Moreover, your organization probably doesn’t want its users to be able to visit certain sites, such as gambling or pornography, from work machines.
And more and more frequently we see DNS used in cybertheft. Since DNS queries must be allowed outbound for most companies’ networks to operate correctly, adversaries who have gained a foothold in a company network use seemingly legitimate DNS queries to exfiltrate sensitive company information, “piggy-back” style, to imposter DNS resolvers under their control.
What’s needed to control unneeded, unwanted, malicious, or cyber-thieving DNS queries is some sort of “filter”: something that can block a machine from being able to translate a domain name into a reachable IP address, therefore preventing the machine from connecting to that IP address, and perhaps consequently preventing an incident from occurring.
That’s where DNS filtering — also known as DNS blocking — services come in. Instead of allowing your machines to send DNS queries to their default DNS servers, you reconfigure them to send their queries to a DNS server that checks the queries against a “blacklist” of known unwanted or malicious domains or IP addresses. If the domain in the query is on the blacklist, the DNS server simply does not reply to your machine with the IP address, so your machine can’t connect. If the query came from a user’s browser, in lieu of an IP address, the DNS filter server will post a message in the browser such as “The domain in question is associated with malicious behavior; this connection has been blocked”.
DNS filtering is a simple, yet very powerful, mitigation against many known and unknown network threats. If your machine can’t resolve the malicious site, the malicious activity can’t take place. Many commercial firewalls come with DNS filtering services available for an additional fee. You can also purchase Internet-based DNS filtering services from companies such as CloudFlare. But the PDNS service from the NSA is free for DIB members, so we’ve decided to take advantage of that and save some cybersecurity costs. Let’s learn a little more about this service.
What is PDNS, and how does it work?
The NSA offers PDNS as a free DNS filtering service, available to DoD contractors, as they describe on their PDNS webpage:
"The mission of the NSA Cybersecurity Collaboration Center is to secure the Defense Industrial Base against threats from malicious cyber actors. To quickly improve cybersecurity at scale, NSA is leveraging PDNS as a low-cost, high impact service that protects critical DIB endpoints from resolving queries to potentially malicious websites."
PDNS is built upon respected security company Akamai’s GovShield architecture, which utilizes both commercial and government threat intelligence to block malware and phishing domains, and it also includes some web content filtering capabilities. Given that phishing is the single greatest threat facing all businesses of all sizes, this is a huge win for DIB members looking to boost up their defense-in-depth cybersecurity programs.
PDNS also comes with a user interface dashboard (“console”) that you can use to review activity as well as perform some configuration changes.
Implementing PDNS
PDNS is quite easy for DoD contractors to put in place. In this section, we will outline the steps necessary to get it up and running in your environment.
Step 1: Determine your eligibility for PDNS. If you have an active DoD contract or have access to DoD information, you likely qualify for PDNS. Reach out to [email protected] or fill out the contact form to inquire about your eligibility for PDNS. If you qualify, you should eventually receive a response from someone at the NSA’s Cybersecurity Collaboration Center, who will provide you with some information about setting up PDNS, and they will put you in touch with Akamai’s GovShield support team.
Step 2: Work with Akamai to enable PDNS. Akamai will require you to fill out and submit a consent form, in addition to providing them with the users in your environment who will be using PDNS. This should include anyone on your internal IT staff or your Managed Service Provider (MSP) team who helps facilitate your cybersecurity program.
Finally, you will be asked to provide Akamai with the public IP address space in which they can expect to receive DNS queries from, i.e. your company’s IP addresses. If you do not know this, you will likely need to get in touch with your Internet Service Provider (ISP). Akamai will let you know if the IP range you provide is/is not valid.
Step 3: Update your DNS infrastructure and confirm that PDNS is enabled. Once Step 1 and Step 2 are complete, you will receive from Akamai a list of the GovShield PDNS service IPs (for two separate regions) which you may use. Work with your IT team to reconfigure your internal DNS server(s) (your “recursive DNS resolvers” as the NSA calls them) to at least two of the IPs for each region. (NOTE: If you don’t use an internal DNS resolver as an intermediary between your endpoints and Internet-based DNS resolvers, it’s a good idea to set one up, even if it’s your firewall. Having workstations and servers query external DNS servers directly is a bad practice, and there are added benefits for internal DNS resolution. And if you don’t even have a firewall? C’mon man!) Configuring DNS service in two regions is recommended to ensure service availability.
Once this is done, Akamai should provide a webpage that you can visit to confirm that the service has been enabled.
Step 4: Enable all user accounts, login to PDNS console, and configure PDNS. Each of the user accounts you specified in Step 2 will receive an email with instructions for setting up their GovShield account, which they should do soon after receiving the email. They can expect to be required to change the default password upon signing in as well as enable multi-factor authentication (MFA) for their PDNS console account.
The Akamai GovShield console is simple to use. In addition to the default malicious site and botnet blocking, you can setup web filters to restrict traffic to problematic sites, such as those associated with gambling, pornography, games, politics, etc. The console comes pre-configured with “canned” web filtering: None, Light, Medium, and Strict.
You can also add custom lists to block or allow traffic to certain domains, including top-level domains (TLD) such as .ru and .cn. This TLD DNS filtering is beneficial to those of us trying to prevent our CUI from getting into the hands of our adversaries, as required by NIST 800-171 and CMMC. The screen shots below show examples of these two console features:
Step 5: Start monitoring PDNS. At this point, everything should be configured correctly, and you should begin seeing activity within the web interface. Although PDNS is doing the heavy lifting in actually filtering and blocking malicious domains, you still need to be continuously monitoring PDNS to see which domains your IT systems are communicating with. If you discover an anomaly or something that doesn’t look quite right, it may require further investigation into the process that is querying the suspicious domain. This has happened in our case, and we leverage free tools such as Windows Sysinternals’ Sysmon and Procmon to get to the bottom of these queries. NOTE: Starting with Sysmon is preferred, given that Procmon generates SO MUCH information (like, gigabytes in a matter of seconds) that it can be a real beast to use. For us, Sysmon has helped us identify the individual processes triggering DNS queries most of the time. When it doesn’t, we take a deep breath and *gulp* use Procmon. But, PDNS will help you identify when these anomalous queries are being made, and your IT team can decide how to proceed.
Once PDNS is up and running, your environment is much more secure. With DNS filtering in place, your company may be one step closer to CMMC compliance as well. We explore why below.
What does DNS filtering have to do with CMMC?
If you were to search through the present iteration of NIST 800-171 — the standard for the protection of CUI that includes the assessment objectives used for CMMC — you will not find anything related to DNS filtering, as it is not a current requirement. However, remember the old CMMC v.1.0 model that was done away with in November 2021? That version of the model contained 20 additional requirements, commonly known as the “delta 20”, that are not part of the current NIST 800-171 standard. Any guesses as to which requirement was included in the delta 20? If you said “DNS filtering”, you’re exactly right! Control SC.3.192 required the use of DNS filtering services.
Although it is not part of the current model, there has been plenty of speculation within the CMMC “ecosystem” over whether or not DNS filtering will be added back into the next revision of NIST 800-171, and therefore back on the table for CMMC. It would not come as a surprise if it were to appear again, as we have seen agencies such as the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) hint at its return. And, with the introduction of PDNS, the DIB has another free tool at its disposal to get DNS filtering in place with little work and no cost required. So, we are operating under the assumption that it is likely to be added back in, and we strongly recommend that you keep it on your radar for CMMC. Plus, it’s just a good, easy to implement, cybersecurity practice.
So good a practice, in fact, that DNS filtering can be used to partially satisfy one of the existing NIST 800-171 assessment objectives, 3.14.6[c] “Outbound communications traffic is monitored to detect attacks and indicators of potential attacks.” DNS filtering is certainly an aspect of monitoring outbound communications traffic. Combine DNS filtering with a firewall configured to only allow specific outbound traffic, and your organization is well on its way to meeting this objective.
Wrapping up
That’s the basic run-through of what you can expect for getting the NSA’s PDNS up and running in your environment, as well as the implications of this service for CMMC. If you’d like to learn more about the current DFARS / CMMC / NIST 800-171 landscape, or how DNS filtering fits into a CMMC-compliant cybersecurity program, grab a seat in one of our Workshops. Or, drop us a line; we love talking about all this stuff!
Good Hunting!
-Adam
