The DBMS must generate audit records when unsuccessful attempts to modify security objects occur.

Changes in the database objects (tables, views, procedures, functions) that record and control permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized changes to the security subsystem could go undetected. The database could be severely compromised or rendered inoperative.

To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.

If the DBMS architecture makes it impossible for any user, even with the highest privileges, to modify the structure and logic of its built-in security objects, and if there are no additional, locally-defined security objects in the database(s), this is not a finding.

Review DBMS documentation to verify that audit records can be produced when the system denies or fails to complete attempts to modify security objects.

If the DBMS is not capable of this, this is a finding.

Review the DBMS/database security and audit configurations to verify that audit records are produced when the system denies attempts to modify security objects.

If they are not produced, this is a finding.

Review the DBMS/database security and audit configurations to verify that audit records are produced when other errors prevent attempts to modify security objects.

If they are not produced, this is a finding.

Deploy a DBMS capable of producing the required audit records when it denies or fails to complete attempts to modify security objects, such as tables, views, procedures, and functions.

Configure the DBMS to produce audit records when it denies attempts to modify security objects, to include reads, creations, modifications, and deletions.

Configure the DBMS to produce audit records when other errors prevent attempts to modify security objects, to include reads, creations, modifications, and deletions.