In my last post, I walked you through the first part of installing the Oracle Database 12c STIG compliance standards sample code. The next step to using these compliance standards is to associate your Oracle Database 12c databases with these standards. You may recall there are two separate standards in the sample code, one for multitenant databases and the other for conventional architecture databases. The process of associating the databases is the same in each case. You simply have to choose the compliance standard that matches your architecture. In this walkthrough, I will show you how to associate a multitenant database with the “Oracle 12c PDB STIG” compliance standard.
The first step is to go to the “Compliance Standards” tab on the “Compliance Framework” page. To access this, follow the menu path “Enterprise” -> “Compliance” -> “Library”:
Click on the “Compliance Standards” tab, then select the “Oracle 12c PDB STIG” compliance standard and click on “Associate Targets”:
On the “Compliance Standard Target Association” page, click the “Add” button:
On the “Select Targets” pop-up, select the databases you want and click the “Select” button (this is my test environment so a lot of the remaining databases are down at the moment):
Back on the “Compliance Standard Target Association” page, click “OK”:
Click “Yes” on the “Save Association” pop-up:
You will see an informational message that the compliance standard has been submitted to the target for processing, and the association count value for the standard is now 1. Click “OK” to close the informational window:
Next, we want to look at the results of the target association, so from the “Enterprise” menu, select “Compliance” and then “Dashboard”:
We can see immediately that we have a lot of issues to address, as the Oracle 12c Database STIG shows an average compliance score in the “Compliance Summary” region of only 22% (please note, the number in your environment may vary from this). You can also see this graphically by selecting the framework from the dropdown list in the “Compliance Framework Summary” region:
TIP: If you see an average compliance score of 0%, this means the evaluation did not complete successfully. One of the main reasons for this is if the DBSNMP account is not available to login as. For example, if the account is locked, expired, or even giving a message that it is about to expire, the evaluation won’t complete. Note that the DBSNMP account can be open in a CDB, but expired in a PDB. To address that it can be easiest to simply login to the CDB, and enter the command:
ALTER USER dbsnmp IDENTIFIED BY <password> CONTAINER=ALL;
Clearly, you can do it container by container if you want to have different passwords for the DBSNMP user in different PDB’s.
If you click on the compliance score in the “Compliance Framework Summary” region, you get a little more information along with the ability to drill in for more details. Click on “Click here for more information …”:
This will take you to the “Compliance Results” page, where you can see the breakdown on a per target or per compliance standard basis (note that the per compliance standard results are just a combination of the per target results since we have only evaluated one compliance standard thus far). To see more details, click on the number of critical violations (e.g. the number “44” for the “HRdb0000_HRDBPDB1” row):
On the “Violations” pop-up, click on the violation count:
This will show you a list of all the compliance standard rules that have been violated, along with a violation count for each rule. While it is not immediately obvious, the numbers of each violation count are actually links to more details:
For example, if you click on the number 35 (for the SV-76031r1_pdbrule), you can see the following accounts have non-standard passwords:
Click “Close” to close the “Violations” window. Resolving the violations is not part of this demo, but in this case you can see that if you change the passwords for these users to something other than the default and re-execute the compliance check, these violations would clear.
My next post in this area will cover installing the reporting capability to match the Oracle Database 12c STIG compliance framework, so stay tuned for more!