Tuning the Bus-stop Files

Configuring and Managing Auditing 12-13 The table consists of these columns: ■ Name - shows components and applications in the domain. ■ Enable Audit - shows whether the corresponding event type is being audited. This column is greyed out unless the Custom audit policy is in force. ■ Filter - shows any filters in effect for the event type. 5. To customize the audit policy, use the Custom option from the drop-down. This allows you to select all the events or hand-pick the appropriate subset as desired by checking the relevant boxes under the Enable Audit column. When you choose the Custom level, an optional filter available for success and failure outcomes of each individual event to further control how they are audited, as explained in Step 6 below. 6. Filters are rule-based expressions that you can define to qualify or filter events for audit. The expressions are based on attributes of the event. For example, a Login type event could specify an initiator as a user filter in which case the event would generate an audit record whenever the specified user logged in. A pencil icon indicates that a filter is available for the corresponding event. Click on the icon to bring up the Edit Filter dialog. Note: Each filter attribute has a formal name and a display name. You may see either name in the filter edit dialog. Display names are shown in the drop-down, while names are shown in the edit dialog. For example, if you select Client Address IP in the drop-down box, it is renamed to RemoteIP after you add it to the filter expression. 12-14 Oracle Fusion Middleware Application Security Guide 7. Click the Select Failures Only button to select only failed events in the policy - for example, a failed authentication. The Enable Audit box is now checked for failed events. 8. ImportExport - These buttons enable you to save and re-use a policy configuration. At any time while editing the policy, click Export to save the current settings to a file, and Import to load the settings from a saved file. 9. Optionally, under “Users to Always Audit”, you can specify a comma-separated list of users to force the audit framework to audit events initiated by these users; auditing occurs regardless of the audit level or filters that have been specified.

10. If you made any policy changes, click Apply to save the changes. For Java

components, you must restart the managed Oracle WebLogic Server on which the affected Java component is running for the changes to be effective. Click Revert to discard any policy changes and revert to the existing policy. About Component Events Each component and application in the domain defines its own set of auditable events. Thus, when you expand the Names column of the table, each component displays a list of events that applies to instances of that component.

12.3.2 Manage Audit Policies for System Components with Fusion Middleware Control

This section describes how to view and update audit policies for system components that are managed through OPMN. Notes: ■ Be aware that if you use this feature to audit key users such as system administrators, this will generate audit traffic anytime that user touches any of the auditable events for any component. For example, a component’s audit policy may be set to None, but if these users perform some activity in the component instance, it is still audited. ■ No validation is performed for user names you enter in this field. Notes: ■ Audit policy for Java components is managed in the domain context. See Section 12.3.1, Manage Audit Policies for Java Components with Fusion Middleware Control ■ See the note at the beginning of Section 12.3, Managing Audit Policies titled Policy Changes Require Server or Instance Restart. Oracle Internet Directory instances do not require a restart.