​SIA​ Proxy can act as a SWG that performs URL filtering and anti-malware scanning in your current network configuration. This occurs when ​SIA​ Proxy is configured to scan all web traffic. You can configure ​SIA​ Proxy as a full web proxy with one of these methods:

• Proxy chaining. Directs all HTTP and HTTPS traffic from your organization's on-premises proxy to ​SIA​ Proxy. For more information, see Proxy chaining.

• Configure browser or system proxy settings. You can modify the browser or system proxy settings to connect a user’s browser or device to ​SIA​ Proxy. For more information, see Configure the proxy in browsers.

• ​ETP Client​. When you configure the client as a local web proxy on the device or you configure it to perform transparent traffic interception, all HTTP and HTTPS traffic is forwarded to ​SIA​ Proxy. For more information, see About ​ETP Client​.

• Security Connector as an HTTP Forwarder. With Security Connector version 2.7.5 or later, you can configure Security Connector as a proxy within your network that forwards traffic to ​SIA​ Proxy. You can configure it as an explicit proxy that forwards web traffic from enterprise devices or as a transparent proxy that forwards traffic directly from the router. For more information, see Configure HTTP Forwarder.

• IPsec tunnels. Uses IPsec tunnels to direct traffic from an office branch to ​SIA​ Proxy. For more information, see Set up IPsec tunnels.

After enabling the proxy in a policy, you select the Full Proxy as the Operating Mode access control setting. This setting configures the default behavior for traffic. Unless otherwise specified in ​SIA​ policy with a bypass or block action, traffic is directed to the full web proxy. You can also select Full Proxy as the mode for mobile traffic.

You can further use these features to secure website access and prevent users from accessing malicious content:

• Decrypt TLS traffic with trusted certificate. ​SIA​ Proxy uses a MITM CA TLS certificate to generate and sign origin certificates for HTTP or HTTPS websites. You need to generate an ​Akamai​ certificate or upload a certificate signed by your company's CA. For enterprise client computers to accept and trust these certificates, the trusted MITM CA root certificate needs to be deployed on all enterprise devices and TLS clients. For more information, see ​SIA​ Proxy MITM certificate.

• User Authentication. You can define the users or user groups that can access websites or web applications after they authenticate. You can require that users authenticate before accessing a website or web application, or you can make authentication optional. Optional authentication may be a useful recovery mode for users who are unable to authenticate. For more information, see User authentication and group policies.

• Inline payload analysis Allows ​SIA​ to scan files or website content before end users see the downloaded content. In ​SIA​, this action is available for files that do not exceed 5 MB. For more information, see Inline payload analysis.

• Static malware analysis for large files. Allows ​SIA​ to scan files that are 5 MB to 2 GB in size. ​SIA​ scans these files after they are downloaded. If ​SIA​ detects malware, a threat event is reported. In the ​SIA​ threat event on the Threat Events report, you can download a deep scan report in PDF format that includes more detailed information. To use this feature, in a policy, you need to enable Inline Payload Analysis and select the Allow and Scan option for large files. For more information, see Static malware analysis of large files.

• Dynamic malware analysis in a Sandbox environment. Scans files in a secure sandbox environment that's isolated from your network. In this environment, file are executed and analyzed to determine whether malicious code or activity is detected. This feature:

  • Analyzes files that are 5 MB to 100 MB in size.

  • Automatically scans files offline (after they are downloaded).

  • Publishes a deep scan report in ​SIA​ when it detects a threat. You can download the report in PDF format from the corresponding event in ​SIA​.

  To use this feature, in a policy, you need to enable Inline Payload Analysis, select the Allow and Scan option for large files, and enable Dynamic Analysis. This feature is available to organizations that are licensed for Advanced Sandbox. For more information, see Dynamic malware analysis.

To implement authentication, you need to also set up:

• Identity providers. A service that creates, manages, and saves user and group identity information for authentication. You can create an IdP or integrate a third-party IdP such as Okta, Microsoft Azure AD, and AD FS. In an IdP configuration, you can enable MFA, define session settings, design the login page, and more. For more information on IdPs, see About identity providers.

• Directories. A service that your enterprise uses to manage users and user groups. You need to associate a directory to an IdP. These directory services are supported:

  • Active Directory
  • Lightweight Directory Access Protocol
  • Active Directory Lightweight Directory Services

  ​SIA​ also offers Cloud Directory, an internal directory that you can use for testing purposes until an IdP is fully deployed. For more information, see About directories.

• Identity connectors. An identity connector is a virtual appliance that you download in ​SIA​ and deploy behind the firewall in your data centers or hybrid cloud environments. You associate an identity connector to a directory. It allows ​SIA​ to synchronize with your directory service inside your data center. For more information, see About identity connectors.

​SIA​ includes reports where you can view detailed information about traffic, such as:

• DNS Activity. Shows data on DNS traffic that's directed to ​SIA​ or ​SIA​ Proxy. This report allows you to:

  • Investigate suspicious activity.

  • Review requests made to a specific domain.

  • Check activity from a specific client internal IP address or machine name.

  • Troubleshoot a failed request based on connection ID or client request ID.

• Proxy Activity. Shows the traffic that's directed to ​SIA​ Proxy. This report can show the requested domain, internal IP address of the user's machine, the username of the user who made the request, the action that was applied to traffic, and more.

These reports are available to super administrators and users who are assigned the etpRestrictedPageViewRole role permission. For more information, see ​Secure Internet Access Enterprise​ roles.

Request Flow

These sections describe the flow of a request in a specific full web proxy configuration:

• Proxy chaining

• Configured system or browser proxy settings

• ​ETP Client​ with an on-premises proxy

• ​ETP Client​ with no on-premises proxy

• HTTP Forwarder as an explicit proxy

• HTTP Forwarder as a transparent proxy

• IPsec Tunnels (beta)

Proxy chaining

This graphic shows the flow of a request when proxy chaining is configured in a network that's enabled for authentication and dynamic malware analysis. For more information about proxy chaining, see Set up proxy chaining.

In this graphic:

1. All DNS, HTTP, and HTTPS requests are forwarded from the user's device to the on-premises proxy.

2. As a result of a proxy chaining configuration, the on-premises proxy forwards requests to ​SIA​ Proxy. If enabled to do so, the on-premises proxy adds the X-Forwarded-For header to identify the client IP address on the corporate network.

3. DNS requests are forwarded to ​SIA​ DNS server. Information about the domain and the HTTP or HTTPS request is recorded in ​SIA​. If you select to trust the X-Forwarded-For header, ​SIA​ Proxy can identify the client IP address. The client IP address is included in the reported threat events.

4. If authentication is required or optional in the associated policy, the user is prompted to authenticate based on the IdP configuration. The request proceeds as long as authentication is successful. Authentication requires that you configure the X-Forwarded-For header.

5. Based on the policy, an action is applied to traffic. If the traffic is allowed, the request is directed to the origin and the user is granted access. Otherwise, it's blocked and an error page is shown to the user.

   📘

   If the bypass action is configured, the request bypasses TLS MITM decryption and it's sent directly to the origin IP address or the destination web server.

6. If the request is allowed and you enabled payload analysis for large files, you can scan website content after it's downloaded by your browser. If your organization is licensed for Advanced Sandbox and you also enabled Dynamic Analysis, this content is directed to a secure sandbox environment.

Configured system or browser proxy settings

You can provide the hostname of ​SIA​ Proxy in the browser or system proxy settings to forward traffic from a user’s browser or device. For more information, see Configure the proxy in browsers.

1. As a result of the browser proxy setting configuration, all HTTP and HTTPS requests are forwarded from the user's device to ​SIA​ Proxy. DNS requests are forwarded to ​SIA​ DNS servers.

2. If authentication is required or optional in the associated policy, the user is prompted to authenticate based on the IdP configuration. The request proceeds as long as authentication is successful.

3. Based on the policy, an action is applied to traffic. If the traffic is allowed, the request is directed to the origin and the user is granted access. Otherwise, it is blocked and an error page is shown to the user.

​ETP Client​ with an on-premises proxy

This graphic shows the flow of a request when ​ETP Client​ forwards requests to an on-premises proxy. In this scenario, the on-premises proxy forwards requests to ​SIA​ Proxy. For more information, see ​ETP Client​ for web traffic.

If your network has an existing on-premises proxy, you can configure that ​ETP Client​ does not override these settings. ​ETP Client​ detects that the on-premises proxy is chained to ​SIA​ Proxy and in turn, the client avoids intercepting web traffic. If ​ETP Client​ detects that the on-premises proxy forwards traffic to ​SIA​ Proxy, the client shows a protected status.

In this graphic:

1. Requests from the users in the corporate network are forwarded to the on-premises proxy. Off-network requests are directed to ​SIA​ Proxy. As configured in the network, all requests are sent to the on-premises proxy.

2. As a result of the proxy chaining configuration, the on-premises proxy forwards traffic to ​SIA​ Proxy. DNS requests are forwarded to ​SIA​ DNS. ​SIA​ Proxy performs TLS MITM decryption.

3. If authentication is required or optional in the associated policy, the user is prompted to authenticate based on the IdP configuration. The request proceeds as long as authentication is successful.

4. Based on the policy, an action is applied to traffic. If the traffic is allowed, the request is directed to the origin and the user is granted access. Otherwise, it is blocked and an error page is shown to the user.

   📘

   If the bypass action is configured, the request bypasses TLS MITM decryption and it's sent directly to the origin IP address or the destination web server.

5. If the request is allowed and you enabled payload analysis for large files, you can scan website content after it's downloaded by your browser. If your organization is licensed for Advanced Sandbox and you also enabled Dynamic Analysis, this content is directed to a secure sandbox environment.

​ETP Client​ with no on-premises proxy

This graphic shows the flow of a request when the ​ETP Client​ machine is configured as a local web proxy or as a transparent proxy where transparent traffic interception is enabled. When this configuration is in place, web requests are directed from ​ETP Client​ to ​SIA​ Proxy for analysis. For more information, see ​ETP Client​ for web traffic.

In this graphic:

1. Regardless if a user is on or off the corporate network, this applies:

   • All DNS requests are directed from ​ETP Client​ to ​SIA​ DNS.

   • All HTTP and HTTPS requests are directed from ​ETP Client​ to ​SIA​ Proxy.

2. Depending on the request, this applies:

   • ​ETP Client​ forwards web requests to ​SIA​ Proxy where the proxy performs TLS MITM decryption.

   • ​ETP Client​ forwards internal requests to the internal network based on Local Bypass Settings or an exception list. Internal requests bypass ​SIA​ Proxy and are forwarded to their destination.

3. If authentication is required or optional in the associated policy, the user is prompted to authenticate based on the IdP configuration. The request proceeds as long as authentication is successful.

4. Based on the policy, an action is applied to traffic. If the traffic is allowed, the request is directed to the origin and the user is granted access. Otherwise, it is blocked and an error page is shown to the user.

   📘

   If the bypass action is configured, the request bypasses TLS MITM decryption and it's sent directly to the origin IP address or the destination web server.

5. If the request is allowed and you enabled payload analysis for large files, you can scan website content after it's downloaded by your browser. If your organization is licensed for Advanced Sandbox and you also enabled Dynamic Analysis, this content is directed to a secure sandbox environment.

HTTP Forwarder as an explicit proxy

You can configure HTTP Forwarder as an explicit proxy. For this configuration, you use a proxy auto-configuration (PAC) file or modify the system or browser proxy settings of the user’s device to forward traffic to HTTP Forwarder. Traffic is then forwarded to ​SIA​ Proxy where its is scanned for malware.

In this graphic:

1. Traffic is forwarded from end user devices to Security Connector as an HTTP Forwarder. An administrator configures device operating systems or browsers to send traffic to HTTP Forwarder through a PAC file or a device management solution. The IP address and port of HTTP forwarder is configured on the OS or browser proxy settings.
2. HTTP Forwarder accepts traffic from the port that was set up in the Security Console console. Traffic from other ports is dropped.
3. Traffic is then directed to ​SIA​ Proxy where it’s scanned for malware.

HTTP Forwarder as a transparent proxy

You can configure HTTP Forwarder as a transparent proxy. For this configuration, the policy-based routing (PBR) rules on the router are modified to forward traffic to HTTP Forwarder. Unlike an explicit proxy configuration, this configuration does not require your organization to modify settings on user devices.

In this graphic:

1. User traffic is directed to the router.
2. An administrator configures policy-based routing rules on the router to direct traffic to HTTP Forwarder. HTTP Forwarder receives traffic on the port that’s configured in ​SIA​ policy.
3. HTTP Forwarder directs traffic to ​SIA​ Proxy where it’s scanned for malware.

IPsec Tunnels

You can configure IPsec tunnels to direct traffic from your office branch to ​SIA​ Proxy. This method uses an organization's SD-WAN solution to create these tunnels. For more information, see Set up IPsec tunnels.

In this graphic:

1. An SD-WAN appliance forwards traffic from the organization’s branch. Traffic from branches that are configured as known locations in ​SIA​ are forwarded and accepted by ​SIA​.

   The SD-WAN Orchestrator or the portal used to manage the SD-WAN solution is where an administrator configures the primary and secondary tunnels that send and receive traffic. The secondary tunnel serves as a backup tunnel in case of failure. An ​SIA​ administrator configures specific settings in ​SIA​ to establish communication with the IPsec tunnel.

2. The IPsec tunnels that are created direct traffic to ​SIA​ Proxy.

3. ​SIA​ Proxy inspects traffic and handles it based on ​SIA​ policy. If traffic is allowed, it is directed to the origin.