Netskope NSK101 Netskope Certified Cloud Security Administrator (NCCSA) Exam Practice Test

To obtain and export a list of all hosts including domains and IP addresses that a user accessed through Netskope Private Access for the past seven days, you can follow these steps:

Access the Netskope Web UI: Log in to your Netskope admin console.

Navigate to SkopeIT:

Go to the SkopeIT section in the Netskope admin console.

Private Apps page in SkopeIT:

In the SkopeIT section, navigate to the "Private Apps" page.

Here, you can find detailed information about the private applications accessed by users, including the domains and IP addresses.

Use the filter options to specify the user and the time range (past seven days).

Export the data as needed for your investigation.

Network Events page in SkopeIT:

In the SkopeIT section, navigate to the "Network Events" page.

This page provides a comprehensive list of network events, including details about the hosts accessed through Netskope Private Access.

Again, use the filter options to specify the user and the time range.

Export the data for reporting purposes.

These two locations within the SkopeIT section of the Netskope Web UI will provide you with the necessary data to meet your security team's requirements.

References:

Netskope Knowledge Portal: Using SkopeIT for Network and Private Apps Analysis​​​​​​​​.

To provide an additional pop-up warning to users before allowing them to proceed to web applications categorized as "low" or "poor" by Netskope's Cloud Confidence Index (CCI), you can:

Enable real-time user coaching based on CCL: This feature allows administrators to create policies that provide real-time guidance and warnings to users when they attempt to access web applications with low or poor confidence levels. This helps in educating users about the potential risks and ensures that they proceed with caution.

References:

Netskope documentation on configuring real-time user coaching and leveraging the Cloud Confidence Index for policy enforcement.

Best practices for using CCL to guide user behavior and enhance security awareness.

=================

To set up a Netskope API connection to Box, two actions that must be completed are: authorize the Netskope application in Box and configure Box in SaaS API Data protection. Authorizing the Netskope application in Box allows Netskope to access the Box API and perform out-of-band inspection and enforcement of policies on the data that is already stored in Box. Configuring Box in SaaS API Data protection allows you to specify the Box instance details, such as domain name, admin email, etc., and enable features such as retroactive scan, event stream, etc. References: Authorize Netskope Introspection App on Box Enterprise - Netskope Knowledge PortalConfigure Box Instance in Netskope UI - Netskope Knowledge Portal

The CCI scoring is a way to measure the security posture of cloud applications based on a set of criteria and weights. The default objective score is calculated by Netskope using industry best practices and standards. However, customers can change the CCI scoring to suit their own business needs and risk appetite. For example, a customer may want to place a higher business risk weight on vendors that claim ownership of their data, as this may affect their data sovereignty and privacy rights. Changing the CCI scoring for this reason would be valid, as it reflects the customer’s own security requirements and preferences. Changing the CCI scoring for other reasons, such as discovering a new SaaS application, punishing an application vendor, or using an application under research, would not be valid, as they do not align with the purpose and methodology of the CCI scoring. References: Netskope Security Cloud Operation & Administration (NSCO&A) - Classroom Course, Module 7: Cloud Confidence Index (CCI), Lesson 1: CCI Overview and Lesson 2: CCI Scoring.

In this scenario, there are two methods to obtain a detailed list of all events from the last 24 hours for a specific user. One method is to export the data from Skope IT Application Events, which is a feature in the Netskope platform that allows you to view and analyze all the activities performed by users on cloud applications. You can use filters to narrow down your search by user name, time range, application, activity, and other criteria. You can then export the data to a CSV or JSON file for further analysis or reporting. Another method is to use the Netskope REST API, which is a programmatic interface that allows you to access and manipulate data from the Netskope platform using HTTP requests. You can use the API to query for events by user name, time range, application, activity, and other parameters. You can then retrieve the data in JSON format for further analysis or integration with other tools. Using the Netskope reporting engine or exporting the data from Skope IT Alerts are not methods to obtain a detailed list of all events from the last 24 hours for a specific user, as they are more suited for generating summary reports or alerts based on predefined criteria or thresholds, rather than granular event data. References: [Netskope Skope IT Application Events], [Netskope REST API].

In the exhibit, a user is uploading a file containing PCI-DSS data to the corporate Google Drive instance. Despite the policy that blocks DLP (Data Loss Prevention) uploads being active, the upload is not blocked. This indicates that the policy is not applied in the correct order.

Netskope applies policies in a top-down manner. If there are multiple policies that could apply to an action, the order in which the policies are evaluated is crucial. In this case, another policy might be allowing the upload before the DLP policy can block it. Ensuring that the DLP policy is higher in the order can resolve this issue.

References:

Netskope policy configuration and enforcement documentation.

Details on how Netskope processes and applies policies based on their order in the policy list.

To verify the status of the Publishers in the European data center, the following methods can be used:

Use the Status field on the Publishers page:

Navigate to the Publishers page in the Netskope UI.

Check the Status field to see if any Publishers are disconnected or experiencing issues.

Use the Netskope Private Access Troubleshooter:

Access the Netskope Private Access Troubleshooter tool.

This tool provides detailed diagnostic information and helps identify connectivity issues with Publishers.

These methods provide direct insights into the health and connectivity status of the Publishers, helping to quickly identify and resolve any issues affecting user access.

References:

Netskope Knowledge Portal: Private Access

Netskope Private Access Troubleshooter

 Protecting Data at Rest in SharePoint:

Protecting intellectual property stored in Microsoft 365 SharePoint requires a solution that can monitor and control data access and usage.

Netskope's API-enabled Protection integrates directly with Microsoft 365 to provide comprehensive security for data at rest.

 API-enabled Protection:

Netskope's API-enabled Protection allows direct integration with SharePoint, enabling continuous monitoring and enforcement of security policies.

It ensures that data such as source code or product designs are protected from unauthorized access and potential data breaches.

 Configuration:

Configure API-enabled Protection by navigating to the Netskope admin console.

Set up the necessary API integrations with Microsoft 365 SharePoint.

Define security policies to monitor and control access to sensitive data stored in SharePoint.

 References:

For more details on setting up and configuring API-enabled Protection for SharePoint, refer to the Netskope documentation on API-enabled protection solutions​​​​.

To restrict cloud users from uploading data to risky cloud storage services as defined by the Cloud Confidence Index (CCI) in the Netskope platform, you would use the following policy elements:

Category: This policy element allows you to define and restrict actions based on the category of the cloud application. For example, you can categorize cloud storage services and create policies that restrict uploads to any application that falls under this category.

Cloud Confidence Level: This policy element leverages the Cloud Confidence Index (CCI), which rates the risk level of cloud applications. By using the Cloud Confidence Level, you can create policies that restrict uploads to applications with a low confidence level, thereby preventing data uploads to risky cloud storage services.

References:

Using the Netskope Knowledge Portal documentation, specifically under policy configuration and enforcement, which details how to use categories and Cloud Confidence Level in policy creation.

Postman collection and API documentation that describes the usage of these elements in the Netskope API.

=================

 To provide a quick view under the Skope IT Applications page showing only risky shadow IT cloud applications being used, you can use two filter combinations: Sanctioned = No and CCL = Medium, Low, Poor. The Sanctioned filter allows you to select whether you want to see only sanctioned or unsanctioned apps in your organization. Sanctioned apps are those that are approved and managed by your IT department, while unsanctioned apps are those that are used without authorization or oversight by your employees. Shadow IT refers to the use of unsanctioned apps that may pose security or compliance risks for your organization. The CCL filter allows you to select the Cloud Confidence Level (CCL) ratings of the apps you want to see. The CCL rating is a measure of how enterprise-ready a cloud app is based on various criteria such as security, auditability, business continuity, etc. The CCL rating ranges from Excellent to Poor, with Excellent being the most secure and compliant and Poor being the least. Risky cloud apps are those that have a low CCL rating, such as Medium, Low, or Poor. By applying these two filters, you can narrow down the list of apps to only those that are unsanctioned and have a low CCL rating, which indicates that they are risky shadow IT cloud applications being used in your organization. References: SkopeIT ApplicationsNetskope Cloud Confidence Index

If a customer wants to detect misconfigurations in their AWS cloud instances, the Netskope feature that I would recommend to them is Netskope Cloud Security Posture Management (CSPM). Netskope CSPM is a service that provides continuous assessment and remediation of public cloud deployments for risks, threats, and compliance issues. Netskope CSPM leverages the APIs available from AWS and other cloud service providers to scan the cloud infrastructure for misconfigurations, such as insecure permissions, open ports, unencrypted data, etc. Netskope CSPM also provides security posture policies, profiles, and rules that can be customized to match the customer’s security standards and best practices. Netskope CSPM can also alert, report, or remediate the misconfigurations automatically or manually. References: Netskope CSPMCloud Security Posture Management

 Reverse Proxy Overview:

A reverse proxy allows users to access sanctioned cloud applications securely from public or untrusted networks.

It ensures that the traffic is inspected and policy controls are enforced before reaching the cloud application.

 Scenario Justification:

Users connecting from public computers, such as those in hotel business centers, cannot have a steering client installed, and IPsec/GRE tunnels are not feasible.

Proxy chaining requires control over the client's browser settings, which is not possible in this scenario.

A reverse proxy can handle the traffic without requiring configuration changes on the public computer.

 Implementation:

Configure the reverse proxy to handle traffic for sanctioned applications.

Ensure the reverse proxy settings are enforced via your organization's security policies.

 References:

Detailed configurations and use cases can be found in the Netskope documentation on reverse proxy solutions​​​​.

Shadow IT is the term for the unauthorized use of IT resources and functions by employees within an organization. It can include cloud services, software, and hardware that are not approved or managed by the IT department. Two use cases that would be considered examples of shadow IT within an organization are: an unsanctioned Microsoft 365 OneDrive account being used by a corporate user to upload sensitive data and an unsanctioned Google Drive account used by a corporate user to upload non-sensitive data. In both cases, the corporate user is using a personal cloud storage service that is not sanctioned by the organization to store work-related data. This can introduce security risks, such as data leakage, data loss, compliance violations, malware infections, etc. The IT department may not have visibility or control over these cloud services or the data stored in them. References: What is shadow IT? | CloudflareWhat is Shadow IT? | IBM

Two statements that are correct about DLP Incidents in the Netskope platform are: An incident can have one or more DLP violations and an incident can be associated to one or more DLP rules. A DLP violation occurs when a file or object matches a DLP rule used in a DLP profile. A DLP rule defines the criteria for detecting sensitive data, such as keywords, regular expressions, fingerprints, machine learning classifiers, etc. A DLP profile is a collection of DLP rules that can be applied to a policy. An incident is a record of a file or object that triggered a DLP policy violation. An incident can have multiple violations if the file or object matches multiple DLP rules from different profiles. An incident can also be associated to multiple DLP rules if the file or object matches more than one rule from the same profile. References: About DLPDLP Profiles

In this scenario, there are three probable causes for the issue of users not being able to access external websites from their browsers after attempting to steer traffic to Netskope using GRE tunnels. One cause is that the configured GRE peer in the Netskope platform is incorrect, which means that the Netskope POP that is supposed to receive the GRE traffic from the customer’s network is not matching the IP address of the customer’s router that is sending the GRE traffic. This will result in a failure to establish a GRE tunnel between the customer and Netskope. Another cause is that the corporate firewall might be blocking GRE traffic, which means that the firewall rules are not allowing the GRE protocol (IP protocol number 47) or the UDP port 4789 (for VXLAN encapsulation) to pass through. This will result in a failure to send or receive GRE packets between the customer and Netskope. A third cause is that the route map was applied to the wrong router interface, which means that the configuration that specifies which traffic should be steered to Netskope using GRE tunnels was not applied to the correct interface on the customer’s router. This will result in a failure to steer the desired traffic to Netskope. The pre-shared key for the GRE tunnel is incorrect is not a probable cause for this issue, as GRE tunnels do not use pre-shared keys for authentication or encryption. Netskope does support GRE tunnels, so this is not a cause for this issue either. References: [Netskope Secure Forwarder], Netskope Security Cloud Operation & Administration (NSCO&A) - Classroom Course, Module 3: Steering Configuration, Lesson 3: Secure Forwarder.

Netskope’s DLP solution is a powerful tool that can help customers protect their sensitive data from unauthorized access, exposure, or loss. One use case for Netskope’s DLP solution is to stop unintentional data movement, such as accidental uploads, downloads, or sharing of confidential files or information to or from cloud applications. Another use case for Netskope’s DLP solution is to ensure regulatory compliance, such as GDPR, HIPAA, PCI-DSS, or other industry-specific standards that require data protection and privacy measures. Netskope’s DLP solution can help customers comply with these regulations by detecting and preventing data breaches, enforcing encryption policies, applying data retention rules, and generating audit reports. Detecting malware in files before they are uploaded to a cloud application or detecting sensitive data in password protected files are not use cases for Netskope’s DLP solution, as they are more related to threat protection or file inspection capabilities. References: Netskope Security Cloud Operation & Administration (NSCO&A) - Classroom Course, Module 6: Data Loss Prevention, Lesson 1: DLP Overview.

According to Netskope, two preferred methods to report a URL miscategorization are: use and use the URL Lookup page in the dashboard. The first method allows you to visit in your browser and enter any URL that you want to check or report for miscategorization. You will see the current category assigned by Netskope for that URL and you can submit a request to change it if you think it is incorrect. The second method allows you to use the URL Lookup page in the dashboard of your Netskope platform tenant and enter any URL that you want to check or report for miscategorization. You will see the current category assigned by Netskope for that URL and you can submit a request to change it if you think it is incorrect. Emailing support@netskope.com or tagging Netskope on Twitter are not preferred methods to report a URL miscategorization, as they are not designed for this purpose and may not be as efficient or effective as using the dedicated tools provided by Netskope. References: [Netskope URL Lookup],  Netskope Security Cloud Operation & Administration (NSCO&A) - Classroom Course, Module 8: Skope IT, Lesson 2: Page Events.

In this scenario, you have deployed the Netskope client in Web mode, which is a feature that allows you to steer your users’ web traffic to Netskope for inspection and policy enforcement. However, some users report that their messenger application is no longer working, even though you have a specific real-time policy that allows this application. Upon further investigation, you discover that the messenger application is using proprietary encryption, which means that Netskope cannot decrypt or inspect the traffic from this application. To resolve this issue, you need to permit access to all the users and maintain some visibility. The configuration change that would accomplish this task is to add a policy in the SSL decryption section to bypass the messenger domain(s). This will allow Netskope to skip the decryption process for the traffic from the messenger application and pass it through without any modification. However, Netskope will still be able to log some basic information about the traffic, such as source, destination, bytes, etc., for visibility purposes. Changing the real-time policy to block the messenger application, creating a new custom cloud application using the custom connector, or editing the steering configuration and adding a steering exception for the messenger application are not configuration changes that would accomplish this task, as they would either prevent access to the application, require additional steps or resources, or reduce visibility. References: [Netskope Client], Netskope Security Cloud Operation & Administration (NSCO&A) - Classroom Course, Module 4: Decryption Policy.

CASB inline interception use cases are scenarios where you need to apply real-time policies and actions on the traffic between users and cloud applications. For example, you may want to block file uploads to a personal Box account to prevent data leakage or exfiltration. You can use Netskope’s inline proxy mode to intercept and inspect the traffic between users and Box, and apply granular policies based on user identity, device type, app instance, file metadata, etc. You can also use Netskope’s inline proxy mode to provide user alerts when sensitive information is posted in Slack. For example, you may want to warn users when they share credit card numbers or social security numbers in Slack channels or messages. You can use Netskope’s steering client to redirect the traffic between users and Slack to Netskope’s inline proxy for inspection and enforcement. You can also use Netskope’s DLP engine to detect sensitive data patterns and apply actions such as alerting or blocking. References: Netskope Inline Proxy ModeNetskope Steering Client [Netskope DLP Engine]

 If you are deploying TLS support for real-time Web and SaaS transactions, then you need to use secure implementation methods that ensure the highest level of encryption and security for your traffic. Two secure implementation methods in this scenario are: support TLS 1.2 only when 1.3 is not supported by the server and require TLS 1.3 for every server that accepts it. TLS stands for Transport Layer Security, which is a protocol that provides secure communication over the internet by encrypting and authenticating data exchanged between two parties. TLS 1.3 is the latest version of TLS, which offers several improvements over TLS 1.2, such as faster handshake, stronger encryption algorithms, better forward secrecy, and reduced attack surface. Therefore, it is recommended to use TLS 1.3 whenever possible for real-time Web and SaaS transactions, as it provides better security and performance than TLS 1.2. However, some servers may not support TLS 1.3 yet, so in those cases, it is acceptable to use TLS 1.2 as a fallback option, as it is still considered secure and widely adopted. Bypassing TLS 1.3 because it is not widely adopted or downgrading to TLS 1.2 whenever possible are not secure implementation methods in this scenario, as they would compromise the security and performance of your traffic by using an older or weaker version of TLS than necessary. References: [TLS], [TLS 1.3].

Legacy solutions, such as on-premises firewalls and proxies, fail to secure the data and data access compared to Netskope Secure Web Gateway because they are designed for a perimeter-based security model, where the applications and the users are both within the corporate network. However, with the rise of cloud computing and remote work, this model is no longer valid. The applications where the data resides are no longer in one central location, but distributed across multiple cloud services and regions. The users accessing this data are not in one central place, but working from anywhere, on any device. Legacy solutions cannot provide adequate visibility and control over this dynamic and complex environment, resulting in security gaps and performance issues. Netskope Secure Web Gateway, on the other hand, leverages a cloud-native architecture that provides high-performance and scalable inspection of traffic from any location and device, as well as granular policies and advanced threat and data protection for web and cloud applications. References: Netskope Architecture OverviewNetskope Next Gen SWG

API-enabled Protection traffic is sent to the Netskope Data Plane. The Netskope Data Plane is responsible for processing and inspecting data in real-time, applying security policies, and ensuring that the traffic conforms to organizational policies.

Netskope Data Plane: This component handles the inline inspection and enforcement of security policies, including API-enabled protection. It ensures that all traffic is securely processed and monitored according to the defined policies.

References:

Netskope architecture documentation describing the roles of different components.

Detailed guides on how API-enabled protection integrates with the Netskope Data Plane for real-time traffic inspection.

=================

Identify the Blocked Policy: According to the exhibit, the website is blocked by the "Global Block Policy."

Create a Custom URL List: To create an exception for the domain, you need to first create a custom URL list that includes the domain in question.

Navigate to the URL List section in the Netskope UI.

Create a new URL list and add the domain that needs to be allowed.

Option B: Create a custom category with the custom URL list as an included URL list and add it to an allow policy above the Global Block policy.

Go to the Policy section in the Netskope UI.

Create a new policy, ensuring it is an "Allow" policy.

Add the custom category to this allow policy.

Position this allow policy above the Global Block policy to ensure it takes precedence.

This ensures that the URLs in the custom list are allowed before the Global Block policy is evaluated.

Option C: Add the custom URL list as an excluded URL list to the category in the Global Block policy.

Edit the existing Global Block policy.

Add the custom URL list to the excluded URL list section of this policy.

This will exclude the URLs in the custom list from being blocked by the Global Block policy.

References:

Refer to the Netskope Knowledge Portal for managing custom URL lists and policy configurations​​​​​​.

SD-WAN technology is used in the following scenarios:

To optimize utilization and performance across multiple Internet connections:

SD-WAN allows organizations to aggregate multiple Internet connections and optimize traffic flow based on application requirements and network conditions. This improves overall network performance and ensures efficient use of available bandwidth.

To replace dedicated MPLS connections with multiple broadband WAN and mobile options:

SD-WAN provides the flexibility to use a mix of broadband, LTE, and other connectivity options to replace traditional MPLS circuits. This can significantly reduce costs and improve agility in network deployment and management.

References:

Netskope Knowledge Portal: SD-WAN Integration

Netskope Knowledge Portal: Benefits of SD-WAN

SaaS API-enabled Protection is a primary function in the Netskope platform that allows customers to connect their sanctioned SaaS applications to Netskope using out-of-band API connections. This enables customers to find sensitive content, enforce near real-time policy controls, and quarantine malware in their SaaS applications without affecting user experience or performance. If you want to use an out-of-band API connection into your sanctioned Microsoft 365 OneDrive for Business application to achieve these goals, you should use SaaS API-enabled Protection as the primary function in the Netskope platform. DLP forensics, Risk Insights, and IaaS API-enabled Protection are not primary functions in the Netskope platform that can be used to connect your application to Netskope. References: [Netskope SaaS API-enabled Protection].

When a user is unable to access a newly added private application despite having the correct Real-time Protection policy in place, the NPA (Netskope Private Access) Troubleshooter tool can be used to diagnose and resolve the issue.

Accessing NPA Troubleshooter:

Navigate to the Netskope Web UI.

Go to the Troubleshooting section and select NPA Troubleshooter.

Verifying User Policy:

Check the specific policy applied to the user to ensure that it allows access to the application.

Ensure that there are no conflicting policies that might be blocking access.

Checking Steering Configuration:

Verify that the steering configuration is correctly set up to route the user's traffic to the Netskope platform.

Ensure that the correct gateways are being used and that the traffic is not being bypassed.

Client Status:

Confirm that the Netskope client is installed and running on the user's device.

Check the client logs for any errors or issues that might be preventing access.

Additional Details:

Review any other relevant details such as the user's network configuration, device status, and any recent changes that might have impacted connectivity.

By systematically using the NPA Troubleshooter tool to verify these aspects, you can identify and resolve the underlying issue preventing access to the private application.

References:

REST API v2 Overview - Netskope Knowledge Portal

Using the REST API v2 dataexport Iterator Endpoints - Netskope Knowledge Portal

Using the REST API v2 UCI Impact Endpoints - Netskope Knowledge Portal

netskopesdk · PyPI

Netskope Rest APIv2(OAS 3.1) - Postman Collection

The NPA (Netskope Private Access) Troubleshooter Tool provides the following status indicators when run:

Steering configuration: This indicates whether the traffic is being correctly steered through the Netskope infrastructure according to the defined policies.

Publisher connectivity: This status shows whether the Netskope Publisher is correctly connected and able to communicate with the Netskope cloud. It ensures that the Publisher, which acts as a gateway, is functioning correctly.

Reachability of the private app: This status verifies if the private application is reachable from the Netskope infrastructure, ensuring that users can access the necessary internal resources.

These indicators help administrators troubleshoot and ensure that the NPA setup is working correctly, providing secure and reliable access to private applications.

References:

Netskope documentation on using the NPA Troubleshooter Tool and the status indicators it provides.

Best practices for troubleshooting NPA connectivity and performance issues.

=================

 AD Connector:

The AD Connector is used to integrate your Netskope tenant with Active Directory (AD) to provision and synchronize user accounts.

It ensures that user information in Netskope is always up-to-date by periodically synchronizing with AD.

To set up the AD Connector:

Navigate to Settings > Tools > Directory Importer.

Configure the AD Connector with your AD details.

Set the synchronization schedule.

This method is commonly used in enterprise environments where AD is the primary user directory.

 SCIM (System for Cross-domain Identity Management):

SCIM is an open standard for automating the exchange of user identity information between identity domains or IT systems.

Netskope supports SCIM for provisioning users from identity providers like Okta, Azure AD, and others.

To configure SCIM:

Go to Settings > Tools > SCIM.

Follow the instructions to set up SCIM with your identity provider.

SCIM is beneficial for environments using modern identity management solutions.

 References:

For detailed configuration steps and additional information, refer to the Netskope documentation on provisioning users using the AD Connector and SCIM​​​​.

Two statements that describe a website categorized as a domain generated algorithm (DGA) are: The website is used to hide a command-and-control server and the domain was created by a program. A domain generated algorithm (DGA) is a technique used by cyber attackers to generate new domain names and IP addresses for malware’s command and control servers. Executed in a manner that seems random, it makes it nearly impossible for threat hunters to detect and contain the attack. A command-and-control server is a server that communicates with malware installed on infected machines and sends commands or updates to them. A program is a piece of software that performs a specific task or function. A domain generated algorithm is implemented by a program that runs on the attacker’s machine or the malware itself, and produces a large number of domain names based on some logic, such as date, time, seed, dictionary, etc. References: Domain generation algorithmAmong cyber-attack techniques, what is a DGA?

The statement that accurately describes the difference between Source IP (Egress) and Source IP (User) address is: Source IP (Egress) is the public IP address of your Internet edge router while Source IP (User) is the address assigned to the endpoint. Source IP (Egress) is the IP address that is visible to external networks when you send traffic from your network to the Internet. It is usually the IP address of your Internet edge router or gateway that performs NAT (Network Address Translation). Source IP (User) is the IP address that is assigned to your endpoint device, such as a laptop or a smartphone, within your network. It is usually a private IP address that is not routable on the Internet. You can use these two criteria to filter traffic based on where it originates from within your network or outside your network. References: Source Address / Source Port vs Destination Address / Destination PortHow to explain Source IP Address, Destination IP Address & Service in easy way

When reviewing files affected by malware in the Netskope UI under Incidents -> Malware, you have the following options:

Identify the exposure of the file identified as malware: This allows you to see where the malware has spread within the organization, which users or systems are affected, and any potential data exposure resulting from the malware.

Determine the Detection Engine used to identify the malware: Netskope provides details on which detection engine (such as AV, sandboxing, or other heuristic engines) identified the malware. This helps in understanding the threat vector and the reliability of the detection.

Downloading the original malware file (option A) is generally not recommended for security reasons and may not be supported directly from the Netskope UI. Remediation of compromised devices (option C) would typically be handled through endpoint security solutions rather than directly from the Netskope UI.

References:

Netskope documentation on malware detection and incident response.

Best practices for handling malware incidents and using the Netskope UI for threat analysis.

=================

To collect the logs from the client machine when you have an issue with the Netskope client connecting to the tenant, two ways that you can use are: from the Netskope client UI About page and from the command line using the nsdiag command. From the Netskope client UI About page, you can click on the “Collect Logs” button to generate a zip file containing all the relevant logs and configuration files from the client machine. You can then send this zip file to Netskope support for troubleshooting. From the command line, you can use the nsdiag command with various options to collect different types of logs and diagnostic information from the client machine. For example, you can use nsdiag -l to collect all logs, nsdiag -c to collect configuration files, nsdiag -t to collect traffic statistics, etc. You can also use nsdiag -h to see all available options and usage instructions. You can then send the output files to Netskope support for troubleshooting. References: Netskope Client Configuration overviewInstall and Test the Client - Netskope Knowledge Portal

In this scenario, a user is connected to a cloud application through Netskope’s proxy, which is a deployment method that allows Netskope to intercept and inspect the traffic between the user and the cloud application in real time. In this case, Netskope can collect and display various information about the user and the cloud application at Skope IT, which is a feature in the Netskope platform that allows you to view and analyze all the activities performed by users on cloud applications. Some of the information that is available at Skope IT are: username, device location, account instance, URL category, user activity, and cloud app risk rating. Username is the name or identifier of the user who is accessing the cloud application. Device location is the geographical location of the device that the user is using to access the cloud application. Account instance is the specific instance of the cloud application that the user is accessing, such as a personal or enterprise instance. URL category is the classification of the web page that the user is visiting within the cloud application, such as Business or Social Media. User activity is the action that the user is performing on the cloud application, such as Upload or Share. Cloud app risk rating is the score that Netskope assigns to the cloud application based on its security posture and compliance with best practices. Destination IP, OS patch version, file version, and shared folder are not information that is available at Skope IT in this scenario, as they are either unrelated or irrelevant to the proxy connection or the Skope IT feature. References: [Netskope Inline CASB], [Netskope Skope IT].

The three technologies that describe the primary cloud service models as defined by the National Institute of Standards and Technology (NIST) are Platform as a Service (PaaS), Software as a Service (SaaS), and Infrastructure as a Service (IaaS). These service models are based on the type of computing capability that is provided by the cloud provider to the cloud consumer over a network. According to NIST, these service models have the following definitions:

Platform as a Service (PaaS): The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

Software as a Service (SaaS): The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Infrastructure as a Service (IaaS): The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

References: The NIST Definition of Cloud ComputingNIST Cloud Computing Program

To enable Netskope to gain visibility into your users’ cloud application activities in an inline mode, you need to use a deployment method that allows Netskope to intercept and inspect the traffic between your users and the cloud applications in real time. Two deployment methods that would match your inline use case are: use a forward proxy and use a reverse proxy. A forward proxy is a deployment method that allows Netskope to act as a proxy server for your users’ outbound traffic to the internet. You can configure your users’ devices or browsers to send their traffic to Netskope’s proxy server, either manually or using PAC files or VPN profiles. A reverse proxy is a deployment method that allows Netskope to act as a proxy server for your users’ inbound traffic from specific cloud applications. You can configure your cloud applications to redirect their traffic to Netskope’s proxy server, either using custom URLs or certificates. Using an API connector or a log parser are not deployment methods that would match your inline use case, as they are more suitable for out-of-band modes that rely on accessing data and events from the cloud applications using APIs or logs, rather than intercepting traffic in real time. References: [Netskope Inline CASB], Netskope Security Cloud Operation & Administration (NSCO&A) - Classroom Course, Module 3: Steering Configuration, Lesson 4: Forward Proxy and Lesson 5: Reverse Proxy.

When designing an architecture with Netskope Private Access, the Netskope Publisher is the element that guarantees connectivity between the Netskope cloud and the private application. The Publisher acts as a gateway, securely connecting users to private applications hosted on-premises or in data centers.

Netskope Publisher: This component facilitates secure access to private applications by connecting the Netskope cloud with the internal network. It ensures that users can access private applications seamlessly while maintaining security and compliance.

References:

Netskope documentation on Private Access and the role of the Publisher.

Best practices for configuring and deploying Netskope Publisher to ensure secure connectivity to private applications.

=================

When creating a real-time policy for cloud applications, you can use access method and device classification as source criteria, in addition to users, groups, and organizational units. Access method refers to how the user accesses the cloud application, such as browser, sync client, mobile app, etc. Device classification refers to the type of device used by the user, such as managed or unmanaged, Windows or Mac, etc. These criteria can help you define granular policies based on different scenarios and risks. References: [Creating Real-Time Policies for Cloud Applications]

To create a policy that will notify and allow users to log into their personal Google Drive instance, you need to configure the following components:

Steering Exception:

This component allows you to create exceptions for specific traffic. In this case, you will configure a steering exception to allow traffic to personal Google Drive instances. This ensures that the policy correctly routes the traffic to the appropriate destination without being blocked or filtered incorrectly.

User Alert:

A User Alert component will be configured to notify users when they attempt to log into their personal Google Drive. This alert can provide information about the policy and any actions the user may need to take. It helps in enforcing the policy by informing users about the specific conditions or restrictions.

References:

Netskope Knowledge Portal: Configuring Steering Exceptions

Netskope Knowledge Portal: Creating User Alerts