Google Online Security Blog: September 2019

128 captures

21 Sep 2019 - 17 Jun 2026

Mar	APR	May
	25
2025	2026	2027

success

fail

About this capture

COLLECTED BY

Collection: Independent Media Afghanistan

TIMESTAMPS

The Wayback Machine - https://web.archive.org/web/20260425122257/https://security.googleblog.com/2019/09/

Security Blog

The latest news and insights from Google on security and safety on the Internet

How Google adopted BeyondCorp: Part 3 (tiered access)

September 17, 2019

Posted by Daniel Ladenheim, Software Engineer, and Hunter King, Security Engineer Intro
This is the third post in a series of four, in which we set out to revisit various BeyondCorp topics and share lessons that were learnt along the internal implementation path at Google.

The first post in this series focused on providing necessary context for how Google adopted BeyondCorp, Google’s implementation of the zero trust security model. The second post focused on managing devices - how we decide whether or not a device should be trusted and why that distinction is necessary. This post introduces the concept of tiered access, its importance, how we implemented it, and how we addressed associated troubleshooting challenges.

High level architecture for BeyondCorp

What is Tiered Access?

In a traditional client certificate system, certificates are only given to trusted devices. Google used this approach initially as it dramatically simplified device trust. With such a system, any device with a valid certificate can be trusted. At predefined intervals, clients prove they can be trusted and a new certificate is issued. It’s typically a lightweight process and many off-the-shelf products exist to implement flows that adhere to this principle.

However, there are a number of challenges with this setup:

Not all devices need the same level of security hardening (e.g. non-standard issue devices, older platforms required for testing, BYOD, etc.).
These systems don’t easily allow for nuanced access based on shifting security posture.
These systems tend to evaluate a device based on a single set of criteria, regardless of whether devices require access to highly sensitive data (e.g. corporate financials) or far less sensitive data (e.g. a dashboard displayed in a public space).

The next challenge introduced by traditional systems is the inherent requirement that a device must meet your security requirements before it can get a certificate. This sounds reasonable on paper, but it unfortunately means that existing certificate infrastructure can’t be used to aid device provisioning. This implies you must have an additional infrastructure to bootstrap a device into a trusted state.

Different access levels for different security states
Solving the bootstrapping challenge
Multiple trust states enable us to use the system to initiate an OS installation. We can now allow access to bootstrapping (configuration and patch management) services based solely on whether we own the device. This enables provisioning to occur from untrusted networks allowing us to replace the traditional IP-based checks.

Configurable frequency of trust evaluations

How did we define access tiers?Maintaining a Healthy Fleet
How did we create rules to implement the tiers?
Rule Enforcement and User Experience
How did we simplify troubleshooting?

Next time

In the next and final post in this series, we will discuss how we migrated services to be protected by the BeyondCorp architecture at Google.

In the meantime, if you want to learn more, you can check out the BeyondCorp research papers. In addition, getting started with BeyondCorp is now easier using zero trust solutions from Google Cloud (context-aware access) and other enterprise providers.
Thank you to the editors of the BeyondCorp blog post series, Puneet Goel (Product Manager), Lior Tishbi (Program Manager), and Justin McWilliams (Engineering Manager).

Trust but verify attestation with revocation

September 6, 2019

Posted by Rob Barnes & Shawn Willden, Android Security & Privacy Team[Cross-posted from the Android Developers Blog]

key attestation systemhttps://android.googleapis.com/attestation/statusformatREVOKEDSUSPENDED KEY_COMPROMISECA_COMPROMISESUPERSEDEDSOFTWARE_FLAW.developer documentationKey Attestation sample

Labels: android security

Labels

Archive

2026
- Apr
- Mar
- Feb
- Jan

2025
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2024
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2023
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2022
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2021
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2020
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2019
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2018
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2017
- Dec
- Nov
- Oct
- Sep
- Jul
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2016
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2015
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2014
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- Apr
- Mar
- Feb
- Jan

2013
- Dec
- Nov
- Oct
- Aug
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2012
- Dec
- Sep
- Aug
- Jun
- May
- Apr
- Mar
- Feb
- Jan

2011
- Dec
- Nov
- Oct
- Sep
- Aug
- Jul
- Jun
- May
- Apr
- Mar
- Feb

2010
- Nov
- Oct
- Sep
- Aug
- Jul
- May
- Apr
- Mar

2009
- Nov
- Oct
- Aug
- Jul
- Jun
- Mar

2008
- Dec
- Nov
- Oct
- Aug
- Jul
- May
- Feb

2007
- Nov
- Oct
- Sep
- Jul
- Jun
- May

Feed

Give us feedback in our Product Forums.

Google
Privacy
Terms

✕

Wait! Don't Go Yet 🚀

Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!

No spam. Unsubscribe anytime.