 We're here to talk about the road to Beyond Corp and how to get to Beyond Corp. So as we just introduced, I'm Maya. I'm a product manager at TailScale. TailScale is a wire guard based mesh VPN. And yes, I do have stickers. Lots of stickers. Lots of stickers. Yeah. And I'm Eric. I'm a security engineer on the Enterprise Infrastructure Protection Team at Google. We deal with Google's corporate security, which relatively relevant to what we're about to talk about today. Yeah, exactly. So what are we going to talk about today? First, we'll cover what we mean when we say both the words Beyond Corp and zero trust and why those are important, and particularly pointing right now. Then we'll dig into what Beyond Corp is to better understand its components and what is needed for that to function. We'll talk about what companies have typically done or tried to do to adopt controls like Beyond Corp and what steps you can take towards, is zero trust architecture. And we'll wrap up with going over the long tail of problems you're going to hit by trying to make something truly zero trust. So to jump in, zero trust. Zero trust is a very trendy phrase these days. But in addition to coming from lots of vendors and analyst firms and yes, conference talks, it really does seem to you like the concept of zero trust has become particularly trendy and mainstream like very recently. And that's probably due to what just happened south of the border. In late January 2022, the US government published a memorandum on zero trust principles and about moving the US government's institutions and networks towards zero trust. And this was kind of surprising, although maybe not that surprising, because this was after in May 2021, the US government also published the executive order 14.028 for improving the nation's cybersecurity. And this is a fall onto that. So as a result of this memorandum, by now US federal agencies have adopted their zero trust plans into their cyber plans and they have to implement what they've decided they're going to do by the end of 2024. So I guess this is just how we do security trends now. So how are zero trust and beyond-corp related? Let's start with traditional networks. In the traditional network architecture, you rely on a network perimeter to delineate between trusted and untrusted users, such as trusted employees inside a firewall versus potentially untrusted employees outside or untrusted actors outside of it. By moving to a zero trust architecture, the location of an individual, specifically what network they're on, is no longer solely what determines whether that individual is trusted, but other context is used to determine whether or not they can access a given application. So with the zero trust architecture, there's no longer such a thing as a privileged physical corporate network. One thing that zero trust doesn't mean though, and people get confused about this, is that VPNs are bad. And I have to say that despite the fact that I work at a VPN company. There's nothing inherently wrong with VPN, but there is something wrong with assuming that because someone's on the VPN, they're trusted, or that they're on the corporate network, they're trusted. So it's more like VPNs that have no application level, access controls are bad, sure. Beyond-corp, introduced in a paper in 2014, is Google's specific implementation from which the broader zero trust principles emerge and zero trust architecture emerges. Yeah. And so beyond-corp is fundamentally an access question. This could be an access to something like your internal corporate wiki. And the way it determines if you, the user, making that request have access, is it considers two primary principles. One is pretty classic, right? It's who you are. What are your credentials? Can you get into this wiki? And then more novelly, it also considers what device you're coming from. So a really good example might be a personal versus a corporate device, right? You might be able to have your credentials on your personal device, but that doesn't mean we necessarily still want you to be able to access the corporate wiki from that device. A really important thing that's just not even in this slide is any discussion of networking. You're talking about VPNs a little bit before, and that's kind of dominated the conversation. And I think that networking is interesting, and your network topology kind of falls out of trying to get these core things. But ultimately, what we're talking about today is access to users and devices, and trying to harden those as much as possible. So first, I said this before, users, we're all kind of familiar with that, right? You are the user, you've done an OAuth dance, you have some credentials, and so on and so forth. So it's pretty much what you'd expect out of any normal application level access question. A few things we will be talking about today is how to harden that. So how do we actually get strong user-first identity and then what are the properties of a strong credential? Because this is fundamental to the access question. Having a strong credential results in stronger access, access decisions. And then the next one is we're gonna talk about devices. So we've discussed stuff like, is this a personal but it's a corporate device? But once you start thinking in that direction, there's a whole kind of different set of questions that you might be interested in asking, right? What is the patch level of that device? Is a really good example. And then how do you store this information? What kind of inventory do you have? And then once you have all of this, how do we again, in the same way that we're gonna think about users credentials, how do we think about device credentials? How do we harden the identity of those device credentials and the storage of them and so on and so forth? And then finally, access is the terrible nitty gritty of given these two pairs of credentials, how do we actually make an access decision? This looks totally different depending on what protocol you're actually using. So as an example, if you're gonna go visit the corporate Wiki, that's gonna look like a very different access decision from a technical perspective of if you're gonna SSH to a prod box. But we actually really do still care about that combination no matter what protocol you're using. And then again, because we now magically have all of this device information, what kind of device information can be used to make an access decision? So if you're trying to get to BeyondCorp or a Zero Trust architecture, how can you actually go about doing it and how do you know how far along you are? So Eric and I have put together a roadmap or a maturity model, whatever you wanna call it, for how you get to Zero Trust. As you go higher from left to right, your organization has more capabilities in terms of how it secures its users, devices, and access to applications on the network. Basically, the more that you harden, the more you're doing Zero Trust. So your first step on the road to BeyondCorp is level one is having an inventory of your users and your devices. At level two, you have a way to measure most of your security controls and enforce some of them. You're able to segment access to specific applications. At level three, we have what's typically called Zero Trust in the market today. It's tiering users and devices based on measurements and enforcing access based on these measurements. So like Eric said, a device that's patched might be treated differently from a device that's not patched. And lastly, level four is what people think they're being sold. It's being able to have dynamically changing risk-based access to applications. This is incredibly hard and something that's not really available in the market today because there are a lot of edge cases. It's what we should be aspiring to as an industry, but we're all still working on the details. So we're going to go through each of these level by level. So level one, as I mentioned, it's about having an inventory of your users and devices. To inventory users who are accessing applications in your environment, the easiest thing to do is to use a single sign-on identity provider, SSO. It's also a great simple security improvement for your organization. This is typically tied to your HR information system. So when a new employee joins, changes teams or leaves, then their identity and so their access to business applications can easily be updated. Even if you have an SSO, you might not be using it consistently. Unfortunately, a lot of SaaS tools charge you extra for the ability to use SSO with their application known as the SSO tax, or sometimes charge you extra just for the ability to enforce SSO for their application. And so for applications where you're not using SSO, you should ask employees to, say, use a password manager, but that's also not something that you can enforce. At this level, you probably also treat employees and contractors' identities the same way, although you might not give contractors access to all of the same applications. In terms of devices at level one, you have a device inventory and some way to manage devices. This can actually be pretty complicated depending on if you have a mix of both company and employee owned or BYOD devices. You probably have a wide mix of operating systems, especially if you support BYOD devices. I think one of my colleagues runs his own OS. You might also support mobile devices. So that makes your life a little bit harder. So although your corporate policy might be to give employees company-owned MacBooks, if you let them BYOD their own mobile devices, you've already added a ton of complexity to what you need to manage. In terms of keeping track of company-owned devices, you ideally have a device inventory of who you've bought what device for, though this is not necessarily more complex than a spreadsheet. And before you let a user connect to a network, then you might have some manual verification that that's actually the expected device. And then at level one in terms of access, it's that flat sort of traditional network where if you're on the network, you're trusted, like a traditional VPN. You know and ideally can control what users and devices are on the network given that you have these inventories, even if it's manual, but you're not segmenting users or devices any further. If you're only dealing with corporate devices and only self-hosted applications, then this, like having a VPN plus an SSO was a pretty good initial set of tools to limit access to your internal applications. And now we're gonna start talking about not just knowing and enumerating but actually measuring and starting to ask questions from, I don't wanna say our users, but our devices at the very least. So this is the slide where I just tell you to use security keys. There was a conversation this morning, hand wave, this is a conversation this morning about passwords and all of the terribleness and I think the password list phrase got thrown out or something like that. Security keys are effectively un-fishable from a browser context. You can go in the technical details of everything, but in terms of producing a good security control that ensures that the initial authentication of your users is strong, there is nothing that compares to just using web-authent-based solutions. So please, I think that's the whole slide. Just use security keys. Oh wait. Oh yeah, and so then we also have things like user properties, right? So this is more classic, right? You want some sort of grouping system like Active Directory. You want a way to say the properties of a particular user, are they an engineer, are they an SRE, so on and so forth because we're gonna wanna use that access information or for access decisions later. And then at level two for devices, we're gonna start thinking about management of devices. Now you can initially start talking about things like MDMs, MDM solutions for mobile devices, but it doesn't actually need to be that complicated. I know plenty of people in playing organizations where it's like, yeah, we just have a script that we run and it checks in occasionally or maybe they use something like Puppet. The ability to just say, ask your device what its patch level is or say later on you might want to force it to update. Having those basic capabilities is fundamental because if you don't, you just can't advance past this particular point. And then yeah, there's someone else on our panel today who is gonna, I think of a OS query sort of training. OS query is a great example of a tool that is open source that you can use that you can install an agent on your devices and then you can start asking questions of your devices. You also want to start thinking about less of like here's this key that I gave you that may be a shared between a bunch of things that lets you on the VPN and start thinking about per device credentials that you can actually associate with the device. This is also where the spreadsheet isn't gonna cut it, right? Like you do need at this point to not think of your inventory as something you only update when you onboard or off-board a device but as something that is continuously living because you're going to be profiling and gathering information from all of your devices. And then level two is of access management is now we have to start thinking about not just having one single policy for all of our applications but we might want to start doing this at a per application level. And there are plenty of open source sort of solutions that do something like this. You know, some engine X plugins go quite a long way. There's also things like the OAuth proxy but the level seven HTTP proxy is a really good way of achieving this because you can't always make the assumption that all your apps are gonna perfectly understand, you know, your format for your user's credentials or your format for your device credentials. And then you also have to start thinking about what are your strategies for non-browser traffic? So this again might be SSH or command line tools. While we generally think of BeyondCorp as a solution for like your browser based traffic, the being able to SSH to a prod box is also something you definitely want to have a strong authorization decision for. And you can't just ignore these sort of access requests because they're not your classic HTTP browser traffic. And then this is where we also are gonna start consuming device credentials. So MTLS is a really good place to start here, right? Give your devices a client certificate. You can, there are a lot of solutions for like Android phones or that kind of thing that I'll allow you to through a enterprise enrollment install client certificates that you use for your corporation. And now we're gonna finally get to level three which is sort of where we see as like zero trust today or whatever. So a very, very common pattern is you have a user and they have a security key and they have a really strong initial authentication and then they exchanged it for some token that is valid till the end of time that just goes on disk or gets thrown at some third party service, right? So IMAP is a great example, right? You have this strong initial authentication and then this device just have a credential that can read the email forever. So the really important part of user authentication is not just to think about the initial authentication but thinking about what are all of the other credentials that a user might have, right? Your SSH keys, your access tokens, so on and so forth and thinking about time-bounding those, right? If you have some initial login and you give somebody a cookie that lasts for 24 hours, that's great, but what other credentials have they also been able to grab from your institution? API access keys, another great example where these things just live forever. What we found very useful is to take weak credentials, maybe bearer tokens are problematic because you can't really hide the secret key, right? There's no secret key, you throw it at someone, you check it into GitHub and it gets on the open internet. We found very useful is to take weak credentials and bind them to strong ones. So for example, if you have a device credential, you might, when you issue someone an API token, put the hash of that device credential in that API token and now when you're making access decisions, you can sort of force a binding between a weak credential and a strong one. And speaking of strong device credentials, first off, we're gonna talk about active management. So this is where, beyond just measuring, we actually wanna start enforcing things. So force patching, great example. Force reboots are another great example where you might patch, but until you reboot, there's nothing that's available. This is also where you can start thinking about what are the other security-specific configuration on your devices, right? And do you want to force these clients to do this? Device-based firewalls, another great example. This is also where we can start thinking more ambitiously about how we are provisioning credentials to devices. So basically all modern devices, right? My laptop, my phone, so on and so forth, has some sort of hardware identity that magic pixie dust, yeah, doesn't change. So this device has a TPM in it. My phone has a strong box, is an Android phone, so it has a strong box as a hardware-based identity for the device. iPhones have the secure enclave. These are great because you can generally challenge them for the identity and then issue corporate credentials based off of them. And that's great because they're no longer physically and manually going and doing this, but you might actually be able to automate some of this. Also, all of these hardware-based identity mechanisms generally have the ability to store private keys. So now you're taking your MTLS certificate that just had a private key that was on disk and you are able to back it by one of these hardware-based solutions and now you have real strong confidence about when that device comes in to my network that it is that device and the request is coming from that device. And finally, we're gonna talk about access and there's a general term that Google has published called tiered access and the sort of summary I wanna give is this. We've talked about personal versus corporate, but anything beyond that, we're gonna start talking about device tiers, right? A personal device is interesting in a corporate device, but what about the patch level of that corporate device? What about other security relevant configuration if it hasn't taken up these particular things we've prescribed to it? Do we wanna continue to allow it access? So when we talk about tiered access, we generally talk about devices losing trust. So this is a device that is a corporate device that should have access, but doesn't because it hasn't done something we want of it. For example, it hasn't patched recently. And critically, the most important tier is a tier that your devices get placed in when they lose access because if they just suddenly lose access and your user has no way of actually regaining that back, that's an extremely bad user experience and you're gonna get some angry messages. So level four. So what we're gonna describe at level four is what people think they're getting, right? So they think that something that implementing a zero trust architecture means that you have dynamic risk-based access to all of your applications for all of your users on all of your devices, and that's not real. That's not possible today. There's a long tail of things that are hard to get right or that are not yet solved for like a normal company to have a zero trust architecture. Specifically, there's a couple of things of the long tail that are hard, SaaS applications, truly risk-based access, device state, and just random network devices. So let's dig in. So this is a friend of ours, Matthew Garrett, who left Google to go work at a startup and realized, oh my God, all of the services my clients use are now hosted web services and starts to think, how do I do zero trust there? And the reality is that this is really hard when you can't put a service behind a proxy. And I think based off the second tweet, Matthew's solution, which I think is a good, if unsatisfying one, is that oftentimes your SSO, that corporate SSO that you paid extra to get, now becomes the access point. So when you go and log in through this and get bounced to your SSO provider that's run by your corporation, it now needs to make intelligent decisions about when I issue you that, Sammel, I forget the assertion or the OIDC token, does this device have a client certificate? Does it have, is it correctly patched and do I wanna now allow this to access the third-party SaaS app for some given amount of time? Yeah, and one workaround that I've heard and I really don't like it, but it's a workaround, is to have the SaaS app's peer-to-peer network so that Ingress traffic to the app is only coming from allow-listed IP addresses that are presumably your corporate network. So an employee who's trying to access Workday or Centifits, whatever happens to be, needs to pass their traffic through your corporate network out the other end to that third application. Some security teams like this because they wanna inspect the traffic or enforce certain things on that traffic, but it is kind of shitty for the user, right? It's like much slower. Yeah, anyways, so in addition to being slow, there's a couple of security downsides that are not great. This is completely a step backwards in time, right? Like you're going back to having a flat network and you're saying that anyone who's on the network can access these SaaS applications, which is not what we're trying to do. It requires the SaaS app to have this functionality. Not every SaaS application lets you have IP allow listing to a set of IPs. And you probably also want a way to correlate audit logs from the SaaS app to your audit logs to know who's actually accessing the application, what they're doing. And you also don't necessarily have fixed IPs, right? Your network changes, you migrate data centers, or more likely you're using a cloud provider, and then you're allow listing all of Google's public IPs or all of Amazon's public IPs, and that's not really closed anymore to anything. That's like you've allow listed a lot of the internet to talk to your internal applications. So relying on IP trust isn't the best way to deal with SaaS apps either. And I think the temptation with tiers is to have a lot of them. People want to do this. They want to say, you know, more than just you have privileged access plus some middle ground, plus no access. And this slide is sort of one of my friends who used to work in Mozilla was working on some of the ways in which they were going to allow, they allow individual applications to prescribe what the requirements are for their own service. So there's two main things that you hit. One is that every service now has to be aware of what tier level it accepts. This gets really messy when you think about things that also might have different levels of tier. A bug system is a great example where some of these might be extra restricted. Additionally, the more you measure, particularly from operating systems, the more you realize that everything is broken and filled with, like held together with duct tape. You know, the version number changed and suddenly all these people lost their access. These type of things happen regularly because ultimately OSPRI is cool, but like the operating system vendors should be providing us that information in a way that isn't gonna break because somebody tweaked, you know, a string. And then I put this in basically all of my slides as well. This is the NSA taking over a Cisco router and doing God knows what to it. State is great until your device starts lying to you, right? Hey, I'm patched and I'm cool and you can let me in. The reality is that there are device state attestation mechanisms. We talked about stuff like TPMs. They work really well for closed ecosystems, right? iPhones are pretty good at detecting if they're broken or not. For when you get into more open ecosystems, like Microsoft where they have to support all of these random devices, I've looked at TPM event logs and I have no idea like is this the thing hacked or is it not? Because to know that information, you'd have to work with one or two or three vendors just to get the right hashes as an example. And the last challenge we're gonna talk about is random network devices. Some devices like thinking of you, printers are just a pain to deal with and manage on your network the same way. Again, I'm still not talking about production network, still talking about the corporate network. It has a lot of devices. Printers don't have secure boot. Printers can't be managed by MDMs. The easiest way for you to set up your printer is with a fixed IP address and then scan your land to find your printer and then use it. But I can't, it's still a device on the network and I still wanna be able to verify and manage access to it in the same way, but I can't. This comes up more in Brownfield than in Greenfield deployments because maybe if you're at a startup if you're trying to adopt a zero trust model you can just not have printers. But existing legacy networks will have a harder time with dealing with these random other devices. So then kind of waving a magic wand and looking at ignoring those challenges we just talked about. If you could have level four, what would that be? It would, there would be a decent way to manage users and user access to SAS applications and correlate logs for when users access those applications. Probably there's only two okay partial solutions today. One is to host everything yourself, which is not super realistic, but you do see becoming more and more common with larger infrastructure tools that offer on-prem solutions. Or the second one and I'll add on to Matthew's list is you can be Google or you can be Microsoft and you can use your single sign-on to access everything. Fundamentally as an industry we don't have a way to deal with this and we need a better way to deal with portable credentials for third-party SAS apps. Ideally also including device credentials, as Eric has pointed out. In terms of devices, you would need to include all the devices that are on your corporate network because they're all a point of entry to your network. Usually the easiest way to address this is actually to move these devices off of the corporate network rather than do whatever they need to do and meet the requirements to remain on the corporate network. And as Eric explained, having hardware-based device out of station from a root of trust that you can actually trust, that's still a very hard problem. And lastly, with all that info-making real-time decisions that aren't just rule-based but that change based on what you know about the user device, quickly enough that the user doesn't notice or get frustrated. And so that's it, right? But as you've learned, that's not exactly easy. So to recap what we talked about today, we proposed different capabilities on your roadmap to adopting a zero-trust architecture that looks a little bit like Google's BeyondCorp. At level one, you are treating the VPN as an access control point for the applications on your network. You can enumerate users and devices. You're using an SSO to inventory users, and you have a manual way to list devices. These are table stakes, IT, and security capabilities. At level two, you have per-service authorization. For example, by using a proxy, you can measure and enforce, you can measure most and enforce some security controls. You have a VPN for your network, an MDM to track and manage your devices, and your users use SSO and MFA, ideally security keys. This is where most security-focused enterprises are today. At level three, you're all in on what the market calls zero-trust architecture, and you've maybe even bought a solution that builds itself that way. What you can do is enforce tiered access to applications based on device characteristics. At level four is what many people aspire to, but no one has yet to fully achieve. You want to be able to dynamically enforce risk-based access to applications, and there's a long list of user, device, and access issues, such as SaaS apps, that are very hard to get right today. I think the wrong takeaway from this talk is to look at this list and say, I'm gonna do a check mark and get to level X, right? BeyondCorp is never really done. It's more the friends you make along the way, right? Like... We're friends. You want to be focusing on these core pillars, and that's not a VPN. It's users, devices, and the way you combine those two pieces of information to determine their access. And that, in and of itself, brings a huge wealth of security benefits, regardless of what level you're at, or if you ever claim that you've accomplished BeyondCorp. And that's it. Thanks so much for joining us and drop questions in the slider. Thank you.