4. Implementing Security Auditing

Security alarms allow you to specify the events to be recorded in the security audit log for individual tables and databases. Using them, you can place triggers on important databases and tables to detect when users attempt to perform access operations that are not normally expected.

For tables, you can monitor the success or failure of any of the following events:

For databases, you can monitor the success or failure of these events:

Security alarm events are considered successful if the user succeeds in performing the specified type of access. If a particular query triggers a security alarm event, however, it does not necessarily mean that the query completed successfully. It simply means that the security access tests for the specified types of events (for example, select, delete, insert, and update) were passed.

Failure of a security alarm event means that the user attempted to perform the associated operation and failed for some security-related reason. For example, a user can fail to gain access to a table or a database because he or she lacks the required permissions. A query or database operation might fail for other reasons, unrelated to security, but these failures do not trigger the associated security alarm event.

Security alarms can be assigned to specific authorization identifiers (individual users or the public, and groups and roles) so that you can limit monitoring to certain users. You can also specify a database event to be raised when a security alarm is triggered. Database Event Grants describes the database event permissions required to raise an event.

When working with security alarms, you can do the following:

• Create security alarm objects of various types for specific tables and databases

• View existing security alarm objects, including the detailed properties of each individual object

You can accomplish these tasks using the SQL statements CREATE SECURITY_ALARM, HELP SECURITY_ALARM, and DROP SECURITY_ALARM, or using Actian Director or VDBA.

To implement a security alarm, follow these basic steps:

1. Create the security alarm. Issue the CREATE SECURITY_ALARM statement to define the conditions that will trigger the alarm. For example:

(In VDBA, use the appropriate Security Alarm branch in the Database Object Manager window.)

2. Have an authorized user issue the ENABLE SECURITY_AUDIT ALARM statement to enable auditing of security alarms. You can also use ENABLE SECURITY_AUDIT (see Security Auditing) to specify other types of auditing.

When user access to the specified database or table triggers the alarm, a record is written to the audit log and the associated database event, if any is defined, is raised.

1. Issue a HELP SECURITY_ALARM statement to obtain the security alarm number. For example:

A typical scenario is to audit all accesses to databases and security-relevant events (such as the creation and deletion of users and the granting of special privileges). The Vector security administrator, however, may decide that although access to certain tables should be monitored, imposing a general auditing control on all tables is not desired.

• Table “addresses” contains a list of addresses is to be audited. Updates or changes to existing information are to be recorded in the audit log.

• Table “all_summary”, a large database table, is used infrequently. Accesses are to be audited to determine whether it should be archived and deleted.