of low category plus INSTALL; time; SYSGEN; privilege; logins (all
types); logouts (all types); access of files through BYPASS, SYSPRV,
and READALL privileges; unsuccessful access to files, devices, and
All of medium category
plus identifier, process, unsuccessful access to protected objects,
NCP, connection (VAX only)
In a site with moderate security requirements,
you want to audit events that can redefine your system. You watch
for changes to system files, system time, or system parameters. You
also monitor image installations and the use of privilege. “Auditing Events for a Site with Moderate Security Requirements” shows the auditing
setting for a site with moderate security requirements.
Example 10-3 Auditing Events for a Site with Moderate Security Requirements
A site with high security requirements expands
its auditing breadth to include network activity. It needs to monitor
changes to the network database, network connections (VAX only), the
use of identifiers as privileges, and privileged file access. Monitor
all file access through SYSPRV, BYPASS, or READALL privilege, and
watch both successful and unsuccessful file access through GRPPRV
privilege. To enable the settings for a high level of auditing, assuming
a medium level is in effect, enter the following set of commands:
The operating system can report a security event
as either an alarm or an audit (see “Auditing Categories of Activity”). Which form you select depends on
the nature of the event. Real-time events or events that should be
treated immediately, such as break-in attempts or changes to the system
user authorization file (SYSUAF.DAT), are classes to enable as both
alarms and audits. Less critical events can be enabled just as audits.
Unless you have a hardcopy operator terminal, the alarm record is
quickly superseded by other system messages. Audit event records,
which are written to the system security audit log, are saved so you
can study them in volume.
There is an advantage to studying event messages.
Many times an isolated auditing message offers little insight, but
numerous audit records reveal a pattern of activity that might indicate
security violations. With auditing of object access, for example,
a security administrator can see a pattern of time, types of objects
being accessed, and other system information that, in total, paint
a complete picture of system activity. “Analyzing a Log File” describes how to produce reports
from audit log files.
Considering the Performance Impact
The default auditing performed by the operating
system primarily tracks changes to the authorization databases. System
events like changes to the system user authorization file (SYSUAF.DAT)
or the installation of images do not occur too often and therefore
are not a drain on system resources.
Auditing additional event classes, particularly
access events and privilege events, can consume significant system
resources if a site enables the event classes without understanding
how their system is used and without evaluating the value of the audit
information. In this respect, implementation of the audit reporting
system is similar to system tuning: it takes a little while to reach
the appropriate level of reporting that is free of spurious details.
For this reason, HP recommends you turn auditing on in phases, not
all at once, and gradually add or subtract event classes until you
reach a satisfactory balance. Use the following guidelines:
Be selective in auditing
object access events. Object access events occur all the time and
therefore have the greatest impact on system performance. Audit file-access
failures in most cases rather than successful file access, or put
auditing ACEs on key files rather than enable auditing for the entire
Examine the layered products
you are running so you understand which privileges they may use. Also
become familiar with site-specific procedures, such as the use of
the READALL privilege during a backup operation. Because privilege
events occur frequently, they have a great impact on system performance.
Enable a few event classes
at a time and then add or subtract, if necessary, until you have sufficient
event information. The more classes you enable, the more overhead
you have and the fewer resources you have for useful work on the system.
Two commands in particular generate a large number
of audit messages:
The DCL PIPE command can
create a large number of subprocesses to execute a single PIPE command.
This can mean a potential increase in auditing events that are related
to subprocess activities (for example, process creation, process deletion,
login, logfailure, and logout).
The UAF command MODIFY
USER/FLAG=AUDIT generates a very large number of audit messages. It
is not usually necessary to set this flag; if you have a particular
AUDIT enabled, you do not need to have the user flag set as well.