Understanding Zero Trust security

The way we work has changed dramatically over the last couple of decades. We used to go to a company office, sit down at our desks, and work from a dedicated desktop computer that stayed there when we left. Nowadays, this sounds like the Stone Age to some. We work from anywhere—our home, a cafe, a train, a beach in Bali, a sailing boat in the middle of the sea—using a multitude of devices—laptops, tablets, mobile phones—and an evergrowing number of cloud apps.

The old security models cannot cope with the current practices. Security used to follow a perimeter or trusted network model: we built high walls, with fancy firewalls and whatnot, around the company’s network and data, and once you were in, you were trusted implicitly.

Nowadays, the cloud is the platform of choice for enterprise infrastructure; there is no single network around which to build a wall. Companies use more and more cloud apps, so the concept of perimeter no longer exists.  In addition to that, as the attackers get more sophisticated and shift to identity attacks like phishing and credential theft, no one can be trusted to be who they claim to be.

With the work landscape changing so drastically and the old security models failing to cope, we needed a way to keep corporate data safe in this new work-from-anywhere world.

Enter Zero Trust security: a security model under which trust must be constantly validated. No user, device, or application can be trusted implicitly. Trust no one is the new norm. Users access is always revalidated when they want to use a service even if they already have a valid session, devices are monitored for compromised software, and health checks make sure that all the latest patches are applied in a timely manner.

But before we discuss Zero Trust security in more detail and explain how it helps companies stay safe, let’s take a stroll down memory lane and see how it all started.

How it all started

Back in 2010, Google disclosed that it had been the target of a highly sophisticated and targeted cyber attack, which later became known as Operation Aurora. The attackers were going after certain Chinese human rights activists and, as Google confirmed, managed to access their Gmail accounts. While at it, they also got access to Google’s intellectual property.

The full details of how the attack went down were never made public, but it is believed that the attackers exploited vulnerabilities in Internet Explorer 6 to establish remote access. From there, they were able to acquire admin credentials and access sensitive systems containing Google’s source code.

Google was not the only one to be attacked, although it was the only one to acknowledge it publicly. The networks of other big companies, like Yahoo, Adobe, Dow Chemical, Morgan Stanley, and more than two dozen others, were also compromised.

The incident was a milestone in cybersecurity history and a wake-up call about the limitations of the perimeter-focused security model. Until then, there was a general belief that while defense-in-depth was a good idea, perimeter security was enough to keep everyone safe. After that attack, Google completely redesigned its security around the Zero Trust model, and many others followed suit. After all, if Google, a company with one of the best-resourced corporate security teams in the world, can be hacked, what chances do the rest of us stand?

Google implemented BeyondCorp, a Zero Trust network. BeyondCorp assumes that all devices and users are potentially compromised. All internal apps are accessed via the BeyondCorp system, regardless of whether the user is in a Google office or working remotely. BeyondCorp uses several security policies, including authentication, authorization, and access control, to ensure that only authorized users can access corporate resources.

One of the main components in BeyondCorp's implementation is the Trust Inferrer. This software looks at information about a user's device to decide how much it can be trusted to access sensitive resources. It checks things like the device's security, whether it has the right software installed, and whether it belongs to an authorized user. Based on all this information, it decides what the device can access and what it can't.

How the Zero Trust model works

The Zero Trust model asks you to act paranoid: Never trust anything inside or outside the network, and constantly verify everything. Assume that the attackers are already here and know exactly how to act once a breach happens.

There are three core principles:

• Never trust, always verify: Every attempt to make a new connection—by a user, device, or app—should be authenticated and authorized. Always verify access, all the time, for all resources. There are no trusted zones, credentials, or devices.
• Implement the principle of least privilege: Only grant users and apps the minimum amount of access they need and no more.
• Assume a breach: Teams should plan for the worst-case scenario and build robust incident response plans so that they can respond as quickly as possible if an attack occurs.

The first two principles are meant to prevent or minimize the impact of attacks. The third one concerns rapidly and effectively managing an attack.

These principles are part of the NIST cybersecurity framework: Identity, Protect, Detect, Respond, and Recover.

In a Zero Trust environment, a user’s access to a service is constantly revalidated using not only credentials but other factors as well, like fingerprints. Devices are monitored for compromised software and health checks make sure that all latest patches are applied in a timely manner. If you want to use a device (e.g., your iPhone) to access work data then it must adhere to certain rules (e.g., have the latest iOS updates installed).

Implementing a Zero Trust model requires a lot of moving pieces: multi-factor authentication, passwordless logins, granular access control, consideration of access based on location or moment in time, detection of malicious authentication patterns, and many more.

WebAuthN and passkeys in Zero Trust

Passwordless authentication can make a Zero Trust environment even more secure, and passkeys is one way to accomplish this.

Passkeys and WebAuthN are not exactly the same thing but they are pretty close.

A passkey provides a way to log into your account using biometrics: fingerprint or facial recognition (with PIN or pattern as a fallback). You enter your username, scan your fingerprint, and boom you are logged in.

WebAuthn, on the other hand, is the technical standard that makes passkeys possible. It provides the framework for websites and apps to securely verify your identity using passkeys.

From a technical perspective, passkeys use public-private cryptographic key pairs to authenticate users. When a user creates an account using a passkey, their device generates two cryptographic keys, one public and one private. The public key stays on the service provider's server, and the private one is saved on the user’s device.

The public key stored on the server is not sensitive information and cannot be used alone to access the account. Thus, passkeys are not vulnerable to server breaches. Even if someone gets your public key, they cannot do anything with it. The private key is securely stored on the user’s device within dedicated components designed to keep sensitive data. These components are isolated and function as a vault, guaranteeing data safety even in the event of a malware attack.

And since you use biometrics to login to an app, a passkey counts also as a second factor, replacing both a password and 2FA, all in one step.

When you go about implementing a Zero Trust framework, passwordless authentication is the way to go. Passwords (and the users that have to remember them) have long been the weakest factor. They are either too easy to guess or too hard to remember. And they make systems open to phishing attacks, a major threat that passwordless authentication is highly resistant to.

Passkeys are resistant to phishing attacks because passkeys are bound to a website or app’s identity, which means they can only be used with the website or app that created them. In other words, they can’t be written down or given to a bad actor. They also cannot be stolen using a login page that looks like the real thing but isn’t. And they also help improve the user experience. If we ask users to authenticate all the time we might as well provide a user-friendly way, like a fingerprint of face scan. Passkeys reduce user friction and streamline the authentication process.

How WorkOS can help with Zero Trust

As we saw, the Zero Trust security model requires several different pieces to be put together. WorkOS provides tools for several of these:

• SSO: With Unified SSO by WorkOS, you can quickly integrate with any provider that supports OIDC, SAML, or OAuth protocols. With SDKs in every popular language, easy-to-follow documentation, and Slack-based support, you can implement SSO in minutes rather than weeks. And unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard — whether they bring 10 or 10,000 SSO users to your app.
• Secure sessions: Great session management should handle security concerns for you. It should only take a few lines to wire into your app, provide easy-to-use hooks to gracefully update the UI when a session is nearing its end, and support revocation from the server to quickly log out users or change their roles in near real-time. With WorkOS session management you can rest assured that your users have a great user experience while staying safe.
• SCIM: With Directory Sync , you can integrate with any SCIM-compliant directory and get user provisioning up-and-running with just a few lines of code. And while webhooks are also supported, WorkOS’s Events API means every SCIM request is processed in order and in real-time.
• Passwordless authentication: Strong, multifactor authentication is at the core of the zero-trust framework, and passwordless authentication is a sort of evolution of MFA and Single Sign-On.‍
  • Passkeys: Login with your fingerprint using WorkOS. Passkeys are built on top of the
    WebAuthn standard that enable the user’s device to securely store the passkey’s private key, with access protected by biometrics, such as a fingerprint. When the user signs in, the private key is used to sign a payload that is verified with the matching public key.‍
  • Magic Auth: Log in or sign up via a unique, six digit one-time-use code sent to your email inbox.‍
• MFA: WorkOS offers a composable, unopinionated MFA API that can be integrated into existing applications. The available types of authentication factors are time-based one-time passwords and one-time password via SMS message.‍
• FGA: Fine-Grained Authorization is the most flexible and granular authorization system that enables you to implement fine-grained permissions in your app. You can use FGA to implement a custom authorization model tailor-made for your application(s), with the ability to integrate elements of role-based access control (RBAC), relationship-based access control (ReBAC), and attribute-based access control (ABAC) as needed.‍
• Radar: WorkOS Radar collects signals on the behavior of users as they sign in to your app. These signals feed into an engine that is looking for abusive or anomalous behavior (like impossible travel or unrecognized devices). When Radar detects a suspicious authentication attempt (bots, brute force attempts, credential stuffing), it can block or challenge that attempt based on the settings you configure. Radar will alert you when something suspicious is happening in real-time, allowing your admins to intervene and alert your users that their accounts might be compromised.

‍Sign up for WorkOS today.