The Far Reach of the White House’s Zero Trust Memo
The new White House memo on zero trust is a strong signal that the US federal government is taking an active stance regarding cybersecurity. Not only does this have far-reaching ramifications for the public and private sectors, it also serves to cut through the noise about zero trust with an impartial source. Let’s look at what the White House has to say and what this means for the cybersecurity sector going forward.
I’ve organized this blog post into two sections:
- The Commentary — A section featuring parts of this memo that caught my attention and a bit of commentary.
- OK, So What? — How will this affect cybersecurity? What does this memo mean for all things US tech going forward?
A transition to a “zero trust” approach to security provides a defensible architecture for this new environment. As described in the Department of Defense Zero Trust Reference Architecture, “The foundational tenet of the Zero Trust Model is that no actor, system, network, or service operating outside or within the security perimeter is trusted. Instead, we must verify anything and everything attempting to establish access. It is a dramatic paradigm shift in philosophy of how we secure our infrastructure, networks, and data, from verify once at the perimeter to continual verification of each user, device, application, and transaction.”Page 2
Zero trust is not just about what you get rid of (e.g. trusted perimeter), but also what you add. Zero trust is about continuous verification of multiple sources of identity and context.
The devices that Federal staff use to do their jobs are consistently tracked and monitored, and the security posture of those devices is taken into account when granting access to internal resources.Page 2
Devices: The Federal Government has a complete inventory of every device it operates and authorizes for Government use, and can prevent, detect, and respond to incidents on those devices.Page 4
In thinking about identity aware access, many overlook device identity but it’s one of the most important context sources. I’m glad it’s called out.
In addition to authentication, agencies should ensure their tools can execute certain protocols for authorization. Authorization, a critical aspect of zero trust architecture, is the process of granting an authenticated entity access to resources. Authentication helps ensure that the user accessing a system is who they claim to be; authorization determines what that user has permission to do. Authorization happens after an authentication event and may be performed by a different set of controls from those that performed authentication. In a zero trust architecture, every request for access should be evaluated to determine whether it is appropriate, which requires the ability to continuously evaluate any active session. If undue risk is identified, mitigations could include requiring reauthentication, limiting access until confirmation that the user requested action is appropriate, or denying access entirely.Page 9
Continuous verification means every single access request should be authorized. Every. Single. Request. Verification should not stop just because the previous one was accepted.
Further, Federal applications cannot rely on network perimeter protections to guard against unauthorized access. Users should log into applications, rather than networks, and enterprise applications should eventually be able to be used over the public internet. In the near-term, every application should be treated as internet-accessible from a security perspective. As this approach is implemented, agencies will be expected to stop requiring application access be routed through specific networks, consistent with CISA’s zero trust maturity model.Page 3
HTTP is the core protocol used for serving applications to web browsers, whether these applications are public or internal-facing. However, beyond user-visible websites, HTTP is also commonly used for many APIs between servers, mobile applications, and other endpoints. 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.Page 14
A huge part of being able to externalize your network topology is being able to isolate and protect your internal data from tampering and eavesdropping in transit. Encrypt all the things. Everywhere. Mutual authentication and TLS is the ultimate form of segmentation.
Agencies must integrate and enforce MFA across applications involving authenticated access to Federal systems by agency staff, contractors, and partners. MFA should be integrated at the application layer, such as through an enterprise identity service as described above, rather than through network authentication (e.g., a virtual private network).Page 7
To that end, public-facing agency systems that support MFA must give users the option of using phishing-resistant authentication within one year of the issuance of this guidance. Meeting this requirement for the general public will mean providing support for Web Authentication-based approaches, such as security keys. Agencies may also offer support for authentication using PIV and CAC credentials for agency staff and contractors who are accessing public-facing systems in their personal capacity.Page 9
While it’s no surprise seeing multi-factor authentication being a requirement, what stands out is that doing so at the network level is explicitly disallowed. Meaning all VPNs and tunnels – nextGen or not – do not meet the standard.
Fortunately, there are phishing-resistant approaches to MFA that can defend against these attacks. The Federal Government’s Personal Identity Verification (PIV) standard is one such approach. The World Wide Web Consortium (W3C)’s open “Web Authentication” standard, another effective approach, is supported today by nearly every major consumer device and an increasing number of popular cloud services.Page 7
However, PIV will not be a practical option for some information systems and situations. Agencies are permitted under current guidance to use phishing-resistant authenticators that do not yet support PIV or Derived PIV (such as FIDO2 and Web Authentication-based authenticators) in order to meet the requirements of this strategy. To the greatest extent possible, agencies should centrally implement support for non-PIV authenticators in their enterprise identity management systems, so that these authenticators are centrally managed and connected to enterprise identities.Page 8
I loved seeing security keys and WebAuthn called out. With folks like Microsoft and Apple leaning into the open standard, WebAuthn is really starting to feel like the future of authentication.
And here’s your timeline!
In sum, I’m pretty impressed with the memo. Not only does it provide a single source of neutral truth for what zero trust actually is, it also validates many of the core ideas we’ve incorporated into Pomerium. But let’s focus on how this potentially impacts the US tech and cybersecurity as a whole going forward.
OK, So What?
You might wonder why any of this is important — Isn’t this just the government announcing changes limited to its own agencies?
The short answer is no; this government shift to adopt a stronger security posture will realistically impact most of the tech sector in the years to come and even possibly everything that touches the tech sector.
The long answer is this: The government’s initiative to adopt zero trust should be seen as the earliest sign of a widespread inflection point for both the public and private sectors.
This should not be read as akin to the government implementing new privacy laws that only affect themselves and direct vendors given privileged access to government infrastructure. Instead, it signals a dramatic and positive shift towards a stronger and purposefully thought-out cybersecurity stance led by the government.
While this is conjecture, I believe this governmental change will influence the private sector at large. To understand this, I want to direct your focus to this segment: Page 4 details the White House’s vision for the Federal Government’s plan with zero trust, the proposed timeline, and most importantly — the five pillars used to evaluate zero trust.
These five pillars dictate how the government evaluates their cybersecurity infrastructure, policies, and stance going forward. When read in context with the full memo, I can only imagine a very different cybersecurity landscape by the end of Fiscal Year 2024.
The strategic goal is to align the government with CISA’s five pillars:
- Applications and Workloads
Unfortunately, these five pillars are an extremely high bar to meet compared to the current ongoing state of cybersecurity, and government agencies have been given an aggressive timeline to make a shift towards zero trust. Look at the fine print behind those pillars and consider the extent of what they touch in our modern digital infrastructure.
Now consider the above within the wider context as we expect the following to happen within the next two years: the government will require adoption of the above zero trust security goals by the end of Fiscal Year 2024 and right now (at time of writing) is the calm before the storm as agencies were given 60, 120, or even 365 days to make a plan or shift.
- In less than 2 months, plans will be written.
- By June 2022, agencies will be making shifts through auditing solutions and informing vendors and companies that do not meet the five pillars above. I expect that these vendors and companies will be given a period of time to also make the shift for their own infrastructure or products and meet the government’s zero trust standards or risk not having their contracts renewed.
- By 2025, agencies will be evaluated on whether they made a conscious and deliberate effort to adhere to those five pillars and whether they succeeded. Agencies that fail muster will probably be pressured to take a more aggressive approach to adopt zero trust.
This will have cascading effects in the US tech sector:
- The nature of adopting zero trust necessitates the government auditing everything within their infrastructure to meet the zero trust standard. Vendors and contractors that fail to meet these standards will need to also adopt zero trust or risk losing their contracts.
- It’s unclear how far that auditing would go, but a true zero trust adoption would likely audit everything within the supply chain. Vendors that do not want to risk their government contracts will also pressure their own supply chains to adhere to zero trust standards set out by the government.
- Rinse and repeat this zero trust shift down and across the supply chain.
So why does this matter? Zero trust will be the litmus test for evaluating companies and their products in the future. The US government has set out standards for evaluating whether a modern infrastructure is zero trust and is committed to making their agencies adopt it for good reason. By articulating concrete details of a zero trust adoption, the US government is signaling to the private sector that zero trust is the path forward in a future rife with cyberattacks and ransomware.
We are seeing an inflection point where organizations will see zero trust as the expected best practice for not just their infrastructure, but also the infrastructure of their suppliers.
Of course, change comes with growing pains. When the agencies start auditing, the organizations and solutions that currently claim to be zero trust but do not fulfill the federal government’s definition of zero trust will be scrambling to pivot or risk being cut off by those interested in federal funding and contracts. Yet zero trust isn’t something that many existing organizations can simply pivot to — zero trust isn’t a product that you buy, it’s ingrained into the very culture of the organization itself.
For example, how many organizations currently use VPNs and are willing to get rid of VPNs immediately to meet zero trust? That’s not a hypothetical either — VPNs were called out by the White House:
Making applications internet-accessible in a safe manner, without relying on a virtual private network (VPN) or other network tunnel, is a major shift for many agencies that will take significant effort to achieve.Page 18
VPNs by definition do not fulfill the zero trust mandate. That means all vendors on the market that utilize a VPN (or are even nextGen VPN) are immediately out of the running, and this should be read as “If you’re a vendor selling a VPN to the government, expect that contract to not be renewed.”
And these zero trust pillars can be expected to apply uniformly to all contracts touching the government’s infrastructure in the future. As the government has laid out a concrete set of requirements for how organizations and products will be judged with regards to cybersecurity, this memo will serve next to the original BeyondCorp paper as a critical gauge for an organization’s security models. The bar has been raised and set, and organizations can expect to have roughly two years to meet it.
To summarize, the White House’s memo signals a different future for modern digital infrastructure and helps move the conversation about zero trust from the abstract (the original NIST and BeyondCorp papers) to the concrete (continuous authorization, device identity, no VPNs). While we wait for agencies to finish writing their plans and evaluating their solutions, I look forward to seeing how their plans include timelines for their vendors to make the shift.
In the meantime, Pomerium will do what it has always done: have productive discussions with organizations about how we can be part of their zero trust infrastructure.
More in CyberSecurity
Signed Headers: A Safety Net for Application Security
What is Zero Trust Architecture and Security?
Zero Trust Maturity Rubric and Tool Matrix
Signed Headers: A Safety Net for Application Security
Cryptographically signed headers are a failsafe authentication mechanism for protecting your applications when Mutual Transport Layer Security (mTLS, also known as mutual authentication) fails. Utilizing signed headers provides defense in depth to the protected application when: What are signed headers? Signed headers take the form of JSON Web Tokens (JWT) for allowing upstream applications to […]