Oracle’s Database Security Assessment Tool (DBSAT) Version 2 (2.0.1)
Background
Oracle recently released a new version of their Database Security Assessment Tool (DBSAT) - version 2.0.1. This is a welcome update as it’s been a while since the initial release in 2016. In fact, the tool hasn't been enhanced or updated in over a year. Overall DBSAT is quite a valuable tool and personally I would recommend Oracle database administrators use it.Advantages of Version 2 over Version 1
Version 2.0.1 seems to offer a number of advantages and general changes. Some of the things I’ve noticed include:- Change in terminology from “Opportunity”, “Some Risk”, “Significant Risk”, and “Severe Risk” to the more conventional terms “Advisory”, “Low Risk”, “Medium Risk”, and “High Risk”.
- A more comprehensive analysis. Running both versions against the same database, version 2 found more “issues”. Even within the same check, the new version sometimes identified more results.
- A new “References” section at the bottom of each check. From the DBSAT documentation: “Provides information on whether the finding is related to a CIS Oracle Database Benchmark 12c v2.0.0 recommendation or related to a GDPR Article/Recital”.
- A whole new Discoverer component designed to search for data based on customizable criteria and then generate a “Database Sensitive Data Assessment Report”. This report can be generated offline on a secondary system (only the source data collection runs on the database server).
- A new output format: JSON for ingestion into other tools or utilities (i.e. via a custom loader). Previously output was provided in HTML for easy manual navigation, Excel where additional columns can be added (i.e. making it more like a check-list), and text for easy cut & paste.
New Feature: “Discoverer”
The Discoverer component is a brand new feature for the purpose of searching for and reporting on “sensitive data”. What that really means is looking for sensitive data by column names (i.e. columns named “SALARY” or “SAL”, etc.) and producing a report on the findings. Reports are only in HTML and CSV formats as of DBSAT version 2.0.1. There’s a list of proposed “sensitive column names” included to get started with, but the list is fully customizable and extensible. In fact, this is the only part of DBSAT that is extensible. But for that reason I think this is a really promising and helpful new feature and can add value for anyone who does need to look for and track sensitive data. It saves them from writing their own similar tool or utility. The biggest downside is of course that the accuracy of the results is only as good as the search criteria and column names. For organizations with strong data modelling rules and policies, this shouldn’t be a problem. But if column names are completely arbitrary and obscure, then the effectiveness of the findings will be diminished.Comparison to ORAchk
For those familiar with Oracle’s more general health check tool ORAchk (or ExaChk), you’ll find the concept and operation reasonably familiar. But while it’s similar, there are still a number of differences. Comparing DBSAT to ORAchk some of the key differences would include:- DBSAT is a two-step operation: fist your collect data, then report on it. The later can be performed on a secondary machine.
- DBSAT gives the option to encrypt the raw data it gathers during the collection phase (more on this later).
- DBSAT has fewer command line switches and is simpler to run and use. Though the basic usage of ORAchk is pretty simple also.
- The HTML reports generated are a little similar in look and feel but also differ in many ways.
- Unlike ORAchk, DBSAT is not extensible meaning you cannot add your own custom audit checks.
- Unlike ORAchk, DBSAT does not offer automated runs or repository storage for comparative analysis and overall estate dashboard (ORAchk offers the “Collection Manager” repository database and APEX application).
- There’s no catalog of checks like ORAchk provides in HTML format.
Integration
Since ORAchk version 12.2.0.1.1_20160916, ORAchk has automatically included the output of the DBSAT utility as a single check within the ORAchk report. In fact all of the old database security related ORAchk checks seem to have been removed from ORAchk and replaced with this single check showing the DBSAT output. Personally I do not think this integration is a good thing for several reasons including:- There’s no guarantee that the version of DBSAT bundled with the version of ORAchk being used is the most recent. Since DBSAT doesn’t seem to be updated nearly as frequently it’s likely not a problem except for a period of time shortly after a DBSAT release.
- The included DBSAT output within an ORAchk report is only in text format and is encapsulated as a single audit check by ORAchk. In the ORAchk output, there’s no included DBSAT HTML, XLS, or JSON data for an easier review or integration into other tools.
- Most significantly, the scope of visibility may be different between an ORAchk report and a DBSAT report. An ORAchk findings report may be treated as low risk from a security and confidentiality perspective and therefore may be shared with a wider audience or handled less securely within an organization. Conversely, DBSAT reports may show current exposures and sensitive information that could be easily exploited if it fell into the wrong hands. Consequently DBSAT findings are often handled and secured with additional scrutiny.
./orachk -excludecheck 39128FBB540C098AE0530D98EB0AFB1A
Or alternatively, the security profile (which currently only includes the DBSAT report) can be skipped:
./orachk -excludeprofile security
Personally I’d suggest manually excluding only the check by the CheckID to not inadvertently exclude other security related checks which may be added to ORAchk in the future. For example, ORAchk’s scope can be quite broad while DBSAT is focused on the Database (and related OS configuration). So possibly the ORAchk “Security” profile could include security checks for other products.
