Extended RBI

Extended RBI


Extended RBI requires additional licensing. Contact Support to enable this feature in your account.

The Extended RBI feature covers additional risk scenarios which are not included in Targeted RBI, i.e. additional web categories and unsanctioned cloud apps which do not require full isolation.

Extended RBI protects the browsing activity and browser for corporate users accessing unsanctioned cloud apps and websites.


The current list of Web Categories and Web Apps available for use with Extended RBI is a subset of what’s available for policies.

Extended RBI allows admins to leverage additional policy matching criteria including:

  • Policy matching based on “cloud apps” definition, to set up isolated browsing session for users as they browse the unsanctioned cloud app
  • Additional web categories in your RBI policies to isolate webpages: e.g. webmail, social, cloud storage
  • CCL – Cloud Confidence Level
  • App Tags – e.g. unsanctioned app
  • Destination Country
  • Up to 25% of the processed NGSWG traffic

Web Categories


The current list of Web Categories and Web Apps available for use with Extended RBI is a subset of what’s available for policies.

The following web categories are available to isolate unsanctioned web apps:

Chat, IM & other communication

Professional Networking

Cloud storage



Application Suite*


*Application suite is required to support log in for some of the apps in scope, which belong to cloud app suites, where log in domains have their own category (e.g. Live accounts, Google accounts).


Cloud Apps


The current list of Web Categories and Web Apps available for use with Extended RBI is a subset of what’s available for policies.

Cloud app matching is available for narrow matching criteria (isolating the app) for the following 18 cloud apps and associated web categories.

Web CategoryCloud App
Chat, IM & other communication
  • WhatsApp
Cloud Storage
  • WeTransfer
  • Box
  • Dropbox
  • Google Drive
  • Microsoft OneDrive
  • iCloud Drive
  • Microsoft Office 365 OneDrive for Business
Professional Networking
  • LinkedIn
  • Facebook
  • Twitter
Web mail
  • Google Gmail
  • Outlook Live (OWA)
  • Yahoo Mail
Application Suites
  • Google accounts
  • Microsoft Live accounts
  • Microsoft accounts
  • Yahoo accounts

Additional Policy Criteria

The additional policy criteria are available to use:

  • App Tag (Unsanctioned only): Sanctioned is not supported and the action will revert to “Alert” if used.
  • CCL
  • Destination Country

Extended RBI Use Cases

Use cases and recommended configurations are described in the sections below.

1- Safely enable web access to unsanctioned cloud apps in a certain web category

Sanctioned apps in these web categories are controlled by CASB controls. Protect endpoint and leverage RBI templates settings to augment data protection capabilities in the isolated session e.g. printing, copy, paste, read-only, uploads, downloads.


2 – Safely enable access to potentially risky apps in a web category, based on CCL

Leverage Netskope’s CCI database to isolate low level confidence apps. e.g. Allow (excellent), Block (poor), Isolate (low CCL). Use RBI as an additional protection and an alternative to block access.


3 – Safely expand access to web pages in a potential risky destination country

RBI Provides additional protection of a user’s privacy because the browser has no context of the user and exposes RBI egress IPs. Actual source IP, endpoint details are not uncovered. This is ideal for research.


4 – Define Fine grain Isolation policies: Isolate specific cloud apps

Ability to go beyond isolation based on category matching, with no need to define exceptions or create custom URL lists for custom categories.

Leverage Netskope’s Cloud App definition to create RBI policies to only isolate your risky app. User browsing is isolated only in the application domain boundaries.


5 – Disable clipboard pasting in unsanctioned apps to reduce data leakage

Disabling clipboard paste in the isolated sessions prevents users from pasting corporate information into these unsanctioned apps. This setting augments Data Protection and does not require activity detection or DLP matching.

6 – Provide Read Only access to personal webmail

Some of the most popular webmail apps are unsanctioned (personal use) apps such as: Gmail, Outlook Live (personal) or Yahoo mail. All of these are not corporate.

Admins can leverage RBI templates to configure policies for certain apps to only allow text input in the login domain. Access to the rest of the webmail app is read-only:

  • Any embedded threat is not executed in the browser
  • No data can be leaked as text input
  • File uploads are disabled

Extended RBI Best Practices

RBI is a stateless service. The user web stat is not carried over beyond the lifetime of an isolated browsing container.

Web apps normally use cookies to persist state and perform authentication. With the introduction of the Extended RBI offering, RBI needs to be able to store this state and access it across RBI sessions to achieve a seamless user experience.

When the ‘Private Navigation’ setting is disabled in the RBI template, and as a result of the user browsing in isolation, RBI will persist cookies in the end user’s browser. Cookies produced by the isolated webpage in RBI will always be stored with the suffix “-NS-RBI” in the name so they remain separate from cookies generated out of isolation.

In the absence of these cookies some complex logins (e.g. Google authentication) will not be possible: users will face redirection loops or sign-in error messages.


Use the ‘Private Navigation’ setting in the RBI template to enable or disable storage of cookies generated browsing in isolation in the end user’s browser to persist across future RBI sessions.

Extended RBI Best Practices for Creating Policies


Corporate or sanctioned IdPs are not supported (e.g., Okta, Ping).

Isolated browsing sessions isolates all browsing from the rest of the user’s browsing activity. If you want to isolate an app, the authentication flow needs to happen inside isolation.

The following cloud apps (categories) need to be explicitly included in the policy to isolate the corresponding authentication flow:

Cloud AppWeb Category
Google accountsApplication Suite
Microsoft Live accountsApplication Suite
Yahoo accountsApplication Suite
Microsoft accountsApplication Suite


Users will not be able to log in to the isolated web app if the policy is not properly configured: isolate web app + authenticated flow. The web app will have no visibility or knowledge about the authentication flow.

Example 1: Isolate unsanctioned (personal) web mail apps based on the destination category.

Add the “Application Suite” category to properly isolate the authentication flow for web mail apps that are part of application suites:


Example 2: Isolate unsanctioned (personal) web Outlook + OneDrive apps based on the destination cloud app.


Fine tune your isolate policy to only send the user browser requests to RBI

RBI sets an interactive browsing session in a managed, isolated environment to protect endpoints/users from malicious content embedded in the web code as they browse these pages. There must be a user browsing a webpage with a web browser.

Adding the browser source criteria to the isolate policy helps prevent undesired traffic hitting the isolate policy and being sent to RBI for isolation, since this is likely not isolatable content (e.g., API call by a desktop agent to fetch content in JSON format; it can’t be isolated).


Create Real-time Protection Policies for content that you cannot isolate

RBI protects users by isolating browsing of webpages. Given the nature of the Netskope Proxy (URLs) vs RBI (webpages only, a subset of URLs), some URL requests matching an isolate policy can reach the RBI platform, but be impossible to isolate (e.g., a url to fetch a packet update or a config file from a user agent that is not a browser).

RBI cannot process those requests without breaking the business flow or interfering with the customers Real-time Protection policies; so, when these situations occur, RBI forwards the request to the destination, fetches the response and forwards it to the Netskope proxy for additional processing.

Requests that are not isolated are regular HTTP requests. Setting controls for those requests requires Content policies and/or Real-time Protection policies. If you want to block, alert, or inspect the content of those responses for DLP or Threat Detection purposes, you must create Real-time Protection policies that address them.

1. Add RBI categories to your threat policies.

Netskope recommends that your threat policy should also inspect responses that are not isolated, so no Malware will hit the endpoint for those situations where it is impossible to set up an isolated browsing session for the user.


2. Create content inspection policies for isolated categories according to your security posture.

Create ‘Block’, ‘Alert’, or ‘Allow’ policies for activities in RBI categories. They will trigger requests that hit an RBI policy and yet they couldn’t be isolated (they were not a webpage). As of today, these policies need to be created on top of the isolate policy, following the proxy policy engine evaluation order:

Share this Doc
In this topic ...