As a company, we have deployed and continue to utilize Remote Browser Isolation to browse unknown or questionable sites based on web categories in a ‘safely allow’ posture instead of an outright block. When one of our analysts requested the purchase of a remote browser service to conduct investigations into sites that didn't fall into the web categories that we already send to RBI, we decided to develop a process to isolate any desired sites using our existing product, incurring no additional cost for the company.
The security team is often asked to investigate suspicious web sites, whether they are phishing, malvertising, or others. Netskope uses our Remote Browser Isolation solution for uncategorized, no content, parked domains, proxies and anonymizers, and known threat websites. For sites outside of those categories that require a safe way to investigate a web site we have created a solution for this.
The approach we took was to create a custom URL list. To keep it distinct from other URL lists we simply called it “RBI_On_Demand”.
Because you cannot create an empty URL list, we added a sample page for testing into the list as a placeholder.
We then created a customer category and for continuity and simplicity, also called it “RBI_On_Demand”.
For our isolation environment, the SOC asked that it be the most restrictive possible with our RBI solution, so we created a custom RBI template as well. To do this, navigate to Policies > Templates > RBI and select NEW TEMPLATE
Keeping with the continuity of the naming conventions we again selected “RBI On Demand” as the name to keep this profile distinct from other use cases.
The next step from the administrator side of the Netskope platform is to create a Real-time policy that can utilize each of these newly created elements. From the Real-time Protection menu, select NEW POLICY > Web Access.
For Source, we have applied this policy to only the users in the Security Operations Center and Netskope administrator team. This is customizable to your needs and environment. *The screenshot below shows the policy applied only to myself.
For Destination, select Category and select the custom category you created earlier, in this case it is RBI_On_Demand.
For Profile & Action we need to select Action: Isolate, and for the RBI Template, select the one you created earlier, in our case here it is RBI On Demand.
Our naming convention for policies follow our internally published doc, that makes it easy to identify the purpose of each policy, and we prepend the type of policy to the beginning of the name. In our case we’re calling the policy [RBI] RBI On Demand.
You will want to place the policy as close to the top of the policy stack as possible in order to ensure the URL in question isn’t acted on by another policy. It isn’t recommended that it be placed above the normal threat categories, as if the site is already categorized as a threat or malicious there should be little need for further investigation.
Within the policy description for our processes we place a description of the policy purpose along with the Change Management ticket # and or a link to the ticket that approved the creation of the policy we are putting in place. This makes auditing the changes in the tenant much easier for us.
Now that we have the basis for our RBI On Demand solution setup (whew, glad we only have to do that once!) we can provide the instruction set to our team for how to utilize it.
Once you have the site URL that needs to be investigated, log into the Netskope tenant and navigate to Policies > Web. Once there select URL LISTS from the tabs at the top of the page.
Locate the URL List named RBI_On_Demand and select Edit from the options menu.
Paste the URL that is being investigated into the text box, ensuring that you are following the formatting rules (see URL formatting rules for more information). The example above ensures that both the main site and any child sites that are spawned by the main site will all match the URL list. This helps to keep the site in question running in isolation.
Save the edited URL list. Select Apply Changes. Place the investigation ticket number or even the ticket URL in the notes section for tracking the activity in the audit logs.
Once the change is applied, open an incognito or private browser and navigate to the site that requires investigation.
There are multiple indicators to let you know that the site is indeed in isolation. In the tab where the site name is, there will be an asterisk, a blue border around the page itself, and a temporary pop up message in the lower right corner will appear indicating what actions are restricted while viewing the site in isolation.
Proceed to conduct your investigation!
Currently it takes an analyst approximately four steps to put a designated site into isolation in this method. The team is working on a more streamlined, automated solution that should only take a single step in the near future. Stay tuned and we’ll share that information with you as well!
For more information on RBI, check out https://docs.netskope.com/en/netskope-help/data-security/remote-browser-isolation/.
We do something similar but we further improve this by automating the adding/removing from the URL list. We find the manual process of logging into the UI and updating the URL list tedious. We've developed a slack command that our SOC can use to to immediately submit/remove URL's from url lists for the adhoc adds.
Thanks for sharing your experience with this. Our team too found it to be a few more steps that they wanted and also took the initial process a step further with the use of a Slackbot to simplify the add/remove URL process. The team is going to have a follow up post about the 'new' process shortly. Have a great week!
Here's how our team took a few of those extra steps out of the way to make RBI on Demand even easier.
In order to view this content, you will need to sign in to your account. Simply click the "Sign In" button belowSign In