7 ms·

I know the approach described in the article is not particularly new [0], but I think it deserves to get more traction than it does (AFAIK). I do have some oth

I know the approach described in the article is not particularly new [0], but I think it deserves to get more traction than it does (AFAIK). 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? [0] https://research.google.com/pubs/pub43231.html https://research.google.com/pubs/pub43231.html

Promarged 9y ago
I'm not a Googler but reading from previous publications BYOD is not supported. This stems from the fact that for BeyondCorp to work they need to be sure the device has not been tampered with. Only having trusted-boot really ensures that.
- lima 9y ago
  Any corporate security mechanism requires the devices not to be tampered with... If anything, BeyondCorp reduces the impact if a device does get compromised.
  - Promarged 9y ago
    Yes, but my point is that only when the corporation issues the hardware themselves they can be sure that the user did not tamper with it. (It's not clear to me if that's what you're saying...)
    - dpark 9y ago
      How do you give someone physical control of a device and then ensure the device hasn't been tampered with? And how is this scenario different if the company owns the device vs the employee?
    - lima 9y ago
      But how is this specific to a BeyondCorp design?
  - pquerna 9y ago
    In a ByeondCorp-like architecture, BYOD is a policy decision. Google as a POLICY has generally said no to all unmanaged machines. 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.
    - dboreham 9y ago
      >Once you logged into the VPN you had carte-blanche access to all kinds of things. 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.
      - pquerna 9y ago
        Partially agree, but the world is a big place. Lots of random internal resources do exist, even at big companies. 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.
- fulafel 9y ago
  Android and x86 at least have no credible assurance about that. Boot chain integrity does nothing to stop you from gaining access through local privilege escalation vulnerabilities.
  - mikelward 9y ago
    But it means you can whitelist trusted OS releases. And ensure devices have all the security updates they claim to. You'd still have intrusion detection, firewall, user presence detection, monitoring at the proxy, etc. to guard against threats posed by local exploits.
    - fulafel 9y ago
      After the user (or malware) gets code execution in ring 0, the whitelists and detection mechanisms are no longer effective.
      - mikelward 9y ago
        They're a necessary condition, not a sufficient condition. (Good signal if present, bad signal if absent.)
theamk 9y ago
I don't know more than what's mentioned in public sources, but I can guess: 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.com/en//pubs/archive/46366.pdf https://static.googleusercontent.com/media/research.google.c...
- mc32 9y ago
  >BYOD is likely supported, but provisioning installs the invasive device monitor 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.
technofiend 9y ago
The article specifically states "Provisioning Chromebooks for new employees is a minimal processing, taking no longer than 90 seconds worth of configuration settings." Other than the badly worded phrase "a minimal processing" I think you can reasonably assume you have your answer. 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.
- ma2rten 9y ago
  You are reading too much into that sentence. Most software engineers at Google actually have a MacBook as laptop and a Linux workstation.
  - jwlato 9y ago
    And that MacBook is primarily a web browser and/or really expensive dumb terminal.
    - bonesss 9y ago
      Primarily... but then it's a MacBook for secondary uses. You can't run minikube on a dumb terminal while off at a conference.
      - technofiend 9y ago
        I guess the question really is can you download code from the repos to your own desktop or laptop and do anything with it?
tyler_larson 9y ago
The answer to both the byod and permissions questions is the "tiered" device trust part from the article. You, the policy-maker decide how certain you are that a device hasn't been pwned given its provenance and user access story, and you assign a "trust tier" accordingly, which determines what resources it can access. 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.
- puzzle 9y ago
  BYOD is possible to at least some degree, with devices like Chromebooks. A few years ago, I was able to use my personal Chromebook to access internal sites. I tried just a few. The sole requirements I remember were a stock install of the OS, a work profile and a Yubikey.
- pkcsecurity 9y ago
  > A lot of this discussion glosses over the fact that U2F really makes this a viable system. 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.
- e12e 9y ago
  > 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 (…) Makes viable: certainly; solves: not so sure. Session hi-jack doesn't magically cease to be a problem.
  - nine_k 9y ago
    It becomes much less of an issue if the connection is re-negotiated periodically, and a new key may require a physical action (touch) from the key generator.
datguacdoh 9y ago
There's a lot more about the end user experience in the most recent published paper: https://research.google.com/pubs/pub46366.html https://research.google.com/pubs/pub46366.html

Promarged 9y ago

I'm not a Googler but reading from previous publications BYOD is not supported. This stems from the fact that for BeyondCorp to work they need to be sure the device has not been tampered with. Only having trusted-boot really ensures that.

lima 9y ago
Any corporate security mechanism requires the devices not to be tampered with... If anything, BeyondCorp reduces the impact if a device does get compromised.
- Promarged 9y ago
  Yes, but my point is that only when the corporation issues the hardware themselves they can be sure that the user did not tamper with it. (It's not clear to me if that's what you're saying...)
  - dpark 9y ago
    How do you give someone physical control of a device and then ensure the device hasn't been tampered with? And how is this scenario different if the company owns the device vs the employee?
  - lima 9y ago
    But how is this specific to a BeyondCorp design?
- pquerna 9y ago
  In a ByeondCorp-like architecture, BYOD is a policy decision. Google as a POLICY has generally said no to all unmanaged machines. 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.
  - dboreham 9y ago
    >Once you logged into the VPN you had carte-blanche access to all kinds of things. 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.
    - pquerna 9y ago
      Partially agree, but the world is a big place. Lots of random internal resources do exist, even at big companies. 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.
fulafel 9y ago
Android and x86 at least have no credible assurance about that. Boot chain integrity does nothing to stop you from gaining access through local privilege escalation vulnerabilities.
- mikelward 9y ago
  But it means you can whitelist trusted OS releases. And ensure devices have all the security updates they claim to. You'd still have intrusion detection, firewall, user presence detection, monitoring at the proxy, etc. to guard against threats posed by local exploits.
  - fulafel 9y ago
    After the user (or malware) gets code execution in ring 0, the whitelists and detection mechanisms are no longer effective.
    - mikelward 9y ago
      They're a necessary condition, not a sufficient condition. (Good signal if present, bad signal if absent.)

theamk 9y ago

I don't know more than what's mentioned in public sources, but I can guess: 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.com/en//pubs/archive/46366.pdf https://static.googleusercontent.com/media/research.google.c...

mc32 9y ago
>BYOD is likely supported, but provisioning installs the invasive device monitor 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.

technofiend 9y ago

The article specifically states "Provisioning Chromebooks for new employees is a minimal processing, taking no longer than 90 seconds worth of configuration settings." Other than the badly worded phrase "a minimal processing" I think you can reasonably assume you have your answer. 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.

ma2rten 9y ago
You are reading too much into that sentence. Most software engineers at Google actually have a MacBook as laptop and a Linux workstation.
- jwlato 9y ago
  And that MacBook is primarily a web browser and/or really expensive dumb terminal.
  - bonesss 9y ago
    Primarily... but then it's a MacBook for secondary uses. You can't run minikube on a dumb terminal while off at a conference.
    - technofiend 9y ago
      I guess the question really is can you download code from the repos to your own desktop or laptop and do anything with it?

tyler_larson 9y ago

The answer to both the byod and permissions questions is the "tiered" device trust part from the article. You, the policy-maker decide how certain you are that a device hasn't been pwned given its provenance and user access story, and you assign a "trust tier" accordingly, which determines what resources it can access. 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.

puzzle 9y ago
BYOD is possible to at least some degree, with devices like Chromebooks. A few years ago, I was able to use my personal Chromebook to access internal sites. I tried just a few. The sole requirements I remember were a stock install of the OS, a work profile and a Yubikey.
pkcsecurity 9y ago
> A lot of this discussion glosses over the fact that U2F really makes this a viable system. 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.
e12e 9y ago
> 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 (…) Makes viable: certainly; solves: not so sure. Session hi-jack doesn't magically cease to be a problem.
- nine_k 9y ago
  It becomes much less of an issue if the connection is re-negotiated periodically, and a new key may require a physical action (touch) from the key generator.

datguacdoh 9y ago

There's a lot more about the end user experience in the most recent published paper: https://research.google.com/pubs/pub46366.html https://research.google.com/pubs/pub46366.html