Information
If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult, if not impossible, to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage.
To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, copy, etc.
This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions using file system protections and limiting log data location.
Additionally, applications with user interfaces to audit records must not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access.
Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.
Modification or deletion of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.
Satisfies: SRG-APP-000118-DB-000059, SRG-APP-000119-DB-000060, SRG-APP-000120-DB-000061
NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.
Solution
Add controls and modify permissions to protect database audit log data from unauthorized modification, whether stored in the database itself or at the OS level.
Logs are stored in the database:
For Standard Auditing, Revoke access to the AUD$ table to anyone who should not have access to it.
For Unified Auditing, Revoke access to the tables with AUDSYS as the owner.
Use the REVOKE statement to remove permissions from a specific user or from all users to perform actions on database objects.
REVOKE privilege-type ON [ TABLE ] { table-Name | view-Name } FROM grantees
Use the ALL PRIVILEGES privilege type to revoke all of the permissions from the user for the specified table. Can also revoke one or more table privileges by specifying a privilege-list.
Use the DELETE privilege type to revoke permission to delete rows from the specified table.
Use the INSERT privilege type to revoke permission to insert rows into the specified table.
Use the REFERENCES privilege type to revoke permission to create a foreign key reference to the specified table. If a column list is specified with the REFERENCES privilege, the permission is revoked on only the foreign key reference to the specified columns.
Use the SELECT privilege type to revoke permission to perform SELECT statements on a table or view. If a column list is specified with the SELECT privilege, the permission is revoked on only those columns. If no column list is specified, then the privilege is valid on all of the columns in the table.
Use the TRIGGER privilege type to revoke permission to create a trigger on the specified table.
Use the UPDATE privilege type to revoke permission to use the UPDATE statement on the specified table. If a column list is specified, the permission is revoked only on the specified columns.
For file-based/OS level auditing, establish an audit file directory separate from the Oracle Home.
Alter host system permissions to the AUDIT_FILE_DEST directory to the Oracle process and software owner accounts, DBAs, backup accounts, SAs (if required), and auditors.
Authorize and document user access requirements to the directory outside of the Oracle, DBA, and SA account list in the system documentation.