In Part I of our OMB Zero Trust Strategy Blog Series, we outlined the U.S. Office of Management and Budget’s (OMB’s) Guiding Principles as outlined in its Federal Zero Trust Architecture (ZTA) strategy memo, “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles” — which led to Forrester Research’s assessment that the “Government gets good.”
In Part II, we look at the seven most interesting, and surprising, recommendations made by the OMB in its memo. While earlier Zero Trust recommendations have often been high-level or focused on existing Best Practices — such as using enterprise-wide identity to access applications, implementing phishing-resistant MFA, and keeping a complete device inventory — the strategy outlined in the OMB’s most recent memo on the subject is tangible, targeted, and bold.
From our perspective, the following are the seven most compelling actions and recommendations outlined by the OMB to help agencies introduce Zero Trust principles to their cybersecurity strategies:
1. User’s Device Must be Included in Authorization Decisions
“When authorizing users to access resources, agencies must consider at least one device-level signal alongside identity information about the authenticated user.”
With this recommendation, the OMB is recognizing what is arguably the most pressing shortcoming of today’s cybersecurity status quo: the vulnerability of user-level identity. Given that credential theft is the primary attack vector in over 60% of all cyber breaches today compounded with reports of increasingly successful circumventions to MFA, it ought to be abundantly clear that traditional, user-level authentication is no longer enough.
In its memo, the OMB recommends that, moving forward, authorization should also include “at least one device-level signal” ( i.e., context about the user’s device to determine whether it is trustworthy). By specifying at least one device-level signal, the OMB is only providing an initial, basic requirement; not suggesting what that device-level signal should actually be.
There are plenty of interesting possibilities for device-level signals, including:
- Proof of ownership – is the user using the right device?
- Software integrity – is the device running the right firmware, OS, applications?
- Memory integrity – is the device’s memory in an expected state?
- Hardware integrity – is the device hardware what I’m expecting?
- Compliance – does the device have the expected security compliance features enabled/configured/operating?
- Cybersecurity tool state – are tools running on the device currently indicating that the device is secure?
Of course, any of these would be useful signals to help ensure that a device and user, taken together, are trustworthy. While a single device-level signal is an excellent start, solutions that can incorporate as many of the above signals, and more, will deliver maximum zero trust protection.
2. VPNs are no longer sufficient: Authenticate into Applications, Not Networks
“In mature zero trust deployments, users strongly authenticate into applications, not into the underlying networks.”
With this statement, the OMB suggests that, for mature zero trust deployments, authentication into the underlying network layer is a non-starter — as it runs counter to the principle of least privilege, and lacks the kind of fine-grained access policies required for a truly zero-trust architecture. Instead, the OMB argues, users should authenticate into applications, potentially signaling that the days of VPNs are numbered.
3. Steer Clear of Static Cryptographic Keys
“… agencies should avoid relying on static cryptographic keys with an overly broad ability to decrypt enterprise-wide traffic, as even a brief compromise of such a key would defeat encryption across the agency.”
Long-lived cryptographic keys with broad decryption capabilities tip the scales in malicious actors’ favor — making it not only possible, but practical for attackers to target them. With this recommendation, the OMB makes clear that in order to shift the balance of power away from malicious actors, agencies must adopt short-lived credentials, implying that they should be ephemeral in nature.
Ideally, organizations should move from static, long-lived cryptographic keys to secure ephemeral credentials without breaking existing protocols. This seamless switch to ephemeral credentials should be achieved through an overlay approach that leverages existing CAs and PKIs with low-code to no-code needed to integrate.
4. Leverage Encryption Protocols Like TLS 1.3 Everywhere
“Agencies should make heavy internal use of recent versions of standard encryption protocols, such as TLS 1.3., that are designed to resist bulk decryption.”
This one may sound like common sense, but far too much traffic transits unencrypted or with outdated technology. While inventorying TLS implementations can be burdensome, it’s clear OMB believes that ensuring critical cryptographic protocols are up to date should be a high priority.
5. Agencies Should Plan for Cryptographic Agility
“More generally, agencies should plan for cryptographic agility in their network architectures, in anticipation of continuing to adopt newer versions of TLS and other baseline encryption protocols.”
It’s not a matter of if but when the world’s first cryptoanalytically relevant quantum computer (CRQC) comes online — meaning, a quantum computer of sufficient computational power to render our current cryptographic standards obsolete.
That’s why we — like the OMB — see crypto-agility as a necessary capability for any secure system. More specifically, we feel it’s imperative that organizations be able to securely upgrade the cryptography used to secure a network while those cryptographic instruments are already field-deployed.
As a concrete example of this, NSA guidance makes clear they expect public key cryptography to be vulnerable to quantum computers within the next decade. And yet, a post-quantum cipher suite has not yet been validated (although NIST is working on it). Conventional HSM or TPM approaches will need to be retrofitted in the field with new hardware, costing an anticipated hundreds of billions of dollars globally.
6. Incorporate Attribute-Based Access to Improve Permissions
“A zero trust architecture should incorporate more granularly and dynamically defined permissions, as attribute-based access control (ABAC) is designed to do.”
Currently, most organizations continue to rely on authorization models based solely upon role-based access control (RBAC) — which relies upon static, pre-defined roles that are assigned to users to determine permissions. The problem with this approach, of course, is that it doesn’t allow for more granular and dynamic permission policies, and typically runs counter to the principle of least-privilege.
7. Use ABAC and RBAC to enforce access checks based on the environment at time of access
“ABAC and RBAC can be used to allow or deny access by enforcing checks based on the user’s identity, the attributes of the resource being accessed, and the environment at access-time. For example, information about the device the user is using (is the device known to the agency? are its patches up-to-date?) provides the basis for a common environment-based check.”
With this recommendation, the OMB identifies some of the types of environment-based access checks that can be incorporated into one’s security architecture to bring the principles of zero trust to life.
How Gradient Can Help
Gradient Cybersecurity Mesh (GCM) — delivered with a simple SaaS + agent deployment model — secures access anywhere and everywhere. Real Zero Trust with zero complexity, Gradient can help achieve, and go beyond, these seven OMB Zero Trust requirements:
| OMB Requirement | Actions organizations must take | How Gradient can help |
|---|---|---|
| User’s Device Must be Included in Authorization Decisions | Prior to allowing any authorization or access to a system, organizations must find a way to use at least one signal from the requesting device, alongside identity information about the authenticated user, to validate the integrity of that device. | Gradient’s core value is leveraging the roots of trust your device already has built into it and continually measuring the full-stack security “fingerprint” of every endpoint against dynamically configurable policies, to prove that your machine is who it says it is and has not been compromised, so access should be allowed. |
| VPNs are No Longer Sufficient: Authenticate into Applications, Not Networks | Re-architect the network for zero trust so that all systems and applications can be isolated while remaining securely accessible over the internet. | With Gradient, organizations’ users and systems can be strongly authenticated directly into applications, using best practices such as TLS 1.3, to obtain hyper-secure, frictionless end-to-end security between user, device, and application regardless of location or architecture of the network. No painful migrations or re-architecture needed. |
| Steer Clear of Static Cryptographic Keys | Create and implement a process to securely rotate keys, manually or automatically, on a more frequent basis across the entire enterprise in a manner that doesn’t risk breaking any business-critical applications. | By simply integrating Gradient’s secure verifier into your existing identity system – e.g., Certificate Authority (CA) or Public Key Infrastructure (PKI) – to act as an intermediate CA, or credential issuer, GCM moves from static, long-lived cryptographic keys to secure ephemeral credentials – fully automated – without breaking existing protocols. GCM is deployed as a SaaS offering, on premises instance, or hybrid. |
| Leverage Encryption Protocols Like TLS 1.3 Everywhere | Comb through each application on the network and perform upgrades to put TLS 1.3 in place. | With Gradient, though, organizations can rapidly adopt TLS/mTLS 1.3 anywhere by installing Gradient’s agents and policy verifier back-end, and then configuring access policy. |
| Agencies Should Plan for Cryptographic Agility | Inventory every cryptographic function used across the enterprise, identify a post-quantum solution and create a migration plan for each one of them. | For devices utilizing Gradient’s Crypto-Agile Bootloader, every cryptographic implementation is modular, and can be changed remotely and securely with new, quantum-resistant algorithms, avoiding painful forklift upgrades and truck rolls thereby reducing the time, complexity, and costs of crypto modernization by orders of magnitude. |
| Incorporate Attribute-Based Access to Improve Permissions | Rearchitect applications to include granular “attributes” for users and systems, and ensure access policies can use these new attributes to enable access. | Gradient enhances the conventional authentication and conditional access flows for users, devices, and applications by using contemporary, fine-grained user and platform attributes for authentication and issuance of authorization credentials. Each of these attributes is re-evaluated at regular intervals to ensure they reflect the most up-to- date information on the state of every device on the network. |
| Use ABAC and RBAC to Enforce Access Checks Based on the Environment at Time of Access | Incorporate environment signals into RBAC/ABAC based access check processes by identifying a solution to analyze the environment’s condition, and determine if it is suitable to allow access. | Gradient uses short-term credentials predicated on user and platform attributes – and can be configured down to the per-transaction level. This enables us to not only do checks at access-time, but continually make these checks at virtually any interval through simple policy configuration. |
Stay tuned for Part III…
What the OMB’s Strategy Could Mean for the Future of Cybersecurity……
We’ve covered the most compelling strategies outlined by the OMB in its most recent memo on zero trust. Tune in to our next installment in the series, where we’ll take a look at what the OMB’s zero-trust strategy might imply about the future of cybersecurity.