In January 2020, the US Department of Defense released version 1.0 of the much-anticipated Cybersecurity Maturity Model Certification (CMMC) standard. CMMC is the latest in a long line of compliance standards, authorities to operate, and other technical barriers to entry for companies who want to do business with the military. As with many others, CMMC is designed to protect controlled unclassified information (CUI) throughout the DOD supply chain.
Unlike previous compliance controls and processes, however, this one comes with teeth. Self-certification is not an option. Organizations will have to certify through a third-party assessment organization (3PAO).
DOD is already projecting that CMMC requirements will appear in contracts as early as June 2020. This puts DOD contractors in the Defense Industrial Base (DIB) under immense pressure to comply, even though the 3PAO certification process is not yet up and running.
Thankfully, CMMC doesn’t contain a lot of new material. For the most part, it rehashes security controls from other government cybersecurity standards developed by the National Institute of Standards and Technology (NIST). Even the organization of controls feels familiar from NIST SP 800-53, NIST SP 800-171, the SANS CIS model, and various FAR clauses which have been in effect for years. The difference this time is that companies have to prove compliance, not just say they’re compliant.
CMMC is also organized into five security levels, which range from “basic cyber hygiene” to “advanced/proactive”. Organizations will have to choose which level they want to certify against based on their product portfolios and the requirements of DOD contracts they want to bid on. If current practice is any indication, DOD agencies will use level five almost exclusively.
DNS security is a consistent theme across CMMC control families. While different tactics are recommended for various levels of certification, it is clear that DOD expects vendors to have complete visibility into their DNS traffic as well as the ability to control it. Here’s a quick overview of how DNS security plays into the CMMC controls, and how BlueCat promotes compliance.
Capability 039 – Control communications at system boundaries
This is the capability where DNS plays the most explicit role in CMMC compliance, particularly at the higher levels of this control family.
Level one (SC.1.175) sets an ambitious baseline, requiring organizations to “monitor, control, and protect organizational communications at the external boundaries and key internal boundaries of information systems.”
There are many different ways to accomplish this level of visibility, but a security solution based on DNS represents perhaps the most elegant solution (and one which anticipates the requirements of higher CMMC security levels). Since nearly every device and application on the network relies on DNS to communicate, it makes sense to use this common denominator for visibility and control.
Through the use of service points which act as the “first hop” in any DNS query, BlueCat provides the unique ability to monitor and control not only external, “north-south” traffic, but also internal, “east-west” traffic. This ability to place DNS controls anywhere and everywhere on the network gets to the “key internal boundaries” requirement in particular. When combined with DNS security on external boundaries through its Cisco Umbrella integration, BlueCat offers even more comprehensive coverage to satisfy this control.
Level three (SC.3.192) adds a level of specificity to the overall requirement for control over network communication, with a specific link to DNS. DOD describes this as a general requirement to “implement DNS filtering services” to reduce attack surface, but leaves selection of the filters up to the individual organizations.
In other words, an organization could take an external threat feed and apply it to DNS traffic, or create its own threat feed. Either method would result in compliance with this control.
BlueCat’s DNS security solutions allow for either method of filtering DNS queries. BlueCat provides external threat feeds to filter out known bad domains, but also allows for the creation of custom security policies. Since they can be applied to both internal and external traffic, those policies cover the entirety of a network, not just requests which reach the network boundary. Around 60% of all network traffic is internal, so the difference is pretty critical.
Level four (SC.4.199 and SC.4.229) takes the requirement for DNS filtering one step further. Where the level three control provides for some flexibility on how security policies are applied, level four explicitly requires the use of threat intelligence to define known bad domains. That threat intelligence can come from industry, government, or other sources, but the assumption is that it is vetted and curated to address current threat vectors. These controls are unique to CMMC – a new requirement for DOD vendors.
BlueCat addresses this requirement in two ways. Our “standard” threat feed is powered by a well known provider whose database of known bad domains is both highly specific and well-researched, drawing from a wide range of sources. In addition, the integration between BlueCat and Cisco Umbrella provides access to Cisco’s large database of bad domains, drawn from the real-time data of the world’s largest network infrastructure provider. Separately, these are best-of-breed threat feeds. Together, they represent an unmatched source of operational intelligence to fulfill this control.
Level five (SC.5.208), also unique to CMMC, goes beyond commercial threat feeds, applying the principles of DNS security to specific network architectures which may be unique to an organization. Building on the previous four levels, this control requires implementation or “organizationally defined and tailored” protections.
The example we use here at BlueCat is the case of a single-use IoT device like a security camera. All day it just sends data to a single server, and that’s the only thing it’s ever supposed to do. If that security camera suddenly sends a DNS query to any other domain, it’s clearly infected. It should be shut down immediately.
Standard threat feeds may block the domain which the security camera is trying to reach, but that is far from certain. If the domain is newly created, it might not appear yet in a threat feed. In these cases, your DNS security system has to be able to block traffic not just on the basis of the queried domain, but on the basis of the device type, application, user, or network area.
BlueCat’s unique position as the “first hop” of any network query allows this kind of security control to be put in place without the need for an on-device agent. With the ability to group devices based on defined policies, BlueCat makes the creation of customized, targeted security controls simple to implement across the enterprise.
Capability 037 – Implement threat monitoring
Level four (SA.4.173 and SA.4.171) of this control requires the implementation of a system for threat hunting which allows security personnel to quickly identify and disrupt anomalous activity. It then looks for a system to leverage, integrate, and share indicators of compromise across the organization.
DNS data is an essential tool for threat hunters, demonstrating the critical link between device-level activity and boundary-level indicators of compromise. The CMMC explanation of these controls specifically mention DNS data as a valuable source of actionable intelligence for threat hunters. Unfortunately, many organizations don’t collect comprehensive DNS logs because their DNS architecture is decentralized and virtually impossible to monitor at scale.
BlueCat provides a single source of truth for DNS data, automating collection and dissemination of core infrastructure information across the enterprise. Using this comprehensive source of intelligence on network activity, BlueCat’s government customers have cut their response time from over a week to hours or less. They can also use BlueCat’s control over DNS traffic pathways to consistently apply security policies across the enterprise simply and easily.
Learn more about using DNS to protect your network in our guide to choosing a DNS firewall.
Critical conversations on critical infrastructure
Find out how your peers are managing their networks through profound change. Watch this series of live interactive discussions with IT pros & join the debate in Slack.
Temporary workaround for SAD DNS
Ahead of Linux’s patch taking effect, BlueCat Labs has a temporary workaround for protecting against the revived Kaminsky DNS cache poisoning attack.
IT pros debate: Should you DIY your DDI?
Five IT pros get real about DIY vs. enterprise DNS solutions during the second Critical Conversation on Critical Infrastructure hosted in Network VIP.
How to Configure DHCP Failover
The DHCP failover protocol provides a method for two DHCP servers to communicate with each other.
How to configure Crossover High Availability (XHA)
In this demo, learn how to configure an XHA pair in BlueCat Integrity.