Developing an Auditing Plan
» Table of Contents |  | | » Glossary | | | » Index | | |
| | |
| ||
| ||
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:
Determine your site's general security requirements: are they high, moderate, or low? Table 1-1 “Event Tolerance as a Measure of Security Requirements”Table 1-1 provides some guidance on determining your security needs.
Once you know your site's needs, refer to Table 9-4 “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 Table 9-4 “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 9-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 Table 9-4 “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:
|
|
|
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 “Auditing Events for a Site with Moderate Security Requirements” shows the auditing setting for a site with moderate security requirements.
Example 9-3 Auditing Events for a Site with Moderate Security Requirements
|
|
|
To enable the settings for a moderate level of auditing, assuming the default events are already in effect, enter the following set of commands:
|
|
|
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:
|
|
|
|
|
|
|
|
|
See “Security Auditing” for more suggestions of event classes to enable.
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.
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.