Database Security Assessment Tool (DBSAT)

The Database Security Assessment Tool (DBSAT) is provided by Oracle as a utility to help you check for common database security issues, as well as helping to identify sensitive data stored in the database.

Remember, it's just a tool, not a guarantee of security.

Related articles.

Basic Security Measures for Oracle Documentation and Downloads

There are two main sources of information regarding the DBSAT tool.

Oracle Database Security Assessment Tool (DBSAT) (Doc ID 2138254.1) : The software is downloaded from a link in this MOS note. You should check for new versions on a regular basis. It also gives a description of the dbsat_extract and dbsat_diff utilities. Database Security Assessment Tool User Guide : This is the main documentation for the DBSAT utility. Prerequisites

You need to have zip, unzip and python on the server.

yum install -y zip unzip python

Check you have Python installed on the server.

$ python -V
Python 2.7.5
$

You can check for zip and unzip using the following commands.

zip -v
unzip -v

If you are planning on running discoverer, you will need a Java 8 JDK, with the JAVA_HOME environment variable set. On my test box I did the following.

export JAVA_HOME=/u01/jdk1.8.0_181

You will need suitable database credentials to connect to the database. When I ran this against some real databases I just used my DBA user and it worked fine. The documentation gives an example of the privileges needed if you want to create a user specifically for running this utility.

create user dbsat_user identified by dbsat_user;
-- If Database Vault is enabled, connect as DV_ACCTMGR to run this command
grant create session to dbsat_user;
grant select_catalog_role to dbsat_user;
grant select on sys.registry$history to dbsat_user;
-- 11g and 12c
grant select on sys.dba_users_with_defpwd to dbsat_user;
-- 12c only
grant select on audsys.aud$unified to dbsat_user;
grant audit_viewer to dbsat_user;
-- 12c covers sys.dba_priv_captures, sys.priv_capture$, sys.capture_run_log$
grant capture_admin to dbsat_user;
-- If Database Vault is enabled, connect as DV_OWNER to run this command
grant DV_SECANALYST to dbsat_user;

In a clean instance I created a test user with a password matching the username to give me an obvious failure.

CREATE USER test IDENTIFIED BY test DEFAULT TABLESPACE users QUOTA UNLIMITED ON users;
GRANT CREATE SESSION, CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE PROCEDURE, CREATE TYPE, CREATE JOB, CREATE MATERIALIZED VIEW TO test; Installation

All you need to do is unzip the tool into a location on the server. Some tools can be run on the client, but I find it easier to keep it on the server.

mkdir -p /home/oracle/dbsat
unzip -o /tmp/dbsat.zip -d /home/oracle/dbsat
cd /home/oracle/dbsat

You can add this location to the path if you like, but I don't bother with that.

Basic Usage

Running the dbsat utility with no parameters will display the basic usage.

$ ./dbsat
Database Security Assessment Tool version 2.0.2 (May 2018)
Usage: dbsat collect [ -n ] <database_connect_string> <output_file>
dbsat report [ -a ] [ -n ] [ -x <section> ] <input_file>
dbsat discover [ -n ] -c <config_file> <output_file>
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)
-c Configuration file for discoverer
$

We can see there three main actions (collect, report and discover).

Collect

Running the collector gathers information from the database and generates a JSON file containing all the information. The collector should be run on the database server. It will prompt you for the database password, then when the password to protect the resulting zip file. The "-n" option means you are not prompted for a zip file encryption password, but from a security perspective you should probably use one.

$ <strong>./dbsat collect dbsat_user@pdb1 pdb1_output</strong>
Database Security Assessment Tool version 2.0.2 (May 2018)
This tool is intended to assist in you in securing your Oracle database
system. You are solely responsible for your system and the effect and
results of the execution of this tool (including, without limitation,
any damage or data loss). Further, the output generated by this tool may
include potentially sensitive system configuration data and information
that could be used by a skilled attacker to penetrate your system. You
are solely responsible for ensuring that the output of this tool,
including any generated reports, is handled in accordance with your
company's policies.
Connecting to the target Oracle database...
SQL*Plus: Release 12.2.0.1.0 Production
Copyright (c) 1982, 2016, Oracle. All rights reserved.
<strong>Enter password:</strong>
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
Setup complete.
SQL queries complete.
OS commands complete.
Disconnected from Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
DBSAT Collector completed successfully.
Calling /u01/app/oracle/product/12.2.0.1/db_1/bin/zip to encrypt pdb1_output.json...
<strong>Enter password:
Verify password:
updating: pdb1_output.json (deflated 88%)
zip completed successfully.</strong>
$ Report

The reporter takes the output file from the collector and converts it into HTML, Excel, JSON, and Text formats. The reporter doesn't need to be run on the database server, but since you have to run the collector there it probably makes sense to run this on the server too. Notice we've used the same file name prefix to call the reporter as we did when running the collector. You are prompted for the password of the source zip file, and the password for the destination zip file.

$ <strong>./dbsat report pdb1_output</strong>
Database Security Assessment Tool version 2.0.2 (May 2018)
This tool is intended to assist in you in securing your Oracle database
system. You are solely responsible for your system and the effect and
results of the execution of this tool (including, without limitation,
any damage or data loss). Further, the output generated by this tool may
include potentially sensitive system configuration data and information
that could be used by a skilled attacker to penetrate your system. You
are solely responsible for ensuring that the output of this tool,
including any generated reports, is handled in accordance with your
company's policies.
Archive: pdb1_output.zip
<strong>[pdb1_output.zip] pdb1_output.json password:</strong>
inflating: pdb1_output.json
DBSAT Reporter ran successfully.
Calling /usr/bin/zip to encrypt the generated reports...
<strong>Enter password:
Verify password:
zip warning: pdb1_output_report.zip not found or empty
adding: pdb1_output_report.txt (deflated 78%)
adding: pdb1_output_report.html (deflated 84%)
adding: pdb1_output_report.xlsx (deflated 3%)
adding: pdb1_output_report.json (deflated 82%)
zip completed successfully.</strong>
$

Looking at the resulting HTML file we can see a summary of the findings.

Each test results in output indicating the risk level. Here is an example of a high risk we created intentionally.

Discover

The discoverer is essentially a separate Java-based tool, not reliant on the collector and reporter, that checks for sensitive data in the database. First you need to create a dbsat.config file. You can call it anything you want as you will be referencing it explicitly later.

cd /home/oracle/dbsat
cp Discover/conf/sample_dbsat.config Discover/conf/dbsat.config

You will need to edit the contents of the "Discover/conf/dbsat.config" file. At a minimum you will need to set the following.

[Database]
DB_HOSTNAME = localhost
DB_PORT = 1521
DB_SERVICE_NAME = pdb1

The "Discover/conf/sensitive_en.ini" file contains a list of potentially sensitive categories of data, each with an associated pattern for column names. You should review this file and consider adding extra sections or patterns as necessary.

Once the config is complete you can run the discoverer, specifying the config file and the output file name. You are prompted for the database credentials and the password for the resulting zip file.

$ export JAVA_HOME=/u01/jdk1.8.0_181
$ <strong>./dbsat discover -c ./Discover/conf/dbsat.config pdb1_discovery</strong>
Database Security Assessment Tool version 2.0.2 (May 2018)
This tool is intended to assist in you in securing your Oracle database
system. You are solely responsible for your system and the effect and
results of the execution of this tool (including, without limitation,
any damage or data loss). Further, the output generated by this tool may
include potentially sensitive system configuration data and information
that could be used by a skilled attacker to penetrate your system. You
are solely responsible for ensuring that the output of this tool,
including any generated reports, is handled in accordance with your
company's policies.
<strong>Enter username: dbsat_user
Enter password:</strong>
DBSAT Discover ran successfully.
Calling /usr/bin/zip to encrypt the generated reports...
<strong>Enter password:
Verify password:
zip warning: pdb1_discovery_report.zip not found or empty
adding: pdb1_discovery_discover.html (deflated 73%)
adding: pdb1_discovery_discover.csv (deflated 30%)
Zip completed successfully.</strong>
$ Issues

I experienced some issues with the current version (2.0.2).

The current version of discoverer doesn't seem to like Java 10. If you don't use Java 8 you get this error.

"Error: Java version 1.8 or later is required."

The current version of reporter seems to have issues with Oracle 18c. There is a date comparison that produces the following error. I'm not sure if this affects the output though, as it looked like the output was complete.

Traceback (most recent call last):
File "/home/oracle/dbsat/./sat_reporter.py", line 6372, in <module>
fn()
File "/home/oracle/dbsat/./sat_reporter.py", line 338, in patch_checks
bundle_date = max_date(bundle_date, x[reldate])
File "/home/oracle/dbsat/./sat_reporter.py", line 6198, in max_date
return max(date1, date2)
TypeError: can't compare datetime.datetime to unicode

I'm not convinced the discoverer actually gives a consistent result. I can take the same table (definition and contents) and place it in different databases and it doesn't consistently identify the table as containing sensitive data. I can't establish a pattern yet. I've not included sample output here as I can't get anything worth showing without running it on a real database, and I'm not going to expose the output from that to the world.

For more information see:

Oracle Database Security Assessment Tool (DBSAT) (Doc ID 2138254.1) Database Security Assessment Tool User Guide Basic Security Measures for Oracle

Hope this helps. Regards Tim...