skip book previous and next navigation links
go up to top of book: HP OpenVMS System Manager's Manual, Volume 2:... HP OpenVMS System Manager's Manual, Volume 2:...
go to beginning of chapter: Getting Information About the System Getting Information About the System
go to previous page: Setting Up, Maintaining, and Printing the Operator Log File Setting Up, Maintaining, and Printing the Operator Log File
go to next page: Monitoring Operating System PerformanceMonitoring Operating System Performance
end of book navigation links

Using Security Auditing  



This section discusses how security auditing works; it also explains how to enable security auditing and how to create a new version of the security audit log file. For more information about the security audit log file, refer to the HP OpenVMS Guide to System Security.

Understanding Security Auditing  

Security auditing is the act of recording security-relevant events as they occur on the system. Security-relevant events are divided into a number of categories called event classes.

By default, the system enables security auditing when you install or upgrade your system for the events shown in Event Classes Audited by Default.

Table 7   Event Classes Audited by Default
Class Description
ACL
Access to any object holding a security Auditing ACE.
AUDIT
All uses of the SET AUDIT command. You cannot disable this category.
AUTHORIZATION
All changes to the authorization database:
  • System user authorization file (SYSUAF)


  • Network proxy authorization files: NETPROXY and NET$PROXY


  • Rights database (RIGHTSLIST)

BREAKIN
All break-in attempts: batch, detached, dialup, local, network, remote.
LOGFAILURE
All login failures: batch, dialup, local, remote, network, subprocess, detached.

If the security requirements at your site justify additional auditing, you can enable security auditing for other event classes by using the DCL command SET AUDIT, as explained in Enabling Security Auditing for Additional Classes.

Security Audit Log File  

The audit server process, which is created at system startup, records the events that are shown in Event Classes Audited by Default in the security audit log file, SYS$MANAGER:SECURITY.AUDIT$JOURNAL.

The usefulness of the security audit log file depends upon the procedures you adopt to review the file on a regular basis. For example, you might implement the following procedure as part of your site audit review policy:

  1. Create a new version of the security audit log file each morning.
  2. Review the previous version of the log file for suspicious system activity. Depending on the number of security events you are auditing on your system, it might be impractical to review every audit record written to the audit log file. In that case, you might want to select a specific set of records from the log file (for example, all Authorization and Breakin records, or all events created outside normal business hours).
  3. If, during your review, you find any security events that appear suspicious, perform a more detailed inspection of the security audit log file, as described in the HP OpenVMS Guide to System Security.

Audit Log Files in Mixed-Version Clusters  

The Audit Analysis utility (ANALYZE/AUDIT) running on earlier-version systems is unable to process the current version of audit log files. You must use the current version of ANALYZE/AUDIT to process the current version of the audit log files. The recommended procedure is to maintain separate audit log files on mixed-version clusters.

If redirecting the audit log files, issue the following command on both the earlier-version node and on the node running the current version:

AUDIT/JOURNAL/DESTINATION=filespec
The destination filespec is stored in the audit server database file. By default, the files are stored in SYS$COMMON:[SYSMGR] and are called SECURITY_AUDIT.AUDIT$JOURNAL and SECURITY.AUDIT$JOURNAL, respectively.

The operating system allows workstations and other users with limited management resources to duplicate their audit log files on another node. The secondary log, a security archive file, is then available to a security administrator on a remote node who has the skills to analyze the file.

Each node in a cluster must have its own archive file. An archive file cannot be shared by multiple nodes in a cluster.

Refer to the HP OpenVMS Guide to System Security for more information.

Displaying Security Auditing Information  

To see which event classes your site currently audits, you can enter the DCL command SHOW AUDIT.

The follow example contains security information:

$ SHOW AUDIT
System security alarms currently enabled for:
  ACL
  Breakin:       dialup,local,remote,network,detached
  Privilege use:
    SECURITY
  Privilege failure:
    SECURITY
 
System security audits currently enabled for:
  ACL
  Authorization
  Breakin:       dialup,local,remote,network,detached
  Login:         dialup,local,remote,network,detached
  Logfailure:    batch,dialup,local,remote,network,subprocess,detached
  Logout:        dialup,local,remote,network,detached
  Privilege use:
    SECURITY
  Privilege failure:
    ACNT      ALLSPOOL  ALTPRI    AUDIT     BUGCHK    BYPASS    CMEXEC    CMKRNL
    DETACH    DIAGNOSE  EXQUOTA   GROUP     GRPNAM    GRPPRV    LOG_IO    MOUNT
    NETMBX    OPER      PFNMAP    PHY_IO    PRMCEB    PRMGBL    PRMMBX    PSWAPM
    READALL   SECURITY  SETPRV    SHARE     SHMEM     SYSGBL    SYSLCK    SYSNAM
    SYSPRV    TMPMBX    VOLPRO    WORLD
  DEVICE access:
    Failure:     read,write,physical,logical,control
  FILE access:
    Failure:     read,write,execute,delete,control
  VOLUME access:
    Failure:     read,write,create,delete,control 

Delaying Startup of Auditing  

Ordinarily, the system turns on auditing in VMS$LPBEGIN just before SYSTARTUP_VMS.COM executes. You can change this behavior, however, by redefining the logical name SYS$AUDIT_SERVER_INHIBIT.

To change the point at which the operating system begins to deliver security-event messages, add the following line to the SYS$MANAGER:SYLOGICALS.COM command procedure:

$ DEFINE/SYSTEM/EXECUTIVE SYS$AUDIT_SERVER_INHIBIT YES
You can initiate auditing during another phase of system startup, perhaps at the end of SYSTARTUP_VMS.COM, by editing the command file to add the following line:
$ SET AUDIT/SERVER=INITIATE
For information about editing SYSTARTUP_VMS.COM, see the HP OpenVMS System Manager's Manual, Volume 1: Essentials.

Enabling Security Auditing for Additional Classes  

To enable security auditing for classes in addition to those shown in Event Classes Audited by Default, use the following format: SET AUDIT/ENABLE=keyword[,...] {/ALARM | /AUDIT}

The HP OpenVMS Guide to System Security contains descriptions of event classes that you can enable.

When you enable auditing for additional event classes, you must specify two qualifiers:

  1. /ENABLE
  2. Either /ALARM or /AUDIT (Although you must specify one qualifier, you can specify both.)

The following table contains explanations of the /ENABLE, /ALARM, and /AUDIT qualifiers.

Qualifier Explanation
/ENABLE
Defines which event classes you want audited. See Tracking Resource Use for more information.
/ALARM /AUDIT
Defines the destination of the event message.
  • /ALARM directs the message to all enabled security operator terminals.


  • /AUDIT directs the message to the security audit log file.


Use the /ALARM and /AUDIT qualifiers to report critical events. Less critical events can be written only to the security audit log file for later examination.

The default event classes listed in Event Classes Audited by Default are sent as both alarms and audits.

The system begins auditing new events on all nodes as soon as you enable them.

Examples

  1. The command in the following example enables auditing for volume mounts and dismounts and sends messages to the security audit log file.
    $ SET AUDIT/ENABLE=MOUNT/AUDIT
  2. The command in the following example enables auditing of unsuccessful file accesses and sends messages to all enabled security operator terminals as well as to the security audit log file.
    $ SET AUDIT/ALARM/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=FILE  

Disabling Security Auditing  

The system continues auditing until you explicitly disable the classes with the /DISABLE qualifier using the following syntax:SET AUDIT/DISABLE=keyword[,...] {/ALARM | /AUDIT}

Enabling a Terminal to Receive Alarm Messages  

The system sends alarm messages to terminals enabled for security class messages. Security alarm messages are not written to the operator log file. They appear only on terminals enabled for security class messages.

In most cases, security alarm messages appear on the system console by default. Since messages scroll quickly off the screen, it is good practice to enable a separate terminal for security class messages and disable message delivery to the system console.

Either choose a terminal in a secure location that provides hardcopy output, or have dedicated staff to monitor the security operator terminal. You can enable any number of terminals as security operators.

To set up a terminal to receive security class alarms, enter the following DCL command from the designated terminal:

$ REPLY/ENABLE=SECURITY 
Example

The following example shows a security alarm message:

%%%%%%%%%%%  OPCOM  25-MAY-2002 16:07:09.20  %%%%%%%%%%%  
Message from user AUDIT$SERVER on GILMORE
Security alarm (SECURITY) on GILMORE, system id: 20300
Auditable event:          Process suspended ($SUSPND) 
Event time:               25-MAY-2002 16:07:08.77 
PID:                      30C00119 
Process name:             Hobbit
Username:                 HUBERT  
Process owner:            [LEGAL,HUBERT]
Terminal name:            RTA1:
Image name:               $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SET.EXE
Status:                   %SYSTEM-S-NORMAL, normal successful completion
Target PID:               30C00126
Target process name:      SMISERVER
Target username:          SYSTEM
Target process owner:     [SYSTEM] 

Generating Security Reports  

The most common type of report to generate is a brief, daily listing of events. You can create a command procedure that runs in a batch job every evening before midnight to generate a report of the day's security event messages and send it to the system manager via Mail.


NoteBecause the MOUNT command translates /NOLABEL to /FOREIGN in the audit record, use ANALYZE/AUDIT/SELECT=MOUNT_FLAGS=FOREIGN instead of ANALYZE/AUDIT/SELECT=MOUNT_FLAGS=NOLABEL.

The following example shows the ANALYZE/AUDIT command line you would use to generate this type of report:
$ ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31JAN2002.AUDIT -
_$ SYS$MANAGER:SECURITY.AUDIT$JOURNAL
$ MAIL/SUBJECT="Security Events" 31JAN2002.AUDIT SYSTEM  

Creating a New Version of the Security Audit Log File  

Because the security audit log file continues to grow until you take action, you must devise a plan for maintaining it.

Use the SET AUDIT command to create a new version of the clusterwide security audit log file. To prevent the loss of audit messages, the previous version of the audit log file is not closed until all audit messages stored in memory are written to the file.

Creating a New Clusterwide Version of the Log File  

To open a new, clusterwide version of the security audit log file, use the following command:

$ SET AUDIT/SERVER=NEW_LOG
The audit server process opens a new version of the audit log file on each cluster node.

After you open the new log, rename the old version, using a naming convention for your files that incorporates in the file name a beginning or ending date for the data. Then copy the file to another disk, delete the log from the system disk to save space, and run the Audit Analysis utility on the old log.

By archiving this file, you maintain a clusterwide history of auditing messages. If you ever discover a security threat on the system, you can analyze the archived log files for a trail of suspicious user activity during a specified period of time.

Creating a New Node-Specific Version of the Log File  

In some cases, OpenVMS Cluster nodes might not share the same system security audit log file. To create a new, node-specific version of the security audit log file, use the following commands:

$ SET AUDIT/DESTINATION=filespec
$ SET AUDIT/SERVER=NEW_LOG
where filespec is a logical name that points to a node-specific file; for example, SYS$SPECIFIC:[SYSMGR]SECURITY. System security audit log files on other nodes are unaffected.
go to previous page: Setting Up, Maintaining, and Printing the Operator Log File Setting Up, Maintaining, and Printing the Operator Log File
go to next page: Monitoring Operating System PerformanceMonitoring Operating System Performance