U2 Businesses Need Audit Logging to Protect Their Assets
May 3, 2017
AUDIT LOGGING FOR ROCKET UNIVERSE 11.3.1 & UNIDATA 8.2
WHY YOUR BUSINESS REQUIRES AUDIT LOGGING
Hardly a day goes by without hearing headline news of IT security breaches. Since your business’s lifeline depends on computerized systems, IT system security has become increasingly vital to enterprises, big and small. Knowing what’s happened and what’s going on inside your enterprise information systems, as well as providing an audit trail to prove it, is not only required by internal operational procedures, but also, for some industries and businesses, is mandated by governmental or industry regulations and standards. In fact, in the US several regulations such as HIPAA, SOX, and industry standard PCI-DSS all have specific requirements for Audit Logging. In European and other countries there are similar standards and regulations.
Audit Logging is an automated system that chronologically records who did what to which system resource and when. IT must spend the time up front configuring audit logging to ensure your organization realizes all of the benefits:
- Accountability via indisputable evidence that someone accessed or modified certain system objects or performed certain actions on the system.
- Reconstruction based on chronologically generated log data that you can use to reconstruct events before, during, and after certain instances trigger a security audit.
- Active Monitoring of events happening on the system. This can help detect and investigate active intrusions.
- System Problem Pre-warning on security or resource usage problems to alert sysadmin to take pre-emptive actions.
INCORPORATE AUDIT LOGGING INTO YOUR SYSTEM OPERATIONS
U2 Audit Logging provides a set of powerful yet flexible features to allow you to build a secure and compliant audit logging solution. It must be emphasized that Audit Logging is only part of the solution as databases are only part of your whole infrastructure. In order to further satisfy your enterprise’s operational, security, and compliance needs, there are other factors that you must consider for a complete audit logging solution. For example:
- How will you log activities outside of the U2 system?
- How much or how little should you log?
- Where should you store the audit log files – on the same system as the database servers or on a separate system?
- What are your log file rotation/switch/backup/retention policies?
- Do you need to periodically examine the audit log or do you review it only after instances happen?
- What’s the best size for system buffer, output block, or sequential log file?
The answers to these questions are often based on your specific compliance requirements and internal policies, as well as benchmarks on your actual system.
By working across the stakeholder teams within your organization (development, IT, management, etc.) you can design a comprehensive audit solution for your business. Rocket Support and Lab Services are always available for questions and assistance.
U2 AUDIT LOGGING QUALITIES
Audit Logging was initially released in Rocket UniVerse 11.2 as a separately licensed component. Based on customer feedback over the years and our own research, we have implemented several important enhancements to Audit Logging in UniVerse 11.3.1 and will be introducing this valuable set of features with UniData 8.2.0. U2 Audit Logging has evolved and been refined with the following design attributes:
Comprehensive – Can record a wide variety of system, data access, or user level activities, ranging from client log-on, session start, command or utility execution to data access or queries. Security-related operations, such as ADE key creation, file encryption, or SQL grant/revoke operations can all be logged.
Flexible Configuration – Can be configured through the uvconfig (udtconfig) file and the new u2audit.config file. The former contains parameters to control the location and type of audit log files, among other things; while the latter contains global and event-specific audit policies and controls including which events should be logged. There are a dozen or so pre-defined system and data events, each of which can also be further configured to generate log records based on user, process, executable, BASIC program, file, or other restrictions. These configurations can be changed through the audman utility and take effect immediately for all existing or new UniVerse/UniData processes, without restarting the system.
Easy to Customize – There are three different log file types, each with its own primary benefit.
- Sequential Logs – have the best throughput and the least impact on system performance when Audit Logging is enabled
- Dynamic Hash File – can be queried using native commands, making reporting easy
- Syslog (for UNIX and LINUX systems) – has the unique capability to send the log records to a remote system, for increased security of the audit logs by storing them off premise.
You can configure the number of concurrent log files (hash or sequential). This can sometimes improve the audit logging efficiency even further.
Easy to Maintain – Although by default Audit Logging is automatically started with the UniVerse/UniData system, you can temporarily disable Audit Logging and resume it later. These capabilities allow you to customize the usage of Audit Logging to your enterprise’s unique security procedures and requirements. You can manage all aspects of Audit Logging through XAdmin or the command line utility audman.
Embedded Security – Since Audit Logging is a security component of UniVerse/UniData, its own security is vitally important. If an audit log can be easily compromised from outside without being traced, the integrity and therefore the value of that system is completely lost. With that in mind, we implemented several measures to ensure its security:
- The u2audit.config file is an encrypted file, editable only through privileged utility* audman, the invocation of which is itself logged.
- The hash log files are protected against user-level write access, so its contents cannot be modified by any BASIC or TCL/ECL commands.
- The sequential or syslog files are created to be accessed only by the privileged Audit Logging process.
- All actions related to managing the audit logging system itself are unconditionally logged by the audit logging system.
- If you want to protect the log file stored on disk from peering eyes, you can turn on the log encryption, which will encrypt all log data using a standard strong encryption algorithm.
Performant – For highly audited systems, we recommend using the sequential or syslog log types. Depending on your applications, sequential log types can significantly improve the audit logging throughput and minimize the performance impact to your application.
AUDIT LOGGING COMPONENTS
Configuration
The uvconfig/udtconfig files contain several audit logging related parameters, all prefixed with AUDIT_LOG… and with defaults chosen to suit general customer systems.
The u2audit.config file is stored under the $UVHOME or $UDTHOME/sys directories. When initially installed, it contains only a few default global policies with no use-settable events turned on. You must manually configure this file to enable user-settable audit logging.
Log file location
By default, all audit related files are created under the $UVHOME/audit or $UDTHOME/audit directory, and usually has the following sub-directories or files:
u2audlog1 – default dynamic hash log file
seqlogs – directory to store sequential log files
lrgrecs – directory to store log records whose size exceeds the system buffer size
staging – temporary location for log records generated by standalone utilities
config – directory to store u2audit.config file versions that were changed by audman –config
Audit Logging daemon
A new daemon process uvaudd(udaudd) will be started by the startup script if audit logging is properly licensed. It will always run, even if you configured the log type to be a hash file. Running the showuv or showud utility should display all running daemon processes including the new audit logging daemon.
The audit logging daemon’s task is to take log data from the system audit buffer and write it out to a sequential log file or syslog. It is a multi-threaded daemon capable of running up to 8 writer threads to concurrently write out log data. The daemon can be stopped and started without restarting UniVerse/UniData – of course, if you stop the daemon while log data is being continually produced, eventually the system buffer will fill up and the U2 sessions won’t be able to continue.
Status and error log files
When the audit daemon is running, it produces status and error messages to two log files:
uvaudd.log – Contains status messages indicating various actions happening inside the daemon
uvaudd.errlog – Contains error or warning messages indicating that you may need to take action to intervene
Audit management utility – audman
To change audit policies or manage audit logging behaviors you will need to run the new audman utility (most of the tasks can also be done through XAdmin).
Audman is a powerful utility that can manage many aspects of the audit logging system. Some examples of the command execution are listed below:
Check audit logging status (log type, number of log files, if encryption is turned on etc.)
audman –logstatus
Check system buffer status (for log type sequential and syslog)
audman –bufctrl –bufstatus 2
Edit configuration policies
audman –config
Display current configuration policies
audman –config –display
Disable/enable audit
audman –disableaudit (-enableaudit)
Start/Stop audit daemon
audman –server –start (stop, restart)
Force to switch a sequential log (e,g. for buffer #0)
audman –bufctrl –switchlog 0
Change the file switch time window (to 1 hour)
audman –bufctrl –seqfileswitch 3600
AUDIT LOGGING POLICIES
For Audit Logging, a UniVerse/UniData system is a collection of resources, such as files, programs, commands, or utilities. When a resource is accessed or invoked it triggers an event. Whether or not the event gets logged depends on the audit policies you specify in the u2audit.config file.
There are two types of policies: global policies and event policies. Global policies control system-wide audit logging behaviors, such as what happens when an audit logging-related error occurred, whether to log all activities of privileged users, how to record file path or program execution stack, etc. Event policies specify event-specific actions. They are the most important means to define your audit logging behavior.
There are three top-level event classes: SYSTEM, DATA and USER. For SYSTEM and DATA, there are also refined sub-classes, such as SYS.COMMAND, SYS.LOGON, SYS.SESSION.START, DAT.QUERY.COMMAND, DAT.BASIC.READ, DAT.BASIC.WRITE, etc., which track a set of specific actions. You can restrict the logging further by specifying a user, process, program, executable, or file policy to log only activities satisfying the restriction policies. For example, you can specify that only when user X reads file Y from program Z a log record is created.
The USER event class deserves further discussion. To generate a USER event, a new BASIC function AuditLog() must be called, which provides log data to the audit system so that a user-generated log record is written into the system audit log file, with the same format of system-generated records. This provides a powerful interface for your application developers to do application-specific pin-point audit logging.
The policy configuration file can be changed only through the audman utility or XAdmin. The change can take effect immediately without restarting the system. This capability can be useful if you want to actively monitoring certain events on a system. For stronger security, you can add a password to protect the configuration file. Without the password, no one can further change the configuration.
WHAT’S NEXT FOR YOU?
Based on existing customer’s experience with U2 Audit Logging, we suggest you take the following actions:
- Know the features
Audit Logging is comprehensive and very customizable. Read the manual to familiarize yourself with all the options.
- Hands-on
Start by adding a few audit policies and observe the result to see if it conforms to your expectation. Gradually making configuration changes to approximate your production.
- Benchmark
Once you are comfortable with the configuration, configure it as you would run with your production. Run your heaviest load. Make sure the performance and log space consumption meet your needs.
- Monitor and tune with production
Always be alert to the changing needs of your system. Make sure Audit logging performs accordingly.
Of source, Rocket U2 Support and Lab Services are always there, ready to help you with any questions or problems during your journey with using U2 Audit Logging.
*A “privileged utility” is a program run by a super user (root or Administrators)
