How to track user sessions within the Cloud SWG logs

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users accessing internet sites via Cloud SWG using Proxy Forwarding access method.

Policies in place to prevent users from accessing suspicious or malicious sites, or other sites blocked by corporate policies such as shopping sites.

SOC team concerned that some users may have accessed a site they should not have had access to due to policy misconfigurations (e.g. a shopping site that may also be incorrectly allowed via another policy; adult images that were categorised as educational), and wants a way of determining whether the user accidently clicked on the site.

What logging fields can a Cloud SWG admin track to determine how the user got there, and what they did when they were there?

Environment

Cloud SWG.

Reporting.

Resolution

The access logs track every request from the user into the service, and is typically available in chronological order. This means that user browsing patterns can be correlated on back end logs. Although the following suggestions below may not be able to address all concerns, it should give some tips on what to look out for when questioning reasons why users were accidently accessing sites they should not have been able to access.

 

• Tracking search strings: When Google or Bing generate search requests, the string searched for is included with the q= string e.g. if I trigger a Google search for testquery, the HTTP request will include that string as shown below
  
  https://www.google.co.uk/complete/search?q=testquery&xxx
  
  The Cloud SWG access logs also includes a 'Search Term' field that logs the search strings, potentially indicating user was searching for specific sites and not going there accidently
  
  
• Referer HTTP header: The Referer HTTP request header, logged in the Cloud SWG access logs, contains the absolute or partial address from which a resource has been requested. The Referer header allows a server to identify referring pages that people are visiting from or where requested resources are being used.
  
  An example of this would be someone accessing a video hosting site like vimeo.com, and clicking a specific streaming object there. The object may be on example.com, but the request to example.com will include the Referer HTTP header that specifies vimeo.com. This way we know that the user clicked the streaming video from the vimeo.com site.
  
  Although this is probably the most useful tool for tracking how a user potentially ended up on a site they should not have been going to, this Referer header does not get populated when you access a site from Google or Bing search engines.
  
  
• Check length of time on specific site: If a user has accidently hit a site they should not be allowed to access, they will typically jump off the site. By tracking the number of requests, and time taken on the site, the Cloud SWG admin will be able to tell whether the user accessed site accidently and got away. 

• HTTP Status screen: Accessing web sites that require logins can take on multiple forms e.g. you are challenges for credentials via a popup (401 HTTP status) or users are presented with a login page (200 OK status with 30x redirects potentially). 
  
  When looking through the access logs, check the HTTP status field for 401, or 200 status pages with the 'login' string (very common endpoint) to get an idea whether user logged into a specific site.
  
  In the case of a login page, the users credentials are often POSTed via a HTML form. By checking the Cloud SWG access logs HTTP 'method' field for POSTs, it may also confirm whether a login was performed.

•  

  Content-type HTTP header: Content-type is a HTTP header that indicates the media type of the resource sent in the HTTP message body. This can be used to check whether the user was looking at videos (streaming content type), or downloading files (binary content type).