I visit customers on a regular basis. And when we sit together in front of the machine I sometimes spot tiny little things which may impose a security risk. This could be things such as
SEC_CASE_SENSITIVE_LOGON=FALSE or the use of
UTL_FILE_DIR or something else. To detect such sensitive spots you should download and use the Oracle Database Security Assessment Tool (DBSAT).
Download and use the Oracle Database Security Assessment Tool
First of all, you need to download the tool from MyOracle Support:
Afterwards you please may check the documentation:
Requirements and Database Releases
To execute the tool you will need the following database privileges and roles:
SELECT on SYS.REGISTRY$HISTORY
DV_SECANALYSTrole (in case Database Vault is active)
AUDIT_VIEWERrole (since Oracle 12c)
CAPTURE_ADMINrole (since Oracle 12c)
SYS.DBA_USERS_WITH_DEFPWD(since Oracle 11g)
AUDSYS.AUD$UNIFIED(since Oracle 12c)
The tool has two components:
- The DBSAT Collector executes SQL queries and runs operating system commands to collect data from the system to be assessed. It does this primarily by querying database dictionary views. The collected data is written to a file that is used by the DBSAT Reporter in the analysis phase.
- The DBSAT Reporter analyzes the collected data and reports its findings and recommendations in multiple formats: PDF, Excel, and Text. The Reporter can run on any machine: PC, laptop, or server. You are not limited to running it on the same server as the Collector.
You can run the DBSAT on database since Oracle Database 10.2.0.5 and on SPARC and Intel Solaris, Linux, Windows, HP-IA, AIX and zLinux.
Copy the zip file to a directory and unzip it, for example:
mkdir -p /home/oracle/dbsat unzip dbsat.zip –d /home/oracle/dbsat cd /home/oracle/dbsat
Execute the DBSAT Collector
Once you have ensured that the user you’ll use to execute DBSAT has all the above mentioned privileges and roles, you can execute it:
$ ./dbsat collect -n "/ as sysdba" dbsatrep
Another option would be for instance:
./dbsat collect scott /tmp/collect_result which interactively will ask you for scott’s password then.
Please see the entire command syntax for
Usage: dbsat collect [ -n ] dbsat report [ -a ] [ -n ] [ -x :section:] Options: -a Report about all user accounts, including locked, Oracle-supplied users -n No encryption for output -x Specify sections to exclude from report (may be repeated for multiple sections)
Execute the DBSAT Reporter
Generating a report is simple and straight forward – by default it will be password protected unless you will use the
./dbsat report dbsatrep
The result reports gives you summary information first:
And then you should watch out for yellow, orange and especially red marked entries such as:
And you’ll get also green messages when something is setup or used in the right way – and we know that this is crucial. Just speaking of old password versions:
Some remarks and findings
First of all, the report seem to run in
CDB$ROOT at first unless you direct it to specific PDBs. In my understanding it means you’ll have to execute DBSAT on a per-PDB basis. This makes sense of course. But I’d rather would have expected an option to run it in all containers in one pass and generate a consolidated report allowing to break down when necessary. This is the call to execute DBSAT in my PDB1:
./dbsat collect -n "sys/oracle@pdb1 as sysdba" dbsatpdb1
This works fine.
And finally, this struck me a bit:
Hm … DBSAT does not seem to be aware that BPs and RUs are a super-set of PSUs and RURs. My database is in better shape – I should get an extra star for applying RUs instead of RURs (or PSUs), and no RED ALERT should be shown.
Well, there’s always some room for improvement.
Finally, the Database Security Assessment Tool is very helpful and highly recommend. The warnings you get are mostly helpful and may signal some undetected risks and issues in your database. It will help you securing your database. And a few things need to be read with a grain of salt.