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.

A phone displays the Google Authenticator app - a tool used in a basic one-time code security approach. Image from Android Guys

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:

‍

“Agencies are encouraged to pursue greater use of passwordless multi-factor authentication as they modernize their authentication systems. However, when passwords are in use, they are a “factor” in multi-factor authentication. If outdated password requirements lead agency staff to reuse passwords from their personal life, store passwords insecurely, or otherwise use weak passwords, adversaries will find it much easier to obtain unauthorized account access—even within a system that uses MFA.”

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?

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

The memo takes a stand on several controversial network security issues.

The memo also opines on several core internet protocols.

**HTTP. **The memo mandates encryption of HTTP traffic. Ok, this is tablestakes. One slightly new thing is mandating the encryption of internal traffic too. This is kind of also tablestakes. (The community was already pretty much there when we saw that hand-drawn “encryption added and removed here” slide leaked from the NSA in 2013. And if you don’t know what I’m talking about, read this!)

**DNS! **But, the memo also mandates the encryption of DNS traffic! This is new. Most DNS traffic is not encrypted. And there’s plenty of controversy around this topic, including that it consolidates DNS traffic around a smaller number of resolvers that support encryption, and the fact that encrypted DNS makes it harder to tell when attackers are using DNS for botnet command-and-control, or to exfil data from a network. These are all legitimate arguments.

But no. The memo comes out unequivocally on the side of encrypting DNS.

This could have a major impact. How long before AWS starts to offer encrypted DNS?

**Email? **Finally, it looks like encrypted email might be a thing (again!). The memo is bit vague here: “FedRAMP will evaluate options for encrypting email in transit.” I, personally, am fascinated. (But then again I’m someone who once wrote a research paper about email security.)

Today’s email protocols use the STARTTLS protocol for encryption; it is laughably easy to do a protocol downgrade attack that turns off the encryption. (See for instance this paper.) Meanwhile encryption with PGP has been a complete failure, due to problems with key distribution and user experience. I don’t see any concrete recommendations here, so it’s hard to say what the technical implementation could be.

Maybe we can all finally stop worrying so much about the CFAA?

I’ll wrap up by pointing out that the memo includes a statement about responsible disclosure and bug bounties. This is pretty fantastic.

“In addition to robust internal testing programs, agencies should scrutinize their applications as our nation’s adversaries do. This requires welcoming external partners and independent perspectives to evaluate the real-world security of agency applications, and a process for coordinated disclosure of vulnerabilities by the general public.”

Later it says:

“Agencies must maintain an effective and welcoming public vulnerability disclosure system for their internet accessible systems.”

In other words, the agencies should support external researchers that scrutinize their systems and responsibly disclose vulnerabilities.

While this is hardly a shocking position to take in 2022, it’s great to see it coming from the government.

Even today, the law is not on the side of security researchers. In particular, the 1985 Computer Fraud and Abuse Act can be used to hold security researchers criminally liable for “exceeding authorized access” to find vulnerabilities in live systems. It seems ridiculous that companies would do this, but even just a few months ago the State of Missouri was seeking to prosecute a St. Louis Post-Dispatch reporter who identified and disclosed a vulnerability in a state website (by viewing its HTML source!).

The memo suggests that nonsense like this should just stop. Which is a good thing.

Conclusion

All in, the memo is pushing for a cybersecurity posture that is well beyond where many companies are today.

Old fashioned technologies like passwords and VPNs are out. Users should authenticate to individual applications, BeyondCorp style, and their access should be monitored and logged. Organizations should inventory user devices, and device context should be provided as part of each authentication to each application — something that is not easy to do in our BYOD world.

MFA should be “phishing resistant” and TOTP authentication is out – this can probably work in the context of government but I’m skeptical if it will have much impact beyond that.

Bug bounties are a good thing, and we should all stop arguing and just encrypt the DNS.

All in, a good set of recommendations. Looking forward to seeing how they impact the industry over the coming months and years.

By Sharon Goldberg, PhD.

CEO of BastionZero

‍

‍