Urgent Need for a Distinct Separation Between Auditor Authority and Administrator Authority

WebSphere Application Server users need a Distinct Separation Between Auditor Authority and Administrator Authority

Category:

Security, Auditing, and Compliance

Executive Summary:

The current WebSphere Application Server design allows users such as wasadmin to stop audit events (by disabling checkpoints), effectively preventing the logging of their own actions.

This functionality directly violates fundamental security principles, specifically Separation of Duties (SoD), Non-Repudiation, and Integrity of the audit trail.

This IBM Idea requests an enhancement to restrict users with wasadmin privileges from disabling checkpoints (i.e., stopping audit events). Only users with the Auditor role should have permission to manage (change) audit configuration settings.

Detailed Problem Description:

The ability for a WebSphere Administrator (such as wasadmin) to disable audit checkpoints undermines essential security safeguards:

1. Violation of Separation of Duties (SoD):
   The same individual who makes changes can also prevent those changes from being logged. An administrator should never have the ability to disable logging of their own actions.
2. Compromises Non-Repudiation:
   By disabling the audit trail, an administrator can perform actions without leaving evidence, allowing them to deny (repudiate) having made the change.
3. Compromises Audit Trail Integrity:
   The ability to disable audit logging compromises the integrity of the audit trail 

Discrepancy with IBM Documentation:

Administrative roles - IBM Documentation 
Our document explicitly states that the Auditor role was added to: 
“…allow distinct separation of the authority of an auditor from the authority of the administrator.”

“The administrator will have the monitor role for those panels, however, the administrator cannot modify those panels”
See link https://www.ibm.com/docs/en/was-nd/9.0.5?topic=technology-administrative-roles#rsecadminroles__auditor

However, the current behavior allows administrators to disable checkpoints (i.e. stop audit events), contradicting this documented security goal.

• Current behavior: An Administrator user retains the ability to disable checkpoints (i.e., stop audit events).
• Documentation intent: The design should enforce separation between Auditor Authority and Administrator Authority, where the Administrator cannot stop audit events.

Requested Enhancement:

We require a design change to strictly enforce the separation of Administrator and Auditor authorities as intended by security best practices and implied by existing WebSphere documentation:

1. Users with Administrator Role:
   WebSphere Administrators (e.g., wasadmin) must not be allowed to disable, delete, or modify any audit configuration settings.
2. Dedicated Auditor Role:
   Only users with Auditor role should possess the necessary permissions to manage the audit configurations.
3. Checking Auditor activities:
   Even the Auditor's ability to disable auditing should be highly regulated. Any modification or temporary disabling of auditing by an Auditor should:
   • Be logged
   • Trigger an alert sent to the site administrators
4. Ensure auditors are notified not just when the subsystem fails, but also when audit events (like repository_save_event) are no longer being logged, even if the subsystem is technically operational.

Link: https://www.ibm.com/docs/en/was-nd/9.0.5?topic=infrastructure-configuring-security-audit-subsystem-failure-notifications