Using Secure Access Cloud Forensics
search cancel

Using Secure Access Cloud Forensics

book

Article ID: 186165

calendar_today

Updated On:

Products

Secure Access Cloud Symantec Products

Issue/Introduction

Secure Access Cloud (SAC) provides full auditing and logging of all end-user access events as well as activities on the corporate resources which are accessed through it.

These events are available by navigating to the Logs tab from the top navigation in the SAC administration console.

Cause

Secure Access Cloud

Resolution

Events Overview

The Forensics section allows viewing, searching and filtering for end-user events based on the user, application, event type, requestId and other parameters.

Event Types

The events logged in the Forensics section include the following types:

  • Access - logged when a used is accessing an application for the first time within a specific session
    Note: Subsequent access events within the same session will not be logged, unless the context of the request has changed.
    • The access events are also differentiated based on the resource type (SSH and Web access events would have different fields, hence are different events).


  • Activity - logged when a specific operation performed by the user, such as URI accessed for web application or SSH command executed for an SSH application.
    • The activity events are also differentiated based on the resource type (SSH and Web access events would have different fields, hence are different events).


  • Key Management - logged when a specific key related operation is performed by the end-user in the application portal, for example generating or revoking an SSH key, RDP key or an end-user API client.


  • MFA - logged when a user is prompted for an additional factor, either via an integrated MFA provider (such as Symantec VIP) or a built-in authentication such as Web Verification.



For example, when a user is accessing a web application which requires an additional authentication validation (e.g. - MFA) the following events will be logged:

  1. An access event for the initial access attempt. This would be a failed access event in scenarios where the user hasn’t already performed an MFA in his current session:

  2. The following event would be the MFA event for the user:

  3. The next event would be the successful access request to the application once the user has successfully validated their identity using MFA:


  4. Following the successful access all activities performed in the application itself would be logged:

Event Structure

Each event contains a section containing common information (such as the user’s UPN, application, etc’) and event specific information (such as the access policy which was matched in a specific access event, or the SSH command executed in an SSH activity event).

Each event is divided into 4 sections:

  • The ‘basic’ section - containing all the common information such as date and time, the result, user and application, etc’.
  • The ‘connection info’ section - containing protocol and activity specific information, such as the protocol version, the URI accessed (in activity events), the response times, etc’.
  • The ‘device’ section - with information about the client, such as device id (if available), browser, OS, etc’.
  • The ‘result’ section - containing details about the result of the access or activity request, such as the policy allowing the access, the request for additional authentication (MFA) and additional details.




The basic section (containing the common fields for both access and activity events)

The following fields are available in the same format across all access and activity events:

  1. Date - The date and time of the request
  2. Result - Success or Failure
  3. Entity - the UPN or the API Client name of the entity performing the access
  4. Event type - Access, Activity, Multi Factor Authentication or Key Management
  5. ApplicationType - Web, SSH, RDP, TCP (not applicable for MFA and Key management events)
  6. Application Name  - the application to which the access is performed (not applicable for MFA and Key management events)
  7. Application Internal - the internal address configured for the application (not applicable for MFA and Key management events)
  8. Client IP - The external IP address from which the request has originated
  9. Country - The GeoIP resolution (based on the Client IP field) of the country from which the request has originated.
  10. Request ID - a unique ID for the request (available in the Secure Access Cloud error pages to assist troubleshooting and request tracing)

Access and Activity events

Web Access Events - Specific Fields

Connection Information Section:

  1. Http version - Based on HTTP RFC
  2. Response time - the end to end response time (from the moment the request reached the secure access cloud front-end, from the client, until the response was sent back to the client)
  3. Referrer - Based on HTTP RFC
  4. Time to first byte - The time passed between the 1st byte leaving the connector towards the application and the 1st byte of response message arrived to connector from the application



Device Section:

  1. Client type - Browser or an API client
  2. Device ID - The unique ID of the devices reported by the integrated endpoint solution (such as OPSWAT)
  3. Device Type - Desktop, Mobile, etc’
  4. OS - The operating system running on the device
  5. Browser - The browser used to perform the operation
  6. User Agent - A parsed ‘User-Agent’ string sent by the browser


Result - ‘Allowed by Policy’ or ‘Failure’ section

In a scenario where the access was successful an ‘Allowed by Policy’ section will be displayed.
The section will contain the Policy to which the user, application and conditions were matched and through which the user has been granted access to the application.

The policy itself is a link to the relevant access policy (also accessible from the ‘Policies’ page).

In a scenario where an access has failed the reason for the failure will be displayed.

The following reasons are possible:

  1. ‘No Matching Policy; - Occurs in a scenario where the user + application + condition group which represent the access request do not exist in any policy configured in the SAC tenant.

  2. ‘Device compliance check is required’ - Occurs in a scenario where a device compliance condition has been requested. In this scenario SAC will redirect the user to a device compliance check to the configured 3rd party service. Once the 3rd party has performed the device compliance check SAC will re-evaluate the access and an additional event will be logged representing the access check result post the device compliance check.

  3. ‘Additional authentication step is required’ - Occurs in a scenario where an additional authentication factor (such as Symantec VIP or Web Verification) is required.

Once the user has performed the additional authentication step SAC will re-evaluate the access and an additional event will be logged representing the access check result post the additional authentication factor.

Web Activity Events - Specific Fields

Connection Information Section:

The Web Activity events are similar to the web access events with the exception of the ‘Connection Info’ section which contains additional information:

  1. Activity Type - The activity performed (URI Access, File Download, etc’)
  2. Status Code - The status returned by the application to the user’s request
  3. HTTP command - The command used (GET, PUT, POST, etc’)
  4. Request URI - The application URI to which the request was sent

Result - ‘Allowed by Default’ or ‘Denied by Policy’ section

By default - all user activities sent to the application are allowed, unless explicitly specified by a specific activity policy.


In a scenario where an activity was blocked by a specific policy the following information will be provided:

  1. Reason - The reason which caused the denial
  2. Policy - The specific policy based on which the request was denied

The basic section (containing the common fields for both access and activity events)

The following fields are available in the same format across all access and activity events:

  1. Date - The date and time of the request
  2. Result - Success or Failure
  3. Username - the UPN or the API Client name of the entity performing the access
  4. ApplicationType - Web, SSH, RDP, TCP
  5. Application Name  - the application to which the access is performed
  6. Application Internal - the internal address configured for the application
  7. Client IP - The external IP address from which the request has originated
  8. Country - The GeoIP resolution (based on the Client IP field) of the country from which the request has originated.
  9. Request ID - a unique ID for the request (available in the Secure Access Cloud error pages to assist troubleshooting and request tracing)

SSH Access Events - Specific Fields

Connection Information Section:

  1. Auth. method - The authentication method used (Temporary token or client certificate)
  2. Local account - The name of the local SSH account used to login to the target host
  3. Client port - The source port on the client ip initiating the connection

Device Section:

  1. Client - The name of the SSH client initiating the connection

SSH Activity Events - Specific Fields

The SSH activity is a combination of the common basic section, the SSH access event fields and the addition of 2 fields in the ‘connection info’ section:

  1. Activity type - whether its command execution, file transfer (scp) or other types of activities
  2. Command - containing the actual SSH command executed on the target host

RDP Access Events - Specific Fields

Connection Information Section:

  1. Auth. method - The authentication method used (Temporary token or Long term key)

TCP Access Events - Specific Fields

Connection Information Section:

  1. Auth. method - The authentication method used (Temporary token or client certificate)
  2. Client port - The source port on the client ip initiating the connection

Device Section:

  1. Client - The name of the client initiating the TCP tunnel connection

MFA Event - Specific Fields

Connection Information Section:

  1. Http version - Based on HTTP RFC

Device Section:

  1. Device Type - Desktop, Mobile, etc’
  2. OS - The operating system running on the device
  3. Browser - The browser used to perform the operation
  4. User Agent - A parsed ‘User-Agent’ string sent by the browser

Key Management Event - Specific Fields

The key management event is generated when a user is performing key related operations (SSH, RDP or Web API keys) such as generate or revoke in the application portal.

  1. Application type -  contains the key type (SSH, RDP or Web).
  2. Action type - The operation performed - Create or Revoke.




Searching and Filtering events

The Forensics screen provides the ability to search the events based on multiple fields.
The search appears in the top bar, with all the fields available for filtering:



The following filters are available:

  1. Timeframe - by default the Forensic logs are filtered for 24 hours. You can provide specific timeframes to filter the events. The maximum timeframe available is 7 days.
  2. Request Id - Each user request is ‘stamped’ with a Request ID. The request id is available in the error pages and enables tracking the actual request which was blocked.
    For example - when a user receives an access denied error message, the request id is available in the error page:

    You could then use the request id to search the specific event in the forensics page and identify the reason why the access has been denied:



  3. User - searching by a specific user, or an API client. You could use use a free text search by typing a text and then selecting the ‘Filter entities starting with prefix:
  4. Application - searching by a specific application. You could use use a free text search by typing a text and then selecting the ‘Filter application starting with prefix:’
  5. App Type - filter events by specific type such as Web, SSH, RDP or TCP applications.
  6. Event Type - filter by access, activity, key management or any other event type.
  7. Result - Filter by successful or failed events.
  8. HTTP response code - search by specific HTTP status codes. Multiple status codes can be entered, separated by a comma

Attachments

Powered by Wolken Software