Back in the day, organizational security was built around the idea of a firewall: The security system blocked access to resources within the organization from external bad actors. Originally, that paradigm was literal: You established a perimeter and kept people from outside the building from accessing the network—and the resources attached to it—inside.
But that’s all changed. Users now access organization resources from anywhere—home offices, coffee shops, sometimes the actual office—via devices that are sometimes owned by the organization, sometimes by the users themselves.
That’s the ecosystem in which Zero Trust security evolved. Zero Trust rejects the idea that if something is ‘inside’ a network or ‘managed,’ it’s inherently more secure or trustworthy than something that isn't. It's less about protecting a network and more about continuously verifying that the devices and users accessing an organization’s resources are trusted and authorized to do so. It’s not a security technique or tactic, it’s a philosophical stance. And it’s how today's cloud-based, hybrid organizations are keeping their data, their users, and their devices safe.
Here’s what you need to know about it.
What Is Zero Trust?
Zero Trust security was first proposed back in 2009 as a way for security teams to address then-prevalent threats that had figured out how to circumvent traditional network defenses. The idea was that all traffic to an organization’s digital resources, regardless of its apparent provenance, should be considered untrustworthy until it could be verified otherwise. No user or user device would be inherently trustworthy; every user and every device should be evaluated.
Then came BYOD. Suddenly, you had people using their own personal devices for work. It was up to them, not you, whether or not the software was up to date. And you, as an admin, didn’t manage the device either. But in the old way of thinking, if that device could get on the network, it might be trusted with networked resources; the existing security system might see no need to validate its requests.
That shift in employee behaviors led to the demand for a Zero Trust model. In this stage of security evolution, users still need to authenticate to systems using common authentication options such as passwords and MFA. But they also need the flexibility to work more autonomously. But admins still need to know whether they can trust the devices that users are authenticating from. Context is important.
Zero Trust looks at the whole picture: the user, the device, and the resources the user is trying to access. As NIST puts it:
Zero Trust refers to an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.
Zero Trust is built around policies. Those policies define the proofs a user or device must present, the access requirements for the resources that are being accessed, and the frequency of verification. It's a “trust nothing, validate everything” model.
With Zero Trust, users and devices can be trusted—or not—based on a wide variety of proofs. For users, you can use things like usernames and passwords, biometrics, or a combination of factors. For a device, admins examine things such as whether or not the device is owned by the organization, whether it’s managed (or supervised), its device family, its OS version, the network it’s on, and more.
That network location check is a popular one in Zero Trust policies. If someone generally uses their work device from their home network, but then heads out to the local coffee shop and tries to check email from there, a Zero Trust system could flag that the device is attempting to access work systems from a different network zone and require the end user to validate that authentication request with additional proofs, such as an additional MFA requests.
These required proofs can vary depending on which resources the user is requesting access to. Authentication and authorization of both user and device are discrete functions that are performed before access to a specific enterprise resource is granted.
How Zero Trust Works
Let's say you have a SaaS application such as Salesforce, and you want to validate people who are trying to access it. On each authentication, you'd examine the context of their authentication request. You might enforce different policies depending on whether or not the device is company-issued, managed or unmanaged, coming from a known network location, or whether you’ve authenticated it before.
Depending on your risk posture, you could run through that policy checklist on every authentication or just on a particular period. Just because a user authenticates and the system checks their devices today, the system might check those devices against that posture the very next time the user tries to authenticate.
Or let's say a user is authenticating into Microsoft from their work computer. The device is managed by the organization, and the organization’s security policies accept that as sufficient reason to trust the device. But the system still wants to verify the user. So it requests biometric confirmation. That will tap into whatever biometric infrastructure you’ve set up—typically enlisting a separate device such as an iPhone to scan the user’s face or fingerprint or with something like Okta Verify or Okta Device Trust on a managed device.
You can get quite granular with these policies: That same user might be granted access to the Microsoft Office apps, but if they try to access, say, AWS production cloud storage, then additional layers of security could need to be met before the user can proceed.
Or say an engineering team uses a proxy service like Teleport to access databases and internal resources. You could have multifactor authentication policies in place to do daily authentications. But you could require that users reauthenticate every time they try to access production data in Teleport. If the data was particularly sensitive, the system could require more extensive checks.
The point is that Zero Trust is a context-aware, policy-driven security model that adapts to the risk posture of your organization.
How to Implement Zero Trust
How you implement Zero Trust depends a lot on the particular security solutions you’re using.
Different solutions support different forms of proof and can scan for different conditions. Some, for example, can filter devices based on whether or not they comply with a specific security posture you’ve defined—whether or not they’re encrypted, say, or they have a specific security app installed. They can use logic to allow a user to download data from a particular application only if they’re running a certain version of the application.
Providers of Zero Trust solutions also differentiate based on the other solutions they integrate with. A provider could, for example, integrate with Kandji to allow privileged access to resources based on whether or not the device is under Kandji management.
Zero Trust and Device Management
IT admins need to know about Zero Trust because they’ll often be the ones who will implement these solutions. But admins who’ve been working with Apple fleets might not be as attuned to Zero Trust as those who’ve been managing other platforms.
For a long time, Mac computers were given free rein on many corporate networks. There was risk, sure, but it wasn’t talked about much or was thought to be lower than for other platforms. But as Apple has expanded in the enterprise, its platforms have increasingly become targets of threat actors.
At the same time, particularly since the COVID-19 pandemic, we’ve seen the evolution of the hybrid workplace and a renewed focus on enabling users to work from different places, with different types of devices.
And IT is changing too. Increasingly, admins are responsible for more than just managing devices. They’re securing those devices, too. They might also be responsible for managing SaaS applications, including identity providers. They need to have a much broader view than they did just a few years ago of security, identity, and other issues.
This means it’s time for those admins to initiate some frank conversations with their network admins, the security team, and the CISO, to talk about implementing Zero Trust.
Kandji can help IT and security admins protect against Mac malware across the entire organization. The Kandji team is constantly working on solutions to streamline your workflow and secure all of your Apple devices. With powerful and time-saving features such as zero-touch deployment, one-click compliance templates, and plenty more, Kandji has everything you need to bring your Apple fleet into the modern workplace.