5 ms·
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 de
by 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 agoAny 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 agoYes, 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...)
- pquerna 9y agoIn 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 agoPartially 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.
- dboreham 9y agoNo disagreement on all that. More layers of security are generally better. The places I worked generally had a centralized SSO service and a strong security team that would hunt down and kill services deployed without authentication.
- fulafel 9y agoAndroid 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 agoBut 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.