An audit administrator sets the audit instructions that the database server performs. The administrator must set an amount of auditing that is comprehensive enough to prove useful but not so exhaustive that it adversely affects system resources. When role separation exists, the DBSSO creates audit masks and the AAO configures mandatory auditing for the DBSA and the DBSSO. You can find advice on how to set the audit instructions in A Guide to Understanding Audit in Trusted Systems (published by the National Computer Security Center, NCSC-TG-001, June 1988).
This section suggests how to choose events to audit, how to set the audit instructions, and how the choices affect performance. For details of how to create and modify audit masks, see Audit Administration.
All the audit masks that the database server uses are stored in the system-monitoring interface (SMI) sysaudit table in the sysmaster database. The masks are updated automatically when the database server is upgraded to a newer version. Although information stored in the sysmaster database is available through SQL, you should use the onaudit utility for all audit-mask creation and maintenance. (See Utility Syntax.) Also, see the description of the sysmaster database in the IBM Informix: Administrator's Reference.
The amount of database server auditing enabled at any given time has a direct effect on operating-system resources and database server performance. Audit records that the database server generates are stored on disk. The greater the number of audit records generated, the more disk space required (for storage), and the greater the amount of CPU time required to process audit records (for storage, viewing, deletion, archiving, and restoration).
How system resources and performance are affected depends on these factors:
For example, a system with parallel-processing capabilities, several terabytes of available disk space, 64 users, and full auditing might experience little degradation in performance and a relatively small disk-space ratio for audit data. However, a single-processor configuration with low disk space, multiple users, and full auditing might experience significant system-resource degradation and relatively rapid disk-space consumption by the audit trail.
From a system performance standpoint, the greatest overhead is incurred when you audit all database server security-related events that all users perform. Full auditing could severely degrade system performance and response time as well as require a significant amount of disk space for audit-record storage (depending on the amount of database server user activity). However, full auditing provides the most audit information and thus reduces the security risk.
You can turn off auditing to eliminate the effect on system performance, but then auditing cannot contribute to system security. At a minimum, we advise that you audit the initiation of new user sessions.
The database server event that, if audited, has the most significant effect on system performance and disk space is Read Row (RDRW). In an established database that is primarily accessed by users who search for information, every row presented to every user generates an audit record. On a high-volume system, this quickly produces large numbers of audit records.
Although database server audit-record generation can adversely affect database server performance and resources, it is still advisable to perform more than minimal auditing. Audit enough events to detect security violations and attempts to circumvent security mechanisms. This section discusses some of the points to remember when you balance security needs with the performance and resource effects of different audit levels.
We recommend that you audit the following events for all standard database server users, at all times, with the _require audit mask:
For Dynamic Server, you should also audit the following events:
The information contained in audit records that are generated when a user modifies discretionary access to an object is important. This information indicates what process changed the access, on what objects, and on whose behalf. In a typical environment, you can expect a low-to-moderate generation rate for audit records of this nature, which results in low disk-space consumption and minimal effect on database server performance.
It is also prudent to audit all database and table Open operations for all regular database server users. Auditing all Open operations indicates the general area within the database server where users are looking. Auditing these operations should not significantly affect database server performance because these operations are performed infrequently compared with other operations.
Creative attempts to circumvent the database server security policy are virtually impossible to detect if minimal or no auditing is performed for regular database server users. If you suspect a security violation or if the database server audit records reveal in the audit trail that a particular user exhibits unusual behavior, enable full auditing for that user. In this way, you can obtain a more complete picture of the activities of the user.
Certain certification and accreditation organizations require that the installation process itself be audited. After configuring the operating system to accept audit data, the OSA should make sure that the AAO audits the actions taken during installation.
The Dynamic Server secure-auditing facility can audit the following events at the fragment level of granularity and shows additional information for fragmented objects:
For more information on the fields in an audit-event record, see Appendix A. Audit Events.
In addition, the database server audits the following events to the RESTRICT/CASCADE level:
For more information on the corresponding SQL statements, see the IBM Informix: Guide to SQL Syntax.
The _require mask can be a valuable tool because it audits every database server user for the events that are specified in this mask. You can use this mask to perform the bulk of the auditing. The _require mask enables you to make rapid changes to the auditing configurations for all users by adding or removing items from this one mask.
The _exclude mask is also useful. It is read last, so its contents take precedence over the instructions in the other masks. As the name implies, the audit events that you specify in the _exclude mask are excluded from auditing. This exclusion is true of every event, including those specified in the _require mask. The Read Row audit event, for example, is a good candidate for the _exclude mask. Read Row is a common event that can generate huge amounts of potentially useless data in the audit trail.
How you use the _default and individual user masks depends on the number of users and their activities. For example, if you have only a few users, you might want to give each one an individual mask. You might then use the _default mask to audit events that are initiated by users who do not normally use your database, and configure the _default mask with a high level of security. To offset any detrimental effects on system performance, set up less-comprehensive individual user masks for frequent users. Or, if you have many users and do not want to create many individual user masks, leave the _default mask empty and rely on the _require mask for most of your auditing.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]