Netcool/OMNIbus security audit log of privileged users

Body

Netcool/Omnibus has been shipping with auditing features for a number of releases:

• In a previous blog we discussed how we could make us of the default ObjectServer audit triggers to track changes made to the configuration of the ObjectServer. Although that mechanism does track who did what and to whom, it does not capture the exact command that was used.
• The existing security audit log specified via the Sec.AuditLog property, writes out internal object codes and application codes which users do not always find easy to decipher.

In Netcool/OMNIbus 8.1.0 Fix Pack 12 we delivered an enhancement (APAR IV94895) to address the above issues. The ObjectServer can now be configured to create a dedicated log of all the SQL commands executed by select user groups.

Example

To produce a dedicated audit log of everything that users belonging to the Administrator and/or System group do, the following properties can be set to:

As indicated by the comments in the above settings, we are using the default settings for both Sec.AuditSqlLog as well as Sec.AuditGroups. If both satisfy your requirements all that may be required to activate the SQL audit log would be to set the Sec.AuditLevel property to ‘info’.

These are all READONLY properties that cannot be altered after the ObjectServer has started. This is done to prevent powerful, but malicious users, from turning off the audit logging before doing deliberate damage to the environment.

An example of the log content that the above settings would create is:

2017-01-31T16:29:25: Information: D-OBX-105-010: Client language command on connection ID 1: [super][isql][][testhost.company.com] [create user 'ben' full name 'Beta Tester'

].

. . .

2017-01-31T16:29:25: Information: D-OBX-105-010: Client language command on connection ID 1: [super][isql][][testhost.company.com] [alter group 'Testers' assign members 'ben'

].

. . .

2017-01-31T16:29:25: Information: D-OBX-105-010: Client language command on connection ID 1: [admin][isql][][testhost.company.com] [update alerts.status set Manager='Test' where Node='testnode'

].

. . .

2017-02-01T11:39:48: Information: D-OBX-105-010: Client language command on connection ID 1: [admin][Administrator][][devtest42] [select GroupName,IsEnabled from catalog.trigger_groups].

. . .

2017-02-01T11:51:19: Information: D-OBX-105-010: Client language command on connection ID 1: [admin][nco_osreport][][testhost.company.com] [select DataType, IsPrimaryKey, IsHidden, IsNoModify, IsNoDefault, ColumnName, Length, ColumnName from catalog.columns where DatabaseName = 'security' and TableName = 'owners' and IsSystem = 0 order by OrdinalPosition;].

You’ve probably noticed that the format of the above log looks the same as a normal ObjectServer debug log. That is because it is the same format.

The advantage in using this dedicated log is that

•        the log can be produced without the requirement to constantly run the ObjectServer at debug log level, then scraping the required log entries from it, and
•        this is a separate log that can be archived on its own.

Warning

• Some client programs that connect to the ObjectServer, such as Netcool/Impact and Netcool/WebGUI, need to use accounts that belong to the System user group. They generate vast numbers of SQL commands. The online user documentation contains hints and tips on how to mitigate against flooding the logs with commands coming from some such clients.

• The existing Sec.AuditLevel property controls the log level of both the existing Sec.AuditLog and the Sec.AuditSqlLog. If one of the two logs is not desired, simply setting the unwanted logfile property to an empty string “”, will suppress logging to that logfile.

Further Reading

• Defining and following an audit trail
• Implementing authorization by using groups and roles
• Netcool/OMNIbus ObjectServer Audit Triggers