Routine System Surveillance
» Table of Contents |  | | » Glossary | | | » Index | | |
| | |
| ||
| ||
The operating system provides a number of mechanisms that allow systematic surveillance of the activity in your system. There are many mechanisms available for monitoring the system either manually or by user-written command procedures, for example:
Accounting utility (ACCOUNTING)
Authorize utility (AUTHORIZE)
Install utility (INSTALL)
System Management utility (SYSMAN)
Proper use of such mechanisms should help you verify settings, alert you to problems, and allow you to intervene. This section describes the most important system surveillance mechanisms--ACCOUNTING and ANALYZE/AUDIT.
You can learn what the normal pattern of resource use is by studying reports of the Accounting utility (ACCOUNTING). To obtain a report, you run the utility image SYS$SYSTEM:ACC.EXE. The resulting data file is SYS$MANAGER:ACCOUNTNG.DAT. Review ACCOUNTING reports because they can provide early indications of problems. Check for the following:
Unfamiliar user names
Unfamiliar patterns of use, such as unusual activity for a particular time of day or day of week
Use of an unusual amount of resources
Unfamiliar sources of login, such as network nodes or remote terminals
As the security administrator, you can have the operating system report on security-related activity by enabling categories of events for auditing using the DCL command SET AUDIT. Using the Audit Analysis utility (ANALYZE/AUDIT), you can periodically review event messages collected in the security audit log file. (See Chapter 9 “Security Auditing” for a full description of the process.)
The operating system can send event messages to an audit log file or to an operator terminal. You define whether events are reported as audits or alarms in the following way:
Ordinarily, enable audits rather than alarms for security-related events because the audit records are written to the system security audit log where you can study them in volume and archive log files for future reference. While an isolated auditing message may offer little insight, numerous audit records produce a pattern of security violations. For example, with auditing of object access, you can see a pattern of time, types of objects being accessed, and other system information that, in total, paint a picture of how the system is being used at different times of day.
To enable audits for unsuccessful access to files, devices, and volumes, enter the following command:
$ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=(FILE,DEVICE,VOLUME)This command records unsuccessful access events in the security audit log file but sends no alarms to the operator terminal.
Enable security alarms for real-time events or events that should be reviewed immediately, for example, intrusion attempts or changes to the system user authorization file (SYSUAF.DAT). For example, to enable alarms for modification to the known file list and changes to system time, enter the following command:
$ SET AUDIT/ALARM/ENABLE=(INSTALL,TIME)This command sends event messages to the operator terminal. To keep a hardcopy record of these alarms, use a hardcopy operator terminal, or enable the events as both alarms and audits.
Because security auditing affects system performance, enable auditing only for the most important events. The following security-auditing actions are presented in order of decreasing priority and increasing system cost:
Enable security auditing for login failures and break-ins. This is the best way to detect probing by outsiders (and insiders looking for accounts). All sites needing security should enable alarms for these events.
Enable security auditing for logins. Auditing successful logins from the more suspicious sources like remote and dialup users provides the best way to track which accounts are being used. An audit record is written before users logging in to a privileged account can disguise their identity.
Enable security auditing for unsuccessful file access (ACCESS=FAILURE). This technique audits all file-protection violations and is an excellent method of catching probers.
Apply ACL-based file access auditing to detect write access to critical system files. The most important files to audit are shown in Table 10-1 “System Files Benefiting from ACL-Based Auditing”. (Table 9-2 “Access Control Entries (ACEs) for Security Auditing” presents an example of how to establish security entries in ACLs.) You may want to audit only successful access to these files to detect penetration, or you may want to audit access failures to detect probing as well.
Note that some of the files in Table 10-1 “System Files Benefiting from ACL-Based Auditing” are written during normal system operation. For example, SYSUAF.DAT is written during each login, and SYSMGR.DIR is written when the system boots.
Table 10-1 System Files Benefiting from ACL-Based Auditing
Device and Directory File Name SYS$SYSTEM
AUTHORIZE.EXE
F11BXQP.EXE
LOGINOUT.EXE
DCL.EXE
JOBCTL.EXE
SYSUAF.DAT
NETPROXY.DAT
RIGHTSLIST.DAT
STARTUP.COM
VMS$OBJECTS.DAT
SYS$LIBRARY
SECURESHR.EXE
SECURESHRP.EXE
SYS$MANAGER
VMS$AUDIT_SERVER.DAT
SY*.COM
VMSIMAGES.DAT
SYS$SYSROOT
[000000]SYSEXE.DIR
[000000]SYSLIB.DIR
[000000]SYS$LDR.DIR
[000000]SYSMGR.DIR
Enable security auditing for modifications to system parameters or the known file list (/ENABLE=(SYSGEN,INSTALL) ).
Audit use of privilege to access files (either write access or all forms of access). Implement the security audit with the keywords ACCESS=(SYSPRV,BYPASS,READALL,GRPPRV). Note that this class of auditing can produce a large volume of output because privileges are often used in normal system operation for such tasks as mail delivery and operator backups.
“Developing an Auditing Plan” provides further discussion of recommended sets of security events to audit.