Security Cloud Platform Configuration
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:
- Go to Settings > Security Cloud Platform > Configuration.
- Under Dynamic URL Classification, click Edit.
- 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.
- Click Save.
- Go to Policies > Web > URL Lookup to search for predefined and custom categories or report miscategorization.
Note
If the URL is miscategorized, use custom categories to define a custom URL category 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:
- Go to Settings > Security Cloud Platform > Configuration.
- Under URL Case Insensitivity Match, click Edit.
- 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.
- 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:
- Go to Settings > Security Cloud Platform > Configuration.
- Under Safe Search, click Edit.
- In the Edit Safe Search, click the toggle to enable or disable. If enabled, Netskope blocks the session when users browse any inappropriate URLs.
- Click Save.
Dynamic Trusted Store
To enable trusted store certificates globally:
- Go to Settings > Security Cloud Platform > Configuration.
- Under Dynamic Trusted Store, click Edit.
- 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.
- 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.
Note
For security, this feature is not supported for remote users when using explicit proxy steering methods.
To trust XFF headers globally:
- Go to Settings > Security Cloud Platform > Configuration.
- Under X-Forwarded-For Header, click Edit.
- 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.
- Click Save.
Dedicated Egress IP Footprint
Note
Contact Support to enable this feature in your account; additional licensing is required.
If Conditional Dedicated Egress IP is enabled for any apps, sources, or anywhere else, then all the non-web traffic will use the Dedicated Egress IP.
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.
Important
Admins must update their IP restrictions for each application.
All Traffic Dedicated Egress IP
To enable dedicated egress IPs for user traffic hitting SaaS apps through the proxy:
- Go to Settings > Security Cloud Platform > Configuration.
- Under Dedicated egress IP Footprint, click Edit.
- In the Edit Dedicated egress IP Footprint, click the toggle to enable or disable.
- 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:
- Go to Settings > Security Cloud Platform > Configuration.
- Under Dedicated Egress IP Footprint, click Edit.
- Configure the Source and Destination specifications.
- 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.
- When a Conditional Dedicated Egress IP policy is enabled, the conditions don’t apply to bypassed traffic (i.e., traffic matching a SSL Do Not Decrypt policy). All bypassed traffic uses dedicated egress IP.
- Click Save.
Important
When configuring a Conditional Dedicated Egress IP policy, keep the following in mind:
Localization Zones
Note
Contact your Sales team or Netskope Support to enable this feature in your account.
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:
- Go to Settings > Security Cloud Platform > Configuration.
- Under Localization Zones, click Edit.
- In the Edit Localization Zones window, click the toggle to enable or disable. If enabled, your users receive content based on their geographic location.
- Click Save.
Identify HTTP Traffic on Non-Standard Port
Note
Contact Support to enable this feature in your account; additional licensing is required.
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.
Note
This feature decrypts SSL on non-standard ports for all traffic, so you must install the root CA certificate on non-web client apps that use SSL. Otherwise, you must configure Do-Not-Decrypt SSL policies rules for these apps. To learn more, see Add a Policy for SSL Decryption.
(Optional) Network Events, Application Events, and Page Events can be configured to log all identified HTTP traffic on standard and non-standard ports.To enable this option in your account, contact Support.
To enable identification for HTTP(s) traffic on non-standard ports:
- Go to Settings > Security Cloud Platform > Configuration.
- Under Identity HTTP Traffic on Non-Standard Port, click Edit.
- 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. Block traffic identified on non-standard ports can also be enabled.
- Click Save.
