| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
Auditing is the practice of capturing a record of security-related events for the purpose of being able to hold users or systems accountable for their actions. A common misunderstanding of the value of auditing is evident when auditing is used solely to determine whether security mechanisms are serving to limit access to a system. When security is breached, it is usually much more important to know who has been allowed access than who has not. Only by knowing who has interacted with the system do we have a chance of determining who should be held accountable for a breach of security. Moreover, auditing can only be used to evaluate the effective security of a system when there is a clear understanding of what is audited and what is not.
The Deployer is responsible for configuring the security mechanisms that will be applied by the enterprise containers. Each of the configured mechanisms may be thought of as a constraint that the containers will attempt to enforce on interactions between components. It should be possible for the Deployer or System Administrator to review the security constraints established for the platform, and to associate an audit behavior with each constraint so that the container will audit one of the following:
It would also be prudent to audit all changes (resulting from deployment or subsequent administration) to the audit configuration or the constraints being enforced by the platform. Audit records must be protected so that attackers cannot escape accountability for their actions by expunging incriminating records or changing their content.
The J2EE programming model aims to shift the burden of auditing away from developers and integrators to those who are responsible for application deployment and management. Therefore, although not currently mandated by the J2EE specification, we recommend that J2EE containers provide auditing functionality that facilitates the evaluation of container-enforced security policy.