Cloud Exchange Hardening
The following sections provide guidance to make your Netskope Cloud Exchange tenants secure.
Item | Specifications |
---|---|
OS |
|
Docker/Podman |
|
Python | Python 3.x |
Sizing the System Based on Anticipated Usage
This section provides recommendations and guidance for selecting the memory/storage/CPU based on the expected volume. Factors include:
Total number of Indicators expected to be stored in the database. This factor defines the storage requirements.
Netskope Cloud Exchange has a “worker-based” scheduling mechanism to cater to the data pull/push for multiple data sources. The number of workers determines how many data sources will be actively fetching data/sharing data concurrently. The total number of worker processes should be equal to the number of cores. If the expectation is to fetch data frequently with multiple data sources, consider increasing the number of cores.
The tables below provides recommendations for standard deployments:
Host Size | RAM (GBs) | Number of Cores | AWS Equivalent | EPM | Total Recommended Free Storage allocated to Cloud Exchange | Recommended Maximum Available Plugin Credits |
---|---|---|---|---|---|---|
Extra Small | 4 | 4 | C6AXL | 20k | 40 | 3 |
Small | 8 | 6 | C62XL | 50k | 40 | 5 |
Medium | 16 | 8 | C62XL | 100k | 80 | 10 |
Large | 32 | 16 | C64XL | 200k | 120 | 20 |
Credits Used | Plugin |
---|---|
3 | Log Shipper |
1 | Ticket Orchestrator |
3 | Threat Exchange |
2 | User Risk Exchange |
2 | Application Risk Exchange |
6 | WebTx |
Above Average Load Design Assumptions (Your numbers may differ)
Dimension | Modeled Load |
---|---|
Events Per Minute | .75 EPM/user |
WebTx | Average 4 KB each. Compressed 7:1 in W3C format. |
Event/Alert | Average 2 KB each |
Assumed user load from events/alert logs | 1 MB/user/day event/alert logs |
Assumed user load from event streaming logs | 4 MB/user/day WebTx (compressed) or 28MB/user/day WebTx (uncompressed) |
Assumed user load from cloud firewall logs | 14 MB/user/day Cloud Firewall logs |
CE runs on Docker on a Linux host. All best practices should be applied to harden the underlying host using CIS L1 benchmarks for either Ubuntu/CentOS or Red Hat Enterprise Linux.
The Netskope CE platform needs access to GitHub, Docker Hub, Netskope tenant, partners platforms and other 3rd-party platforms you wish to integrate with. Do evaluate network configurations like HTTP Proxy setup, Firewall rules, etc., to ensure the connectivity is available. The Netskope CE stack needs connectivity to these Public URLs.
For fetching third party plugins:
https://github.com
For fetching alerts and events from Netskope tenant:
https://*.goskope.com
For fetching web transactions from Netskope datalake:
https://*.googleapis.com
https://*.pubsublite.googleapis.com
Note: currently, Netskope web transaction logs are retrieved from http://us-west1-pubsublite.googleapis.com/ or http://europe-west3-pubsublite.googleapis.com/ However, these addresses are subject to change - thus the recommendation to use wildcards to ensure reachability
For reporting analytics to Netskope AWS service:
https://reporting.netskope.tech
For pulling docker images from Docker Hub (connectivity to additional hosts may be required since the docker images will be behind a CDN):
https://hub.docker.com
https://auth.docker.io
https://registry-1.docker.io
https://index.docker.io/
https://dseasb33srnrn.cloudfront.net/
https://production.cloudflare.docker.com/
If you are behind an HTTP or HTTPS proxy server, for example in corporate settings, you need to add the proxy configuration in the Docker systemd service file. Refer to https://docs.docker.com/config/daemon/systemd/#httphttps-proxy for details.
Netskope Log Shipper 1.0.0
https://*.goskope.com
Netskope WebTx 1.0.0
Connectivity to subscription path
ArcSight 1.1.1
Connectivity to ArcSight Server
AWS S3 1.0.0
https://*.s3.amazonaws.com/
Azure Cloud Storage 1.0.0
Connectivity to Azure Connection String
Azure Sentinel 1.0.0
https://*.ods.opinsights.azure.com/
Chronicle 1.3.1
https://malachiteingestion-pa.googleapis.com
Elastic 1.1.0
Connectivity to Elastic Server Address
Google Cloud SCC 1.0.1
https://securitycenter.googleapis.com/v1/organizations
https://cloudresourcemanager.googleapis.com/v1/projects
Google Cloud Storage 1.0.0
https://cloud.google.com/storage
Microsoft Defender for Cloud Apps 1.1.0
https://*/api/v1/discovery/upload_url/
LogRhythm 1.1.1
Connectivity to LogRhythm Server
QRadar 1.1.1
Connectivity to QRadar Server
Rapid7 1.1.1
Connectivity to Rapid7 Server
Syslog 1.1.1
Connectivity to SIEM Server
Netskope Ticket Orchestrator (ITSM) 1.0.0
https://*.goskope.com
Cloud Exchange 1.0.0
Connectivity to Netskope Cloud Exchange URL
JIRA ITSM 1.0.1
Connectivity to Jira Cloud Instance URL
Microsoft Teams 1.0.1
Connectivity to Webhook URL
Notifier 1.0.1
Connectivity to respective platform URL
ServiceNow 1.0.2
Connectivity to ServiceNow Instance URL
Netskope Threat Exchange 1.0.0
https://*.goskope.com
Carbon Black 1.0.4
https://defense.conferdeploy.net
CrowdStrike 1.0.0
https://api.crowdstrike.com
https://api.eu-1.crowdstrike.com
https://api.laggar.gcw.crowdstrike.com
https://api.laggar.gcw.crowdstrike.com
Cybereason 1.0.1
https://integration.cybereason.net:8443
Digital Shadows 1.0.1
https://api.searchlight.app/
GitHub DLP 1.0.0
https://api.github.com
Microsoft Defender for Cloud Apps 1.0.1
https://{url}/api/discovery_block_scripts/
Microsoft Defender for Endpoint 1.1.0
https://graph.microsoft.com/beta/security/tiIndicators
https://graph.microsoft.com/.default
https://login.microsoftonline.com/
Mimecast 1.0.0
https://us-api.mimecast.com/
Misp 1.0.0
Connectivity to MISP Base URL
Proofpoint 1.0.0
https://tap-api-v2.proofpoint.com
SentinelOne 1.1.0
Connectivity to management URL
ServiceNow Threat Intelligence Plugin 1.0.0
https://*.service-now.com
STIX/TAXII 2.0.0
Connectivity to Discovery URL
ThreatConnect 1.0.0
Connectivity to ThreatConnect Base URL
ThreatQ 1.0.2
Connectivity to ThreatQ URL
Netskope Risk Exchange 1.0.0
https://*goskope.com
Connectivity to SCIM URL
CrowdStrike CRE 1.0.0
https://api.crowdstrike.com
https://api.eu-1.crowdstrike.com
https://api.laggar.gcw.crowdstrike.com
https://api.laggar.gcw.crowdstrike.com
Google BeyondCorp 1.0.0
https://cloudidentity.googleapis.com/v1
Microsoft Azure AD 1.0.1
https://graph.microsoft.com/
Mimecast CRE 1.0.0
https://us-api.mimecast.com
Okta CRE 1.0.0
Connectivity to your okta domain
Proofpoint 1.0.0
Connectivity to Proofpoint URL
Security Advisor 1.0.0
https://www.securityadvisor.io
If you have conditional access enabled with vendors or SaaS apps for Netskope solutions, or need to SSL Allowlist by IP instead of domains, here is the list of Netskope consolidated list of IP addresses (for tenant access from Cloud Exchange in case your firewall does not support FQDN-based rules). Subscribe to this link by clicking the Follow icon on this page: https://support.netskope.com/s/article/NewEdge-Point-of-Presence-Data-Plane-and-Management-Plane-Global-Edge-Expansion-Status-and-IP-Range
Port | Configurable? | Description |
---|---|---|
443/80 | Yes, during the setup script. | Used to access the CE UI. |
15672 | No. | Used to access the RabbitMQ dashboard. |
Note that Cloud Exchange can be accessed via TLS 1.3 or 1.2 (as of 3.3.3). The choice of which version to use is configured via the setup script. Set TLS 1.3 and do not configure TLS 1.2 support.
Cloud Exchange supports configuring a global proxy that can be used selectively as needed to communicate with external resources. Where a proxy is available for use, leverage the Cloud Exchange setup script tool (as of 3.3.3) to set the proxy globally.
Default Username | Default Password | Configurable? | Description |
---|---|---|---|
admin | admin | Yes, Can be changed during the first login. | Used to access the Cloud Exchange UI. |
user | - | Yes, via Maintenance Password during the setup. | Used to access the RabbitMQ dashboard. |
cteadmin | - | Yes, via Maintenance Password during the setup. | Used to access the mongo database. |
Cloud Exchange supports integrating with Identity Providers via SSO, though users can also be created locally on the box by the admin administrator that is logged in locally. There will only be one root admin. SSO should be the primary method of logging into CE, and where available, should leverage multi-factor authentication. There should be no other local users defined if possible.
Only users that require tokens should be provided roles that include token creation. Roles and users can be set up to have read-only only access. Use least privileged access to create roles with read-only access when possible for most users.
Password Management
There is currently no mechanism to enforce complex passwords or password expiration in Cloud Exchange. Again, SSO is expected to manage these advanced identity requirements. Account credentials should have an expiration and users should be prompted to reset their SSO password periodically.
The original admin should change its default password during the first session. If other users had to be defined locally, the administrator should periodically change their passwords via the GUI, although users can also be prompted to change their passwords manually in their own sessions via the Settings > Account > Change Password setting.
Credentials required for all Cloud Exchange operations are stored within the Mongo database. MongoDB is password protected. Authentication configured during the setup. The data stored within Mongo is unencrypted.
Note
Data encryption within Mongo is available in the Enterprise edition.
When creating an API token for CE to use to communicate, use least privileged access concepts. For now, a Netskope RESTful v1 API token must be installed for CE to communicate with Netskope (it is required for uploading file hashes for use in threat prevention and DLP policies) - it should be rotated on a regular basis. Netskope Cloud Exchange does use the v2 RESTful API endpoint for all other calls when it is provided. Create and provide a properly entitled v2 token.
The following privileges are required with the v2 token:
Read: /api/v2/events/data/network
Read: /api/v2/events/data/application
Read: /api/v2/events/data/page
Read: /api/v2/events/data/audit
Read: /api/v2/events/data/infrastructure
Read: /api/v2/events/data/alert
Read Write: /api/v2/policy/urllist/file
Read Write: /api/v2/policy/urllist
Read Write: /api/v2/policy/urllist/deploy
The Logs managed by CLS are not persisted within CE during normal operations. The logs are fetched and transmitted over TLS communication.
In case of RabbitMQ paging out the messages to disk, the log messages would get stored on disk momentarily.
Acronym | Description |
---|---|
AD | Active Directory |
API | Application Programming Interface |
CE | Cloud Exchange |
CLS | Cloud Log Shipper |
CRE | Cloud Risk Exchange |
CTE | Cloud Threat Exchange |
CTO | Cloud Ticket Orchestrator |
CIS | CIS benchmark standard |
DLP | Data Leak Prevention |
IdP | Identity Provider |
SSL | Secure Socket Layer |
SSO | Single Sign-on |
TLS | Transport Layer Security |
UI | User Interface |