I do have some other questions, though:
1) Does this infrastructure support BYOD, and if so, what does the provisioning process look like?
2) What permissions do employees have their devices?
3) How are device compromises handled?
I don't think beyondcorp necessarily changes your incident response story, assuming you already have one.
A lot of this discussion glosses over the fact that U2F really makes this a viable system. U2F solves the MITM problem and ensures that the anyone who logs in does so with a company-issued hardware authenticator in physical communication (usually USB, but maybe also NFC or Bluetooth) with the client device. This means that even in a byod story, there's a piece of corp-issued hardware always attached. This in turn means that impersonation requires physical device theft in addition to credential theft.
This. Really, BeyondCorp is only amazing insofar as it takes full advantage of U2F. U2F is the real (and lasting) innovation we're looking at here.
Makes viable: certainly; solves: not so sure. Session hi-jack doesn't magically cease to be a problem.
1) BYOD is likely supported, but provisioning installs the invasive device monitor (as chrome extension [0])
2) Paper mentions that you can at least install your own printers. I would think that SW engineers would have full access, subject to device monitor being happy.
3) Since all keys (both per-user and per-device) are stored centrally, it should be fairly easy to revoke all device keys in this case.
[0] https://static.googleusercontent.com/media/research.google.c...
Probably not. Since they lock down which apps run or not, I doubt they'd trust some home rolled, untrusted, unverified install with unknown executables running.
The article also mentions that "The model benefited the fact that all of Google’s internal applications are already on the Web". I'm just going to assume that means Google employees are using web-based remote access for development. If that's the case then their Chromebooks are really just expensive dumb terminals. We may differ on this but I personally don't see any reason to drop $1k+ on a dumb terminal just to say I own the hunk of plastic I do my job on every day, particularly when my employer will hand me one for free when I start my new job.
Based on that assumption I think you can also reasonably assume permissions around futzing with the needed browser plugins are limited and device compromise is handled how Chromebooks normally handle most problems: wipe and reinstall.
You can't run minikube on a dumb terminal while off at a conference.
More importantly: with the kinds of operations Google is running these days you'd really expect lots of the APIs youd need for product development to be readily accessible.
So, yeah, you'd be hacking on your laptop separately, and maybe doing some kinds of work. They run a monorepo, though, so it'd be of a somewhat peripheral nature. Proper dev is what the dev station is for.
Your comment seems to be mostly a bunch of wild speculation, but if you are presupposing they use Chromebooks as dumb terminals, I don't know where you're getting this $1000 figure from. If that's were the use-case then there's no reason not to go with the cheapest Chromebooks available, which can be as low as $200.
> if you are presupposing they use Chromebooks as dumb terminals, I don't know where you're getting this $1000 figure from. If that's were the use-case then there's no reason not to go with the cheapest Chromebooks available, which can be as low as $200.
That's wrong: A dumb terminal is basically a screen, a keyboard, and a network interface. A $200 Chromebook is going to have much lower quality versions of all three than a $1000 Chromebook. So, there is a very good reason why Google wouldn't issue "the cheapest Chromebooks available."
So my original assumption was therefore must be using a web interface to some sort of unix desktop and then sshing from there, right? However on second thought the article implies once you're trusted you're trusted and all systems are enforcing their own security so maybe people are sitting on UNIX desktops at Starbucks, authenticating via a certificate and then trusted across the public interfaces of Google's assets. That too would make perfect sense and still fit the spirit of the article.
The question is really do you have trusted access from a portable device or simply via one?
Again this really is speculation on my part and I'll happily own that. I can only dream of the level of access the average Googler has; the regulatory oversight and internal interpretation of same has resulted in far harsher limits in my space.
You'd still have intrusion detection, firewall, user presence detection, monitoring at the proxy, etc. to guard against threats posed by local exploits.
If anything, BeyondCorp reduces the impact if a device does get compromised.
Some resources might require a managed machine by policy, but others may not.
Imagine your Corporate Cafe menu. You don't want it posted on Buzzfeed that y'all be having filet mignon on Tuesdays, but you really don't care about the posture of a device. Contrast this with your internal source code repository or wiki. You might really care about device posture for that type of resource.
Previously you had to put both the Cafe Menu and your Source Code under one big hammer: The VPN. Once you logged into the VPN you had carte-blanche access to all kinds of things.
BeyondCorp gives you a L7 place to drive POLICY decisions in a consistent manner.
In my experience this isn't generally true and hasn't been true in properly run organizations since the late 90's. I don't know if it was the case at Google at some point in the past (seems unlikely). Everywhere I've worked for decades has viewed the internal network as hostile. You need credentials to access every internal site/app/resource (including the cafeteria menu). The VPN is just an extra onion layer to guard against screwups with internal endpoint protection, and because to be honest it is pretty easy to deploy so why not.
Internal resources are owned by many separate teams. They implement AuthN / AuthZ on their own. Resources might prompt for a username & password and then do an LDAP Bind with them, or they might have a local database, or they might use an SSO/SAML, or any other number of mechanisms.
Resource owners want to move fast, they want new internal apps. Central IT/Security wants to add WAFs, 2FA, centralized logging, and all kinds of other controls.
The BeyondCorp model moves these responsibility to an easier to deploy model. It's now centralized as a service, rather than each internal app needing to buy 5 security appliances that they are required to put in their rack.