Netskope Client & Managed Devices

Netskope offers multiple steering mechanisms and the Netskope Client is the most recommended option due to its operating nature and the available feature list. The Netskope Client is a lightweight application which can be installed on a managed device and it can be used to steer traffic from the device to Netskope Security Cloud. It provides real-time visibility of the managed devices accessing the cloud and web from any location. The Client uses Forward Proxy Steering mechanism where the Client creates an SSL tunnel from the end device and terminates it at the Netskope forward proxy in the Cloud.

So when the mode of steering is Netskope Client, all managed devices are expected to have the Netskope Client installed. In the context of this blog, a device is classified as managed if it has the Netskope Client installed. In this post, let us discuss the possible settings and changes which can be made in the Netskope tenant to accommodate a Lost/Stolen managed device. It must be remembered that for any change to be reflected in the Netskope Client, the client must be able to connect to the internet and the tenant to download and update to the latest configuration.

Device Status using Netskope API

Once a managed device is classified as stolen/lost, we’ll need to check if the device has connected to the Netskope cloud. The device has to connect to the internet to pull the latest configurations which are mentioned in the blog post. To keep track if a particular device has come online or if the status of the client for the device has changed, the admin could leverage Netskope’s built- in API endpoint. The API endpoint which helps us with the client information is /v1/clients. We have built a below sample query which could be used to check all the clients whose ‘last event’ timestamp is greater than a required particular epoch time 1724829057.

"https://TENANT_NAME.goskope.com/api/v1/clients?token=TOKEN&query=last_event.timestamp%20gt%201724829057"

Where TENANT_NAME is your Netskope tenant name, TOKEN must be replaced by your REST API v1 token and the timestamp must be replaced according to the scenario. (Please note that the REST API v1 tokens will be deprecated from October 15, 2024. We advise our customers to use equivalent REST API v2 endpoints for their use cases. For the above mentioned use case, the equivalent REST API v2 endpoint is being developed. Until the development is complete, the above REST API v1 endpoint should get the job done). You can get creative with this endpoint and use other fields to filter such as ‘host_info.hostname’ or ‘users.user_groups.username’. The admin can also use the above endpoint to pull all of the client information into a SIEM and set up alerts and notifications on the SIEM platform based on the client logs provided by Netskope.

Client Configuration

It is recommended to have a dedicated user group which is for Lost/Stolen Devices. The specific user group must be associated with a Netskope client configuration. All the settings recommended below are for the Lost/Stolen Device client configuration.

Tunnel Settings:

1. All the checkboxes in ‘Tunnel Settings’ must be unchecked except the ‘Periodic Device Classification’ and ‘Periodic re-authentication for Private Apps’.
2. Ensure that the ‘Periodic Device Classification’ interval is set to 1 minute and ‘Periodic re-authentication for Private Apps’ is set to 3 minutes. (Although Private App traffic is recommended not to be steered)
3. Ensure that ‘Pre-logon for Private Apps’ is disabled. (Please note that the CustomerZero team does not use pre-logon for any of its use cases. In case your team has controls which depend on Netskope Private Apps and its pre-logon function, it is recommended to leave this feature enabled and configured.)

Endpoint DLP:

Ensure that the checkbox ‘Enable Endpoint DLP’ is checked so that endpoint DLP is up and running for all the hosts part of this Client configuration. Creating EPDLP policies for the user group will be discussed later in the blog post.

Install & Troubleshoot:

1. Ensure that the ‘Upgrade Client Automatically to’ is set to ‘Latest Golden Release’. Golden releases are recommended as they are much more stable than regular latest releases.
2. Ensure that ‘Show upgrade notification to end users’ option is unchecked
3. Ensure that below 3 options are disabled as well
   1. Uninstall clients automatically when users are removed from Netskope
   2. Allow users to unenroll
   3. Enable advanced debug option

Tamperproof:

1. Ensure that the ‘Allow disabling of Clients’ and ‘Allow disabling of Private Apps Access’ are unchecked. (These will be automatically unchecked when ‘Fail Close’ is enabled)
2. Ensure that the below mentioned options are checked/enabled
   1. Hide Client Icon on System Tray
   2. Password protect Client uninstallation
      1. AlphaNumeric password
      2. Should include special characters (* & % $ # !)
      3. Should be of at least 15 characters in length
   3. Protect Client configuration and resources

Steering Configuration

As mentioned earlier, it is recommended to have a dedicated user group for stolen devices and the user group must be associated with a particular steering configuration which is used for such use cases. Let’s discuss the various settings to be enabled and disabled for the particular steering configuration.

1. Make sure you have set steering for ‘All Traffic’ and also the ‘Steer DNS traffic’ is enabled.
2. Make sure to check that ‘Steer private apps’ is disabled so that the stolen device is unable to connect to private apps. (Note: This feature can vary based on your Organization’s requirement, if there are resources which are behind Netskope Private Access which are useful in such scenarios, then the steering should be allowed)

3. In the Exceptions tab, make sure that all the unnecessary exceptions are removed for this steering configuration. Only allow the exceptions which are crucial for the functioning of other sensors on the host like EDR, MDM, etc. Later in the post, we would advise to block all outgoing traffic from the host, so if ERD or MDM is not bypassed, their outgoing traffic will also be blocked and that is not recommended.

Policies

Real-time Protection:

To ensure that all the cloud and web traffic from the host is blocked, the admin has to create a real-time policy which blocks all the outgoing traffic from the host. Please keep in mind this only blocks the traffic which is steered to the Netskope Security Cloud, any traffic which is bypassed is not blocked. This is why we had advised earlier in the blog to steer all traffic except a few essential tools like EDR, MDM, etc. To create a traffic which blocks all the outbound traffic,

1. Click on New Policy → Web Access
2. On the ‘Destination’ field, click on ‘Category’ and change it to ‘Any Traffic’
3. Set the ‘Action’ to block
4. Set the ‘Source’ field to the stolen/lost devices group

Endpoint Protection:

To ensure that there is no data loss from the endpoint via USB or Printers, we’ll need to have an active Endpoint protection policy which is enabled for the stolen/lost devices group and blocks all USB and Printer data transfer.

SSL Decryption:

To ensure that all outgoing and incoming data can be decrypted by the Netskope Security Cloud, the admin has to ensure that there are no SSL Decryption policies for the Stolen/Lost device group. There is also an option to forcefully create an SSL Decryption policy which forces decryption for all traffic originating from the Stolen/Lost device group. Below is an example which can be used.

Skope IT Events

The Netskope Admin could use Skope IT events to obtain further information about the Stolen/Lost Device. The Application Events, Page Events, Network Events and Alerts provide invaluable information and context about the whereabouts of the Stolen/Lost device. Using Netskope APIs, the events can also be pulled from the Tenant to a SIEM and create queries for monitoring based on specific criteria. Information such as host IP, timestamps, apps which the host tried to access and much more information can be obtained from the Skope IT page.

Coexistence with other sensors

When a device is Stolen/Lost, it is essential to leverage all of the sensors which are deployed on the sensors. When all of the sensors work in parallel, it becomes comparatively easier to handle the situation and prevent data loss from the Stolen/Lost device. That is the reason we highly encourage Netskope admins to understand the other sensors which may be installed on the host and what their capabilities and limitations are. For example, if a sensor can be used to remotely wipe the host but is hosted with the Netskope Private Access, the Netskope admin will have to allow Private access traffic to the Stolen/lost device, blocking private access traffic will render the remote wipe sensor ineffective.It is also important to understand other sensors on the host as Netskope might be interfering with the other sensor’s communication to their respective POP/Tenants. The same logic applies to the other sensors installed, they should not be configured in such a way that they interfere with the Netskope Client process on the Stolen/Lost device.