The problem with "implementing a zero trust architecture" is that it's framing an ongoing process as an end state. You'll see the same disappointment that people saw when they decided "we're going to do DevOps".
I thought that "Shift Left" was going to be the new DevOps buzzword for security groups, but I liked that because it implied an ongoing process, not a "we're going to become perfect and fix this once and for all".
Google's BeyondCorp - the precursor to zero trust architecture - said you need to secure three things: users, devices, and application policies. Your security teams are probably already aware of many of good tools available to secure the users and apps, but the device security piece has very weak tooling even today. You may have heard of MDM software. No one wants to use it.
One of the problem's with MDM software is that corps want you to login and use your personal phone, I guess to save costs, and to make it easy for you to do work out of your regular business hours.
If a company asked me to use MDM software and set themselves up as a device owner on a phone I purchased and used every day my answer is: hell no
If they want that, they can buy me a phone, and pay for the mobile/data plan. I've worked places that have done this, having 2 phones is a pain, but you only use the corp one at work or if you're oncall.
BYOD support without having everything managed by the company is a pain point Apple and Google are trying to solve.
For Chrome, it will perform a very intrusive popup whenever you log into an extra Google account to get you to use a different profile. If you say yes, that new profile will be governed by the administrators without them gaining access to the entire Chrome browser.
For Android, there are 'Work Profiles'[0], however I haven't tried this and I wouldn't be surprised if it breaks fundamental parts of Android and/or it's disabled on certain OEM Android makers.
For iOS, User Enrollment[1] is a thing.
The main problems I see with these solutions is that they add a lot of complexity to MDM configurations, so chances are the organization will either go without MDM, or ask you to set up your device under full MDM. Under the second scenario I would suggest purchasing an extra phone just for work - this also helps with the possibility of an internal investigation, or even subpoena, asking for access to any phone with work data on it, as chances are they won't limit searches and data exports to data stored in your work profile.
At a previous company I declined the "perk" of the company paying for my phone plan, because it required giving them control over it. I was mostly worried about losing my phone number accidentally upon parting ways.
Nowadays, Android can have a Work profile that your company can control (and wipe, for example) that doesn't affect your personal stuff. It's actually convenient because you have a separate instance of Chrome, which is a good workaround for mobile Chrome not supporting multiple profiles inside the app like the desktop version does.
I just like that there will eventually be a big shiny C-level-friendly website that I can show my bosses, that they can show their bosses, so we might actually get funding to start working on Zero Trust. Nobody cared about BeyondCorp but they might care about NIST.
People get into all sorts of trouble trying to reason axiomatically about "Zero Trust". It's definitely a problem with the term, and a strength of "BeyondCorp"; BeyondCorp can only mean the one set of things, because it's meaningless outside of Google's branding. But everyone feels like they can work out what "Zero Trust" should mean. So the first thing you have to do is, you have to rewire your brain to read "Zero Trust" as the marketing term of art that it is.
The OMB ZT stuff is a reaction to USG breaches, and I think in particular the OMB hack. There's a "before" state and a desired "after" state.
In the "before" state, you're one of the 2.1 million federal employees, and you start your day by inserting a PIV card into a reader, and with that, you're given access to an intranet that in turn gives you access to a bananas number of different things that nobody can keep track of or secure.
In the "after" state, each service is responsible for establishing its own tight trust boundaries, and instead of providing a network dial tone that people mistakenly assume is a proxy for trust, the USG infrastructure provides you with end-to-end authentication for requests regardless of the network you're using.
As far as OMB and NIST talking about ZT goes, the major problem you're trying to solve is that there are a zillion federal agencies --- way more than you think there are, like you know that there's a Department of the Interior, but also under Interior there's a Susquehannah River Basin Commission with 100 employees, and there are other agencies that have like 4-5 employees. And what you're trying to do is provide a security strategy and a toolbox and a set of best/worst practices that you can apply across all of these organizations, to replace what I understand to be the status quo ante strategy of "stick it on the VPN, pretend we've kept it off the Internet, and call it a day".
The other important subtext to all of this is that there's a huge give and take between USG and industry, where USG tends to take its lead from what's happening in industry, but it also participates in the industry in that it is one of the largest customers for technology products, so the industry is intensely interested in what it does. So when USG decides to demand "Zero Trust" for its agencies, and sets out a standard set of requirements for ZT, industry goes nuts making sure their products are responsive to that standard.
The good thing here is that the OMB memo is smart, and ZT as construed by the current administration's IT people is a pretty good baseline security strategy, so in this one instance the USG is being a force for good, in that it's aligning a lot of industry work around a strategy that people should be seriously considering adopting anyways. And I think there's pretty broad recognition/agreement about that in the "security community" (hate that term), so when USG (here: NIST) does some big new thing about ZT, it gets a lot of positive attention.
I'm kind of unclear how the device part is supposed to work. Let's assume the work laptop is fully locked down, and employees' personal laptops are completely compromised with each keystroke sent directly to ransomware rings. Are you supposed to block your employees from logging into your SaaS apps and internal web apps from their personal devices? What's the mechanism for that?
You generally run an agent on the client machine that verifies machine identity and configuration as part of authentication. Beyond identity is an example.
Agents on the client can’t really be trusted unless there’s a secure boot and only authorised software is running - at which point it’s not really a personal device any more.
I thought that "Shift Left" was going to be the new DevOps buzzword for security groups, but I liked that because it implied an ongoing process, not a "we're going to become perfect and fix this once and for all".
Google's BeyondCorp - the precursor to zero trust architecture - said you need to secure three things: users, devices, and application policies. Your security teams are probably already aware of many of good tools available to secure the users and apps, but the device security piece has very weak tooling even today. You may have heard of MDM software. No one wants to use it.