Detections
Analytics
O19C-00-002000 - Oracle Database must generate audit records for the DOD-selected list of auditable events, when successfully accessed, added, modified, or deleted, to the extent such information is available.
Warning! Audit Deprecated
This audit has been deprecated and will be removed in a future update.
View Next Audit VersionInformation
Audit records can be generated from various components within the information system, such as network interfaces, hard disks, modems, etc. From an application perspective, certain specific application functionalities may be audited, as well.The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events, timestamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked).
Organizations may define the organizational personnel accountable for determining which application components must provide auditable events.
Auditing provides accountability for changes made to the database management system (DBMS) configuration or its objects and data. It provides a means to discover suspicious activity and unauthorized changes. Without auditing, a compromise may go undetected and without a means to determine accountability.
The Department of Defense has established the following as the minimum set of auditable events:
- When privileges/permissions are retrieved, added, modified or deleted.
- When unsuccessful attempts to retrieve, add, modify, delete privileges/permissions occur.
- Enforcement of access restrictions associated with changes to the configuration of the database(s).
- When security objects are accessed, modified, or deleted.
- When unsuccessful attempts to access, modify, or delete security objects occur.
- When categories of information (e.g., classification levels/security levels) are accessed, created, modified, or deleted.
- When unsuccessful attempts to access, create, modify, or delete categorized information occur.
- All privileged activities or other system-level access.
- When unsuccessful attempts to execute privileged activities or other system-level access occurs.
- When successful or unsuccessful access to any other objects occur as specifically defined by the site.
Satisfies: SRG-APP-000091-DB-000066, SRG-APP-000091-DB-000325, SRG-APP-000492-DB-000333, SRG-APP-000494-DB-000344, SRG-APP-000494-DB-000345, SRG-APP-000495-DB-000326, SRG-APP-000495-DB-000327, SRG-APP-000495-DB-000328, SRG-APP-000495-DB-000329, SRG-APP-000496-DB-000334, SRG-APP-000496-DB-000335, SRG-APP-000498-DB-000346, SRG-APP-000498-DB-000347, SRG-APP-000499-DB-000330, SRG-APP-000499-DB-000331, SRG-APP-000501-DB-000336, SRG-APP-000501-DB-000337, SRG-APP-000502-DB-000348, SRG-APP-000502-DB-000349, SRG-APP-000503-DB-000350, SRG-APP-000503-DB-000351, SRG-APP-000504-DB-000354, SRG-APP-000504-DB-000355, SRG-APP-000505-DB-000352, SRG-APP-000506-DB-000353, SRG-APP-000507-DB-000357, SRG-APP-000508-DB-000358
Solution
Both Standard and Unified Auditing are allowed in Oracle Database 19c.The default is mixed auditing mode.
The predefined policy ORA_SECURECONFIG is enabled by default in mixed mode.
Configure the DBMS's auditing settings to include auditing of events on the DOD-selected list of auditable events.
1. Successful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels).
To audit granting and revocation of any privilege:
CREATE AUDIT POLICY <policy_name> ACTIONS GRANT;
CREATE AUDIT POLICY <policy_name> ACTIONS REVOKE;
To audit grants of object privileges on a specific object:
CREATE AUDIT POLICY <policy_name> ACTIONS GRANT ON <schema>.<object>;
If Oracle Label Security is enabled, this will audit all OLS administrative actions:
CREATE AUDIT POLICY <policy_name> ACTIONS COMPONENT = OLS ALL;
2. Successful and unsuccessful logon attempts, privileged activities or other system-level access.
To audit all user logon attempts:
CREATE AUDIT POLICY <policy_name> ACTIONS LOGON;
To audit only logon attempts using administrative privileges (e.g., AS SYSDBA):
AUDIT POLICY <policy_name> BY sys, sysoper, sysbackup, sysdg, syskm;
3. Starting and ending time for user access to the system, concurrent logons from different workstations.
This policy will audit all logon and logoff events. An individual session is identified in the UNIFIED_AUDIT_TRAIL by the tuple (DBID, INSTANCE_ID, SESSIONID) and the start and end time will be indicated by the EVENT_TIMESTAMP of the logon and logoff events:
CREATE AUDIT POLICY <policy_name> ACTIONS logon, logoff;
4. Successful and unsuccessful accesses to objects.
To audit all accesses to a specific table:
CREATE AUDIT POLICY <policy_name> ACTIONS select, insert, delete, alter ON <schema>.<object>;
Different actions are defined for other object types. To audit all supported actions on a specific object:
CREATE AUDIT POLICY <policy_name> ACTIONS all ON <schema>.<object>;
5. All program initiations.
To audit execution of any PL/SQL program unit:
CREATE AUDIT POLICY <policy_name> ACTIONS execute;
To audit execution of a specific function, procedure, or package:
CREATE AUDIT POLICY <policy_name> ACTIONS execute ON <schema>.<object>;
6. All direct access to the information system.
[Not applicable to Database audit. Monitor using OS auditing.]
7. All account creations, modifications, disabling, and terminations.
To audit all user administration actions:
CREATE AUDIT POLICY <policy_name> actions create user, alter user, drop user, change password;
8. All kernel module loads, unloads, and restarts.
[Not applicable to Database audit. Monitor using OS auditing.]
9. All database parameter changes.
To audit any database parameter changes, dynamic or static:
CREATE AUDIT POLICY <policy_name> ACTIONS alter database, alter system, create spfile;
Applying the Policy:
The following command will enable the policy in all database sessions and audit both successful and unsuccessful actions:
AUDIT POLICY <policy_name>;
To audit only unsuccessful actions, add the WHENEVER NOT SUCCESSFUL modifier:
AUDIT POLICY <policy_name> WHENEVER NOT SUCCESSFUL;
Either command above can be limited to only database sessions started by a specific user as follows:
AUDIT POLICY <policy_name> BY <user>;
AUDIT POLICY <policy_name> BY <user> WHENEVER NOT SUCCESSFUL;
See Also
https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_Oracle_Database_19c_V1R4_STIG.zip
Item Details
Audit Name: DISA Oracle Database 19c STIG v1r4 OracleDB
References: CAT|II, CCI|CCI-000172, Rule-ID|SV-270504r1167741_rule, STIG-ID|O19C-00-002000, Vuln-ID|V-270504
Plugin: OracleDB
Control ID: f6d5c012317f411c208d1c515136a1f5b79033f8893ecb7856a93b57348e302d