I read the federal government’s Zero-Trust Memo so you don’t have to

Yesterday, the Office and Management and Budget (OMB) released a memo:“Moving the U.S. Government Towards Zero Trust Cybersecurity Principles”.  The memo is a reaction to 2020’s SolarWinds incident and 2021’s Colonial Pipeline rasomware attack, and advises the Federal Government on what steps each agency must take to improve its cybersecurity.

Many of the items in the memo go well-beyond even what the top enterprises and tech startups are doing today. It looks like the government is planning to position itself as a cybersecurity leader (rather than a laggard), while also pushing the private sector into a more robust cybersecurity posture. 

Also, if you get into it, this memo is actually about a lot more than zero trust.  

Sure, it covers authentication, network segmentation and role-based access control, which are all things that we’re used to thinking about when we say zero trust.  But it also talks about more controversial things like bug-bounty programs and encrypted DNS. It tells us to stop rotating passwords, and stop putting in those annoying special characters as requirements in password policies. (Hooray!)  And it comes down unexpectedly hard on VPNs.  

Let’s get into the details.

‍

The memo mandates “zero-trust” authentication: SSO along with MFA and device context.

Zero trust is used in a variety of different ways, but to me zero-trust means something very simple: 

Do not give long-lived credentials to your users. 

This is very sensible.  If you don’t give your users long-standing credentials, you don’t have to worry about them walking away with those credentials when they leave the organization. You don’t have to worry that a compromise of their devices later leads to a compromise of their credentials. 

The memo advocates the well-established as the modern approach to zero-trust: centralized SSO, along with MFA. 

It also says that while role-based access control (RBAC) is good, agencies should not rely too much on “static predefined roles”. Instead, access should be more “fine-grained” and “dynamic”. This sounds like Just-In-Time (JIT) access control, where a user is granted access to a resource only while she needs it, and that access is revoked when she is done. 

But what kind of MFA? 

Here’s where it gets interesting. The memo comes right out and tells agencies to

“discontinue support for protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications''.  

We can all get behind the elimination of SMS/phone based 2FA, which is known to be vulnerable to phishing and sim-swapping attacks. 

But the memo also dismisses the popular one-time code approaches like the TOTP protocol (the Google Authenticator on your phone), which is basically the state of the art for SaaS business everywhere.  

Instead, users should be issued “phishing resistant tokens”, like PIV cards and yubikeys.  This seems very feasible in the context of a government agency, because each employee can receive her token as part of her onboarding when she is hired.  However, this sort of thing is harder to do if you are a SaaS service (e.g. a payroll service, a bank) that is seeking to offer MFA to a broad swath of your customers. 

It will be interesting to see if these MFA recommendations will have any impact beyond the government.  Maybe phone-based MFA will finally go away? (Doubt it.)

Adding in device context. 

The memo also goes beyond MFA to mandate that authentication should “incorporate at least one device-level signal alongside identity information”.  That is, that authentication also checks that the user is authenticated from a “trusted” device.  

This feature is already prevalent by most IdP's. (Here’s an example of a rudimentary device context feature that you can use with Okta SSO. )

But most companies don’t use it. Why? Because they would have to do things like push device certs to signal a managed device or integrate device posture checks with authentication.  In other words, supporting device context in a bring-your-own-device (BYOD) pretty hard, as it requires IT teams to manage and inventory user devices. 

‍

Passwordless Access is the Future!

 Here I’ll just screenshot the memo directly, since it makes itself pretty clear: 

‍

Those outdated password requirements are all the annoying things we all hate when logging into government websites.  The memo says “Password policies must not require use of special characters or regular rotation.” 

VPNs are deprecated! 

I didn’t expect the memo to come out quite so hard on VPNs.  But the very first section says: 

 “the Federal Government can no longer depend on conventional perimeter-based defenses”.

And later, the memo says:

“Users should log into applications, rather than networks”

So that’s it. Your VPN is not good enough. Users should log into each application separately, using the zero-trust authentication described above.  

Importantly, the memo is not only deprecating old fashioned VPNs where users hold long-lived credentials. It’s also deprecating more modern VPN approaches where users login to the VPN with SSO+MFA (e.g. all the new VPN services based on wiregard).  Because even with these new approaches, the user is still logging into the network, not the application.

So why is authentication on the application layer more valuable than at the network layer? The network layer is too formless (it’s like giving out keys to office buildings).  Meanwhile, the application layer maps onto individual user actions (it’s like assigning and enforcing specific organizational roles and responsibilities). 

The memo is advocating for a BeyondCorp approach.  In fact, it goes even further by suggesting that we don’t really need VPNs anymore: 

“Enterprise applications should be able to be used over the public internet.”

RIP VPNs?