Google Online Security Blog: October 2019

The Wayback Machine - https://web.archive.org/web/20220318002641/https://security.googleblog.com/2019/10/

How Google adopted BeyondCorp: Part 4 (services)

October 31, 2019

Posted by Guilherme Gonçalves, Site Reliability Engineer and Kyle O'Malley, Security Engineer
IntroBeyondCorpfirst postsecond postthird post

High level architecture for BeyondCorpIdentifying and gating services
How do you identify and categorize all the services that should be gated?
Google began as a web-based company, and as it matured in the modern era, most internal business applications were developed with a web-first approach. These applications were hosted on similar internal architecture as our external services, with the exception that they could only be accessed on corporate office networks. Thus, identifying services to be gated by BeyondCorp was made easier for us due to the fact that most internal services were already properly inventoried and hosted via standard, central solutions. Migration, in many cases, was as simple as a DNS change. Solid IT asset inventory systems and maintenance are critical to migrating to a zero trust security model.

Enforcement of zero trust access policies began with services which we determined would not be meaningfully impacted by the change in access requirements. For most services, requirements could be gathered via typical access log analysis or consulting with service owners. Services which could not be readily gated by default ACL requirements required service owners to develop strict access groups and/or eliminate risky workflows before they could be migrated.
How do you know which trust tier is needed for every service?previous blog postprinciple of least privilege
What do you do with services that are incompatible with BeyondCorp ideals?

It may not always be possible to gate an application by the preferred zero trust solution. Services that cannot be easily gated typically fall into these categories:

Type 1: "Non-proxyable protocols", e.g. non-HTTP/HTTPS traffic.
Type 2: Low latency requirements or localized high throughput traffic.
Type 3: Administrative and emergency access networks.

The typical first step in finding a solution for these cases is finding a way to remove the need for that service altogether. In many cases, this was made possible by deprecating or replacing systems which could not be made compatible with the BeyondCorp implementation.

When that was not an option, we found that no single solution would work for all critical requirements:

Solutions for the "Type 1" traffic have generally involved maintaining a specialized client tunneling which strongly enforces authentication and authorization decisions on the client and the server end of the connection. This is usually client/server type traffic which is similar to HTTP traffic in that connectivity is typically multi-point to point.
Solutions to the "Type 2" problems generally rely on moving BeyondCorp-compatible compute resources locally or developing a solution tightly integrated with network access equipment to selectively forward "local" traffic without permanently opening network holes.
As for “Type 3,” it would be ideal to completely eliminate all privileged internal networks. However, the reality is that some privileged networking will likely always be required to maintain the network itself and also to provide emergency access during outages.

It should be noted that server-to-server traffic in secure production data center environments does not necessarily rely on BeyondCorp, although many systems are integrated regardless, due to the Service-Oriented Design benefits that BeyondCorp inherently provides.
How do you prioritize gating?

Prioritization starts by identifying all the services that are currently accessible via internal IP-access alone and migrating the most critical services to BeyondCorp, while working to slowly ratchet down permissions via exception management processes. Criticality of the service may also depend on the number and type of users, sensitivity of data handled, security and privacy risks enabled by the service.
Migration logistics

Most services required integration testing with the BeyondCorp proxy. Service teams were encouraged to stand up "test" services which were used to test functionality behind the BeyondCorp proxy. Most services that performed their own access control enforcement were reconfigured to instead rely on BeyondCorp for all user/group authentication and authorization. Service teams have been encouraged to develop their own "fine-grained" discretionary access controls in the services by leveraging session data provided by the BeyondCorp proxy.
Lessons learnt
Allow coarse gating and exceptions

Inventory: It's easy to overlook the importance of keeping a good inventory of services, devices, owners and security exceptions. The journey to a BeyondCorp world should start by solving organizational challenges when managing and maintaining data quality in inventory systems. In short, knowing how a service works, who should access it, and what makes that acceptable are the central tenets of managing BeyondCorp. Fine-grained access control is severely complicated when this insight is missing.

Legacy protocols: Most large enterprises will inevitably need to support workflows and protocols which cannot be migrated to a BeyondCorp world (in any reasonable amount of time). Exception management and service inventory become crucial at this stage while stakeholders develop solutions. Run highly reliable systems
The BeyondCorp initiative would not be sustainable at Google’s scale without the involvement of various Site Reliability Engineering (SRE) teams across the inventory systems, BeyondCorp infrastructure and client side solutions. The ability to successfully achieve wide-spread adoption of changes this large can be hampered by perceived (or in some cases, actual) reliability issues. Understanding the user workflows that might be impacted, working with key stakeholders and ensuring the transition is smooth and trouble-free for all users helps protect against backlash and avoids users finding undesirable workarounds. By applying our reliability engineering practices, those teams helped to ensure that the components of our implementation all have availability and latency targets, operational robustness, etc. These are compatible with our business needs and intended user experiences.
Put employees in control as much as possible

Employees cover a broad range of job functions with varying requirements of technology and tools. In addition to communicating changes to our employees early, we provide them with self-service solutions for handling exceptions or addressing issues affecting their devices. By putting our employees in control, we help to ensure that security mechanisms do not get in their way, helping with the acceptance and scaling processes.
Summarysetting contextdevicestiered accessBeyondCorp research papersGoogle Cloud (context-aware access)Cloud OnAirThank you to the editors of the BeyondCorp blog post series, Puneet Goel (Product Manager), Lior Tishbi (Program Manager), and Justin McWilliams (Engineering Manager).

Protecting against code reuse in the Linux kernel with Shadow Call Stack

October 30, 2019

Posted by Sami Tolvanen, Staff Software Engineer, Android Security & Privacy Team

Control-Flow Integrity (CFI)Shadow Call Stack (SCS) Return-oriented programmingReturn-oriented programming (ROP)automatically generating this type of kernel exploit Shadow Call Stack

4.144.19upstream LinuxCONFIG_SHADOW_CALL_STACK=y # CONFIG_SHADOW_CALL_STACK_VMAP is not set # CONFIG_DEBUG_STACK_USAGE is not set By default, shadow stacks are not virtually allocated to minimize memory overhead, but CONFIG_SHADOW_CALL_STACK_VMAP can be enabled for better stack exhaustion protection. With CONFIG_DEBUG_STACK_USAGE, the kernel will also print out shadow stack usage in addition to normal stack usage which can be helpful when debugging issues.
AlternativesARMv8.3 Pointer Authentication (PAC)Control-flow Enforcement Technology (CET) Conclusion

Improving Site Isolation for Stronger Browser Security

October 17, 2019

Posted by Charlie Reis, Site Isolator The Chrome Security team values having multiple lines of defense. Web browsers are complex, and malicious web pages may try to find and exploit browser bugs to steal data. Additional lines of defense, like sandboxes, make it harder for attackers to access your computer, even if bugs in the browser are exploited. With Site Isolation, Chrome has gained a new line of defense that helps protect your accounts on the Web as well. Site Isolation ensures that pages from different sites end up in different sandboxed processes in the browser. Chrome can thus limit the entire process to accessing data from only one site, making it harder for an attacker to steal cross-site data. We started isolating all sites for desktop users back in Chrome 67, and now we’re excited to enable it on Android for sites that users log into in Chrome 77. We've also strengthened Site Isolation on desktop to help defend against even fully compromised processes. Site Isolation helps defend against two types of threats. First, attackers may try to use advanced "side channel" attacks to leak sensitive data from a process through unexpected means. For example, Spectre attacks take advantage of CPU performance features to access data that should be off limits. With Site Isolation, it is harder for the attacker to get cross-site data into their process in the first place. Second, even more powerful attackers may discover security bugs in the browser, allowing them to completely hijack the sandboxed process. On desktop platforms, Site Isolation can now catch these misbehaving processes and limit their access to cross-site data. We're working to bring this level of hijacked process protection to Android in the future as well. Thanks to this extra line of defense, Chrome can now help keep your web accounts even more secure. We are still making improvements to get the full benefits of Site Isolation, but this change gives Chrome a solid foundation for protecting your data. If you’d like to learn more, check out our technical write up on the Chromium blog.

USB-C Titan Security Keys - available tomorrow in the US

October 14, 2019

Posted by Christiaan Brand, Product Manager, Google Cloud Google’s automatic protectionsstrongestbuiltexpandedextended

USB-C Titan Security Key
YubicoFIDOFeitian TechnologiesGoogle StoreBulk orders

We highly recommend all users at a higher risk of targeted attacks to get Titan Security Keys and enroll into the Advanced Protection Program (APP), which provides Google’s industry-leading security protections to defend against evolving methods that attackers use to gain access to your accounts and data. You can also use Titan Security Keys for any site where FIDO security keys are supported for 2FA, including your personal or work Google Account, 1Password, Coinbase, Dropbox, Facebook, GitHub, Salesforce, Stripe, Twitter, and more.

No More Mixed Messages About HTTPS

October 3, 2019

Posted by Emily Stark and Carlos Joan Rafael Ibarra Lopez, Chrome security team Update (04/06/2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the Chrome Platform Status entry for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://. Sites with mixed images will continue to trigger the “Not Secure” warning. mixed contentprogressChrome will gradually move to blocking all mixed content by default Timeline

In Chrome 79, releasing to stable channel in December 2019, we’ll introduce a new setting to unblock mixed content on specific sites. This setting will apply to mixed scripts, iframes, and other types of content that Chrome currently blocks by default. Users can toggle this setting by clicking the lock icon on any https:// page and clicking Site Settings. This will replace the shield icon that shows up at the right side of the omnibox for unblocking mixed content in previous versions of desktop Chrome.

Accessing Site settings, from which users will be able to unblock mixed content loads in Chrome 79.

In Chrome 80, mixed audio and video resources will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 80 will be released to early release channels in January 2020. Users can unblock affected audio and video resources with the setting described above.

Also in Chrome 80, mixed images will still be allowed to load, but they will cause Chrome to show a “Not Secure” chip in the omnibox. We anticipate that this is a clearer security UI for users and that it will motivate websites to migrate their images to HTTPS. Developers can use the upgrade-insecure-requests or block-all-mixed-content Content Security Policy directives to avoid this warning.

Omnibox treatment for websites that load mixed images in Chrome 80.

In Chrome 81, mixed images will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 81 will be released to early release channels in February 2020.

Resources for developers

Use Content Security Policy and Lighthouse’s mixed content audit to discover and fix mixed content on your site.

See this guide for general advice on migrating servers to HTTPS.

Check with your CDN, web host, or content management system to see if they have special tools for debugging mixed content. For example, Cloudflare offers a tool to rewrite mixed content to https://, and WordPress plugins are available as well.

Chrome UI for Deprecating Legacy TLS Versions

October 1, 2019

Posted by Chris Thompson, Chrome security team[Cross-posted from the Chromium blog]
Update (04/06/2020): The removal of legacy TLS versions was originally scheduled for Chrome 81, but is being delayed until at least Chrome 84. Chrome will continue to show the “Not Secure” indicator for sites using TLS 1.0 or 1.1, and Chrome 81 Beta will show the full page interstitial warning for affected sites. Our hope is that this will help alert affected site owners ahead of the delayed removal. Check the Chrome Platform Status entry for the latest information about the removal of TLS 1.0 and 1.1 support. we announcedover 0.5% of page loadsPre-removal warning

The new security indicator and connection security information that will be shown to users who visit a site using TLS 1.0 or 1.1 starting in January 2020.
Removal UI

The full screen interstitial warning that will be shown to users who visit a site using TLS 1.0 or 1.1 starting in Chrome 81. Final warning subject to change.
our original announcement