Detections
Analytics

6.1.15 Ensure the 'PROCEDURE' Audit Option Is Enabled

Information

In this statement audit, PROCEDURE means any procedure, function, package or library. Enabling this audit option causes any attempt, successful or not, to create or drop any of these types of objects to be audited, regardless of privilege or lack thereof. Java schema objects (sources, classes, and resources) are considered the same as procedures for the purposes of auditing SQL statements.

Rationale:

Any unauthorized attempts to create or drop a procedure in another's schema should cause concern, whether successful or not. Changes to critical stored code can dramatically change the behavior of the application and produce serious security consequences, including enabling privilege escalation and introducing SQL injection vulnerabilities. Audit records of such changes can be helpful in forensics.

Solution

To remediate this setting, execute the following SQL statement in either the non multi-tenant or container database, it does NOT need run in the pluggable.

AUDIT PROCEDURE;

Notes:

Not all auditing options work alike. In particular, the statement auditing option audit PROCEDURE does indeed audit create and drop library as well as all types of procedures and java schema objects. However, privilege audits do not work this way. So, for example, none of audit CREATE ANY PROCEDURE, audit DROP ANY PROCEDURE, or audit CREATE PROCEDURE will audit create or drop library activities. In statement auditing, PROCEDURE has a larger scope than in privilege auditing, where it is specific to functions, packages and procedures, but excludes libraries and perhaps other object types.

Audit PROCEDURE does not audit altering procedures, either in your own schema or in another via the ALTER ANY PROCEDURE system privilege. There seems to be no statement audit that is a better replacement for Audit ALTER ANY PROCEDURE, but beware that will not create any audit records for users that do not have the privilege. Thus, attempts to alter procedures in one's own schema are never audited, and attempts to alter procedures in another's schema that fail for lack of the ALTER ANY PROCEDURE privilege are not audited. This is simply a weakness in the current state of Oracle auditing. Fortunately, though, all that the ALTER command can be used for regarding procedures, functions, packages and libraries is compile options, so the inability to comprehensively audit alter procedure activities and requests is not as bad as it would be for other object types (USER, PROFILE, etc.)

See Also

https://workbench.cisecurity.org/benchmarks/13413

Item Details

Category: AUDIT AND ACCOUNTABILITY

References: 800-53|AU-3, 800-53|AU-12, CSCv6|6.2, CSCv7|6.2, CSCv7|6.3

Plugin: OracleDB

Control ID: 7f466f25f993eb008f95d2b845f4c30b98357d154368fc935c8d8e88177859b7