Security Cloud Platform Configuration

Netskope Secure Web Gateway provides the different global configuration settings below.

Dynamic URL Classification

Dynamic URL classification looks at the textual contents of a page and dynamically determines the category for the uncategorized URLs. This feature is turned off by default. After a page has been dynamically categorized, the classification applies to all of your tenant instances. The page classification to a category expires every 12 hours so that if any changes occur to the page, the content is re-evaluated so the chosen category matches the current page content.

To enable dynamic URL classification globally:

1. Go to Settings > Security Cloud Platform > Configuration.
2. Under Dynamic URL Classification, click Edit.

   

3. In the Edit Dynamic URL Classification, click the toggle to enable or disable. If enabled and users browse an uncategorized URL, Netskope dynamically classifies it into a predefined category.

   

4. Click Save.
5. Go to Policies > Web > URL Lookup to search for predefined and custom categories or report miscategorization.

   

URL Case Insensitivity Match

URL lists allow you to compile lists of URLs to include or exclude in policy scans. To enable your URL lists to be treated as case insensitive:

1. Go to Settings > Security Cloud Platform > Configuration.
2. Under URL Case Insensitivity Match, click Edit.

   

3. In the Edit URL Case Insensitivity Match window, click the toggle to enable or disable. If enabled, all URLs included in your URL lists are matched in a case-insensitive manner.

   

4. Click Save.

Safe Search

To block porn and other explicit content in image format that violates your corporate policy, use the Safe Search feature. Supported search engines include Bing, DuckDuckGo, Google, and Yahoo.

To enable safe search globally:

1. Go to Settings > Security Cloud Platform > Configuration.
2. Under Safe Search, click Edit.

   

3. In the Edit Safe Search, click the toggle to enable or disable. If enabled, Netskope blocks the session when users browse any inappropriate URLs.

   

4. Click Save.

Dynamic Trusted Store

To enable trusted store certificates globally:

1. Go to Settings > Security Cloud Platform > Configuration.
2. Under Dynamic Trusted Store, click Edit.

   

3. In the Edit Dynamic Trusted Store, click the toggle to enable or disable. If enabled, Netskope blocks the session when users browse any inappropriate URLs.

   

4. Click Save.

X-Forwarded-For Header

An X-Forwarded-For (XFF) header is used to identify the originating IP address of a user connecting to a web server through an HTTP proxy. Without the XFF header, the proxy server will be identified as the originating IP address. Use this feature to trust IP addresses contained in the XFF header.

To trust XFF headers globally:

1. Go to Settings > Security Cloud Platform > Configuration.
2. Under X-Forwarded-For Header, click Edit.

   

3. In the Edit X-Forwarded-For Header, click the toggle to enable or disable. If enabled globally, Netskope trusts XFF headers for all traffic in your organization and overrides your XFF configurations for your IPSec tunnels, GRE tunnels, and Explicit Proxy over Tunnel. If disabled, you can trust XFF headers for traffic going through specific tunnels.

   

4. Click Save.

Dedicated Egress IP Footprint

There are several auth-related services which may require configuration to allow Netskope Cloud IPs as the source address to these services.

For example, with active auth on the O365 Proxy, the local ADFS server may restrict auth from certain source IPs. Another case is when you want IdP providers to restrict auth requests from certain source IPs, or similarly restrict application access to a specific application. In these cases, you can use the Netskope Cloud IPs for these configurations.

Web and cloud apps that rely on source IP addresses as a form of identification and security can use the Netskope Dedicated Egress IP Footprint feature to help transition from on-premises security controls to a Security Service Edge (SSE) architecture. This provides admins with an additional option to enable access to these applications and minimize disruption to users.

Netskope’s Dedicated Egress IP Footprint feature allocates a minimum of two IP addresses from Netskope owned IP ranges per data plane that matches your accounts NewEdge traffic management zone/region. The dedicated IP ranges are completely separate from the shared IP ranges. Port exhaustion is monitored by the Netskope platform.

All traffic will use these IP addresses and is available for all steering methods and traffic except for Netskope Private Apps (NPA) traffic.

You can see the list of IPs assigned to your account by going to Settings > Security Cloud Platform > Enforcement > Netskope IP Ranges. The Dedicated IP Ranges tab lists the assigned dedicated IPs. You can copy the IP ranges to use for conditional access policies on the SaaS side.

All Traffic Dedicated Egress IP

To enable dedicated egress IPs for user traffic hitting SaaS apps through the proxy:

1. Go to Settings > Security Cloud Platform > Configuration.
2. Under Dedicated egress IP Footprint, click Edit.

   

3. In the Edit Dedicated egress IP Footprint, click the toggle to enable or disable.

   

4. Click Save.

After saving this configuration, Netskope sends all traffic through the dedicated egress IP.

Conditional Dedicated Egress IP

(Optional) You can specify Source and Destination criteria to route matching traffic through the dedicated egress IP. If no criteria is specified, dedicated egress IP applies to all traffic.

To enable dedicated egress IPs for a subset of traffic hitting SaaS apps through the proxy:

1. Go to Settings > Security Cloud Platform > Configuration.
2. Under Dedicated Egress IP Footprint, click Edit.
3. Configure the Source and Destination specifications.

Important

When configuring a Conditional Dedicated Egress IP policy, keep the following in mind:

• Any traffic matching the policy criteria uses the dedicated egress IP to egress. The remaining traffic uses a Netskope public IP to egress.
• All Source and Destination conditions are OR conditions. That is, if any conditions are matched, then that traffic egresses out via the dedicated egress IP.
• Due to the policy’s OR logic, if the policy excludes users and includes domains, then Netskope sends matching domain traffic from excluded users to the dedicated egress IP.
• Netskope doesn’t support using the same network profile as match criteria for both Source IP and Destination IP.
• To add an app belonging to a cloud app suite as a match condition, you must select its cloud app suite from the Cloud App Suite dropdown list. Individual apps belonging to cloud app suites are unavailable for selection from the Application dropdown list. For example, Box is unavailable for selection, but you can select its cloud app suite, Box App.



4. Click Save.

Localization Zones

Localization zones further extend NewEdge global coverage by providing the same experience as direct-to-net with native language and localized content support for all websites, even when there’s no in-country Data Plane (DP). This feature also addresses certain websites or SaaS applications that require users to be local (geo-blocking or geo-fencing). In addition, localization zones maintain users’ experiences during failover or maintenance situations, even when using an out-of-country DP. Localization zones don’t change or modify the traffic path, such as traffic backhauling that adds latency.

For example, when this feature is enabled, a user in Greece receives search results and websites relevant to Greece and in the Greek language, despite connecting via the NewEdge DP in Vienna, Austria. Similarly, in a failover situation for a user in Mexico (where there’s one single DP), the user can connect via the Dallas DP and continue to receive localized content in Spanish. In the case of Mexico, localization zones extend the resilience of NewEdge via six DPs to ensure both security coverage and digital experience remain intact at all times. These DPs include Atlanta, Dallas, Miami, Phoenix, and two in Los Angeles.

The following table lists the currently supported countries for this feature:

Region	Supported Country	In-Country NewEdge DP
Americas	Anguilla	No
Americas	Antigua and Barbuda	No
Americas	Argentina	Yes
Americas	Aruba	No
Americas	Bahamas	No
Americas	Barbados	No
Americas	Belize	No
Americas	Bermuda	No
Americas	Bolivia	No
Americas	Bonaire	No
Americas	Cayman Islands	No
Americas	Chile	Yes
Americas	Colombia	Yes
Americas	Costa Rica	No
Americas	Cote D'Ivoire	No
Americas	Curaçao	No
Americas	Dominica	No
Americas	Dominican Republic	No
Americas	Ecuador	No
Americas	El Salvador	No
Americas	French Guiana	No
Americas	Greenland	No
Americas	Grenada	No
Americas	Guadeloupe	No
Americas	Guatemala	No
Americas	Guyana	No
Americas	Haiti	No
Americas	Honduras	No
Americas	Jamaica	No
Americas	Martinique	No
Americas	Mexico	Yes
Americas	Nicaragua	No
Americas	Panama	No
Americas	Paraguay	No
Americas	Peru	Yes
Americas	Saint Barthélemy	No
Americas	Saint Kitts and Nevis	No
Americas	Saint Lucia	No
Americas	Saint Martin	No
Americas	Saint Pierre and Miquelon	No
Americas	Saint Vincent and the Grenadines	No
Americas	Suriname	No
Americas	Trinidad and Tobago	No
Americas	Turks and Caicos Islands	No
Americas	Uruguay	No
Americas	Venezuela	No
APAC	Afghanistan	No
APAC	American Samoa	No
APAC	Bangladesh	No
APAC	Bhutan	No
APAC	British Indian Ocean Territory	No
APAC	Brunei Darussalam	No
APAC	Cambodia	No
APAC	Cook Islands	No
APAC	Federated States of Micronesia	No
APAC	Fiji	No
APAC	French Polynesia	No
APAC	Hong Kong	Yes
APAC	Indonesia	No
APAC	Kiribati	No
APAC	Laos	No
APAC	Macau	No
APAC	Malaysia	No
APAC	Maldives	No
APAC	Marshall Islands	No
APAC	Mongolia	No
APAC	Myanmar	No
APAC	Nauru	No
APAC	Nepal	No
APAC	New Caledonia	No
APAC	New Zealand	Yes
APAC	Norfolk Island	No
APAC	Palau	No
APAC	Papua New Guinea	No
APAC	Philippines	Yes
APAC	Samoa	No
APAC	Singapore	Yes
APAC	Solomon Islands	No
APAC	South Korea	Yes
APAC	Sri Lanka	No
APAC	Taiwan	Yes
APAC	Thailand	Yes
APAC	Timor-Leste	No
APAC	Tonga	No
APAC	Tuvalu	No
APAC	Vanuatu	No
APAC	Vietnam	No
APAC	Wallis and Futuna	No
EMEA	Aland Islands	No
EMEA	Albania	No
EMEA	Algeria	No
EMEA	Andorra	No
EMEA	Angola	No
EMEA	Armenia	No
EMEA	Austria	No
EMEA	Azerbaijan	No
EMEA	Bahrain	No
EMEA	Belarus	No
EMEA	Belgium	Yes
EMEA	Benin	No
EMEA	Bosnia and Herzegovina	No
EMEA	Botswana	No
EMEA	Bulgaria	No
EMEA	Burkina Faso	No
EMEA	Burundi	No
EMEA	Cameroon	No
EMEA	Cape Verde	No
EMEA	Central African Republic	No
EMEA	Chad	No
EMEA	Comoros	No
EMEA	Congo	No
EMEA	Croatia	No
EMEA	Cyprus	No
EMEA	Czech Republic	No
EMEA	Democratic Republic of the Congo	No
EMEA	Denmark	No
EMEA	Djibouti	No
EMEA	Egypt	No
EMEA	Equatorial Guinea	No
EMEA	Eritrea	No
EMEA	Estonia	No
EMEA	Ethiopia	No
EMEA	Finland	No
EMEA	Gabon	No
EMEA	Gambia	No
EMEA	Georgia	No
EMEA	Ghana	No
EMEA	Gibraltar	No
EMEA	Greece	No
EMEA	Guernsey	No
EMEA	Guinea	No
EMEA	Guinea-Bissau	No
EMEA	Hungary	No
EMEA	Iceland	No
EMEA	Iraq	No
EMEA	Ireland	Yes
EMEA	Israel	Yes
EMEA	Isle of Man	No
EMEA	Italy	Yes
EMEA	Jersey	No
EMEA	Jordan	No
EMEA	Kazakhstan	No
EMEA	Kenya	No
EMEA	Kuwait	No
EMEA	Kyrgyzstan	No
EMEA	Latvia	No
EMEA	Lebanon	No
EMEA	Lesotho	No
EMEA	Liberia	No
EMEA	Libya	No
EMEA	Liechtenstein	No
EMEA	Lithuania	No
EMEA	Luxembourg	No
EMEA	Macedonia	No
EMEA	Madagascar	No
EMEA	Malawi	No
EMEA	Mali	No
EMEA	Malta	No
EMEA	Mauritania	No
EMEA	Mauritius	No
EMEA	Mayotte	No
EMEA	Moldova	No
EMEA	Monaco	No
EMEA	Montenegro	No
EMEA	Morocco	No
EMEA	Mozambique	No
EMEA	Namibia	No
EMEA	Netherlands	Yes
EMEA	Niger	No
EMEA	Nigeria	Yes
EMEA	Norway	No
EMEA	Oman	No
EMEA	Pakistan	No
EMEA	Poland	Yes
EMEA	Portugal	No
EMEA	Qatar	No
EMEA	Reunion	No
EMEA	Romania	No
EMEA	Russian Federation	No
EMEA	Rwanda	No
EMEA	San Marino	No
EMEA	São Tomé and Príncipe	No
EMEA	Senegal	No
EMEA	Serbia	No
EMEA	Seychelles	No
EMEA	Sierra Leone	No
EMEA	Slovakia	No
EMEA	Slovenia	No
EMEA	Somalia	No
EMEA	South Sudan	No
EMEA	Sudan	No
EMEA	Swaziland	No
EMEA	Sweden	Yes
EMEA	Tajikistan	No
EMEA	Tanzania	No
EMEA	Togo	No
EMEA	Tunisia	No
EMEA	Turkey	No
EMEA	Turkmenistan	No
EMEA	Uganda	No
EMEA	Ukraine	No
EMEA	Uzbekistan	No
EMEA	Yemen	No
EMEA	Zambia	No
EMEA	Zimbabwe	No

To enable localization zones:

1. Go to Settings > Security Cloud Platform > Configuration.
2. Under Localization Zones, click Edit.

   

3. In the Edit Localization Zones window, click the toggle to enable or disable. If enabled, your users receive content based on their geographic location.

   

4. Click Save.

Identify HTTP Traffic on Non-Standard Port

By default, Cloud Firewall (CFW) inspects all traffic on standard and non-standard ports, but web policies are applied only on standard web ports. The “Identify HTTP Traffic on Non-Standard Port” feature allows you to inspect all web traffic on standard and non-standard ports. When enabled, the Netskope service applies web policies to all web traffic, even on non-standard ports, without the need to configure custom ports.

To enable identification for HTTP(s) traffic on non-standard ports:

1. Go to Settings > Security Cloud Platform > Configuration.
2. Under Identity HTTP Traffic on Non-Standard Port, click Edit.

   

3. In the Edit Identify HTTP Traffic on Non-Standard Port window, click the toggle to enable or disable. If enabled, the Netskope service applies configured Real-time Protection policies for cloud app, web access, and firewall policies on all identified HTTP traffic on non-standard ports. That is, the same policy that applies to HTTP traffic on standard ports also applies to traffic on non-standard ports.

   

4. Click Save.