Managing Audit Logging

Audit logging is a feature in which every access to LightWave Server can be logged to a file or EMS collector in order to support security auditing. Audit logging is optional – it can be completely disabled, or selectively enabled for specific events or for specific objects. Additionally, logging can be restricted to 'failure' event outcomes only.

Audit Log Record Contents

Each audited event generates a single log record. Each log record contains the following standard information:

a timestamp
the NonStop system name
the NonStop process name for LightWave Server
the object involved
the action attempted
the outcome (success, failure)
the remote IP address
the remote username
object- and/or event-specific details

Audit Objects

object name	description
default	wildcard; see below
acp	Access Control Policy
api	API
apidoc	API Swagger/OpenAPI
audit	Audit settings
certificate	Certificate
csr	Certificate Signing Request
DDL	DDL
diaglog	Diagnostic log
diaglog:settings	Diagnostic log settings
dialog	Pathway dialog
dictionary	Dictionary
group	Group
httplog	HTTP log
httplog:settings	HTTP log settings
identity	Identity management
intermediate	Intermediate certificate
process	SERVER or SWORKER process
profile	User profile
service	User-defined service
session	Console user session
transaction	TMF transaction
type	Type subsystem
user	User

Audit Actions

action	description	example objects
default	wildcard; see below	all
access	non-specific access attempt	all
control	begin, commit or abort	dialog, transaction
create	create an object	acp, api, csr, dictionary, group, user, service, ...
delete	delete an object	acp, api, diaglog, dictionary, group, user, service, ...
execute	execute	api, service
export	export an object	api, dictionary, service
import	import an object	api, certificate, dictionary
install	install an object	certificate
list	get list of objects of some type	acp, api, dictionary, group, user, service, ...
read	read the details of an object	acp, api, apidoc, dictionary, group, user, service, ...
redeploy	redeploy an object	service
renew	renew an object	certificate
start	start an object	audit, process, session
stop	stop an object	audit, process, session
takeover	takeover from backup	process
update	update an object	acp, api, dictionary, group, user, service, ...

Audit Logging Configuration

Audit logging is configured in an EDIT file named AUDITCFG located in the same subvolume as the SERVER and SWORKER executable files. A default AUDITCFG file is supplied, with the setting enabled=0, meaning audit logging is disabled.

Since audit logging is intended to produce an audit trail for security purposes, the AUDITCFG file should be secured such that only authorized employees may edit the file.

The general format of AUDITCFG is:

[audit]
enabled={ 0 | 1 }
appenders= <appender-name> [, <appender-name-2>] …
monitor=<seconds>

[<appender-name>]
<log-appender-settings>
<audit-rules>

[<appender-name-2>]
<log-appender-settings>
<audit-rules>

enabled is the global setting for audit logging. If not set to "1", audit logging will be disabled.

appenders is a comma-separated list of 'log appenders'. Each log appender specifies a destination for logging events, (such as a file, or the NonStop Event Management System (EMS)) and one or more 'audit rules' that specify which audit events should be written to the destination and under what conditions they should be written. There can be multiple simultaneous appenders with destinations and audit rules. See ... for a description of <log-appender-settings>.

monitor is the interval at which the AUDITCFG file should be checked for updates and automatically take effect. The value is specified in seconds. A value of 0 disables monitoring. Small values for monitor may impact peformance – a value of 15 or greater is recommended.

Audit Rules

The general form of <audit-rules> is:

audit-<object>-<action> = { on | off | fail }
audit-<object>-<action>-severity = <severity-level> [, <failure-severity-level> ]

...

Where <object> is an auditable object type, e.g. user, session, process, etc. and <action> is an action that may be attempted on that object, .e.g. start, create, read, update, delete, etc. Any combination of object and action may be specified, however, there are many combinations for which events are not generated, e.g. audit-process-read.

With { on | fail | off } , ‘on’ specifies that both ‘success’ and ‘failure’ events should be logged, ‘fail’ specifies that only ‘failure’ events should be logged, ‘off’ specifies to no events should be logged

<severity-level> is a value 1, 2, or 3 that is logged along with the event. When <failure-severity-level> is also specified, <severity-level> is used with ‘success’ events and <failure-severity-level> is used with ‘failure’ events. It is up to the user to assign/interpret 1 as the highest or lowest severity. If not specified, a value of 2 will be used.

Events and Rule Matching

LightWave processes generate events in the form <object>-<action>-<outcome>, where outcome is 'success' or 'failure', for example: session-start-failure or user-update-success. When an event occurs, LightWave looks for an audit rule that matches the event's <object> and <action>. Then, the <outcome> of the event is evaluated against the matching audit rule's setting (on, off, fail) to determine if the event should actually be logged to the log destination (e.g. file). In the absence of a matching rule, the 'off' setting applies.

Default Action, Default Object

There is a special <action>, ‘default’, that is treated as a wildcard, and is used when no more specific rule has been specific. Likewise there is a special <object>, ‘default’, that is treated as a wildcard and is used when no more specific rule has been specified. (The <action> default takes precedence over the <object> default.). Combining the two defaults, i.e. audit-default-default, creates a wildcard rule used when no specific, default action or default object setting has been specified.

For example, given the following entries:

TEXT

[my-appender]
audit-default-default=off
audit-session-default=on
audit-default-start=fail

If a 'session-start-success' (i.e. logon) event occurs, because there is no specific rule audit-session-start, the setting for audit-session-default, ‘on’, applies and the event would be logged.

If a 'process-start-success' event occurs, because there is no specific rule audit-process-start, and there is no audit-process-default rule, the setting for the audit-default-start rule, ‘fail’, applies and the event is not logged, though it would have if it had been a process-start-failure event.

If an 'api-execute-failure' event occurs, because there is no specific rule audit-api-execute, nor a rule audit-default-execute, nor a rule audit-api-default, the audit-default-default rule setting, 'off' applies, and the event is not logged regardless of the event outcome. Had the audit-default-default rule also been absent, the effect would be the same – if there is no matching rule, 'off' is assumed.

With regard to the audit-api-execute rule, “success” means that LightWave successfully processed the request and returned a reply, not that the api itself succeeded.

Audit Log Format

CEF Format

The audit log output format CEF is the “Common Event Format”. See (https://kc.mcafee.com/resources/sites/MCAFEE/content/live/CORP_KNOWLEDGEBASE/78000/KB78712/en_US/CEF_White_Paper_20100722.pdf) for details.

Examples

Update Events

When an update event occurs (for example, user-update-success), the CEF extension will contain a key, "journal", whose value will be a list of updated object properties in the form property-name: old-value -> new-value, property-name: old-value -> new-value, ...