![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
The operating system calls the $CHKPRO system service any time a process (subject) attempts to access a protected object. The system service performs the access arbitration according to the rules described in Section 4.3. By looking at the SET AUDIT settings for the associated object class, the service also determines whether you enabled auditing for the associated object access event. When an alarm or an audit is required, $CHKPRO generates an audit record that identifies the process (subject) and object involved and includes the final outcome and any supplemental event information supplied by its caller.
Privileged server processes use the $CHECK_ACCESS system service to determine whether their clients should be allowed access to the protected objects being served. The $CHECK_ACCESS system service provides a calling interface appropriate for servers and is layered on top of the $CHKPRO service. As a result, it performs object access auditing in the same manner as $CHKPRO.
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 is a two-step process:
After developing a general notion of your site requirements, you need to consider how much security reporting is realistic. Balance the suggestions in Table 9-4 with the following site factors:
| 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 Table 9-4, 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. Example 9-3 shows the auditing setting for a site with moderate security requirements.
Example 9-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
Logfailure: batch,dialup,local,remote,network,subprocess,detached
Logout: batch,dialup,local,remote,network,subprocess,detached
Privilege use:
ACNT ALLSPOOL ALTPRI AUDIT BUG BYPASS CMEXEC CMKRNL
DETACH DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPORT
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
DETACH DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPORT
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=*
$ SET AUDIT/AUDIT/ENABLE=ALL/CLASS=*
$ SET AUDIT/AUDIT/DISABLE=ALL/CLASS=*
See Section 10.3.2 for more suggestions of event classes to enable.
The operating system can report a security event as either an alarm or an audit (see Section 9.2.1.1). 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. Section 9.5 describes how to produce reports from audit log files.
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 frequently 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, Digital 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:
Two commands in particular generate a large number of audit messages:
The operating system can send event messages to an audit log file or to an operator terminal. If a site wants additional copies, it can send duplicate messages to a remote log file or an application listener mailbox.
The operating system writes all security event messages to the latest version of the security audit log file. This log file is created by default during system startup in the SYS$COMMON:[SYSMGR] directory and named SECURITY.AUDIT$JOURNAL. Table 9-5 describes some of its more notable characteristics.
Ordinarily, all cluster events are written to a single audit log file. The use of one security audit log file in a cluster results in a single record of all security-relevant events on the system. For this reason, one clusterwide log file is preferable to node-specific audit logs, which lose the interrelationship of events across the cluster, thus producing an incomplete analysis of security events. You can, if you wish, create node-specific audit logs (see Section 9.4.1.1), but this is not the recommended procedure.
| Characteristic | Advantage |
|---|---|
| Binary | A binary file requires the least amount of disk space. |
| Clusterwide | A clusterwide file, when processed by the Audit Analysis utility, results in one report of security-relevant events in the cluster. |
| Sequential record format | A sequential record format is easily analyzed by user-written programs. See the OpenVMS System Management Utilities Reference Manual for a description of the message format of the security audit log file. |
The usefulness of the security audit log file depends upon the procedures you adopt:
The security audit log file continues to grow until action is taken, so you must devise a plan for maintaining it.
Typically, sites rename each day's log file and create a new one. To open a new, clusterwide version of the security audit log file, use the following command:
$ SET AUDIT/SERVER=NEW_LOG
To create a new, node-specific log, precede the SET AUDIT/SERVER=NEW_LOG command with the command SET AUDIT/DESTINATION=filespec where the file specification includes a logical name that resolves to a node-specific file (for example, SYS$SPECIFIC:[SYSMGR]SECURITY).
Once you have opened the new log, rename the old version with a name that incorporates a beginning or ending date for the data.
To save space on the system disk, you may want to copy the file to another disk and delete the log from the system disk. Even sites with a dedicated auditing disk, which is common to environments with high security requirements, may want to relocate the old version to make space for future messages.
Once you archive the file, run the Audit Analysis utility on the old log (see Section 9.5.2). 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.
To relocate the file from the SYS$COMMON:[SYSMGR] directory, edit the command procedure SYSECURITY.COM. This procedure executes each time the system is rebooted, before the audit server is started.
To relocate the file, perform the following steps:
$ IF .NOT. F$GETDVI("$1$DUA2","MNT") -
_$ THEN MOUNT/SYSTEM $1$DUA2 AUDIT AUDIT$ /NOREBUILD
$ DEFINE/SYSTEM/EXEC VMS$AUDIT_SERVER AUDIT$:[AUDIT]VMS$AUDIT_SERVER.DAT
$ SET AUDIT/JOURNAL=SECURITY - _$ /DESTINATION=AUDIT$:[AUDIT]SECURITY
The operating system sends alarm messages to terminals enabled for security class messages. In most cases, these security alarms appear on the system console by default. Because 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. Choose either a terminal in a secure location that provides hardcopy output or have dedicated staff to monitor the security operator terminal. Any number of terminals can be enabled 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
For long-term use of a specific terminal, you can modify your site-specific startup command procedure to automatically enable the terminal. For example, the following command lines in a startup command procedure disable the delivery of security alarms to the system console and enable alarms on terminal TTA3:
$ DEFINE/USER SYS$COMMAND OPA0: $ REPLY/DISABLE=SECURITY $ DEFINE/USER SYS$COMMAND TTA3: $ REPLY/ENABLE=SECURITY
The authorization and SYSGEN event classes occasionally produce such lengthy alarm messages that the messages get truncated. For this reason, it is best to enable these classes for both alarms and audits. When an alarm message is truncated, the text indicates it is incomplete. As long as you have enabled the classes for audit messages, you can use ANALYZE/AUDIT to display the complete message.
The operator terminal and the audit log file are the primary destinations for security event messages. A site can choose to send copies of audit messages to a remote log file (called an archive file) or a listener mailbox.
The operating system allows workstations and other users with limited management resources to duplicate their audit log file on another node. This secondary log, the security archive file, is then available to a security administrator on a remote note who has the skills to analyze the file. In some situations, the archive file can also provide insurance should the local audit log file be tampered with in some way. one node can direct auditing messages to an archive file. Once enabled, the audit server writes a copy of each auditing message to the security archive file as well as to the security audit log file.
Note
Each node in a cluster must have its own archive file. An archive file cannot be shared by multiple nodes in a cluster.
Use the following procedure to write security audit messages to a remote security archive file:
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD AUDIT_ARCHIVE /ACCESS=NETWORK /DEVICE=WORK2- _UAF> /DIRECTORY=[AUDIT_ARCHIVE]
UAF> ADD/PROXY SMLNOD::AUDIT$SERVER AUDIT_ARCHIVE/DEFAULT UAF> EXIT
$ SET AUDIT/ARCHIVE=ALL/DESTINATION=BIGNOD::WORK2:- _$ [AUDIT_ARCHIVE]SMLNOD_MAY_93.AUDIT$JOURNAL
To create a new archive file, rename the current file; the next time the system starts up, it creates a new one for you.
If the network goes down, messages intended for the security archive file are lost. Security operator terminals receive notice of the lost connection and the number of lost messages. Once the network is up, the audit server reestablishes connection to the original archive file and continues writing event messages.
Analyzing the security archive file is identical, in most respects, to analysis of the security audit log file. You can analyze a remote security archive file at any time, even while the file is open. See Section 9.5 for more information.
As an additional feature of the security auditing facility, you can create a listener device to receive a binary copy of all security-auditing messages. (A listener device is a permanent or temporary mailbox that you create with the Create Mailbox [$CREMBX] system service.) You can set up an application to receive and process auditing information and react to events as they occur on the system. Each system can have one listener device, and it can receive only events that are occurring on the local node.
To enable the listener device to receive security-auditing messages, execute the SET AUDIT/LISTENER command in the following format:
SET AUDIT/LISTENER=device-name
For the device-name parameter, supply either the logical name specified when you created the mailbox or the equivalence name of the mailbox, in the form of MBAn, where n represents the unit number of the mailbox. If you create the device as a temporary mailbox, you must use the Get Device and Volume Information ($GETDVI) system service to return the mailbox device name.
To disable a listener device, enter the following command:
$ SET AUDIT/NOLISTENER
On VAX systems, refer to the files AUDSRV_LISTENER.B32 (a VAX BLISS program) and AUDSRV_LISTENER.MAR (a VAX MACRO program) in the SYS$EXAMPLES directory for examples of a program that processes audit-event messages sent to a listener mailbox on a DECtalk device.
Collecting security audit messages in the security audit log file is useless without periodically reviewing it for suspicious activity. You use the Audit Analysis utility (ANALYZE/AUDIT) to examine the data in the security audit log file.
ANALYZE/AUDIT generates a report from the log file so that you become familiar with normal activity on your system and can easily spot atypical activity. It summarizes events for you and plots where activity is occurring on the cluster. The utility also helps you analyze atypical activity because it is capable of selecting a subset of information from an audit report and of providing fuller information for your analysis. While the analysis of a single audit log file might not be significant, audit records can, over time, reveal a pattern of activity that indicates security violations.
This section describes how to analyze audit log files on your system. Although the way you use ANALYZE/AUDIT depends upon the security needs at your site, there are a number of common steps that you should follow, regardless of the extent to which you use the utility. Before you can recognize potential security problems, you need to become familiar with the normal operation of your system. Then you can develop a procedure for generating and reviewing audit reports on a periodic basis. Whenever your regular analysis of audit log files leads you to suspect a security problem, you should perform a detailed investigation of selected security events.
As a security administrator, you should be able to answer the following questions before analyzing an audit log file:
By knowing the answers to these questions, you can eliminate false alarms, which otherwise may cause you to wrongly suspect a security problem.
Step 2: Periodically Analyze the Audit Report
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. (You can use the same procedure to create a new version of the audit log [see Section 9.4.1.1].)
The following example shows the ANALYZE/AUDIT command line to generate this report:
$ ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31DEC1995.AUDIT - (1) _$ SYS$MANAGER:SECURITY.AUDIT$JOURNAL $ MAIL/SUBJECT="Security Events" 31DEC1995.AUDIT SYSTEM (2)
Depending on the number of security events that you are auditing on your system, it can be impractical to review every audit record written to the audit log file. In this case, you can select a specific set of records from the log file, such as all audit records related to changes in the authorization database and break-in attempts, or all events occurring outside normal business hours.
Analyze any subprocess-related audits with the knowledge that a pipe subprocess (created by the DCL PIPE command) can generate the audits. The 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).
6346P017.HTM OSSG Documentation 22-NOV-1996 13:05:16.35
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.