The Skyhigh Client Proxy Context Advantage
July 9, 2024
By Jeff Ebeling – Cloud Security Architect, Skyhigh Security
Skyhigh Client Proxy (SCP) is an extremely valuable tool that is available to all Skyhigh Secure Web Gateway (SWG) customers. It is used to transparently authenticate and redirect HTTP/S traffic to Skyhigh Secure Web Gateways (SWG On Prem and/or SWG Cloud). In addition to identifying the user that called the process making the web request, SCP provides additional context that can be used to make more intelligent proxy filtering and connection decisions! Furthermore, as described later in this technical blog, SCP can be used and its benefits can be realized regardless of where Skyhigh SWG is in a proxy chain.
To get started, please review the SCP Product Guide and particularly the section that describes the context provided in the SCP headers (SCP Metadata). The SCP provided headers include:
- Customer ID
- Username (from system login)
- Groups (from client whoami)
- Original Destination IP
- Process Name (that made request on client)
- Process EXE Path
- System Information
- AV Installed?
- Crowdstrike ID
- AV On?
- Crowdstrike Overall Score
- AV Up to Date?
- Crowdstrike OS Score
- FW Healthy?
- Crowdstrike Sensor Config
- Client OS Name and Version
- User Language
- Localtime
- Client MAC Address
- Process Up Time
- System Name
- Exe Signer
- SCP Policy Name
- Exe Product Name
- SCP ID
- Exe MD5 Hash
- Matched Device Profiles
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
More notes on SCP headers (SWEB headers) are provided later in this blog.
Obviously SCP works seamlessly with Skyhigh SWG, but what if the Skyhigh SWG (Cloud or On Prem) must act as a parent proxy to a third party proxy that is already used in the environment, or if Skyhigh SWG is just being used as a filtering service attached to a third party decrypting proxy? This article describes how SCP’s full value can be realized in any environment that includes Skyhigh SWG.
Use Case: Decrypting Proxy (e.g. F5-SSLO) with Skyhigh SWG
In this use case, authentication is optionally performed on a decrypting proxy for proxy aware traffic. This allows for true authentication with Kerberos, NTLM, LDAP, SAML etc when supported by the decrypting proxy. SCP also provides a way to “authenticate” traffic that isn’t proxy aware. Independent of authentication, the context provided by SCP can be used by both the decrypting proxy and Skyhigh SWG. The decrypting proxy can check the SWEB headers provided by SCP via a sideband call to Skyhigh SWG on-Prem (example rules shown below) and then use the context in connection and filtering decisions. For example, the context provided by SCP could be used to decide whether to allow the connection, whether or not to decrypt, or even if true authentication should be initiated. The decrypting proxy can also just simply forward the SWEB headers provided by SCP to SWG so that the added context can be used in SWG rules. F5 has a published integration guide for this architecture.
Use Case: Third Party Proxy as a Child to Skyhigh SWG (Cloud or On Prem)
In this use case, there is no requirement to decrypt at first proxy. True authentication can still be performed via the first proxy using proxy authentication via 407 status codes. SCP is able to intercept HTTP/S direct or proxied requests and make explicit proxy requests to a local Skyhigh or third-party proxy. Interception of already proxied traffic allows SCP to successfully operate in “secure networks” that have no default route and/or the DNS servers don’t resolve external addresses. SCP provides a method for authenticating traffic that isn’t proxy aware. This architecture provides a simple “on ramp” to Skyhigh SSE enabling far superior functionality over any local proxies that may currently be in use. In addition, SCP adds a transparent proxy option for Windows and Macs to cover applications that are not proxy aware and are running in explicit proxy environments. All the child proxy has to do is “next hop” the SCP traffic to the Skyhigh SWG (Cloud or On Prem) with the SWEB headers left intact.
Additional Notes on SCP SWEB Headers
SCP provides all contextual information via SWEB headers inserted into the CONNECT request for HTTPS transactions or the individual method requests for HTTP transactions. Commands within an accepted HTTPS proxy connection DO NOT get headers. When SWG verifies SWEB headers it will remove them by default (disabling removal is part of the SWPS authentication settings used when evaluating the Authentication.Authenticate property in Skyhigh SWG).
Base64 encoded SWEB headers generated by SCP are first encrypted with the tenant’s shared secret included as part of the SCP policies generated in Skyhigh Cloud or Trellix ePO. The tenant is identified using the SWEB customer ID header. A third party proxy cannot decrypt the SWEB headers and will only be able to forward headers provided by SCP.
Skyhigh SWG (when acting as a decrypting proxy) persists SWG context throughout the HTTPS connection. When using Next Hop Proxy to Skyhigh SWG cloud from Skyhigh SWG On Prem with Secure Channel setting enabled, some SWEB headers are always added automatically. The automatically added headers are: CustomerID, Username (Authentication.Username), and Groups (Authentication.UserGroups). SWG generated SWEB headers are encrypted by Skyhigh SWG On Prem with the credentials (Customer ID and Shared Secret) that are part of the UCE Hybrid configuration. If SCP is used for the connection directly to any proxy, all SWEB headers are naturally included.
SCP is user identification more than authentication, a system call gathers username and groups associated with the process caller, from time of login, groups will only be current as of last client directory connection.
Sideband Call Example Ruleset
Learn More
Discover how your organization can use Secure Web Gateway and Skyhigh Client Proxy to protect your employee systems and data while gaining greater visibility and more granular control of your HTTP and HTTPS traffic.