Developing an Auditing Plan

As system manager or site security administrator, you have to determine the level of security required at your site before you can understand which security events to audit.

Assessing Your Auditing Requirements

Assessing your auditing requirements is a two-step process:

Determine your site's general security requirements: are they high, moderate, or low? “Event Tolerance as a Measure of Security Requirements” provides some guidance on determining your security needs.
Once you know your site's needs, see the “Events to Monitor Depending on a Site's Security Requirements” for a suggested list of event classes to enable.

After developing a general notion of your site requirements, you need to consider how much security reporting is realistic. Balance the suggestions in “Events to Monitor Depending on a Site's Security Requirements” with the following site factors:

The sensitivity of the data at your site
The amount of time you have to analyze log files
The disk space you have available
Your knowledge of a security threat: where is it coming from or likely to come from
The tuning requirements of your system (See “Considering the Performance Impact” for information about performance impact.)

Table 10-4 Events to Monitor Depending on a Site's Security Requirements

	Low	Medium	High
Goal	Monitor local events with high impact	Track changes to system definition	Monitor database changes; track use of process control system services Monitor network connections through DECnet Phase IV (VAX only)
Classes to Enable as Alarms	ACL, authorization, break-in (all types), logfailure (all types)	Same as low category plus use of SECURITY privilege	Same as medium category plus INSTALL, time, SYSGEN, unsuccessful privilege use
Classes to Enable as Audits	ACL, authorization, breakin (all types), logfailure (all types)	All 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 volumes	All of medium category plus identifier, process, unsuccessful access to protected objects, NCP, connection (VAX only)

In “Events to Monitor Depending on a Site's Security Requirements”, the event classes suggested for a low-security site are the default settings for the operating system. If these classes are not the current defaults on your system, you can enable them with the following command:

$SET AUDIT/ALARM/AUDIT -
_$ /ENABLE=(ACL,AUTHORIZATION,BREAKIN:ALL,LOGFAILURE:ALL)

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

System security alarms currently enabled for:
  Authorization
  Breakin:       dialup,local,remote,network,detached

System security audits currently enabled for:
  ACL
  Authorization
  INSTALL
  Time
  SYSGEN
  Breakin:       dialup,local,remote,network,detached
  Login:         batch,dialup,local,remote,network,subprocess,detached,server
  Logfailure:    batch,dialup,local,remote,network,subprocess,detached,server
  Logout:        batch,dialup,local,remote,network,subprocess,detached,server

  Privilege use:
    ACNT      ALLSPOOL  ALTPRI    AUDIT     BUG       BYPASS    CMEXEC    CMKRNL
    DIAGNOSE  DOWNGRADE EXQUOTA   GROUP     GRPNAM    GRPPRV    IMPORT    IMPERSONATE
    LOG_IO    MOUNT     NETMBX    OPER      PFNMAP    PHY_IO    PRMCEB    PRMGBL
    PRMMBX    PSWAPM    READALL   SECURITY  SETPRV    SHARE     SHMEM     SYSGBL
    SYSLCK    SYSNAM    SYSPRV    TMPMBX    UPGRADE   VOLPRO    WORLD

  Privilege failure:
    ACNT      ALLSPOOL  ALTPRI    AUDIT     BUGCHK    BYPASS    CMEXEC    CMKRNL
    DIAGNOSE  DOWNGRADE EXQUOTA   GROUP     GRPNAM    GRPPRV    IMPORT    IMPERSONATE
    LOG_IO    MOUNT     NETMBX    OPER      PFNMAP    PHY_IO    PRMCEB    PRMGBL
    PRMMBX    PSWAPM    READALL   SECURITY  SETPRV    SHARE     SHMEM     SYSGBL
    SYSLCK    SYSNAM    SYSPRV    TMPMBX    UPGRADE   VOLPRO    WORLD

  FILE access:
    SYSPRV:      read,write,execute,delete,control
    BYPASS:      read,write,execute,delete,control
    READALL:     read,write,execute,delete,control

To enable the settings for a moderate level of auditing, assuming the default events are already in effect, enter the following set of commands:

$SET AUDIT/ALARM/AUDIT/ENABLE=PRIVILEGE=(SUCCESS:SECURITY,FAILURE:SECURITY)
$SET AUDIT/AUDIT/ENABLE=(INSTALL,SYSGEN,TIME,PRIVILEGE=(SUCCESS,FAILURE))
$SET AUDIT/AUDIT/ENABLE=ACCESS=(BYPASS,SYSPRV,READALL)/CLASS=FILE
$SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=(FILE,DEVICE,VOLUME)

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:

$SET AUDIT/ALARM/ENABLE=(INSTALL,SYSGEN,TIME,PRIVILEGE=(FAILURE:ALL) )
$SET AUDIT/AUDIT/ENABLE=(CONNECTION,IDENTIFIER,NCP,PROCESS:ALL)
$SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=*

To enable all auditing:

$SET AUDIT/AUDIT/ENABLE=ALL/CLASS=*

To disable all auditing:

$SET AUDIT/AUDIT/DISABLE=ALL/CLASS=*

See “Security Auditing” for more suggestions of event classes to enable.

Selecting a Destination for the Event Message

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:

Evaluate your auditing requirements, as described in “Assessing Your Auditing Requirements”.
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 file class.
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.