In our fifth breakdown of the Networks Pillar requirements as outlined in M-22-09, we will discuss the pillar summary, necessary situational awareness items, and action items for agencies responsible for meeting the mandate. This section is broken into five topics: network visibility and attack surface, encrypting DNS traffic, encrypting HTTP traffic, encrypting e-mail traffic and enterprise-wide architecture and isolation strategy.
Networks – Bottom Line Up Front (BLUF):
As agencies segment networks, move away from intranets and permit access to enterprise services from any network, inspecting traffic in these environments will become less practical and valuable over time.
This is consistent with the Trusted Internet Connection (TIC) initiative, as updated in OMB Memorandum M-19-26, which gives agencies the flexibility to maintain appropriate visibility without needing to perform inline traffic decryption.
DO make heavy internal use of recent versions of encryption protocols like TLS 1.3 that are designed to resist bulk decryption.
DO use deep traffic inspection which can correlate with visible or logged metadata, machine learning techniques, and other heuristics for detecting anomalous activity. As described in NIST SP 800-27, risks of weak or compromised network inspection devices can be higher for networks that service a diverse set of users, devices and network destinations.
DO NOT rely on static cryptography keys with an overly broad ability to decrypt enterprise-wide traffic.
DNS is historically unencrypted but encryption is gaining adoption. Agencies are already required to have DNS requests routed through CISA-operated infrastructure. To support secure agency DNS traffic, CISA’s Protective DNS offering will support encrypted DNS communication and will scale to accommodate use from agency cloud infrastructure and mobile endpoints.
DO resolve DNS queries using encrypted DNS wherever it is technically supported. DNS resolvers must support DNS over HTTPS or DNS over TLS.
DO use encrypted DNS in applications like web browsers and at the operating system level where available.
DO use explicitly configured encrypted DNS servers rather than automatic network discovery.
DO continue to identify and log contents of DNS requests by accessing audit information from the designated DNS resolvers.
DO document in your zero trust migration plan, a description of instances that have identified a lack of technical support for encrypted DNS.
DO provide plans to update operating systems or otherwise ensure support for encrypted DNS enterprise-wise by FY24.
DO NOT use unencrypted DNS over TCP/UDP ports 53.
OMB Memorandum M-15-13 and DHS Binding Operational Directive (BOD) 18-01 currently require agencies to use HTTPS, the encrypted form of HTTP, across all internet-accessible web services and APIs. They do not, however, require the use of HTTPS for traffic that is solely internal. Zero trust architectures—and this strategy— require agencies to encrypt all HTTP traffic, including within their environments.
DO work with the DotGov Program at CISA to “preload” agency-owned .gov domains as HTTPS-only in web browsers.
DO be aware that the .gov Top-level domain has announced an intent to eventually preload the entire .gov space as HTTPS-only zone.
DO NOT use unencrypted HTTP traffic within even your internal network. Always use HTTPS.
CISA will evaluate the viability of this initiative and make recommendations to OMB to inform future actions because unlike HTTP and DNS, there is not a clear path forward today for guaranteeing that Federal emails are encrypted in-transit, particularly for emails with external parties. As part of its evaluation, CISA should partner with FedRAMP to convene and consult with cloud service providers and other participants in the email ecosystem.
DO in consultation with CISA, develop a zero-trust architecture roadmap that describes how the agency intends to isolate its applications and environments.
DO include that roadmap in the full zero trust implementation and investment plan required by this memorandum. The roadmap should also describe the agency’s operational and security objectives for any enterprise-wide network it may currently operate. In addition, the agency should explain how cloud-based infrastructure will fit into the agency’s zero trust architecture.
DO move away from the practice of maintaining a broad enterprise-wide network that allows enhanced visibility or access to many distinct applications and enterprise functions.
DO strategically adopt cloud platforms which typically feature strong identity- and attribute-based access control and rely on identity governance and virtualized logical isolation of environments. As a result, they are well optimized for zero trust architectures, and agencies are expected to make robust, secure use of cloud-based infrastructure.
This is the fifth in a series of blog posts on Zero Trust and M-22-09. You can find the first post here along with posts on Identity, Devices and Applications and Workloads. Each week, Swish will publish a new post covering the Summary, Situational Awareness Items, and Agency Action items for each section of the Memorandum. Swish Engineering POCs are available for individual discussions. Contact Us to learn more!