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.
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:
[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
CEF:0|NuWave|LightWave|1.6|process-start|process-start-success|2|phs=\\ATC.$S0400 start=2018-03-06T16:29:17Z cat=LWS-PROCESS object=\\ATC.$DATA13.LWS.SERVER caid=(29,2) paid=(29,2) filesystem=$DATA.LWS
CEF:0|NuWave|LightWave|1.6|user-update|user-update-failure|2|phs=\\ATC.$S0400 start=2018-03-06T21:41:22Z cat=LWS-PROCESS src=173.162.164.177 suser=admin method=POST request=/lightwave/api/v1/console/identity/user/4 message=malformed request
CEF:0|NuWave|LightWave|1.6|user-update|user-update-success|2|phs=\\ATC.$S0400 start=2018-03-06T21:41:49Z cat=LWS-PROCESS src=173.162.164.177 suser=admin user-id=4 password-change=false journal=name:John->Jean-Luc
CEF:0|NuWave|LightWave|1.6|session-start|session-start-failure|3|phs=\\ATC.$S0400 start=2018-03-06T21:58:36Z cat=LWS-PROCESS src=173.162.164.177 suser=anonymous method=POST request=/lightwave/api/v1/console/session message=invalid credentials
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, ...