Audit Log

Introduction

The Audit Log feature is available from version 8.2 and above.

The Audit Log enables you to see:

  • Changes made to ControlUp’s configuration settings, such as adding a new hypervisor.
  • Remote operations performed on managed assets through ControlUp, such as rebooting a virtual machine or killing a process on a managed computer.

The Audit Log does NOT collect information on setting changes to personal preferences, such as column presets, and any user management activities, such as user signing in/out.

These logs are primarily used in corporate environments. The audit log uploads data to the ControlUp cloud or can be configured to save to a local SysLog server. The Audit Log is by default, configured to enable centralized auditing in hybrid cloud environments.

Auditing Methods

Group Actions

The auditing is carried out separately for each OBJECT on each TARGET and includes all details and completion status for each audit log entry.

Auditing Optimizations

The initialization and completion records carry only the relevant data to save storage and traffic.

The initialization record contains all data except the output, while the completion record contains the output, status, and the error message if the action failed. 

In the case of mass/group activity in public configuration, we have separate 'initialized' audit log entries for each object and one common 'completion' entry for all objects in the group because in such case the action is completed successfully for all objects or failed for all objects.

The Audit Log documents up to ten automated action executions, per trigger, per minute in the organization. If the number of executions exceeds the limit, the automated actions run without auditing, even if the enforced mode is enabled.

The following audit log entry is added to document the exception in CA: 
"The amount of audit log entries generated by the trigger exceeds the permitted limit and will be silenced for a while."

Storing the Audit Logs

The Audit Logs may be stored in the following ways:

  • ControlUp cloud: This is the default configuration for hybrid cloud environments. Once support for the cloud data-store is implemented, it is possible to view an audit log report in SOLVE. The data is retained in this log for a period of a year after it was first recorded. This option is NOT available for on-premises implementations.
    For complete information on viewing Audit Logs, see here.
    The following is an example of the Audit Log stored in SOLVE.
    mceclip2.png
  • SysLog: The contents of the SysLog data-store can be viewed using any standard SysLog reader (e.g. Splunk). On-premises implementations can only store audit logs on their SysLog Servers.
    The following is an example of the Audit Log stored on a Syslog Server.
    mceclip1.png

Actions are reported in the Audit Log as two separate entries; once for initialization of the action and once for completion of the action. 

Audit Log Settings

Only the organization owner can modify the audit log settings. The organization owner is displayed and managed in the Security Settings pane in the consoled.

Go to the Audit Log tab by clicking Audit Log from the Settings ribbon and the Audit Log page appears.

mceclip0.png

  • Enable Centralized Auditing - For enabling/disabling the audit log data-storage in the hybrid cloud environment.
    • Fail action if auditing fails - Enforced mode. Prevents actions from being executed if the auditing was not completed properly. Not available in SysLog.
  • Send to SysLog Server -Enables you to save the auditing records to a SysLog server by entering its:
    • IP/hostname - Enter the IP address or hostname of the SysLog server.
    • Port - Enter the port to use to connect to the SysLog server.
    • Protocol Select the protocol to use to connect to the SysLog server – UDP or TCP

Once you have finished making changes to the settings, click Apply to save the changes or OK to save the changes and close the window.

Audit Logs Data

For each entry in the audit logs, the following information is stored: 

Item

Description

ActionId

The ID of the performed action. All audit entries related to the same event have the same unique identifier.

This is a hidden field but is essential for matching between the initialized and completed entries.

GroupId

The ID of an event performed as a group. All audit entries related to the same grouping-command have the same grouping unique identifier.

This is a hidden field but is essential for matching records that belong to the same group-command.

Date

Date and time of the event.

Origin

The source of the event (Web client, Console, PowerShell, automated action, Insights, etc.).

Status

The status of the event (initiated, completed, aborted, error, etc.)

Requesting Computer

The hostname or IP address of the computer from which the event was initiated. This can be:

  • The computer used.
  • The console, if the user performed an action from the console.
  • The monitor where the AA/cmdlet was executed.
  • The SOLVE/Insights (if available) if an action was performed manually from SolVE/Insights.

Requesting User 

The user account of the user who initiated the event.

Credentials

The user account that was used to execute the command.

Note: If this is the same as the Requesting User, this field is left blank.

Activity

The type of action that was performed (kill a process, add a computer, etc).

Details

Additional information that is specific to the command.

Object Type

The type of object on which the command was executed.

Output

The output of the operation.

Executing Computer

The name of the object on which the command was executed (computer hostname, hypervisor name, Netscaler name, organization name, username, etc).

 

Powered by Zendesk