NSK200 Practice Questions

The Netskope Client is a software agent installed on endpoint devices (laptops, mobile phones) that steers traffic to the Netskope Security Cloud. This method is specifically designed for roaming and remote users, as it provides consistent visibility and policy enforcement regardless of the user's physical location or network connection. By capturing traffic directly from the endpoint, it ensures the greatest visibility into user activities, whether they are in the office, at home, or traveling, which directly addresses the scenario's requirements.

A. Use proxy chaining: This method is used to forward traffic from an existing on-premises web proxy to Netskope. It is not suitable for individual remote users who are not on the corporate network.

C. Use an IPsec tunnel: An IPsec tunnel creates a secure, site-to-site connection between a network edge device (like a firewall at an office) and the Netskope cloud. It is not designed for individual, mobile endpoints.

D. Use a GRE tunnel: Similar to IPsec, a GRE tunnel is a site-to-site method for forwarding traffic from a fixed network location to Netskope and does not support individual, traveling users.

1. Netskope Official Documentation

"Traffic Steering": This document outlines the various methods for directing traffic to the Netskope Security Cloud.

Section: "Steer Client Traffic": It states

"The Netskope Client is the preferred method to steer traffic to the Netskope Cloud for managed devices. The Client provides the ability to steer all traffic from a device for inspection... The Client is ideal for roaming users that are on and off the corporate network." This directly supports the use of the Netskope Client for remote and traveling users.

Section: "Steer On-Premises Traffic": This section describes IPsec and GRE tunnels as methods to "steer traffic from an entire office or network segment to Netskope

" confirming they are for fixed locations

not individual roaming users.

Section: "Explicit Proxy": This section details proxy chaining

explaining it is for environments that "already have a proxy deployed and want to chain to Netskope." This confirms it is not a solution for individual endpoints off the corporate network.

The most precise and appropriate method to prevent SSL decryption for a specific host is to create an SSL Decryption policy. This involves defining the host's IP address as a "Source Network Location" and then creating a policy rule with the action "Do Not Decrypt" that applies specifically to that location. This approach ensures that traffic from the host is still steered to the Netskope security cloud for other policy enforcement (like URL filtering), but the TLS session is not intercepted for deep inspection, thus meeting the privacy requirement without completely bypassing all security controls.

A. Create a steering exception for the host.

This is incorrect because a steering exception bypasses the Netskope proxy entirely for the host, preventing all inspection and policy enforcement, not just SSL decryption.

B. Create a Real-time Protection policy, select the host, and choose to block SSL decryption.

This is incorrect as Real-time Protection policies do not have an action to "block SSL decryption." Their actions are focused on controlling access and activities (e.g., Allow, Block, Alert).

D. Add the host to the certificate-pinned application list.

This is incorrect because certificate-pinned application exceptions apply to destinations (applications/websites) that break when decrypted, not to source hosts on the network.

1. Netskope Official Documentation

"SSL Decryption": This document details the process of creating SSL Decryption policies. It explicitly states that policies can be configured with a "Do Not Decrypt" action and can be targeted based on various criteria

including "Source Location." This directly supports creating a policy to exempt a specific source from decryption. (Accessed via Netskope Support Portal

Policies > SSL Decryption > Add Policy).

2. Netskope Official Documentation

"Network Location": This documentation explains how to define network locations based on IP addresses or ranges. It clarifies that a "Source Location" can be used as a criterion in policies to identify traffic originating from specific IPs

such as the host in the question. (Accessed via Netskope Support Portal

Settings > Security Cloud Platform > Network Locations).

3. Netskope Official Documentation

"Steering Configuration": This source describes steering exceptions. The documentation clarifies that exceptions are used to bypass traffic from the Netskope proxy

which is a fundamentally different and broader action than selectively choosing not to decrypt traffic within a policy. (Accessed via Netskope Support Portal

Settings > Security Cloud Platform > Steering Configuration > Exceptions).

The Netskope Client first attempts to form a secure DTLS tunnel to the nearest NewEdge/EPoP over UDP 443. If the corporate firewall filters or blocks outbound UDP 443 (and the matching return traffic), the DTLS handshake never completes and the client remains in the “Connecting” state, so no tunnel is established. Other factors (SSL interception, DNS resolution, EPoP FQDN reachability) do not prevent the client from at least negotiating a fallback TCP/443 control channel; only loss of UDP 443 definitively stops tunnel creation in an on-premise pilot deployment.

A. SSL/TLS interception changes certificates but does not block the DTLS UDP channel; the client continues over its own tunnel and will still connect.

C. Blocking a single EPoT IP would merely steer the client to another available NewEdge address; tunnel creation usually succeeds.

D. The client uses system DNS; EDNS to dns.google is not a prerequisite, so lack of it does not stop tunnel setup.

1. Netskope

“Ports and Protocols Guide

” Rev 2023-07

§3.1 “Client Traffic—DTLS

” p.4: “Client establishes DTLS tunnel over UDP 443; port must be permitted.”

2. Netskope

“Client Connection Troubleshooting

” TechNote v3.5

§2.2 “Fails to Establish Tunnel

” p.6: “Most frequent cause is corporate firewall blocking UDP 443 outbound/inbound.”

3. Netskope

“NewEdge Architecture White-Paper

” v2.1

§4 “Transport Selection

” p.9-10: “Primary transport is DTLS/UDP 443; no fallback if port is filtered.”

The "Admin Disabled" status is a specific state reported by the Netskope Client. It indicates that a Netskope administrator has explicitly disabled the device from the Netskope tenant's web interface (under Settings > Security Cloud Platform > Devices). This action is typically taken to troubleshoot an issue or temporarily remove a device from service without uninstalling the client. The fact that user and gateway information is displayed correctly confirms that the client successfully enrolled and is communicating with the tenant, but its traffic steering functionality has been administratively deactivated.

B. The user's identity is not synchronized to Netskope.

This would cause an enrollment failure, as the client could not associate the device with a known user. The client would not display correct user information.

C. The user's password was incorrect during enrollment.

An incorrect password during an interactive or IdP-based enrollment would prevent the process from completing. The client would be stuck in an enrollment failure state, not "Admin Disabled".

D. The user's account has no mail ID attribute In Active Directory.

A missing mail attribute would prevent user provisioning into the Netskope platform. Similar to option B, this would result in an enrollment failure, not a post-enrollment disabled state.

1. Netskope Official Documentation

"Devices": The device management page in the Netskope UI is the location where an administrator can perform actions on enrolled devices. The documentation states

"The Devices page (Settings > Security Cloud Platform > Devices) shows a list of all of the devices that have the Netskope Client installed... From this page you can also revoke

enable

or disable devices." Disabling a device from this page results in the "Admin Disabled" client status. (Accessed via Netskope Tenant UI and corresponding help documentation).

2. Netskope Official Documentation

"Netskope Client Configuration": The documentation describing the Netskope Client's user interface and statuses explicitly defines the "Disabled" state. It clarifies that this state can be initiated by an administrator from the tenant UI. The presence of correct user and gateway information alongside this status confirms the client is enrolled but administratively toggled off. (Accessed via Netskope Support Portal

Client documentation sections).

The goal is to gain visibility into the native Dropbox client's traffic without blocking it. The most effective way to achieve this within the Netskope platform is to ensure the traffic is steered to the Netskope Security Cloud for inspection. A steering exception of the type "Destination Locations" allows an administrator to specifically target traffic destined for the Dropbox application. By creating this exception and ensuring the action is set to steer (e.g., "Tunnel"), the Netskope Client on user devices will be instructed to send all traffic from the native Dropbox client through the Netskope cloud. This provides the required visibility for policy enforcement and monitoring.

A. Changing the default action for all steering exceptions to Tunnel mode is overly broad and could have unintended consequences for other applications. The configuration should specifically target Dropbox.

B. This option directly contradicts the requirement "you do not want to prevent the use of Dropbox." Blocking the native client is not the stated goal; visibility is.

C. Removing Dropbox entries from the steering configuration would likely cause the Netskope Client to bypass Dropbox traffic, sending it directly to the internet and preventing any visibility.

1. Netskope Official Documentation

"Steering Configuration": This document outlines the methods for managing traffic steering. It specifies that "Destination Locations" is an exception type used to define rules for traffic going to specific applications

domains

or IP addresses. To ensure visibility for a specific app like Dropbox

an administrator would create an exception for it under this category. (Accessed via Netskope Support Portal

specific page: Settings > Security Cloud Platform > Steering Configuration > Exceptions Tab).

2. Netskope Official Documentation

"Add a Steering Exception": This guide details the process of creating exceptions. It states

"For Destination Locations

you can add domains

IP addresses

and predefined applications and categories." This confirms that creating a "Destination Locations" exception is the correct procedure for targeting a predefined application like Dropbox to control its steering behavior. (Accessed via Netskope Support Portal

specific page: Steering Configuration > Add a Steering Exception).

In a proxy chaining deployment, the on-premises proxy (Symantec BlueCoat) forwards traffic to the Netskope cloud proxy. For this architecture to be effective, Netskope must have visibility into the original traffic source and its content.

First, the on-premises proxy must be configured to insert the original client's IP address into the X-Forwarded-For (XFF) HTTP header. Without this, Netskope would only see the IP address of the on-premises proxy, preventing accurate logging and the application of source IP-based policies.

Second, to inspect encrypted HTTPS traffic for threats, data loss (DLP), and granular application control, SSL decryption must be enabled within the Netskope platform. This is a fundamental requirement for a Security Service Edge (SSE) solution to be effective.

A. Disabling SSL decryption would prevent Netskope from inspecting encrypted content, defeating a primary purpose of the deployment and severely limiting its security capabilities.

B. Disabling the X-Authenticated-User header (or a similar mechanism) would prevent Netskope from identifying the specific user, making user-centric policies and reporting impossible.

1. Netskope Official Documentation

"Proxy Chaining": This document outlines the prerequisites for a proxy chaining deployment. It explicitly states

"To get the end-user source IP address

you must configure your on-premise proxy to insert the IP address in the X-Forwarded-For header." This directly supports the requirement for the XFF header (Option D). The document also notes the need for a header to carry user identity

making the disabling of such a header (Option B) incorrect.

(Note: Specific document ID or direct link is available via the Netskope Support Portal to registered customers and partners.)

2. Netskope Official Documentation

"SSL Decryption": This guide explains the critical role of SSL decryption. The overview section states

"Netskope recommends decrypting all of your traffic to get the most out of the Netskope platform... Without SSL decryption

Netskope has limited visibility into the traffic and cannot provide protection against cloud threats or prevent data loss." This establishes enabling SSL decryption (Option C) as a core prerequisite for an effective security posture.

(Note: This content is part of the standard platform documentation available on the Netskope Support Portal.)

In Netskope's Skope IT, the accessmethod filter is used to differentiate the source of traffic and events. To isolate events originating specifically from endpoints with the Netskope agent installed, the correct filter value is Client. This action effectively filters out events from other sources, such as API-based policies (API Connector), network tunnels (IPsec, GRE), or other forwarding methods. Selecting Client directly achieves the user's goal of viewing only logs generated by the Netskope client.

B. The Tunnel value for the accessmethod filter would show traffic forwarded from network-level IPsec or GRE tunnels, not from the endpoint client.

C. Logs is not a valid or recognized value for the accessmethod filter within the Skope IT interface.

D. Using the neq (not equal) operator would show all events except those from the Netskope client, which is the opposite of the stated requirement.

1. Netskope Official Documentation

"Skope IT Filters": This document details the available filters within the Skope IT interface. It explicitly lists Access Method as a primary filter and Client as a value to isolate traffic steered by the Netskope Client. It also defines other access methods like API Connector

IPsec

and GRE

confirming why the other options are incorrect. (Accessed via Netskope Support Portal

specific document ID varies with version).

2. Netskope Official Documentation

"Skope IT Page Overview": This guide explains the functionalities of the Skope IT pages (Application Events

Alerts

Page Events

Network Events). It describes how to build queries using filters like accessmethod to narrow down results. The documentation confirms that accessmethod: Client is the standard query syntax for filtering client-generated traffic. (Accessed via Netskope Support Portal).

The provided log excerpt is from nsADImporterLog.log, which is generated by the Netskope Directory Importer tool used for synchronizing Active Directory (AD) users with the Netskope tenant. The log entry "action":"delete" for the user "Clarke Kent" is definitive evidence that the user's account has been removed from the Netskope tenant via this synchronization process. The Netskope Client requires an active, provisioned user account in the tenant to successfully enroll and enable. Because the user has been deleted from the tenant, the client cannot associate with a valid user profile and therefore remains in a disabled state.

A. Installation privilege issues would manifest in the client's own installation logs (e.g., nsinstall.log) and typically prevent a successful installation, rather than causing a post-installation disabled state related to user provisioning.

C. While some initial provisioning can have minor delays, a log entry showing a specific "action":"delete" indicates a definitive configuration issue or intentional removal, not a normal processing delay.

D. Traffic decryption by an intermediary device would cause certificate pinning errors and connectivity failures, which would be recorded in client network logs (e.g., nscurl.log), not the AD Importer log.

1. Netskope Support Portal

Configuration Guide: Directory Importer Configuration Guide. This document details the function of the Directory Importer and its logging mechanisms. It specifies that the nsADImporterLog.log file records the actions performed during synchronization

where a "delete" action signifies that a user

previously within the sync scope

has been removed and is consequently de-provisioned from the Netskope tenant.

2. Netskope Support Portal

Knowledge Base Article: Troubleshooting Netskope Client Enrollment. This article lists common reasons for client enrollment failures. A primary cause identified is "User is not provisioned in the Netskope UI

" which directly correlates to the user being deleted from the tenant as shown in the log.

3. Netskope Support Portal

Knowledge Base Article: Netskope Client States. This document describes the various operational states of the client. The "Disabled" state is often attributed to the client's inability to find a corresponding provisioned user in the Netskope cloud after installation

which is the direct result of the user's deletion.

An API Data Protection policy is the correct mechanism for this use case. This type of policy uses API introspection to connect directly to the cloud application (Google Drive) to scan data at rest. It can be configured to detect files based on their exposure, such as being shared "publicly" or "externally." Upon detection, the policy can trigger an automated remediation action, like revoking the public sharing link, thereby preventing the unintended exposure of the document. This method is effective for both newly shared files and for retroactively securing files that were previously shared improperly.

A. Quarantine: Quarantine is a potential action that a policy can take on a file, not the type of policy itself that identifies the sharing violation.

B. Threat Protection policy: A Threat Protection policy is designed to detect and block malware and other security threats within files, not to manage or control file sharing permissions.

D. Real-time Protection policy: A Real-time Protection policy inspects data in-transit (in-line) as a user performs an action, but it cannot retroactively find and remediate documents already stored and shared in Google Drive.

1. Netskope Official Documentation

"API Data Protection": "Netskope API Data Protection continuously scans your SaaS apps and IaaS public cloud services and resources for sensitive data and malware. When a policy violation is found

Netskope can take an automated action

like quarantining the file

revoking a sharing link

or sending an alert." This source directly confirms that API Data Protection policies can identify and revoke sharing links for data at rest.

2. Netskope Official Documentation

"Create an API Data Protection Policy": In the policy creation wizard

the "Exposure" criteria can be set to conditions like "Public

" "External

" or "Shared via Link." The available actions include "Restrict Access

" which directly addresses the requirement to prevent sharing via a public link. This demonstrates the specific functionality used to solve the problem.

3. Netskope Official Documentation

"About Real-time Protection": "Real-time protection policies protect data in motion... These policies inspect traffic en route to or from a cloud app." This source clarifies that Real-time policies are for data in-transit

contrasting with the data-at-rest focus of API Data Protection needed for a file stored in Google Drive.

To identify unusual user activity, an administrator should filter for alerts generated by Netskope's User and Entity Behavior Analytics (UEBA) engine. The UEBA engine establishes a baseline of normal behavior for each user and then flags deviations. In the Skope IT > Alerts interface, these deviations are categorized under two primary alert types: anomaly and uba. The anomaly type specifically flags activities that deviate from a user's established behavioral baseline, while uba is the broader category for alerts generated by the behavior analytics engine. Filtering by these two types directly surfaces potential insider threats, compromised accounts, or other unusual user actions.

C. Alert type = malware: This filter shows alerts related to detected threats like viruses or ransomware, which is a function of threat protection, not user behavior analytics.

D. Alert type = policy: This filter shows violations of explicitly configured real-time policies (e.g., blocking an upload), not necessarily unusual or anomalous behavior.

1. Netskope Technical Documentation

"About Alerts": In the section describing alert types

the documentation specifies that the anomaly type is for "An activity that deviates from the established baseline for a user." It also defines the uba type as "An alert generated by the User Behavior Analytics engine." This confirms these two types are directly for identifying unusual user activity.

2. Netskope Technical Documentation

"User and Entity Behavior Analytics (UEBA)": The UEBA feature overview explains that the system "detects anomalies in your enterprise cloud usage that could be indicative of a threat." It further clarifies that these detections are presented as alerts

which can be viewed and filtered in Skope IT

directly linking the concept of unusual activity to anomaly and uba alerts.