What is included in Awingu’s extensive auditing capabilities?

Awingu admins have access to the Awingu Dashboard.

The Awingu dashboard gives a live overview of ‘activity’ (what application sessions are active for each user), ‘application overview’ (what applications & servers are provisioned), ‘Insights’ (e.g. what is the usage for the applications), Audit & Anomalies.

In this FAQ we’ll focus solely on the usage audit log.

1. Where is the log stored?

The data of this audit log is stored on the Virtual Machine where Awingu is hosted. Awingu will keep the log on the virtual appliance for 13 months. You can export the log in .csv format. The information is stored in near real-time (there are some database look-ups which might create a few seconds delay)

2. Who has access?

This information is only available to users with admin credentials. In case of a multi-tenant environment, only tenant admins get to see the audit log for their specific tenants. Obviously they won’t get to see audit logs of other tenants.

Superadmins (that manage the total Awingu platform) can get access to audit logs from individual tenants.

Note: there is an admin change log available in ‘system settings’ (not in the dashboard) which logs all changes and activities from the admin within the system settings.

3. What information is logged?

The information is classified in multiple categories (users sessions, applications, sessions….). population of each category will be based on the setup of your organization (e.g. if you don’t have any file shares connected, then the files audit log will be empty).

The audit log will keep track of the following fields:

• • • User sessions: start of session | end of sessions (time of logout) | Awingu domain (/tenant) | user session ID * | IP address | user name | labels (ie. The Awingu rights of the user at that particular time) | location (estimated geo location based on IP address)
    • Application sessions: start of session | end of session (time of logout) | Awingu domain (/tenant) | Client session ID | application session ID** | user session ID* | client session numeric ID | application key | server | port | exe (what applications) | recorded (was this session auto-recorded or not)
    • Shared application sessions: start of session | end of session (time of logout) | Awingu domain (/tenant) | Client session ID | application session ID** | client session numeric ID | IP address
    • Web applications: Timestamp (only a start of session is known to Awingu) | Awingu Domain (/tenant) | User Session ID * | Name (of the web application) | URL | behind reverse proxy
    • IdP Sessions: (In case SaaS applications are started via Awingu’s workspace; both when Awingu is used as IdP, and when an external IdP is configured in front of Awingu and the application is started from within the workspace); Login time (only a start of session is known to Awingu) | Awingu Domain (/tenant) | Service Provider Name (the name of the external IdP in case external IdP is used) | Username | User Session ID * | Assertion Consumer Service | Request Issuer | Request ID
    • Shares: (when sharing files via Awingu); Timestamp | Awingu Domain (/tenant) | User Session ID * | IP address (= IP address of the client that created/updated/deleted/accessed the share) | country | Action (e.g. create a new share, Access, delete, update | Name (of the shared file) | Drive | Path (on the file share) | Created By (user) | Expires (expiry date of the share | ID | Public (true or false) | Mode (download or preview) | checksum | Range (only if ‘preview’ is chosen; range of bytes downloaded)
    • Files: important: this audit log only keeps track of application movements via Awingu files. It an application is opened via a published application or directly on the file server, Awingu will not be able to log these activities; Timestamp | Awingu Domain (/tenant) | User Session ID * | Action (e.g. create a new share, Access, delete, update | Drive | Path (on the file share) | Destination Drive | Destination File Path

Note: for compliance reasons, the admin will need to make a deliberate match between the user session and the application / file /… session (using the user session ID* key or the application session ID**) if he wishes to get insights into, for example, what files a user opened or deleted.

Note 2: Awingu does not log key strokes or activity ‘within’ the application. Awingu however does offer the possibility to record full sessions. This needs to be activited by the admin. End-users will get a notification message prior to starting the recorded session, and, need to accept the recording before entering the session.

Note 3: Awingu ‘anomaly’ detection goes one step further and takes the information from the audit log and will test for a set of pre-defined anomalies.

How can you do a look-up?

Let’s take a simple example in which you need to look-up what applications a user opened, what files he opened (via Awingu files) at what point in time, and from what location

1. 1. 1. Look up the used based on username in the “user sessions” log, copy the ‘user session ID’; based on this search you will have insight in the assumed location (based on IP address) of the user when starting his Awingu session (when he logged into Awingu)
      2. Query the “user session ID” in the “application sessions” log. Here you will find what applications (see “exe”) the users opened (and closed) at what time
      3. Query the “user session ID” in the “Files” log. Here you will find what file actions were performed on what path (e.g. download, open,…)