4 ms·

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

by wffurr 10y ago

kuschku 10y ago
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.
- londons_explore 10y ago
  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 10y ago
    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 10y ago
      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.)
- weeks 10y ago
  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 10y ago
    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.

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

by wffurr 10y ago

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

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.

londons_explore 10y ago
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 10y ago
  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 10y ago
    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.)
weeks 10y ago
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 10y ago
  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.