[hdhzy]

As far as I remember BeyondCorp required users to be equipped only with attested hardware (no BYOD). This device's health then was constantly being monitored and taken into account when granting / denying access. I'd like to see the differences between IAP and Google's internal BeyondCorp. Quick search did not reveal anything.

[wffurr]

The only BYOD device allowed is Chromebooks with a signed bootloader, aka no developer mode or Crouton.

[kuschku]

Unless you modify the hardware, of course.

Considering Google has teams designing custom PCBs and even ICs, there's a non-insignificant amount of Google devs who could easily circumvent this entire system.

[weeks]

The purpose of ascertaining device identity is to prevent someone who can't obtain legitimate Google issued hardware from using stolen user credentials. If you're already a Google employee you can just ask for more trusted hardware, so there would be little point in breaking that part of the security model.

[kuschku]

Well, there was recently a case where one of the developers for Google's custom LIDAR hardware stole the plans and gave them to Uber.

And people argued he had no option to hide it.

As I mentioned there, too, it's trivial to break that security if you have the knowledge to design and reverse custom ICs, and you could just steal the laptop of someone else, clone their trusted hardware system, and ensure their laptop is back in place.

Then later use that account to download the data to be sent to Uber.

I mean, for many cases of corporate espionage this is easily doable — it's just fancy DRM, after all. Not by the average dev, but for people who design this hardware or similar hardware in the first place, definitely.

[londons_explore]

Google's model requires two factor user auth, and trusted hardware.

Even someone with serious hardware-foo would only be able to maybe break the trusted hardware bit (by cloning one device id to another, or emulating a device). They couldn't get round the two factor authentication bit.

I'd say it's still a pretty watertight model.

[pizzetta]

Like many things, I'm sure you can make a case for exceptions or whitelists --although granted they likely monitor and or shunt traffic to less trusted vlans or something?

[londons_explore]

The ultimate BeyondCorp setup has no vlans. All networking kit is considered untrusted (and can be the public internet). All traffic is end to end encrypted between the employees device and the specific server they want to communicate with via HTTPS.

Obviously, getting entirely to that model is a lot of work, mostly for services which don't use HTTPS (network shares, ftp, smtp, ssh, enterprise java apps, etc.)

[brazzledazzle]

I think that's why the describe this as "...a building block toward BeyondCorp..." We'd pay for them to develop a service that did the whole 9 yards (multi-platform agents, CA, client-certs, etc.).

[closeparen]

In general, you can prevent BYOD with this approach by rolling out client certificates with config management and requiring them at the proxy.

[londons_explore]

And the client certs can be tpm backed so they can't be copy+pasted to other machines.

[mikecb]

Part of the announcement was that additional contextual auth capabilities would be added.