This is a short write-up on different approaches and nuances of Netskope Android client (NSClient) deployments, as it differs from, for example, the deployment of the Netskope iOS Client.
This post will cover a rather easy and common deployment of steering and protecting certain app traffic to Netskope. This is similar to how iOS enables per-app VPN deployment. If you are interested is the high-level overview of our mobile capabilities, you might want to check out the following blog post: Netskope's capabilities on mobile platforms - The Netskope Community
The mentioned functionalities and configuration of the Netskope Android client are described in the documentation center: https://docs.netskope.com/en/netskope-client-supported-os-and-platform.html.
When you start deploying the NSClient with a Mobile Device Management (MDM) solution such as VMware Workspace and Microsoft Intune, the NSClient will be installed under the work profile. This is a neat feature in Android that allows a user to use the MS Outlook app in the personal space as well as the work profile. Because the NSClient is only installed in the work profile, this means that only the traffic originating from work applications is steered to Netskope. WhatsApp traffic in the personal profile will not be steered to Netskope.
When using the NSClient, a Netskope tenant CA certificate will be installed in the user certificate store of the work profile. Accordingly, by default, the whole work profile will be tunneled to Netskope. Apps and/or traffic within the personal profile will not be steered to Netskope.
Because the Netskope tenant certificate is not installed in the system certificate store of the work profile, apps that do not explicitly trust the user certificate store will throw errors when TLS decryption is performed.
The inability to install a third-party custom CA into the system store has been introduced since Android Nougat (source: https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html).
The Netskope Client adds nifty traffic steering capabilities on Android that allow organizations to determine which applications they would like to bypass directly to the internet (5G/WiFi) or steer to Netskope to inspect traffic or connect to a private application.
The image below shows the work profile of an organization where the organization wishes to steer Chrome traffic to Netskope to connect to the internal Sharepoint and also protect against malware and enforce compliance on the corporate browser.
These traffic streams are highlighted in orange. Other applications/processes where certificate pinning is used or video traffic is originating, such as OneDrive, Teams, and Samsung Bixby, can be bypassed. These traffic streams are highlighted in green.
The configuration of the steering policies is performed in a steering profile that can be applied based on the group of the user or the organizational unit (OU). This can be found in the Settings page of Netskope -> Security Cloud Platform -> Steering Configuration -> <Select your config> -> Exceptions -> New Exception -> Certificate Pinned Application -> Create a new definition for the Android Platform.
See below two different RegEx definitions based on the Android application IDs. The first RegEx will make the Nsclient only steer traffic from Chrome and MS Edge to Netskope, while bypassing all other work-related processes/applications.
Or if you would only like to steer Microsoft Edge to Netskope:
To make it more visual on what is selected and what is not based on these rules:
Source: https://regex101.com/ (PCRE2)
If you want to steer different applications you can easily find the application ID on the Google Playstore. Just search for the application and the application ID will be shown in the URI, just like the example below (underlined in red).
There are different approaches to steer and secure user traffic on an Android system. This post illustrates how to accomplish real-time inspection for the Microsoft Edge and Chrome browsers within the work profile. If you would like to inspect other applications, it is important that such applications explicitly allow TLS decryption (do not perform certificate pinning).
Another excellent approach for protecting managed applications that are certificate pinned (i.e., Microsoft Office 365 and Google Workspace) is Netskope CASB. This will protect your applications and users against threats and data loss in scenarios where applications are certificate pinned on a mobile device, or when an agent cannot be automatically installed (third-party contractors, BYOD). For more information, take a look at https://www.netskope.com/products/casb.