The very first item in the STIG reads as follows:
Group ID (Vulid): V-2420
Group Title: DBMS software monitoring
Rule ID: SV-24597r1_rule
Severity: CAT III
Rule Version (STIG-ID): DG0010-ORACLE11
Rule Title: Database executable and configuration files should be monitored for unauthorized modifications.
Vulnerability Discussion: Changes to files in the DBMS software directory including executable, configuration, script, or batch files can indicate malicious compromise of the software files. Changes to non-executable files, such as log files and data files, do not usually reflect unauthorized changes, but are modified by the DBMS as part of normal operation. These modifications can be ignored.
The third item is very similar, if not identical:
Group ID (Vulid): V-2423
Group Title: DBMS software and configuration file monitoring
Rule ID: SV-24383r1_rule
Severity: CAT II
Rule Version (STIG-ID): DG0050-ORACLE11
Rule Title: Database software, applications and configuration files should be monitored to discover unauthorized changes.
Vulnerability Discussion: Unmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.
The key words here are “changes to files in the DBMS software directory … can indicate malicious compromise of the software.” We are therefore advised to monitor our files for unauthorized modifications. This sounds like one of the simplest things to do, but can actually be quite tricky. The basic approach recommended by the STIG authors is to dump the output of an “ls -as” command to a file and then compare to a previous dump, possibly using checksums. This is very, very basic (the authors of the STIG even warn us that “these are not as comprehensive as some tools available”) and fails to consider some important questions, like how often should we run our comparison, and how will we tell the difference between a normal, expected change and a malicious one? In the event that we do find a difference, this approach also fails to tell us some very important information: when was the file actually modified, and who modified it?
There are commercial tools out there like the venerable Tripwire that can monitor changes to specific files, directories or file types much more closely, but these cost money which is often in short supply. An alternative to these sorts of tools is the auditd service, which is available on most Linux distributions. For those not familiar with it, a brief overview of auditd is available here.
Auditd is very flexible, and can be configured to monitor any number of things. A good place to start (emphasis on start) with your rules configuration is the stig.rules file, available directly from Red Hat. This rule set was developed to help system administrators meet the requirements of the Linux OS STIG, and is not specifically geared towards database servers. As such, these rules can generate a lot of unnecessary audits on Oracle files as they tend to catch every access to every library and every acceptable internal modification that Oracle performs. On a busy system this can amount to hundreds of audits per second. Depending on the amount of disk capacity you have, your log monitoring infrastructure, and the history requirements for your audit trail you may want to limit the forms of access that you record.
Once your auditd configuration is tuned you will have excellent visibility into the changes made to your critical infrastructure files, including when modifications took place, who modified the files, and how the access or modification was accomplished. Changes can be captured in real time with many varieties of open source or commercial monitoring software and alerts generated when specific files are accessed or changed.
All quotations from the Database STIG taken from:
Defense Information Systems Agency. Oracle 11 Database Installation STIG Version 8 Release 1.10. http://iase.disa.mil/stigs/app-security/database/Pages/index.aspx. Published January 2014. Accessed April 4, 2014.