8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23ai | Misc | PL/SQL | SQL | RAC | WebLogic | Linux
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.
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_extractanddbsat_diffutilities. - 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.
$ ./dbsat collect dbsat_user@pdb1 pdb1_output 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. Enter password: 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... Enter password: Verify password: updating: pdb1_output.json (deflated 88%) zip completed successfully. $
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.
$ ./dbsat report pdb1_output
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
[pdb1_output.zip] pdb1_output.json password:
inflating: pdb1_output.json
DBSAT Reporter ran successfully.
Calling /usr/bin/zip to encrypt the generated reports...
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.
$
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
$ ./dbsat discover -c ./Discover/conf/dbsat.config pdb1_discovery
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.
Enter username: dbsat_user
Enter password:
DBSAT Discover ran successfully.
Calling /usr/bin/zip to encrypt the generated reports...
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.
$
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 unicodeI'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...