Extended RBI Best Practices and Considerations

RBI is a stateless service. The user web state 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.

Extended RBI Best Practices for Creating Policies

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 App	Web Category
Google accounts	Application Suite
Microsoft Live accounts	Application Suite
Yahoo accounts	Application Suite
Microsoft accounts	Application Suite

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:

RBI Extended Categories

When you create policies, a banner in the Cloud section displays if you select a cloud application that has a suite associated with it. Click Add to quickly add the associated suite while you’re creating the policy.

Cloud apps and their associated suite includes:

• Google Gmail – Google Accounts suite
• Google Drive – Google Accounts suite
• Microsoft OneDrive – Microsoft Live Accounts suite

The UI after you click Add and the associated app suite appears.

RBI 3rd Party Authentication Flow

The third party authentication flow feature for RBI simplifies the policy definition process for applications that use alternate domains for authentication. This is accomplished by comparing browser navigation events generated within RBI to a list of well known domains used for authentication and forcing those navigation events to remain within RBI. There are certain domains such as facebook.com and linkedin.com that are used for authentication as well as hosting legitimate web sites. For such cases, users navigating to these domains from within isolation will remain in RBI isolation regardless of their Real-time Protection policies. To navigate directly to the site, type the URL directly into the browser navigation bar instead of following hyperlinks from within an isolation RBI session.