4.2. Enable security auditing and examine audit data output.

4.2. Enable security auditing and examine audit data output.
Prev	Chapter 4. Security	Next


	[WAS_8.0_INFOCENTER]

Security auditing was introduced in WAS V7. The primary goals of the auditing subsystem are:

Confirm the effectiveness and integrity of the existing security configuration.
Identify areas where improvement to the security configuration might be needed.

The security auditing system has the ability to capture the following types of auditable events:

Authentication
Authorization
Principal-credential mapping
Audit policy management
User registry and identity management
Delegation
Administrative configuration management

NOTE: Before enabling security auditing, the following steps needs to be completed:

Global security must be enabled
A user with the Auditor role is required to enable and configure the security auditing subsystem.

Here are the steps to configure and use the security auditing subsystem:

Enable Security auditing
- Go to Global security > Security auditing, in the administration console (ISC).
- Select the Enable security auditing checkbox.
- Select the action from the Audit subsystem failure action dropdown list to be perform when an audit subsystem failure occurs.
- Select the Auditor ID from the Primary auditor user name dropdown list. The Auditor role is needed to make changes to the security auditing configurations.
- Click Apply and save configuration.
Figure 4.3.
Define Event type filters

Figure 4.4.

Event type filters are used to specify the types of auditable security events that are audited. Default event type filters are included with the product, but you can also configure new event type filters to specify a subset of auditable event types to be recorded by the security auditing subsystem.
Default filters:
Figure 4.5.

Procedure to create new filters:
1. Click Security > Security auditing > Event type filters > New...
  Figure 4.6.
2. Enter a unique name for the new filter.
3. Select what events should be recorded when this filter is applied:
  - Select the events that you want to be audited from the Selectable events list.
  - Click => to add the selected events to the Enabled events list.
  - Select the outcomes that you want to audit from the Selectable event outcomes list.
  - Click => to add the selected outcomes to the Enabled event outcomes list.
4. Click OK and save the changes.
Figure 4.7.

Now we have a new filter which can be specified in audit service provider and the audit event factory.
Configure Audit service provider
The Audit service provider is used to format the audit data object that was passed to it before outputting the data to a repository. By default, you will find one audit service provider. However you can create new audit service provider. The new security audit provider can be binary file based emitter [default] or any third-party audit service provider.
1. Go to Global security > Security auditing
  
  Figure 4.8.
2. Click on Audit service provider and click on New
  
  Figure 4.9.
3. Select Binary file-based emitter
  Enter a unique name for the new Audit service provider.
  Specify the Audit log file location.
  Enter the maximum size of the audit log, default size is 10 megabytes.
  Enter the maximum number of audit logs to store, before the oldest log is rewritten.
  Behavior when maximum reached:
  - Overwrite oldest: the oldest audit log is rewritten; notification is not sent to the auditor.
  - Stop server: It stops the audit service, sends a notification to the SystemOut.log, and quiesces the application server.
  - Step Logging: stops the audit service, but does allow the WebSphere process to continue. Notifications are not posted in the SystemOut.log.
  Select the filters that can be used by the audit service provider and click =>
  
  Figure 4.10.
4. Click on Apply and save the changes.
  
  Figure 4.11.
Create Audit event factory
The audit event factory collects the data associated with the auditable security events and builds the audit data object. The object is then sent to the audit service provider to be formatted and recorded to a specified repository. By default, one audit event factory is available. However you can your own new audit event factory.
1. Go to Global security > Security auditing
  
  Figure 4.12.
2. Click Audit event factory configuration > New...
3. Enter a unique name for the new audit event factory.
  Select either IBM audit event factory or Third party event factory radiobutton. If you select third party event factory, input its class name.
  Select the audit service provider (created above)
  Select the event type filters (created above).
  Enter custom properties that are required [if any]
  
  Figure 4.13.
4. Click Apply and save changes.
  
  Figure 4.14.
Secure audit data
Your audit data has the option to be encrypted, signed or encrypted and signed.
Encryption: Audit logs can be encrypted to ensure your audit data is protected. The audit logs will be encrypted using a certificate that is saved to a keystore in the audit.xml file. By encrypting your audit records, only users with the password to the keystore will be able to view or update the audit logs.
1. Go to Security auditing > Related items > Audit encryption keystores and certificates.
  
  Figure 4.15.
2. Click on New and create a new keystore.
  
  Figure 4.16.
  
  Click OK and save changes.
3. Now create a new personal certificate in the keystore.
  Click on the [keystore name] > Personal certificates > Create self-signed Certificate...
  
  Figure 4.17.
Now configure the encryption:
1. Select Security auditing > Related Items > Audit record encryption configuration.
  Figure 4.18.
2. Select Enable encryption check box.
3. Select the keystore that we created earlier from the dropdown.
4. Select the self-signed certificate that we created earlier from the dropdown. Or you can create a new personal certificate also.
5. Click OK and save changes.
Signing: Audit logs can be signed to ensure the integrity of your audit data. By signing your audit records, modifications of the audit logs can be traced.
1. Go to Security auditing > Related Items > Audit record signing configuration
  
  Figure 4.19.
2. Select Enable signing check box.
  Select the keystore that has the signing certificate, from the dropdown.
  Then select the signing certificate from the dropdown or create a new certificate in the selected key store. You can create a new certificate using Automatically generate certificate option.
  Figure 4.20.
3. Click OK and save changes.
Define Audit monitoring
Notifications can be enabled to generate alerts when the security auditing subsystem experiences a failure. Notifications can be configured to record an alert in the System logs or can be configured to send an alert through email to a specified list of recipients.
1. Go to Security auditing > Related Items > Audit monitor
  Figure 4.21.
2. Click on New... under notifications.
  Enter a name for the notification.
  Select the Message log check box to specify the failure notifications are recorded in the audit log.
  Select the Email sent to notification list check box to specify that failure notification email should be sent to the addresses listed in the notification list.
  Enter the email address to add and outgoing mail [SMTP] server name.
  Click =>, to add the email address.
  Click OK and save changes.
  
  Figure 4.22.
3. Select Enable monitoring checkbox.
  Select Monitor notification in drop down list.
  Figure 4.23.
4. Click OK and save the changes.

After you finished all the steps, restart the server for the changes to take effect.

Prev	Up	Next
Chapter 4. Security	Home	4.3. Configure user repositories (e.g., federated, standalone LDAP, local OS).