The number of days that audit events are retained in the database is configurable on the Audit Events page when logged in using an administrator or Fallback account.
To set the number of days to retain audit events in the database
|
Caution:
Making changes to this setting after auditing has begun will affect the events currently stored in the database. If the new number of days is less than the previous number of days, all auditing information currently stored in the database which does NOT fit within the new range will be permanently deleted. Resetting the number of days back to the previous setting will NOT undo the deletion. If the new number of days is greater than the previous number of days, all events currently in the database will follow the new retention setting. Please note that this is a background task which may take some time. Depending on the number of audit events in the table and the length of time the Auditing page has been open, some of the audit events appearing in the audit events table may no longer exist. You need to refresh the page to ensure that the displayed audit events accurately reflect the events stored in the database. |
The Audit Settings dialog appears. In the Retention Days field, enter the number of days to retain the audit events. Entering 0 retains all events indefinitely, otherwise there is a maximum of 1095 days. By default, this is set to 90 days.
|
NOTE: Keep in mind that the longer the amount of time, the more space these events will require in the database. |
A confirmation dialog appears. Click the Save button.
A loading screen is displayed while the changes are made. Once the loading screen closes, the changes are in effect and all auditing information currently stored in the database which did NOT fit within the new range will be deleted.
Refresh the page to update the audit events table.
|
NOTE: It may take additional time for the audit events table to reflect the changes to the database. |
The following procedure explains how to view a detailed explanation of the conditions that were evaluated during an audit event.
|
NOTE: In some cases, if the user fails to enter valid credentials the authentication event message notes that it was a failed authentication and there will be no event details nor associated risk score event for the access attempt. |
To display details for an individual audit event
From the Reports page, click Auditing to open the Auditing page. By default, the audit events for the current day are displayed.
The following types of audit events appear:
Click a risk score event to open a panel displaying the details about the event (see Filtering the audit events for information on locating a specific event and/or an event from a previous date). By default, this panel displays the conditions and any associated modifiers which were triggered during the access attempt. The score listed to the right of the condition name is the score assigned to the triggered condition with any triggered modifiers also taken into account. Use the expand properties button (right arrow) to the left of a condition name to view the modifiers that were triggered marked with an icon depicting their effect on the condition score ( for increased, for decreased, and for no effect).
Switching the Conditions filter to Show All displays all conditions and modifiers that were monitored during the access attempt regardless of whether they returned true or false.
The following procedure explains how to download a summary of the audit events information.
To download audit events information
From the Auditing page, you can create overrides for users that are receiving high risk scores. For example, if a user is on a business trip they might be triggering conditions due to their change in location, time of access and as a result their risk score would increase. And if their risk score is too high or they are unable to provide secondary authentication, an override can be created for the user which means the Security Analytics Engine returns a risk score of zero for the user. To avoid allowing a malicious user access to applications, only create an override when you are positive the user is legitimate.
|
NOTE: After being created, policy overrides can also be managed on the Policy Overrides page. See Policy Overrides page for more information. |
|
NOTE: In cases where overrides have been disabled for a risk policy, the risk score will always be reported regardless of whether there is an override in place for the user. |
See the following sections for more information:
© ALL RIGHTS RESERVED. Conditions d’utilisation Confidentialité Cookie Preference Center