CSE Feature Guide: Global Edge

SonicWall Cloud Secure Edge (CSE) has many features available that allow for various use cases from simple to complex. 

Below you will find a description of the goal for each use case and supporting documentation you may follow to configure such use cases. If you are new to CSE and would like to configure an initial Service Tunnel to more quickly get started, please follow this guide:

CSE Getting Started Overview: Service Tunnel on GlobalEdge

Glossary

• Access to Resources
  • Hosted Websites
  • Infrastructure Services
  • Identity Provider Routing
  • Identity Provider IP Whitelisting
  • Service Tunnels
  • Service Tunnel: Search Domains
• Device trust
  • Device Geolocation Visibility and Policies
  • Trust Integrations
• Monitoring & Reporting
  • Downloadable Reports
  • ELK FileBeat Integration
  • Events API
• User Management
  • System for Cross-domain Identity Management (SCIM)
  • SSO for Administrator Access to Command Center
  • One-Time Passcode MFA for Command Center Administrators

Access to Resources

• Hosted Websites
  In CSE, a hosted website is generally referred to as an internal web server or set of Webservers that make up a web service. These can be anything from development environments, internal HR web servers, or other Intranet sites. This, like other services, can be achieved through a Service Tunnel. However, when using a service tunnel you are limited to Policy Decisions which happen on Layer 4 (Networking Layer) of the OSI model. With Hosted Websites, a HTTPS reverse proxy is utilized, which opens up possibilities to implement Layer 7 (Application Layer) policies such as restricting specific user groups to specific endpoints on the webserver. In addition, this allows unregistered device (with the CSE App) use cases to access your service if desired. Below you may find guides from CSE documentation to configure this use case.
  
  Register a Hosted Website
  Layer 7 Policies
  Advanced Settings for Hosted Websites
  
  
• Infrastructure Services
  Infrastructure Services in SonicWall CSE use a reverse proxy component packaged in the CSE app. This proxy allows users to connect to a local port which CSE then proxies to a destination service behind an AccessTier. The infrastructure category covers all non-HTTP TCP-based services. This can be protocols such as SSH, RDP, Kubernetes API, and Databases. While other TCP protocols can be configured as a "Generic TCP" service. Below you will find CSE documentation to guide you through these options.
  
  Generic TCP Services
  SSH Servers
  Kubernetes API
  RDP Servers
  Databases
  
  
• Identity Provider Routing
  In modern corporate environments, a cornerstone of day-to-day operations is the Identity Provider (IDP). SonicWall CSE can add a layer of security to IDPs by requiring device posture checks and a CSE policy check upon a user's login. To achieve this we use various combinations of policy controls in the respective IDP and an SSO connection to SonicWall CSE which utilizes CSE as an external IDP. Thus allowing your IDP to call out to SonicWall CSE during authentication to pass authentication through the CSE Policy Engine. Below you may find documentation to configure such a use case with various IDPs which we have documented.
  
  IDP Routed SaaS applications
  Okta
  Microsoft EntraAD
  OneLogin
  
  
• Identity Provider IP Whitelisting
  If you utilize Service Tunnels in your SonicWall CSE environment you may want to add policies to more sensitive applications in your Identity Provider (IDP) in order to add a layer of security. While it is up to your IDP to support IP zoning policies, we do provide the egress IPs for all our Global Edge AccessTiers which you can input into such policies. Once configured, this will require your users or admins to connect to the Service Tunnel to gain access to the target SaaS application. Below you will find guidance on this setup.
  
  Secure SaaS Applications with IP Allowlisting
  Okta IP Allowlisting
  EntraAD Allowlisting
  Global Edge IP Ranges
  
  
• Service Tunnels
  SonicWall Cloud Secure Edge (CSE) offers a VPN solution with Wireguard and device posture checks to negotiate access using layer 4 policies into corporate or other private network use cases. This type of tunneling is known as a split tunnel which only tunnels the required traffic defined in the tunnel's configuration. The remaining traffic will egress out of a local interface as usual. Below you can find the getting started guides which cover this use case as well as SonicWall documentation with more details on your options.
  
  CSE Getting Started: Create A Service Tunnel
  Publish a Service Tunnel
  Layer 4 Policies
  
  Service Tunnel: Search Domains
  In many traditional corporate configurations, you will find Windows file sharing to share files between machines on a network. In many cases, a VPN will be utilized to achieve network connectivity to the file share. With Service Tunnel, SonicWall uses a split tunnel meaning only the defined traffic will egress over the tunnel. Thus we need to define the search domain used for Windows file sharing on the Service Tunnel. Below you will find documentation guiding you through this configuration to set up search domains.
  
  Search Domains
  Publishing Service Tunnels 

Device Trust

• Device Geolocation Visibility and Policies
  As part of the SonicWall Cloud Secure Edge (CSE) Application, you can gain visibility and make policy decisions based on the geolocation of your users. This is especially helpful for those who may be working remotely or working while traveling. You may also ensure your users are not coming from sanctioned countries or countries not permitted by corporate policy to operate from. This comes in the form of Event logging for visibility and a trust factor which lowers a device's score based on Geolocation. Below you will find a guide for both enabling Geolocation and adding a trust factor of which Geolocation is one.
  
  Enable Geolocation
  Geolocation Trust Factor
  
  
• Trust Integrations
  SonicWall Cloud Secure Edge (CSE) has additional trust factors that can be checked in the form of a Trust Integration. These integrations utilize the API of Capture Client, SentinelOne, or Crowdstrike to gain access to another source of trust information for the device which is registered to SonicWall CSE. These additional signals from these additional security suites allow CSE to lower a device's score to dynamically deny them from services if one of these integrations detects a threat on the device. These signals vary from integration to integration and you may find more information below.
  
  Trust Integrations
  SonicWall Capture Client
  SentinelOne
  CrowdStrike

Monitoring & Reporting

• Downloadable Reports
  In the SonicWall Cloud Secure Edge Command Center, you may find various pieces of information on users that you want to see in a more complete view or apply custom filters to. In such cases, you may want to download a report of your Devices or Internet Threat Protection. These reports come in a CSV format to display the attributes and properties of each object that SonicWall CSE maintains. To find more info on where to download such reports, check out the documentation below.
  
  Downloadable Reports
  
  
• ELK FileBeat Integration
  In cases where your organization utilizes  ELK (Elasticsearch, Logstash, Kibana) Stack(s) for log storage and monitoring you may want to include your SonicWall Cloud Secure Edge (CSE) event logs into your stack. To achieve this the CSE Command Center supports integration with Filebeat to send logs to your ELK Stack. Please find the respective documentation below for configuration.
  
  Analyzing Cloud Secure Edge Events in your ELK Enterprise Logging Solution
  
  
• Events API
  A more advanced use case that SonicWall Cloud Secure Edge (CSE) offers is access to the events in your environment through the SonicWall CSE's RestAPI. This API can pull queries with a request.  You may want to utilize the API in cases such as configuring your Security Event and Incident Management (SIEM) to make a GET request to the API on an interval to collect CSE Event logs. While we don't provide configuration steps in your SIEMs outside of ELK, the API information may be used to configure custom solutions or in line with your SIEM's documentation on querying APIs. You may find information on the Events API here.
  
  Events API Spec
  API Guide

User Management

• System for Cross-domain Identity Management (SCIM)
  Until enabled, SonicWall Cloud Secure Edge (CSE) relies on user authentication events to have user information pushed to the directory within CSE. This means user information would only be known by SonicWall after the initial time the system saw the user. With SCIM, we can pull this data from the Identity Provider instead of waiting for user authentication. Below you will find documentation for this solution and how to implement it.
  
  Enabling SCIM for End Users
  
  
• SSO for Administrator Access to Command Center
  Out of the box, administrators are made locally in the SonicWall Cloud Secure Edge (CSE) tenant where they are managed directly in SonicWall's CSE Command Center. As an administrator, you can configure Admin SSO from your Identity Provider (IDP) for more dynamic access controls based on your IDP's policies. Once configured, this will give administrators the option of signing in with SSO or in some cases, a local account. This configuration also supports IDP-initiated flows for ease of login.
  
  Single Sign On: Managing Admins
  Okta
  Microsoft EntraAD
  Google Workspace
  
  
• One-Time Passcode MFA for Command Center Administrators
  To help further protect the SonicWall Cloud Secure Edge (CSE) Command Center, we offer a time-based one-time password option as an additional login factor when authenticating into the Command Center as an administrator. This is a global setting for all administrators. You may find more details on how to configure this below.
  
  Time-based One-Time Passcode