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