Configuring the Stand-alone Audit Loader

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. Configuring and Managing Auditing 12-15 Audit policy for system components is managed in their home pages. The domain Audit Policy Settings page manages audit events for Java components running in the domain. The events are organized in a tree structure under the Name column. The tree can be expanded to reveal the details of the events available. Use these steps to view and update audit policies for OPMN-managed components: 1. Log in to Fusion Middleware Control. 2. Using the topology panel to the left, navigate to the system component of interest such as Oracle Internet Directory. 3. From the component menu, navigate to Security, then Audit Policy. The Audit Policy Settings page appears 4. A drop-down list of pre-configured audit levels can be selected. Two pre-defined levels Low, Medium will automatically pick up a subset of the audit events for all the components. ■ None - No events are selected for audit. ■ Low - A small set of events is selected, typically those having the smallest impact on component performance. ■ Medium - This is a superset of the Low set of events. These events may have a higher impact on component performance. ■ Custom - This level enables you to fine-tune the policy, and is described in Step 5 below. The table shows the events you can audit for the component instance. This example is for Oracle Internet Directory: The table consists of these columns: See Also : Section C.1.1, What Components Can be Audited? for the list of auditable components. Note: The table of events under the drop-down box cannot be edited for the pre-defined levels. It can only be edited in custom level. 12-16 Oracle Fusion Middleware Application Security Guide ■ Name - shows the component events grouped by type, such as Authorization events. ■ 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.

7. Click Select Failures Only 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”, a comma-separated list of users can

be specified 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. 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.