Security auditing is an important part of the security infrastructure.
Security auditing provides a mechanism for auditable events to be tracked
and archived while ensuring the integrity of the records.
Before you begin
Before enabling the security auditing subsystem for service integration,
you must enable global security in your environment.
About this task
The primary responsibility of the security infrastructure is to
prevent unauthorized usage of resources. Security auditing has two primary
goals:
- Confirming the effectiveness and integrity of the existing security configuration.
- Identifying areas where improvement to the security configuration might
be needed.
Security auditing achieves these goals by providing an infrastructure
that you can use to implement your code to capture and store supported security
auditable events. All code other than the Java™ enterprise application code is considered
to be trusted. Each time an enterprise application accesses a resource, any
internal application server process that has audit points that are added within
their code can be recorded as an auditable event. The security auditing subsystem
captures the following types of auditable events:
- Authentication
- Authorization
- Principal and Credential Mapping
- Key management
- System management
- Security policy management
- Audit policy management
- Administrative configuration management
- Administrative runtime management
- User registry and identity management
- Password changes
- Delegation
These types of events can be recorded into audit log files. The
audit log flies can be signed and encrypted to ensure data integrity. These
audit log files can be analyzed to discover breaches over the existing security
mechanisms and to discover potential weaknesses in the current security infrastructure.
Security event audit records are also useful for providing evidence, accountability,
and vulnerability analysis. The security auditing configuration provides four
default filters, a default audit service provider, and a default event factory.
This following steps describe how to customize your security auditing subsystem.
Additional information specific to messaging is included in the step description
where appropriate.
Procedure
- Enabling the security auditing subsystem
Security
auditing is not performed unless the audit security subsystem has been enabled.
Global security must be enabled for the security audit subsystem to function,
as no security events occur if global security is not also enabled.
To
allow messaging security events to be audited, audit security must be enabled:
- For each bus to be audited, click ,
and select the Enable the auditing service for this bus check
box.
- For publish/subscribe messaging, also on each topic space on the bus being
audited, click
,
and select the Enable the auditing service for this topic space check
box.
- Auditor
role
A user with the auditor role is required
to enable and configure the security auditing subsystem. It is important to
require strict access control for security policy management. The auditor
role provides granularity to support separation of the auditing role from
the authority of the administrator.
- Creating security auditing event type filters
You can configure event type filters to only record a specific subset
of auditable event types in your audit logs. Filtering the event types that
are recorded makes for simpler analysis of your audit records by ensuring
the records to only display what you selected as important for your an environment.
The
audit events that can be configured for messaging are:
- SECURITY_AUTHN
- This event is produced when the identity of a messaging client or messaging
engine connecting to a messaging bus is authenticated.
- SECURITY_AUTHZ
- This event is produced when the identity of a messaging client is checked
for access authority to a bus or a message queue when sending, directly or
by publication, or receiving messages, directly or by subscription.
- SECURITY_AUTHN_TERMINATE
- This event is produced when the connection between a messaging client
or messaging engine and a messaging bus is terminated.
- SECURITY_MGMT_CONFIG
- This event is produced when a messaging client changes the contents of
a service data object (SDO) repository in an import or remove operation.
You can create event filters for each permutation of an
event and its possible outcomes such as SUCCESS, DENIED, or error conditions
of different levels of severity.
See messaging security events for more information
on which messaging security audit events are produced and when they are produced.
- Configuring audit service providers for security auditing
The audit service provider is used to format the audit data object
that is passed to it before outputting the data to a repository.
- Configuring audit event factories for security auditing
The audit event factory gathers the data associated with the auditable
events and creates an audit data object. The audit data object is then sent
to the audit service provider to be formatted and recorded to the repository.
- Protecting your security audit data It is important
for the recorded audit data to be both secured and with the data integrity
ensured. To ensure that access to the data is restricted and secure, you can
encrypt and sign your audit data.
- Configuring security audit subsystem failure notifications
You can enable notifications to generate alerts when the security
auditing subsystem experiences a failure. Notifications can be configured
to record an alert in the audit logs or can be configured to send an alert
through email to a specified list of recipients.
Results
After successfully completing this task, you audit data is recorded
for the selected auditable events that were specified in the configuration.
What to do next
After configuring security auditing, you can analyze your audit
data for potential weaknesses in the current security infrastructure and to
discover security breaches that might have occurred over the existing security
mechanisms.