HP HP-UX Auditing System Extensions White Paper

Page 1

HP-UX 11i v2 and 11i v3 Security

Configuring and Managing the Auditing System

Technical white paper

Table of contents

Audience............................................................................................................................................ 2

Introduction......................................................................................................................................... 2

Auditing system overview ..................................................................................................................... 3

Architecture..................................................................................................................................... 3

Audit tags ....................................................................................................................................... 5

Audit trail........................................................................................................................................ 5

Audit events .................................................................................................................................... 5

Audit tunable parameters (HP-UX 11i v3 only) ..................................................................................... 7

Self-auditing programs...................................................................................................................... 7

Auditing system extensions (HP-UX 11i v3 only) ................................................................................. 13

HP-UX Auditing System Administration.................................................................................................. 14

Installation..................................................................................................................................... 14

Configuration ................................................................................................................................15

Management................................................................................................................................. 18

Writing a DPMS service module .......................................................................................................... 19

Service Provider Interfaces (SPIs) ...................................................................................................... 19

DPMS service module implementation............................................................................................... 19

Best practices .................................................................................................................................... 19

Audit policy................................................................................................................................... 20

Audit generation and capture.......................................................................................................... 20

Audit retention and storage............................................................................................................. 21

Audit log analysis .......................................................................................................................... 21

Audit log configuration, security, and protection................................................................................ 22

Troubleshooting................................................................................................................................. 22

Glossary........................................................................................................................................... 24

For more information.......................................................................................................................... 26

Send comments to HP......................................................................................................................... 26

Page 2

Audience

This white paper is for security administrators responsible for defining and implementing host audit security policies, and for system administrators responsible for configuring and managing HP-UX. This white paper provides guidance to administrators for planning, deploying, configuring, and managing the HP-UX Auditing System features on HP-UX 11i v2 with HP-UX Standard Mode Security Extensions (SMSE) installed and on HP-UX 11i v3 with HP-UX Auditing System Extensions installed. In addition, the white paper provides Best Practices that you can use to address certain compliance criteria. You can compare these settings with your internal security policy and any compliance criteria that must be satisfied.

Note

This paper does not address auditing on a system converted to trusted mode.

Introduction

The purpose of auditing is to selectively record security relevant events for analysis and detection of security breaches. The auditing system records instances of access by subjects to objects on the system, and enables you to detect any attempts to bypass the protection mechanism for objects, including the misuse of privileges. Auditing also helps expose potential security weaknesses in the system. Many regulations, such as PCI, HIPAA, and Sarbanes-Oxley, require some form of auditing.

In the past several years, industry and government oversight of businesses has increased dramatically. Guidelines and laws have been defined that require businesses to protect information and to impose more significant penalties for failure to do so. This protection of information goes beyond internal corporate information and extends to the privacy of customer data and practices for the protection of business operations and infrastructure. Adherence to these regulations is generally referred to as regulatory compliance or, simply, compliance. Businesses must demonstrate appropriate internal IT controls or face penalties for noncompliance. Significant regulatory compliances are as follows:

• Sarbanes Oxley (SOX) – Pertains to protection of public company financial data

• PCI – Pertains to customer credit card information

• HIPAA – Pertains to healthcare information

• Graham Leach Bliley Act – Pertains to financial institutions

• Safe Harbor – Pertains to international privacy protection

• SEC/OCC – Pertains to US financial securities (for example, stocks)

Most of these criteria do not mandate specific security mechanisms or processes, but they define a high level of practices to which businesses must adhere. Businesses must determine appropriate processes and mechanisms to meet the specified practices.

Page 3

Auditing system overview

This section describes the HP-UX Auditing System architecture and provides a high-level description of the major HP-UX Auditing System components. For a complete introduction and overview of HP-UX Auditing System, see audit(5).

Architecture

Figure 1 shows the main user-space and kernel-space components of the HP-UX Auditing System on HP-UX 11i v2 and 11i v3. Components that are only available on HP-UX 11i v3 are labeled.

Figure 1. HP-UX Auditing System Architecture

HP-UX Auditing System consists of commands, daemons, configuration files, data files, libraries, kernel modules, and system calls. The following HP-UX Auditing System components are standard on HP-UX 11i v2 and 11i v3.

Commands

• audsys(1M) — Starts and halts the auditing system, sets and displays the auditing system status

information, and specifies the primary and secondary audit trails and their size switches.

• audevent(1M) — Changes and displays the auditing selection status of profiles, events, and

system calls.

Page 4

• userdbset(1M) — Modifies the per-user AUDIT_FLAG attribute stored in the userdb(4)

database.

• audisp(1M) — Analyzes and displays the audit information contained in the specified audit trails.

For more information, see the corresponding manpages.

System calls

• audswitch(2) — Invoked by privileged programs to temporarily suspend or resume auditing on

the current process; it affects only the current process. This call cannot suspend auditing for processes created by the current process with the exec system call.

• audwrite(2) — Invoked by privileged self-auditing processes to generate higher-level audit

records of their own. These self-auditing processes are capable of turning off the generation of lowlevel (system call level) audit records using the audswitch(2) system call and turning it back on after invoking audwrite(2) to generate a higher-level audit record.

• getaudproc(2) — Invoked by privileged programs to determine whether the calling process is

audited or not.

• setaudproc(2) — Invoked by privileged programs to audit a process or not. For example,

for a new login session, depending on the value of the per-user or per-system AUDIT_FLAG attribute in userdb(4) or security(4) configuration files, respectively.

Daemons

• audomon(1M) — User space daemon that monitors the capacity of the current audit trail (Primary

Audit Trail) and the file system on which the audit trail is located. You can configure audomon to automatically switch to a Secondary Audit Trail when certain capacity limits are met. You can also configure the daemon to run a specified script after each successful switch to perform various operations on the last audit trail, such as running a script to copy the last audit trail to a remote system. For an example, see audomon(1M).

• Audit daemon — A kernel daemon that collects audit records and periodically writes the records to

the disk. On HP-UX 11i v2, the audit daemon is single threaded. On 11i v3, the audit daemon is multi-threaded to improve performance by writing audit data into multiple audit trail files simultaneously.

Files

• audit.conf(4), audit_site.conf(4) — Files containing event mapping information and

site-specific event mapping information, respectively. The audevent(1M) and audisp(1M) commands use these files.

• Audit trail — Audit records are collected in audit files as audit trails in binary format and are

compressed to save disk space. On HP-UX 11i v2, the audit trail is a single file. On HP-UX 11i v3, HP-UX Auditing System is capable of using more than one writer thread to log data to minimize the impact of audit on system performance. Each writer thread writes to one file, allowing an audit trail to be written in parallel by multiple kernel threads and potentially increasing the throughput of the system. As a result, an audit trail is present on the file system as a directory with multiple audit files in it.

• userdb(4) — The user database that contains the per-user AUDIT_FLAG attribute for controlling

whether a particular user is audited.

• security(4) — The security defaults configuration file that contains the per-system AUDIT_FLAG

attribute. This is the default AUDIT_FLAG attribute for those users that do not have a AUDIT_FLAG attribute set in userdb(4).

Page 5

Audit tags

When a user logs in, a unique audit session ID called an audit tag is generated and associated with all audit records for the user's processes associated with that login. The audit tag is a string that includes the login name and the login time, and remains the same during the login session. Even if a user changes identity within a single session, all events are still recorded with the same audit tag and accountable under the original login user's name.

Audit trail

An audit trail contains all audit records in chronological order and provides a complete information trail for display and analysis. An active audit trail must be in use whenever the auditing system is enabled. Access to the auditing system, including the audit trails, is restricted to privileged users.

The Primary Audit Trail is the current audit trail in which audit records are currently being written, while the Secondary Audit Trail is the next audit trail that will store new audit records when certain capacity limits are reached for the Primary Audit Trail. The trail names and various attributes for the trails, such as the capacity limits, are set using the audsys(1M) command.

The audomon(1M) daemon determines when the current trail exceeds a specified size or when the auditing file system is dangerously full. When that occurs, the daemon automatically switches the Primary Audit Trail to the Secondary Audit Trail with the same base name but with a different timestamp extension. You can specify a script when starting audomon(1M) to perform various operations on the Primary Audit Trail that was just successfully switched, such as remotely copying the audit trail to a remote, centralized server for archiving purposes.

For performance reasons, the HP-UX Auditing System on 11i v3 is by default in normal mode in which the audit trail consists of multiple files under a single directory to allow concurrent writing of audit records by the kernel Audit Daemon. You can also configure the HP-UX Auditing System in compatibility mode in which the audit trail is a single file. For information on how to modify the audit trail mode on HP-UX 11i v3, see audsys(1M). For HP-UX Auditing System on 11i v2, an audit trail can only consist of a single file.

Audit events

The auditing system records instances of access by subjects to objects on the system in log files for selective security related system events. Audit events, also known as audit records, are generated when users make security-relevant system calls and when self-auditing programs invoke audwrite(2) to generate self-audit records. Each system call audit record and self-audit record contains the following information about the event:

• Who caused the event (the subject)

– Real and effective user name and process id – Audit session id and audit tag – Name of command executed to trigger the event – Hostname and IP address of source host from where the user logged in

• What is the event

– The event type: a system call event or a self-audit event – The object (for example, file being modified and the user login account) – Action performed on the object (for example, modification of a file’s permissions) – Whether the event succeeded or failed. If it failed, the reason for the failure.

Page 6

• Where the event occurred (host name and IP address of host)

• When it occurred (timestamp)

• Details (for example, system call arguments and self-auditing text)

There are also audit records called version and system call table records that appear at the beginning of each audit trail, and a Process ID (PID) Identification Record for each audited process.

Each of these audit records consists of an audit record header and a record body. The record header comprises a sequence number, process ID, event type, and record body length. The sequence number gives relative order of all records; the process ID belongs to the process being audited; the event type is a field identifying the type of audited activity; the length is the record body length expressed in bytes. The record body is the variable-length component of an audit record, containing more information about the audited activity. The following sections describe each audit record type.

Version records

A version record is at the beginning of each audit trail and indicates the version of the audit subsystem. The audit record structure design might change over time, and the version record directs audit display applications how to interpret the audit trail.

System call table records

The record after the version record in an audit trail is a system call table record that contains kernel system call table information, such as what parameters or additional information are being collected for each system call. The system call table record enables user space applications that process the audit trail (for example, the audisp(1M) display tool) to determine how to interpret binary audit records at run time. This allows these applications to be decoupled from kernel changes (for example, addition of new system calls and addition of new audit information).

PID identification records

When a process is audited the first time, a PID identification record (PIR) is written into the audit trail, containing information that remains constant throughout the lifetime of the process. The PIR includes the process ID; the parent process' ID; audit tag; real user ID; real group ID; effective user ID; effective group ID; group ID list; effective, permitted, and retained privileges; compartment ID; and the terminal ID. The PIR is entered only once per process per audit trail.

System call audit records

A system call record contains system call specific audit data and is unique for each audited system call. The record contains, for example, the time the audited event completes, whether the system call ended in either success or failure, and the system call parameters. Use audevent(1M) to display the system calls that are currently being audited. On HP-UX 11i v2, use audisp(1M) to determine the associated information (for example, parameters and return values) recorded for each audited system call. On HP-UX 11i v3, use auditdp(1M) to determine the information recorded for each audited system call. The audisp and auditdp commands also report Compartments and Fine Grained Privileges (FGP) information on HP-UX 11i v2 and HP-UX 11i v3, respectively. This includes the compartment ID and effective, permitted, and retained privileges of the process.

Self-audit records

A self-auditing record contains high-level auditing data generated by self-auditing programs and Dynamically Loadable Kernel Modules (DLKMs). The record contains, for example, the time the selfauditing process invoked audwrite(2) to write the record and a high-level description of the event. For examples of self-audit records, see Self-auditing programs

Page 7

Audit tunable parameters (HP-UX 11i v3 only)

You can modify the auditing operation dynamically by changing one of the following audit tunable kernel parameters:

• audit_memory_usage — Defines the percentage of physical memory to be used by audit

records. If the audit record memory usage exceeds the audit_memory_usage limit, the audit subsystem blocks the system call until memory usage decreases to within the limit. You can change this tunable value at any time. However, you cannot lower its value below the memory currently used by the audit subsystem for records. Valid values are 1 to 10, inclusive. The default is 5.

• audit_track_paths — Enables and disables tracking of current and root directories for the

auditing subsystem. When audit_track_paths is set to 0, Audit does not resolve absolute pathnames, and HP-UX HIDS is unable to open the device and collect data. This is because HIDS always expects a complete pathname for its purposes.

Setting the audit_track_paths to 1 enables both Audit and HP-UX HIDS to resolve and report absolute pathnames for their accounting purposes. This also causes additional tracking by the kernel, resulting in a small degradation in performance, even if auditing subsystem is not in use. The tunable is set to 0 (default) when the system is installed without HP-UX HIDS. The tunable is set to 1 when HP-UX HIDS is first installed. You cannot change this tunable when either HIDS or auditing is running.

Although not required, HP recommends you reboot the system when changing the audit_track_paths tunable to enable or disable the recording of absolute pathnames. Otherwise, Audit or HP-UX HIDS might not resolve and report absolute pathname consistently.

• diskaudit_flush_interval — Defines the periodic time interval (in seconds) between two

consecutive flushes of audit records buffered in the kernel memory. Set the value of this tunable so that buffers are cleaned when they are approximately half full, or are idle for a long time but still holding some data in the buffer. Keeping the tunable value too low results in flushing too soon and can lead to too many small write operations that can affect performance. On the other hand, keeping the value too high might lead to high unflushed memory consumption. Valid values are 1 to 100, inclusive; HP recommends a value from 3 to 6. The default value is 5.

The kctune command is the administrative command for HP-UX kernel tunable parameters. It provides information about tunable parameters and their values, and makes changes to tunable values. For more information, see kctune(1M).

Self-auditing programs

To reduce the amount of low-level log data and to provide a higher-level recording of some typical system operations, a collection of privileged programs are given capabilities (privileges) to perform self-auditing. Most of these programs generate audit data under a single event category. For example, audsys(1M) generates the audit data under the event admin. Other programs might generate data under multiple event categories. For example, the telnetd(1M) generates data under the events login and ipcopen. For a list of predefined event categories, see audevent(1M).

This section contains a description and list of the self-auditing programs and DLKMs on HP-UX 11i v3 that produce self-audit event records with self-audit text. The event names (in parentheses) indicate the event categories under which the self-audit record is generated.

Note:

The list assumes the installation of AuditExt v3.1 and corresponding patches as specified in the AuditExt v3.1 Release Notes.

Page 8

The list and information is incomplete and might change in the future.

Audit aware

Most self-auditing programs are audit aware. They can suspend the currently specified low-level system call auditing on themselves by invoking the audswitch(2) system call and can produce a high-level description of the operations they perform by invoking the audwrite(2) system call to generate self-auditing events. The audit suspension they perform only affects these programs and does not affect any other processes on the system. The list of audit aware programs is as follows:

• audevent(1M) (admin)

audevent: getting event and syscall status audevent: [disable|enable] [success|failure] for [event|syscall] name

• audisp(1M) (admin)

audisp : argv1 … argvn (for various error conditions)

• auditdp(1M) (admin)

auditdp: argv1 … argvn auditdp: invalid command line auditdp: audit_dpms_write_nevent(3) failed auditdp: audit_dpms_read_event(3) failed auditdp: data has been successfully processed

• audfilter(1M) (admin)

audfilter: argv1 … argvn audfilter: User is not authorized to run audfilter audfilter: Invalid command line options audfilter: Daemon is not started yet audfilter: Request to kill daemon [failed|succeeded] audfilter: Request to load audit filtering rules [failed|succeeded] audfilter: Request to clear audit filtering rules [failed|succeeded] audfilter: Request to display audit filtering rules [failed|succeeded] audfilter: Request to display audit filtering rules in preview mode [failed|succeeded] audfilter: Request to display daemon status [failed|succeeded] audfilter: Request to change daemon’s wakeup period [failed|succeeded]

• audfilterd(1M) (admin)

audfilterd: argv1 … argvn audfilterd: User is not authorized to run audfilterd audfilterd: Failed to raise necessary privileges for audfilterd audfilterd: Failed to access the configuration file /etc/audit/filter.conf audfilterd: Invalid command line options audfilterd: Invalid wakeup period audfilterd: Daemon is already running audfilterd: Daemon status displayed audfilterd: Failed to install signal handler audfilterd: Failed to start the server audfilterd: Failed to fork as a background process: error message

• audomon(1M) (admin)

audomon: FreeSpaceSwitch point reached, audomon has successfully switched auditing to pathname of new audit trail audomon: AuditFileSwitch point reached, audomon has successfully switched auditing to pathname of new audit trail

Page 9

audomon: kernel audit daemon has switched auditing to the backup trail audomon: FreeSpaceSwitch point reached, but audomon failed to switch audit trail audomon: AuditFileSwitch point reached, but audomon failed to switch audit trail audomon: failed to update audit trail configuration information in /etc/audit/audnames:current_trail=pathname of current trail

• audsys(1M) (admin)

audsys: argv1 … argvn audsys: various error condition messages (too many to list here)

audsys: current audit trail directory is changed to pathname audsys: auditing system started audsys: auditing system shut-down

• authadm(1M), roleadm(1M), cmdprivadm(1M) (admin)

ACCESS CONTROL CHECK:successful|failed; username=username; program=authadm|roleadm|cmdprivadm; euid=euid; ruid=ruid; egid=egid; rgid=rgid;

ACCESS CONTROL SUPPRESS:successful|failed; username=username; program=authadm|roleadm|cmdprivadm; euid=euid; ruid=ruid; egid=egid; rgid=rgid;

• chfn(1) (admin)

User= name Temporary file busy (open or lockf of /etc/ptmp failed) User= name No account for user User= Current user No passwd file entry User= name Error in chown (of /etc/ptmp) User= name Error in chmod (of /etc/ptmp) User= name Successful chfn

• chsh(1) (admin)

User= name shell= shell Permission denied User= name shell= shell Temporary file busy (open or lockf of /etc/ptmp failed) User= name shell= shell Can’t create temporary file (/etc/ptmp) User= name shell= shell Can’t recover (can not rename /etc/ptmp to /etc/passwd) User= name shell= shell Chsh failed User= name shell= shell Successfully changed

• dtlogin(1)

User=name uid= user id audid= audit id attempted to login - too many users on the system

User=name uid= user id audid= audit id attempted to login - bad audit flag

User=name uid= user id audid= audit id attempted to login - bad audit id User=name uid= user id audid= audit id attempted to login - bad group id User=name uid= user id audid= audit id attempted to login - bad user id User=name uid= user id audid= audit id Successful login - no home

directory User=name uid= user id audid= audit id attempted to login - no home

directory User=name uid= user id audid= audit id Successful login User=name uid= user id audid= audit id Failed login (bailout)

Page 10

• groupadd(1M) (admin)

Attempt to add a new group failed A new group added successfully.

groupname=name gid=gid group_members=uid list

• groupdel(1M) (admin)

Attempt to delete a group failed A group with groupname=name is deleted successfully

• groupmod(1M) (admin)

Attempt to modify a group failed The group record of groupname=%s is modified successfully

[New_groupname=name] | [ gid=gid] | [New_group_members=uid list]

• inetd(1M)

inetd: Failed setauduser for user username

• init(1M) (admin)

Run level is changed to level Dead process: pid

• lpsched(1M) (open)

File(s) filename(s) was printed for user username @ hostname on printer printer name File(s) filename(s) was not printed for user username @ hostname on printer printer name due to an error.

• newgrp(1) (modaccess)

newgrp=name [Failed|Successful] newgrp newgrp=name setresuid failed

• passwd(1) (admin)

User= username passwd successfully changed User= username shell successfully changed User= username home directory successfully changed User= username gecos information successfully changed Attempt to change <passwd|shell|home|gecos information> failed

• privedit(1M) (admin)

ACCESS CONTROL CHECK: privedit: attempt to edit file: file=’filename’; username=username; program=privedit; euid=euid; ruid=ruid; egid=egid; rgid=rgid;

ACCESS CONTROL CHECK: privedit: failed to edit file: file=’filename’; username=username; program=privedit; euid=euid; ruid=ruid; egid=egid; rgid=rgid;

• privrun(1M) (admin)

ACCESS CONTROL CHECK: privrun: attempt to execute command: command=command; username=username; program=privrun; euid=euid; ruid=ruid; egid=egid; rgid=rgid;

Page 11

ACCESS CONTROL CHECK: privrun: command execution failed: command=command; username=username; program=privrun; euid=euid; ruid=ruid; egid=egid; rgid=rgid;

• setfilexsec(1M) (modaccess)

Could not lock file No passwd entry Memory allocation failed Failed to re-exec the command after initializing FAT Not authorized Failed to raise necessary privileges Could not register exit routine Configuration file update failed for file pathname

• setrules(1M) (admin)

Memory allocation failure Failed to create ipc rules for compartments (filename>, line #) Failed to create network rules for compartments (filename, line #) Undefined compartment cmpt_name referenced in (filename, line #) Conflicting network rule definition between cmpt_name and cmpt_name (filename, line #) Could not create pipe for c-preprocessor Could not create child process Failed to remove privileges in the child process Could not setup pipe communication Failed to exec cpp Conflicting network rule definition between cmpt_name and cmpt_name (filename, line #) Bad IPC rule: rule definition between cmpt_name and cmpt_name (filename, line #) Duplicate compartment definition for cmpt_name (filename, line #) Compartment name too long: cmpt_name Duplicate interface rule for network interface name in compartment cmpt_name (filename, line #) and compartment name (filename Pre processing of rule file filename failed

, line #)

• useradd(1M) (admin)

Attempt to modify template file failed Attempt to add a new user failed A new user added successfully, username=name uid=uid gid=gid shell=shell pathname home_dir=pathname comment=comment audid=audit id inactive=#days expire=date|’’’’

Template file pathname was modified successfully | The defaults file is modified successfully [HOMEDIR=pathname] [GROUPPID=pgid] [INACT=#days] [[EXPIRE] | [EXPIRE=MM/DD/YY]] [CHOWN_HOMEDIR=pathname] [START_PROGRAM=shell path] [SKEL_DIR=pathname] [COMMENT=comment] [CREAT_HOMEDIR=pathname] [ALLOW_DUP_UIDS=yes|no]

• userdel(1M) (admin)

Attempt to delete a user failed A user with username=name is deleted successfully

• usermod(1M) (admin)

Attempt to modify a user record failed The user record of user=name is modified successfully

[New_username=name] [uid=uid] [gid=gid] [home_dir=pathname] [shell=shell path] [comment=comment] [supplementary_groups=gid list] [inactive=#days] [expire=date string]

Page 12

Audit unaware

Some self-auditing programs do not invoke the audswitch(2) system call to suspend system call auditing on themselves, nor directly invoke audwrite(2) to generate self-audit records. Instead, these privileged programs invoke a library routine that generates a self-auditing event on its behalf. For example, telnetd(1M) is a privileged program that invokes the pam_hpsec(5) PAM module for authenticating users. The hpsec PAM module invokes the audwrite(2) system call to generate successful and failed login self-audit events on behalf of telnetd. In addition, a logoff self-auditing event is generated on telnetd’s behalf by a DLKM.

The following self-auditing programs invoke the hpsec PAM module for authenticating users:

• telnetd(1M), rlogind(1M), sshd(1M), remshd(1M), rexecd(1M), su(1), ftpd(1M)

(login,ipcopen)

login event: Service=telnet|login|ssh|ftp User=login_user Status=Successful (login) login event: Service=shell|exec User=login_user Status=Successful

Command="command & args" RemoteUser=remote_user login event: Service=telnet|login|ssh|ftp> User=login_user Status=Failed ("Authentication failed") (login) login event: Service=su User=target_user Status=Failed("Authentication

failed") login event: Service=ftp User=login_user Status=Failed login event: Service=telnet|login User=login_user Status=Failed ("No account present for user") (login) login event: Service=shell|exec User=login_user Status=Failed("Access

denied by ruserok.") Command="command & args" RemoteUser=remote_user Networking service = telnet|rlogin|rexec|shell

Executing login pid = pid.” (ipcopen) Networking service = ftp

Request outcome = success|failure Validation tool = unspecified|passwd Service event = start_of_service|unspecified Remote system = ip address Remote user = username|unspecified Local system = ip address Local user = username|uid|unspecified Login successful. User = username | Repeated login failures. | Failed login attempt - shell not in /etc/shells. | Failed login attempt - name in /etc/ftpd/ftphosts. | Failed login attempt - Anonymous FTP access denied. | Failed login attempt - guest login not permitted. | Failed login attempt - access denied for user. | Failed login attempt - user unknown. | Failed login attempt - user access denied. | Failed login attempt - Kerberos authentication must succeed. |

username|

Page 13

Failed login attempt - login incorrect. | Failed login attempt - anonymous password not rfc822. (ipcopen)

The login event for the Service=su self-audit event is only generated when the pam.conf entry for su does not have the bypass_setaud flag set and when source user is not root. See pam_hpsec(5).

Dynamically Linked Kernel Modules

DLKMs can generate the following self-audit records:

• Command command tried to execute code from stack

• Command command has core dumped

• logoff event: Service=telnet|login|ssh|shell|exec User=login_user (login)

Generated only when AudReport product is installed.

• logoff event SID session_id PGRP process_group PPID parent_pid PID pid

program (login) Generated only when AudReport product is not installed

Auditing system extensions (HP-UX 11i v3 only)

On HP-UX 11i v3, HP-UX Auditing System Extensions extends the features of the HP-UX Auditing System by offering the following features and benefits to better facilitate regulatory compliance:

• Enhanced audit data (for example, program name and source IP address)

• Enhanced filtering capabilities to filter non-relevant data based on customer-specific needs and

improve the quality of the audit trail

• Performance improvement by reducing the I/O activities of logging events that are not required to

be logged

• Enhanced manageability of the audit log data

• Command line interface and a set of open APIs for extracting audit data

• Tools to generate web-based audit reports from HP-UX raw audit data

HP-UX Auditing System Extensions provides two major products for enhanced audit record filtering and reporting.

Audit Filtering

Audit Filtering features are available on HP-UX 11i v3 with the AudFilter product that contains a set of tools to customize and enforce the audit data pre-filtering policy on the system and the audit_filters DLKM that makes filtering decisions and enforces the filtering policy in the kernel. An efficient pre-filtering policy controls the size and quality of the raw data, minimizes the performance impact of auditing, and reduces the operational cost associated with audit data management. The AudFilter product consists of the following major components:

• The filter.conf configuration file that specifies the rule-based audit record pre-filtering policy

enforced in the kernel. For more information, see filter.conf(4).

• The audfilter configuration tool to interpret the filtering policy as specified in the configuration

file, filter.conf, and to implement the policy. You can also use the audfilter tool to display or clear out the filtering policy currently being enforced in the kernel. For more information, see audfilter(1M).

• The audfilterd service daemon handles service requests from the audfilter tool, and

reevaluates and reloads the filtering policy whenever the mounted file system table changes. For more information, see audfilterd(1M).

Page 14

• The audit_filters DLKM makes filtering decisions and enforces the filtering policy in the kernel.

Filtering in the kernel can occur both before and after the invocation of the system call code. See the definitions of system call pre-filtering and post-filtering in Glossary

Audit Reporting

The AudReport product consists of the following components:

• Commands

auditdp(1M) — An audit data processing tool that selectively extracts, or filters, audit data from a data source in one of several possible formats and writes the data to the target, in the same or different format. The tool uses the DPMS framework, and is available only on HP-UX 11i v3 with the AudReport product installed.

• Libraries

DPMS (Data Process Module Switch) — A framework implemented as a library that contains a set of common programming interfaces (APIs) and Service Modules to selectively read and write audit data in various formats (for example, XML Audit Reports).

DPMS provides a layer of separation between applications (for example, auditdp(1M)) that need to extract information from audit data source and the underlying modules that have the knowledge about the internal data format. This framework is primarily designed for HP-UX audit data that the HP-UX system collects (see audit (5)). However, the framework allows service modules to be plugged in to handle the data in any format. With this layer of separation, an application can treat any data using the same APIs by simply applying the service module corresponding to the given set of data. The application does not need knowledge about the internal format of the data to use the information.

For more information on DPMS, see audit_dpms(5). For a description of the various DPMS Service Modules, see audit_hpux_portable(5), audit_hpux_raw(5), and

audit_hpux_xml(5). For a description of the Audit DPMS APIs that applications writers use, see audit_dpms_api(3). For a description of the Audit DPMS Service Provider Interface that a

DPMS Service Module writer must support, see audit_dpms_spi(3). For a description of the configuration file for filtering Audit DPMS data, see audit_dpms_filter(4). For a description of how a DPMS service module is implemented, see Writing a DPMS service module

• Files

One or more configuration files that you can use to select auditing information in the audit trail to include in an audit report. You specify the files using the auditdp –S option. They contain filtering rules that are described in audit_dpms_filter(4).

HP-UX Auditing System Administration

This section describes the basic installation, configuration, and management of the HP-UX Auditing System by the Audit Administrator.

Installation

The features described in this paper assume the following software has been installed, depending on the HP-UX release:

• HP-UX Standard Mode Security Extensions (SMSE) (HP-UX 11i v2)

Previously, the auditing system was only supported on systems converted to trusted mode. By installing the HP-UX Standard Mode Security Extensions bundle, you can now perform audits without converting the system to trusted mode.

Page 15

• HP-UX Auditing System Extensions (HP-UX 11i v3)

The auditing system is installed as part of the base HP-UX 11i v3 distribution. However, Auditing System Extensions bundle must be installed to make use of the AudReport and AudFilter product features.

Both products are available on software.hp.com and have Release Notes on the Business Support Center that contain details about product compatibility, installation requirements, patch requirements, and installation instructions.

Configuration

This section describes guidelines and steps for configuring users for audit, configuring events for audit, and roles.

Configuring users for audit

Users are audited depending on the value of either the system wide AUDIT_FLAG security attribute or the per-user AUDIT_FLAG security attribute. The AUDIT_FLAG security attribute is described in security(4). A user is audited if either of the following conditions is true:

• The user AUDIT_FLAG is set to 1.

• The system wide AUDIT_FLAG is set to 1.

To set the system wide and per-user AUDIT_FLAG values, use either of the following methods:

• userdbset command. See userdbset(1M) and userdb(4).

• HP-UX Security Attributes Configuration tool. See secweb(1M).

The audit user selection policy is based on the AUDIT_FLAG setting for the user responsible for the event. The responsible user is traced back to the original login user, not to the user corresponding to the real or effective user at the moment an event happens. For example, a user logins as user “Joe” and then either executes a setuid program to run as user “Ben” or issues the su command to the target user “Ben.” All events that occur while “Joe” is running as “Ben” are attributable to the original login user “Joe” and are audited depending on the AUDIT_FLAG security attribute for login user “Joe,” not on the AUDIT_FLAG security attribute for user “Ben.” For su(1), you can modify this user selection policy to audit based on the target user (see description of the bypass_setaud flag in pam_hpsec(5)), if su(1) requires the source user to be authenticated and the authentication is successful. Because root does not need to authenticate when invoking su(1), users logged in as root are always audited as user root, regardless of the bypass_setaud flag setting for su(1).

If a user is not selected for auditing, audit records associated with the user are generated in the following cases:

• At the time user starts a session and ends a login session. Those events are considered system

events more than user events and are therefore generated based on whether the login event is being audited rather than whether the user is being audited.

• By programs that do self-auditing and make arbitrary decisions to ignore the user selection.

• If Audit Filtering (11i v3 only) is configured to generate audit records for those users who are not

selected for auditing using the !audited_process flag. See filter.conf(4).

• System call auditing of inetd spawned daemons if inetd is not started with the –a option.

If a user is selected for auditing, audit records associated with the user are not generated in the following case:

Page 16

• The root user runs su – non_root_user, where the target non-root user is being audited. When

the root user switches to another user, the Pluggable Authentication Module (PAM) is not invoked; no authentication is done when running as root. Therefore, audit records are not generated as being triggered by the non-root target user, but are instead attributable to the root user.

Configuring events for audit

Use the audevent(1M) command to specify system activities (auditable events) that you want to audit. Auditable events are classified into event categories and profiles for easier configuration. After an event category or a profile is selected, all system calls and self-auditing events associated with that event category or profile are selected. When the auditing system is installed, a default set of event classification information is provided in /etc/audit/audit.conf file. In order to meet site-specific requirements, you can also define event categories and profiles in

/etc/audit/audit_site.conf. For more information, see audit.conf(4) and audevent(1M).

On HP-UX 11i v3, the AudFilter product enables you to audit events not audited according to audevent(1M) by specifying a filtering rule that contains the !audited_event directive.

Configuring audit filtering

To configure and load audit filtering, follow these steps:

1. Customize the filtering rules in /etc/audit/filter.conf. The filter.conf file contains the

rule-based audit filtering policy that the auditing subsystem uses to determine what activities to audit on the system. For more information, see filter.conf(4).

2. Start the filter daemon as follows:

# audfilterd –s

The audfilterd service daemon handles service requests from the audfilter(1M) configuration tool, and reevaluates and reloads the filtering policy whenever the mounted file system table changes. For more information, see audfilterd(1M).

3. Load the filtering rules as follows:

# audfilter –c

The audfilter configuration tool interprets the filtering policy as specified in the filter.conf configuration file and implements the policy. Use audfilter to display or clear out the filtering policy currently in effect.

Configuring audit settings to be preserved across reboots

To preserve audit settings across reboots, edit the /etc/rc.config.d/auditing file and make the following changes as needed:

• AUDITING flag –- Set to 1 to enable the auditing system at system startup.

• Primary and secondary log files

– PRI_AUDFILE – Absolute pathname of the audit trail where audit records begin to be logged. – PRI_SWITCH – Switch size (maximum size in kilobytes) for the primary audit trail – SEC_AUDFILE – The trail to which the audit system switches when the primary reaches switch

size.

– SEC_SWITCH – Switch size (maximum size in kilobytes) for the secondary audit trail

• Number of log files in an audit trail

Page 17

NTHREADS – The number of log files that compose an audit trail. The recommended value is the number of processors on a system divided by two.

• Audevent settings – Arguments to the audevent command

– AUDEVENT_ARGS1 describes those events that are audited for both success and failure. – AUDEVENT_ARGS2 describes those events that are success only. – AUDEVENT_ARGS3 describes those events that are failure only. – AUDEVENT_ARGS4 describes those events that are audited for neither success nor failure.

• Audomon settings

AUDOMON_ARGS describes arguments to the audomon daemon.

Configuring roles

You can base auditing on HP-UX Role-Based Access Control (RBAC) criteria and the

/etc/rbac/aud_filter file. HP-UX RBAC Version B.11.23.02 and later support the use of an

audit filter file to identify specific HP-UX RBAC criteria to audit. You can create a filter file named /etc/rbac/aud_filter to identify specific roles, operations, and objects for which to generate audit records. Audit records are generated only if the attributes of a process match all three entries (role, operation, and object) found in /etc/rbac/aud_filter. If a user's role and associated authorization are not found in the file or do not explicitly match, no audit records specific to role-toauthorization are generated.

Authorized users can edit the /etc/rbac/aud_filter file using a text editor and specify the role and authorization to be audited. Each authorization is specified in the form of operation, object pairs. All authorizations associated with a role must be specified in a single entry. You can specify only one authorization per role on each line; however, the wildcard character (*) is supported. The following are the supported entries and format for the /etc/rbac/aud_filter file:

role, operation, object

• role – Any valid role defined in /etc/rbac/roles. If * is specified, all roles can be accessed

by the operation.

• operation – A specific operation that can be performed on an object. For example,

hpux.printer.add is the operation of adding a printer. Alternatively, hpux.printer.* is the operation of either adding or deleting a printer. If * is specified, all operations can be accessed by the operation.

• object – The object the user can access. If * is specified, all objects can be accessed by the

operation.

The following are examples of /etc/rbac/aud_filter entries that specify how to generate audit records for the role of SecurityOfficer with the authorization of (hpux.passwd,

/etc/passwd), and for the Administrator role with authorization to perform the hpux.printer.add operation on all objects:

SecurityOfficer, hpux.passwd, /etc/passwd Administrator, hpux.printer.add, *

Note

When HP-UX SMSE B.11.23.02 is used in conjunction with HP-UX RBAC (version B.11.23.04 or later) on HP-UX 11i v2, you can restrict the use of the userdbset command based on user authorizations.

Page 18

Use an editor (for example, vi) to directly edit the /etc/rbac/aud_filter file. The HP-UX RBAC administrative commands do not provide an interface to configure /etc/rbac/aud_filter.

Management

This section describes how to enable and disable auditing, and how to rotate audit log files.

Enabling auditing

To enable auditing, use one of the following methods:

• Enter the /sbin/init.d/auditing start command. When you do this, the following occurs:

– Reads the /etc/rc.config.d/auditing file. – Displays events to be audited by running audevent using the AUDEVENT_ARGS flags. – Turns on the auditing system by running audsys -n. – When audsys is run for the first time, the command creates the /etc/audit/audnames file

using the log file names and sizes specified by PRI_AUDFILE and SEC_AUDFILE. Thereafter, each time the audsys -n command is invoked, it uses the audit log names and sizes from the audnames file.

– Starts the audomon daemon with the AUDOMON_ARGS.

• HP-UX Security Attributes Configuration Tool

Used to view and configure system-wide and per-user (local users and NIS users) values of security attribute. You can launch this from the HP System Management Homepage (SMH) or HP System Insight Manager (SIM). For more information, see secweb(1M).

• Entering the audsys –n and audomon commands manually.

Disabling auditing

To disable auditing, enter the audsys –f command.

Rotating audit logs

To enable audit log rotation, run the audomon daemon. The audomon daemon monitors the capacity of the current audit trail and the file system on which the audit trail is located, by checking the FileSpaceSwitch (FSS) and AuditFileSwitch (AFS) switch points. If either switch point is reached, audit recording automatically switches to an alternative audit trail. For example, if the auditing system was started using audsys -n -c /var/.audit/my_trail -s 1000, the following command starts the audomon daemon:

audomon -p 20 -t 1 -w 90 -X "/usr/local/bin/rcp_audit_trail hostname”

This command has the following behaviors:

• The audomon daemon sleeps at least 1 minute at intervals.

• When the size of the current audit trail reaches 1000*90% or 900 kilobytes, or the file system that

contains the current audit trail has reached (100%-20%) * 90% or 72% full, audomon starts printing warning messages to the console.

• When the size of the current audit trail reaches 1000 kilobytes, or the file system that contains the

current audit trail has reached 100% - 20% or 80% full, audomon switches recording data to: /var/.audit/my_trail.yyyymmdd_HHMM, where yyyymmdd_HHMM is replaced by the time when the switch has happened.

• After the switch succeeds, audomon invokes the following command:

Page 19

sh -c "/usr/local/bin/rcp_audit_trail hostname /var/.audit/my_trail"

This copies /var/.audit/my_trail to a remote system, assuming that is what the given script intends to do.

Writing a DPMS service module

The Audit Data Process Module Switch (Audit DPMS) framework offers the ability to selectively access audit data in various formats through a set of common programming interfaces. It provides a layer of separation between applications that need to extract information from audit data source and the underlying modules that have the knowledge about the internal data format. For more information, see audit_dpms(5).

The framework allows Audit DPMS service modules to be plugged in to handle the data in any format. The service modules are a set of dynamically loadable objects invoked by the Audit DPMS API to handle a particular type of audit data and format. Currently, HP-UX provides three DPMS service modules to handle reading and writing from and to HP-UX raw audit data, reading and writing from and to HP-UX portable audit data, and writing to XML format data. For more information, see audit_hpux_raw(5), audit_hpux_portable(5), and audit_hpux_xml(5), respectively.

You can develop new DPMS service modules to plug into the Audit DPMS framework to handle audit data from a source in another format. This section describes how to write a DPMS service module.

Service Provider Interfaces (SPIs)

A new DPMS service module must support the Audit DPMS Application Programming Interfaces (APIs) (for example, audit_dpms_start(3), audit_dpms_end(3), audit_dpms_read_event(3), and audit_dpms_write_event(3)) by implementing the corresponding DPMS service module Service Provider Interfaces (SPIs) (audit_dpm_start(3), audit_dpm_end(3), audit_dpm_read_event(3), and audit_dpm_write_event(3)). The Audit DPMS interface library is the layer implementing the APIs, while the Audit DPMS service modules implement the APIs for different audit record formats. For more information about the Audit DPMS APIs, see

audit_dpms_api(3). For more information about the Audit DPMS SPIs, see audit_dpms_spi(3).

A new DPMS service module can make use of the Audit DPMS interface to allow an application to register a set of filtering rules where only the audit events that meet the filtering criteria are returned to the caller. This interface is provided entirely within the DPMS switch; DPMS modules therefore do not provide a plug-in for this interface. For the grammar of the filtering rules, see audit_dpms_filter(4).

DPMS service module implementation

A sample DPMS service module will be available on a future release of the AudReport product.

Best practices

Although best practices must be developed by each individual organization based on their particular environment, there are some general best practices that can be universally applied. contains best practices to provide guidance for making decisions as part of the planning stage.

This section

Page 20

Audit policy

Develop a policy for auditing based on the amount of security the site requires, the types of users administered, and the costs of auditing. Document the policies, perform periodic reviews, and update

policies as needed. Based on the policy, take the following decisions as part of planning:

• Decide which users and events to audit based on the site policy.

• Decide whether to audit the selected events for success, for failure, or both. Auditing for failure

locates abnormal events; auditing for success monitors system use.

• Determine level and format of audit info depending on the site policy.

• Define roles (who gets to do what)

– Security Administrator

Plans what to audit according to site security policy and goal; implements policies; and develops an archive strategy and encryption of archives.

– System Administrator

Plans for disk space (local and remote) and other resources; configures automatic backup, archiving, and log rotation; and for centralized management, determines audit server and network layout of audited systems.

– HP-UX RBAC

Implement roles such as readers of audit trails to protect audit trails from snooping.

• Establish standard operational procedures to support and maintain the policies. For example:

– Decide whether audit subsystem must block, suspending system activities so no audit data is ever

lost, or must discard records rather than suspending system activities when the disk space is exceeded on audit file systems.

– Determine a regular maintenance schedule that can automatically back up and free up space for

more audit records.

Audit generation and capture

Collecting sufficient data to meet the requirements of regulations and forensic analysis is a big challenge. For example, the payment card industry standard requires organizations to track and monitor all access to network resources and cardholder data. Data must be collected from many sources including security systems, operating and storage systems, and applications. Events that must be recorded include the following:

• Privileged, administrative or root access.

• Enabling and disabling of security system and accesses to audit logs.

• System and service startup and shutdown.

• File accesses and changes to access rights on servers.

• Rejected system, application, file, or data access attempts and other failed actions.

• Login attempts and the amount of data sent and received during the session on remote access and

wireless access system.

Note:

Log sources typically reference an internal clock when placing a time stamp on a log entry. Ensure all log sources internal clocks are synchronized to a trusted, accurate time server.

Page 21

Audit retention and storage

Storage cost is the most significant operational cost of auditing. The amount of audit data depends on the site policy for the following major factors: different number of users; different usage of the system or system loads (web or application server, timesharing system, workstation); degree of traceability and accountability that is required. As you plan for the storage of audit logs, remember the following:

• You must set aside more disk space for the audit trail if auditing is done for monitoring of system

use than auditing for abnormal events.

• You can reduce storage cost by reducing the amount of audit data generated. Define pre-filtering

rules, using the AudFilter product, that reduce the potential size of the audit trail while not compromising security. You can define filtering rules for events that are not generally interesting for audit purposes. For example, any read-only operations on world-readable objects, operations on non-existing files, any operation on files owned by the user on /home.

• If you expect the audit data volume to be high, configure audit trails on a logical volume consisting

of multiple physical disks and multiple physical I/O cards. Use the -N option with audsys command to split the audit trail into multiple files.

• Frequently accessed data, such as production data, must be available on-line. Data not requiring as

frequent or ready access such as back-up data can be stored off-line. You can use the auditdp command to filter on-line data to remove unnecessary information. This enables you to keep the audit file at a manageable size and keep the less interesting information in off-line, backup storage. For example, use auditdp to filter only login and logout events from one month’s audit trail. If you need to access other records, you can recover them from off-line backup tapes.

• To keep audit files at a manageable size, you can invoke the audomon daemon. This monitors the

capacity of the current audit trail and the file system on which the audit trail is located. If either capacity limit is reached, audit recording automatically switches to an alternative audit trail and backs up the current audit trail to a secondary storage".

• Deploying a log management solution is better than storing audit data distributed across systems

because it facilitates access to logged data collected from across the organization and unifies searching, reporting, alerting, and analysis across any type of enterprise log data.

• Ensure that when the required data retention period has ended, the logs are retired by destroying

them according to the organization's data destruction policies.

Audit log analysis

The cost of analysis is roughly proportional to the amount of audit data collected. The cost of analysis includes the time it takes to review audit records, and the time it takes to archive them and keep them in a safe place. The following best practices address the need to make analysis easier, enabling the organization to extract the wealth of information logs can provide:

• Regular review and analysis helps to identify late hours login, login failures, failed access to system

files, and failed attempts to perform security-relevant tasks. Depending on the systems, risk environment, and other requirements, logs must be reviewed in real-time, daily, monthly, or every 90 days.

• Automation can significantly improve analysis because it takes much less time to perform and

produce more valuable results.

• Analyzing logs using a log management solution is better than analyzing logs separately in

different systems because attacks usually involve multiple assets.

• You can analyze logs by extracting useful reports from the audit trail by using the following tools:

– Audit Record Display (audisp) in HP-UX 11i v2.

Page 22

– Audit Trail Reports (auditdp) in HP-UX 11i v3. In addition, you can use the following tools in

/opt/audit/AudReport/bin:

audit_p2l — This sample script demonstrates how to convert audit data in portable format (see audit_hpux_portable(5)) to message lines similar to syslog. The script takes no options or

arguments. It reads portable audit data from stdin and outputs the message lines to stdout. For example, in order to convert HP-UX raw audit data to messages in follow mode and store the results in /var/adm/auditlog, issue the following command line:

$ auditdp -r <raw_audit_log> -P -o follow -O sync | \ audit_p2l > /var/adm/auditlog &

auditreport_generator — This sample script demonstrates how to use the auditdp

command (see auditdp(1M)) to generate a collection of web-based audit reports, for example, login history data, logoff history data, su history data, root account activities report, and file access report.

auditreport_setup_web — This sample script sets up the Apache server properly to bring up the generated audit reports in a web browser. It includes setting up the password that is required to access the audit reports through web; setting up the http alias; and restarting or bringing up the Apache server.

Audit log configuration, security, and protection

Ensuring the confidentiality, integrity, and availability of logs is very important. As you plan for this, remember the following:

• Logging mechanisms must neither be deactivated nor compromised to provide business continuity of

logging services in the event of an incident.

• Ensure that log files cannot be edited or deleted. Generally only administrators and auditors must

have access to log files for review and management only. All privileged user (the administrator and auditor) access must be logged and reviewed thoroughly and frequently by others outside that user domain.

• Communications must be protected with mechanisms such as encryption (for example, HP-UX IPSec

and SSL).

• Protect the confidentiality and integrity of log files using either message digests or encryption or

digital signatures.

• Provide adequate physical protection for logging mechanisms and stored logs by preventing

unauthorized physical access.

Troubleshooting

This section describes potential problems and their solutions. To stay current with product updates and patches, monitor the HP security software news and events web site at www.hp.com/security

• Self-audit login events are being generated for users even though they are disabled for auditing.

When a user remotely logs in using telnet, ssh, and remsh, user authentication is performed by the pam_hpsec(5) PAM module. The module always generates self-audit login events, regardless of whether auditing for a user is enabled (AUDIT_FLAG=1) or disabled (AUDIT_FLAG=0). Likewise, logoff events are generated by a DLKM when the user logs off.

• System call level events are being generated for daemons spawned by inetd (for example,

telnetd(1M) and remshd(1M)) even though auditing is disabled for user root.

Page 23

The inetd daemon honors the AUDIT_FLAG only for the user under whom the service is run when inetd is started with the –a option. Self-audit login and logoff events are generated regardless of

the inetd –a option and whether the user is enabled or disabled for auditing. Most inetd services run as user root and disabling auditing for root is not recommended, as this results in no system call auditing of users logged in as root.

• After upgrading AuditExt, starting Audit with audsys –n returns the failed to match audit

trail version; specify different audit trail error.

The version of the audit trail for the upgraded product is newer than the previously installed product. You must disable auditing (audsys –f) before upgrading the AudReport product. To proceed after receiving this error, disable auditing and then enable it to start creating an audit trail with the latest version. The new version can include more audit data for each event, for example, the IP address of the origin of the event, the command name of the event, and the audit session ID.

Note:

Both audisp and auditdp are capable of handling both versions of the audit trails. Therefore, you do not need to know about the internal format of raw audit data.

• If a system crash or reboot with the reboot -n command occurs when the audit trail is being

written, the audit trail might be corrupted. Remove the corrupted audit trail and start the audit subsystem.

Page 24

Glossary

Audit Aware Programs

Privileged programs that invoke either the audswitch system call to suspend system call auditing or the audwrite system call to generate self-auditing events. Audit aware programs are also called self-auditing programs.

Audit Event

Also called an Audit Record. An event is an instance of a subject accessing an object. For example, a process opening a file or a user logging into a system. Audit records are generated when users make security-relevant system calls and when self-auditing processes call audwrite(2).

Audit File

A file that stores audit records in binary format.

Audit Process Identifier (PID) Information Record (PIR)

An audit record written into the audit trail once for each process, containing information that remains constant throughout the lifetime of the process.

Audit Tag

A unique audit session ID that uniquely identifies (or tags) all audit records generated for a particular login session.

Audit Trail

All pieces of audit files that together store audit records in chronological order and provide a complete information trail for displaying or analysis.

On HP-UX 11i v2, an audit trail is a single audit file. On HP-UX 11i v3, an audit trail is composed of one or more audit files.

Base Event

A particular system operation that is audited and pre-defined by the HP-UX operating system. This is either a self-auditing event (for example, login) or a system call (for example, open).

Event Category

A set of base events that affect a particular aspect of the system (for example, the creation of an object, such as a file, directory, special device file, and IPC object.)

Filtering

Any one of the following types of audit filtering:

System call pre-filtering — Filtering of system call and self-audit events in the kernel based on process (user) and event selection flags, and performed before the system call specific code executes.

System call post-filtering — Filtering of system call events in the kernel based on the success or failure of system call, and performed after the system call specific code executes.

Page 25

AudFilter Product pre-filtering — Fine-grained filtering in the kernel to selectively record the audit records that were generated and stored in the audit trail. This reduces the size of the audit trail and enhances system call pre- and post-filtering by supporting rules-based filtering as a function of other attributes, such as system call parameters (for example, the open(2) oflag parameter), file owner, file system on which a file resides, and system call errno.

AudReport Product post-filtering — Fine-grained filtering in user space to selectively extract audit records that were generated and stored in the audit trail, and to produce useful reports.

Primary Audit Trail

The current audit trail in which audit records are being written.

Profile

A set of base events defined for a particular type of system (for example, web server and file server).

Secondary Audit Trail

The audit trail in which audit records will be written when certain capacity limits are reached for the Primary Audit Trail.

Self-Auditing Events

An auditable event that describes a series of actions performed by a program in order to provide a more high-level and meaningful description of an event (for example, user login event), instead of a low system call level description provided by a series of System Call Events.

Self-Auditing Program

A privileged program that produces self-auditing events. These are not necessarily Audit Aware Programs.

System Call Events

An auditable event that describes the invocation of a security relevant system call.

Page 26

For more information

To read more about the HP-UX Auditing System, see the following:

• Manpages (either installed on the system or at

http://www.hp.com/go/hpux-clickable-manpages

• HP-UX System Administration Guide: Security Management at:

http://www.hp.com/go/hpux-core-docs

Click on the HP-UX version you want and scroll down to User guide.

Send comments to HP

HP welcomes your input. Please give us comments about this white paper, or suggestions for the HPUX Security or related documentation, through our technical documentation feedback website:

http://www.hp.com/bizsupport/feedback/ww/webfeedback.html

© Copyright 2011 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Trademark acknowledgments, if needed.

5900-1628, Created July 2011

Share with colleagues