Securing Oracle 19c with DBSAT 4.2: How It Works, Why It Matters, and What It Found in My Database

A practical, end-to-end walkthrough of Oracle's Database Security Assessment Tool — from install and configuration to running the Collector and Discoverer, reading the reports, and using them as audit evidence. Built on a real run against Oracle Database 19c (Non-CDB) on Oracle Linux 8.10.

If you run Oracle databases, here's an uncomfortable question: do you actually know where your sensitive data lives, and how exposed it is right now? Most teams can't answer precisely. Oracle's Database Security Assessment Tool (DBSAT) answers it in minutes — for free. In this blog I'll explain how DBSAT works, walk through implementing it on Oracle 19c, and show you the real findings from my own lab run, including the one real-world bug I had to work around.

What is DBSAT, and how does it work?

DBSAT is a free, lightweight command-line tool from Oracle (downloadable from My Oracle Support Note 2138254.1) that inspects an Oracle database's security posture and discovers where sensitive data resides. It is read-only and non-intrusive it issues SELECT queries against data-dictionary views and reads OS/network configuration. It never modifies your application data.

It runs as three components that form two pipelines:

1. Collector

Connects via SQL*Plus and gathers configuration and security metadata users, privileges, roles, audit settings, encryption, network and OS configuration into a single JSON file.

2. Reporter

Processes the Collector's JSON (no database connection needed) and produces the Security Assessment Report in HTML, Excel, JSON and Text, with every finding risk-rated and tagged to standards.

3. Discoverer

A separate Java/JDBC component that scans column names and comments against regex patterns to locate sensitive data (PII, financial, health), producing a Sensitive Data Assessment Report.

Key idea

The Discoverer matches on metadata column names and comments  not on the row values themselves. Naming a column CARD_NUMBER or commenting it "cardholder data (PCI-DSS)" is what drives detection. That's why good data dictionaries make DBSAT dramatically more effective.

Key features

• Three-in-one: configuration assessment plus sensitive-data discovery in one tool.
• 100+ security checks across users, privileges/roles, authorization, encryption, fine-grained access control, auditing, database configuration, network, and OS.
• Six risk levels High Risk, Medium Risk, Low Risk, Evaluate, Advisory, Pass.
• Standards tagging findings map to CIS, DoD STIG, Oracle Recommended Practices, and EU GDPR.
• Multiple formats HTML for humans, Excel for tracking, JSON for automation, Text for diffs.
• Sensitive-data patterns for PII, financial (PCI), and more the 4.2 pattern set even detects India-specific IDs (Aadhaar, PAN, IFSC) out of the box.
• Lightweight & safe no agent, minimal load, read-only ideal to run against production.

Level	Meaning
High Risk	Immediate action required — exploitable vulnerabilities or critical misconfigurations
Medium Risk	Should be addressed in the near term — reduces attack surface
Low Risk	Minor issues — good hygiene improvements
Evaluate	Requires human judgment — depends on your specific environment and policies
Advisory	Informational — awareness items and best-practice recommendations
Pass	Compliant — no action needed

Benefits why bother?

For DBAs

• One repeatable command set replaces dozens of manual hardening queries.
• A prioritized, vendor-blessed remediation worklist (in Excel).
• Safe on production — read-only and low overhead.
• Scriptable across the whole fleet.

For Security & compliance

• An objective, consistent security baseline for every database.
• A sensitive-data inventory for privacy programs (GDPR, PCI).
• Dated, tagged artifacts that work as audit evidence.
• A shared language ("High Risk PRIV.DBA") DBAs and auditors both understand.

How to implement it — my real setup

Here's exactly what I did on the lab box. The whole thing took under 30 minutes.

Environment

Component	Details
OS	Oracle Linux 8.10 (RHEL compatible) · AWS EC2 · host ip-172-31-14-202
Database	Oracle Database 19c Enterprise Edition 19.0.0.0.0 · Non-CDB · service ORCL · port 1521 · ARCHIVELOG
DBSAT	Version 4.2 (Mar 2026)
Java	OpenJDK 17 (required for DBSAT 4.2)

Step 1 Prerequisites & install

# DBSAT 4.2 needs Java 17 — point JAVA_HOME at it

$ export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-17.0.13.0.11-...

$ export PATH=$JAVA_HOME/bin:$PATH

$ java -version

  openjdk version "17.0.13" 2024-10-15 LTS

# Unzip DBSAT and confirm the version

$ unzip dbsat_4_2.zip -d /u01/app/oracle/

$ cd /u01/app/oracle/dbsat

$ ./dbsat --version

  Database Security Assessment Tool version 4.2 (Mar 2026)

Step 2 Create the DBSAT database user

DBSAT connects as a low-privilege user with read access to the data dictionary. This is what I granted:

CREATE USER dbsat IDENTIFIED BY "********";

GRANT CREATE SESSION          TO dbsat;

GRANT SELECT_CATALOG_ROLE     TO dbsat;

GRANT SELECT ANY DICTIONARY   TO dbsat;

GRANT SELECT ANY TABLE        TO dbsat;

GRANT EXECUTE_CATALOG_ROLE    TO dbsat;

GRANT READ ON SYS.AUD$        TO dbsat;

ALTER USER dbsat DEFAULT TABLESPACE users QUOTA UNLIMITED ON users;

Note on least privilege

This grant set is intentionally broad so the Collector and Discoverer both work without fuss. Oracle also documents a tighter least-privilege set (e.g. EXECUTE ON SYS.DBMS_SQL is the one grant whose absence most often breaks the Reporter). For a real production assessment, lean toward the documented minimum.

Step 3 Run the Collector and generate the report

# Collect security configuration into a JSON file

$ ./dbsat collect dbsat@ORCL  /u01/app/oracle/dbsat/orcl_security

   Enter password: ********

# Build the report, then extract the bundle into HTML/XLSX/JSON/TXT

$ ./dbsat report  -n /u01/app/oracle/dbsat/orcl_security

$ ./dbsat extract     /u01/app/oracle/dbsat/orcl_security_report

Step 4 Run the Discoverer (sensitive-data scan)

$ ./dbsat discover -n -c Discover/conf/custom_sensitive.config \

       /u01/app/oracle/dbsat/custom_sensitive

   Enter username: dbsat

   Enter password: ********

   DBSAT Discover ran successfully.

Field note a real DBSAT 4.2 gotcha

On this 4.2 build, the Reporter/Discoverer threw a java.lang.IndexOutOfBoundsException while encrypting the output bundle. The fix: pass -n (no encryption), which skips the encryption step and lets the run complete. The trade-off is that the reports are written unencrypted — so if you use -n, treat the output as highly sensitive and lock it down (restricted directory, encrypt-at-rest, short retention). It is, after all, a map of your weaknesses.

What DBSAT actually found in my database

This is where DBSAT earns its keep. The Discoverer scanned all schemas and flagged a sweep of regulated data — every category came back High Risk:

SUMMARY:

Metric	Value
Sensitive rows	20,002
Sensitive columns	36
Schemas exposed	6
Data categories	9
Risk level	High (on all)

Findings by Category

Sensitive Category (real result)	Tables	Columns	Rows
Identification Info — Public IDs (name, email, phone)	3	9	13,001
Identification Info — Personal IDs (PAN, passport, tax ID)	3	5	12,001
Identification Info — National IDs (US SSN)	1	1	3,000
Biographic Info — Address	2	4	13,000
Biographic Info — Extended PII (date of birth)	2	2	13,000
Financial Info — Card Data (PAN, CVV) PCI	2	4	5,001
Financial Info — Bank Data (account, IBAN, IFSC)	3	5	7,001
Job Info — Compensation Data (salary, bonus)	2	3	2,001
Job Info — Employee Data	3	3	5,001

Concrete column-level hits included AADHAAR_NUMBER (India Aadhaar), PAN_NUMBER (India PAN), PASSPORT_NUMBER, SSN (US Social Security Number), CARD_NUMBER + CVV (cardholder data), IBAN, IFSC_CODE, BANK_ACCOUNT_NUMBER, SALARY/BONUS (income), and TAX_ID — across the CUSTOMER, HR, PAYROLL and FINANCE schemas. Notably, DBSAT 4.2 detected the India-specific identifiers automatically using its built-in sensitive.ini patterns.

In parallel, the Security Assessment swept the configuration side and flagged real issues across every domain — over-privileged accounts (DBA, SELECT ANY TABLE, EXP_FULL_DATABASE), risky parameters (O7_DICTIONARY_ACCESSIBILITY, REMOTE_OS_AUTHENT), gaps in auditing, no Transparent Data Encryption, and weak network-encryption settings. Each finding arrived with a severity and a concrete recommendation.

Understanding the reports

DBSAT writes the same content in four formats — pick the one that fits the consumer:

Format	Best For
HTML	The human-readable report — color-coded severities, findings, and recommendations.
Excel (.xlsx)	Remediation tracking — add owner / due-date / status columns and filter by risk.
JSON	Automation and baseline diffing — compare runs over time and alert on drift.
Text / CSV	Quick grep/diff, tickets, and the Discoverer's column-level CSV inventory.

How DBSAT reports are used in an audit

This is where DBSAT pays for itself at audit time. The reports don't certify compliance — but they are excellent, defensible evidence:

• Point-in-time posture: a dated report of exactly how the database was configured, by control area.
• Configuration-drift evidence: diff the JSON across quarters to prove controls stayed in place (or improved).
• Remediation tracking: the before/after report pair showing a High-Risk finding moved to Pass is exactly what auditors accept.
• Least privilege & separation of duties: the Privileges & Roles section is direct evidence for SOX ITGC and access reviews.
• Audit-trail configuration: the Auditing section evidences that privileged actions and logons are being captured.
• Data inventory: the Discoverer's output feeds a GDPR Record of Processing / data-classification program the "where is our sensitive data" map.

Framework	What DBSAT gives the auditor
PCI-DSS	Cardholder-data discovery (Card Data category) + encryption / audit / access findings
GDPR	Personal-data inventory + GDPR-tagged findings (supports Art. 25 & 32)
SOX	Least-privilege / SoD evidence + audit-trail configuration (customer mapping)
ISO 27001	Access control, cryptography and logging evidence supporting Annex A (customer mapping)

Be precise with auditors

DBSAT officially tags findings to CIS, STIG, Oracle Recommended Practices and GDPR. PCI is evidenced through sensitive-data discovery; SOX and ISO 27001 are your organization's mapping of DBSAT findings, not Oracle assertions. And "all Pass" does not equal "compliant" — technical controls are necessary, not sufficient.

Key Takeaways

• DBSAT is free, read-only, and fast  there's no reason not to run it on every Oracle database you own.
• Three components, two outputs: Collector→Reporter for configuration risk; Discoverer for the sensitive-data map.
• It works: on my 19c box it surfaced 20,002 sensitive rows across 6 schemas and a full set of configuration weaknesses  in minutes.
• DBSAT 4.2 needs Java 17. If you hit the encryption IndexOutOfBoundsException, run with -n and secure the unencrypted output yourself.
• Reports are audit gold dated, tagged, diffable evidence of posture, drift, and remediation.
• Run it on a schedule (e.g. quarterly), baseline the JSON, and track findings to closure in the Excel report.