Zero trust is gaining ground across the industry and prompting a wave of new offerings and proprietary technology. At Cisco, we’re taking a more foundational approach to help define industry-wide standards that promote zero trust principles, whether it’s through simplifying and democratizing technology or our work with Internet Engineering Task Force (IETF), Fast Identity Online (FIDO) Alliance, and others.
For example, Cisco’s Duo Security has been a pioneer and strong advocate of WebAuthn, passkeys, and other passwordless technologies, working to shape best practices and implement open source libraries to speed the adoption of these new technologies.
Most recently, we teamed up with the MASQUE Working Group within the IETF to define a set of new standards around HTTP/2 and HTTP/3 that lays the groundwork for new methodology for secure access. This new set of technologies are only the beginning of our quest to make zero trust standardized, interoperable, and ubiquitous across all devices and systems.
Why VPNs aren’t part of our zero trust approach
While virtual private networks (VPNs) are a critical and effective tool, zero trust access methods need to evolve to provide a frictionless user experience without sacrificing security controls.
While most zero trust network access (ZTNA) solutions typically fall into the VPN category, we at Cisco don’t use VPN technologies (like packet capture, DTLS, or IPsec) for zero trust to protect enterprise privacy integrity and support a hybrid access model.
Part of our enterprise privacy push is to ensure that our zero trust technology looks identical to any other internet traffic and doesn’t provide on-path attackers with any clues as to the purpose of the session. This is a stark departure from DTLS, IPsec, or noise protocols used with most VPN and ZTNA solutions that are easily recognizable from other internet traffic.
Strong device-bound credentials
Too many ZTNA offerings today trade a strong credential (such as Duo MFA) for a weaker credential (such as a JWT, Paseto, or SSO cookies in a browser). Unfortunately, these tokens and cookies have varying degrees of security effectiveness that depends entirely on the identity providers implementation and how much trust is placed in the browser itself.
To counter this trend, we will trade a strong credential for an equally strong credential that is bound directly to the device itself. We also support SSO solutions as a secondary authentication method to give additional options to customers, even though first factor authentication will always be a device-bound credential that doesn’t rely on the security of the browser or the identity provider.
We at Cisco are focusing our efforts around a technology called DPoP-ACME-SSO—or Demonstrated Proof of Possession for ACME Certificates using SSO enrollment. DPoP-ACME-SSO ensures that only the device where the user is performing a strong authentication (again, like Duo MFA) is granted an identity credential bound directly to that device using hardware key storage, ensuring that only device can ever have that credential. This differs from passkey technology, which can be potentially shared across devices.
Biometric authentication is a strong secondary factor for customers who want additional identity-based methods. This leverages existing standards such as WebAuthn and passkeys (for example, Duo Passwordless) for the second factor. Right now, there’s work underway to natively integrate these biometric identity technologies without the need for an embedded or external browser component, creating a frictionless access user experience while ensuring a stronger security outcome.
Strong device-bound credentials are automatically renewed each month without user intervention and hardware-bound keys are rotated with each new identity certificate reinforcing the security of the solution. Renewal will continue approximately every month until an administrator decides to revoke access for that user and device combination. The administrator can also revoke any second factor authentication methods using the second factor identity providers system.
MASQUE: A new, standards-based zero trust access protocol
MASQUE is a working group in the IETF that is standardizing new protocol capabilities for HTTP/2 and HTTP/3 for secure access. We collaborate directly with MASQUE to adopt and shape the standards for use in zero trust access solutions. We also teamed up with OS vendors to bring this technology directly into the OSes, in order to enable zero trust access directly from the device with no need for a vendor specific ZTNA or VPN software implementation.
This new frictionless security technology will allow any vendor to participate and leverage these open standards to build zero trust access solutions that can be audited by customers and implemented using open source software instead of proprietary protocols and solutions that can’t be easily reviewed for security vulnerabilities by customers or government agencies. End users also benefit because their hybrid work experience will blends seamlessly with their in-office experience.
Better security, better performance
One key advantage of these new OS-native zero trust access implementations is the ability to bring micro-segmentation all the way to the application running on the device. This significantly improves security properties over traditional ZTNA and VPN solutions in that the networking segmentation is brought directly into the application itself.
Additionally, these new OS-native implementations of zero trust access improve performance by removing the need for a kernel- to user-mode bump required by current ZTNA and VPN technologies. Not only does this allow for the zero trust micro tunnels to be entirely contained within the applications themselves, it also eliminates the context switching needed to encapsulate application traffic.
A new trust model
Traditional zero trust solutions only take into account three aspects of trust: user, device, and destination application. We believe that source application is an equally important factor to include in any zero trust access decision. Our new design will allow for application and device attestation, supporting a four-pillar trust model to make informed zero trust access decisions.
Conclusion
Cisco’s future-focused approach to zero trust access will significantly improve and standardize solutions across vendor ecosystems, ultimately simplifying workflows and user experiences. All the proprietary control and data plane technologies used in current ZTNA solutions will soon be replaced with a single set of standardized technologies that are easy to audit and are widely available in open source allowing for interoperability and improved security.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Instagram
Facebook
Twitter
LinkedIn
Amazing stuff. Zero Trust built right into the OS. Brilliant.
Looks like other vendors are agreeing to support this. Great work
I would think the work at IETF is draft-biggs-acme-sso-01, but that one expired.
What I did find a video: Encrypted DNS Policy and Technical Call, 26th June 2023
Something I wonder is, how will Linux (and maybe BSD)-based client devices that are not Android integrate into this ? I’m aware SPIRE and SPIFFE (SPIFFE Workload API / SPIFFE SVID) exist for example. Would it be similar to that ? CNCF’s Keylime project maybe (using Secure Boot and TPM 2.0 and checking disk encryption is enabled) ? Maybe Envoy proxy could play a role there too ? When I take a Linux machine, I can see everything which is installed has hashes, so lot’s of infrastructure exists. Is their anything like Linux Integrity Measurement Architecture (IMA) widely deployed ? Because let’s be clear, I assume simple sidecar model will not be enough for Linux desktop/laptop.