Example of Using Filter Rules

Alice in Company (cell) X is responsible for activating some operations (event class critical_transactions). Other principals in the company are also authorized to activate the same operations, but only under certain conditions; for example, when Alice is not available. The system administrator wants to log an audit record regardless of the event outcome (that is, audit conditions = all) or who activates these operations. The administrator also wants to generate an alarm if the activator is not Alice. This specification is implemented by the following two filters:

Filter 1:

filter type: principal
key: Alice
guide 1:
audit conditions - all
audit actions - log
event classes - critical_transactions

Filter 2:

filter type: cell_overridable
key: X
guide 1:
audit conditions - all
audit actions - log, alarm
event classes - critical_transactions

When Alice invokes events in the critical_transactions event class, the principal filter (filter 1) is applicable because its key matches Alice's identity. The principal filter is more specific than the cell filter. Although the cell filter (filter 2) is also applicable to Alice (Alice belongs to cell X), it is overridden by the principal filter because the cell filter is overridable. For other principals in Company (cell) X, the only applicable filter is the cell filter (filter 2). Thus, these same events will cause an audit record to be logged and also raise an alarm.

Nonoverridable world and cell filters are also useful. Without them, an administrator, for example, would have to delete all filters for groups and principals of a cell in order to make a cell-wide filter effective to the whole cell. (System administrators may want to introduce a temporary nonoverridable cell filter when a cell is suspected to be the source of a security problem.)

The following figure illustrates the override relations between different types of filters. An arrow from filter type X to filter type Y means that X overrides Y.

Override Relations Between Filter Types

DCE groups are generally defined for the purpose of granting access permissions. A group filter specifies auditing the intent to use the group's privileges, instead of specifying auditing the principals that belong to the group. That is, a group filter would not have auditing effects on a member principal of the group unless the principal has the intent to use the group's privileges (by including the group in the PAC). Because group filters are defined to audit the intention of using a group's privileges, they are independent of other filters and are not overridable.