The Inner Circle

Expand all | Collapse all

NSA Selecting a Protective DNS Service

  • 1.  NSA Selecting a Protective DNS Service

    Posted Mar 06, 2021 11:58:00 PM
      |   view attached
    Hi All,

    The NSA just published Selecting a Protective DNS Service.

    Due to the centrality of DNS for cybersecurity, the Department of Defense (DoD) included DNS filtering as a requirement
    in its Cybersecurity Maturity Model Certification (CMMC) standard (SC.3.192). The Cybersecurity and Infrastructure
    Security Agency issued a memo and directive requiring U.S. government organizations to take steps to mitigate related
    DNS issues. Additionally, the National Security Agency has published guidance documents on defending DNS [1, 2, 3].
    This guidance outlines the benefits and risks of using a protective DNS service and assesses several commercial PDNS
    providers based on reported capabilities. The assessment is meant to serve as information for organizations, not as
    recommendations for provider selection. Users of these services must evaluate their architectures and specific needs
    when choosing a service for PDNS and then validate that a provider meets those needs.

    ------------------------------
    Michael Roza CPA, CISA, CIA, MBA, Exec MBA
    ------------------------------


  • 2.  RE: NSA Selecting a Protective DNS Service

    Posted Mar 07, 2021 07:29:00 AM
    Edited by Simon Waters Mar 07, 2021 07:32:57 AM

    For some reason I thought this had come out a little while ago.

    It doesn't mention ECS (DNS recursive resolvers pass on the client subnet to allow DNS based load balancing), this is a fairly direct trade-off between privacy and performance, although my experience of life with/without is I'd always opt for privacy, especially if the recursive resolvers are relatively close to the client devices. Partly because this immediately risks leaking identity clues which is you've deploy DNS over TLS or DNS over HTTPS, you'd reclaimed.

    It only mentions exfiltration once, where as some providers aren't attempting to keep fine enough metrics to spot and act on exfiltration attempts in real time.

    I've seen reports of vastly differing levels of effectiveness in blocking the low hanging threats between PDNS providers (caveat emptor), which leads me to a cynicism that either you want the best and put serious effort in, or perhaps you'll get 90+% of the value from using Quad9 everywhere, or similar commodity service. Worth being brutally honest about security gain per buck here, if you aren't prepared to proxy all HTTPS traffic, or other strong controls, this is a control that may be easily bypassed in many configurations, even if it is by using IP addresses (malware doesn't have to look pretty). So I see it about reducing noise from phishing, and other common threats, and another hurdle for attackers to trip over or work to avoid.

    NCSC pushed hard on this in the UK and offer its own protective DNS service for the UK public sector.

    NCSC are cagey about the zone files that they use as blacklists for the service (RPZ).

    The NCSC service does explicitly stop newly registered domains for a period, and I've seen incidents stopped by this control.

    Indeed a nice psychological technique we saw was scammers emailing out "see the attached documents" with no document attached, and then researching and registering domains relevant to anyone who "bites" and replies "you didn't attach a document", by sending a more comprehensive and convincing email with links for newly registered domains, which also looks solicited as it is a reply to an existing thread, to make them more likely to open the file. 

    Of course the problem with being harsh on newly registered domains, is not only false positives, but that it is easily bypassed. Skilled threat actors are already buying established domains, this was one of the techniques noted as used by the actors behind the "Solarwinds" campaign. Some of the DNS analytics folk like Farsight track DNS changes as an additional signal. less skilled threat actors could just wait a week or two. Most people's networks will rapidly leak if their DNS is resolving a domain, heck quite a lot of places the security tools will leak that information by scanning links.



    ------------------------------
    Simon Waters

    ------------------------------



  • 3.  RE: NSA Selecting a Protective DNS Service

    Posted Mar 07, 2021 11:12:00 AM
    Hi Simon,

    You are probably thinking of "NSA Adopting Encrypted DNS in Enterprise Environments".


    ------------------------------
    Michael Roza CPA, CISA, CIA, MBA, Exec MBA
    ------------------------------



  • 4.  RE: NSA Selecting a Protective DNS Service

    Posted Mar 07, 2021 11:14:00 AM
      |   view attached
    Attached is the document: NSA Adopting Encrypted DNS in Enterprise Environments

    ------------------------------
    Michael Roza CPA, CISA, CIA, MBA, Exec MBA
    ------------------------------



  • 5.  RE: NSA Selecting a Protective DNS Service

    Posted Mar 08, 2021 01:43:00 PM
    For some concrete info on setting up RPZ in BIND and getting a DNS firewall going there's an old article of mine from Linux Magazine in 2014:

    https://www.linux-magazine.com/Issues/2014/161/Security-Lessons-DNS-Security

    TL;DR: firewall outgoing port 53, force clients through a controlled resolver, and use RPZ to apply policy as desired. More details are in the above article.

    As for logging everything so you can find indicators of compromise and so on:

    https://www.linux-magazine.com/Issues/2014/162/Security-Lessons-Logging-DNS-Replies/(language)/eng-US

    TL;DR: firewall outgoing port 53, force clients through a controlled resolver and enable logging. More details are in the above article.

    Obviously with DoH (DNS over HTTPS) you would also need a HTTPS proxy that can filter DNS requests, but most bad guys aren't using DoH... yet.

    ------------------------------
    Kurt Seifried
    Chief Blockchain Officer and Director of Special Projects
    Cloud Security Alliance
    [email protected]
    ------------------------------