Discovering Sensitive Data
Oracle has long had strong database encryption functionality and it keeps getting better. But they have been lacking a simple way to identify sensitive data in the database so you know what to encrypt, audit or protect via policies. I thought that might have improved recently with the release of a new database security assessment tool called DBSAT.
New Oracle Security Tool
I was very excited when Oracle released their new free database security assessment tool (DBSAT). It is very easy to install and use so it lowers the barriers to properly securing your data. This is good and I think if you use no other tool, then this is a good place to start with your database security if you are using Oracle. The tool helps you find many common vulnerabilities relating to missing patches, poor configuration, excessive access rights, and other database vulnerabilities that can be very dangerous if they go unnoticed.
However, I found what I consider to be a serious deficiency in the tool and a missed opportunity,
There are three parts to the DBSAT tool. These are called the Collector, the Reporter, and the Discoverer.
The Collector collects information about vulnerabilities such as missing patches, poor configuration, etc. It does a pretty good job here, although I did find some vulnerabilities identified by other scanning tools that that it did not catch. More on that in a future article.
The Reporter takes the results of the Collector step and presents them in an easy to read PDF report. This is very helpful but it lacks the ability to sort and filter vulnerabilities that some of the other tools have, and there can be a very large number of vulnerabilities so this can be a material deficiency as you begin to take steps to mitigate the vulnerabilities that are reported. More on that in a the future article.
Discoverer Doesn’t Discover Everything
The Discover is the real topic of this article. The Discover is intended to identify sensitive data in the database. I was very excited to see this feature in DBSAT because the only Oracle tool available to do this previously was a feature of Application Data Modeling (ADM) which is an element of the Data Masking and Subsetting package. This package requires an extra license and it is a bit cumbersome to use for this purpose. ADM gives the user the ability to identify sensitive data and together with Transparent Sensitive Data Protection (TDSP), the ability to enforce rules protecting that data.
As I tested DBSAT, I was disappointed to find that it is significantly less robust then the alternate method using ADM. The more robust ADM method allows the user to specify three patterns to search for sensitive data. These patterns are checked against the Column Names, Column Comments, and the data itself. You can specify a regex expression looking for certain patterns or words in the data, for example, ^\d{3}-\d{2}-\d{4}$ for a string that looks like a social security number. Unfortunately, DBSAT seems to only allow searching for patterns within the Column Name and the Column Comments, and does not provide the ability to search for patterns in the data. This approach relies heavily on the designers having used descriptive column names or comments and I think this leaves significant potential to miss sensitive data.
Application Data Modeling
To use ADM in order to find the sensitive data in your database, you must license the Data Masking and Subsetting package. You find ADM in OEM by navigating to Enterprise/Quality Management/Data Discovery and Modeling. The process involves creating a data model which collects meta data about your schema including table and column information. Then you define patterns for finding sensitive data in the tables, and a job will be executed in the background that will identify columns with names, comments, or data that match the patterns that you specify. The job will produce an XML file that can be used with Transparent Sensitive Data Protection or for other purposes.
If you specified a robust set of sensitive data patterns, then this XML file is a much more robust list of potential sensitive data than the list provided by DBSAT Discoverer.
Example
Lets say you have a the following table in an organization that uses An Employee’s Social Security Number as his Employee Number. For simplicity, lets also assume that no column comments have been assigned.
Employee (Employee Name, EmployeeAddress, EmployeeNbr)
“John Smith”, “18 Main Street, Exton, PA”, “721-99-2998”
“Peter Jones”, “20-42 Broadway, NYC, 10019”, “782-48-2332”
“Anna Newman”,”Anchorage AL, 22884″,”773-33-2002″
Without knowing the actual name of the EmployeeNbr column, or that it uses the SSN, we might set up search criteria similar to this:
- Column Name: Contains SSN, Identifier, Social
- Column Comment: Contains SSN, Identifier, Social
Using DBSAT, you can only specify these two criteria, so we would miss the entire EmployeeNbr column because it does not match the criteria for names or column comments.
But if you use the Application Data Model functionality to identify the sensitive data, you can specify a pattern to match against the data in the table. Then it will pick up this column despite the vague column name. A Pattern might look like this:
Data Pattern: ^\d{3}-\d{2}-\d{4}$
Use ADM With Transparent Sensitive Data Protection
So if you can license Data Masking and Subsetting, then I recommend using ADM to identify sensitive data in your database. Then encrypt that data and/or protect it with Transparent Sensitive Data Protection.
Either way, the other features of DBSAT such as finding vulnerabilities related to patching and poor configuration make it a good addition to the database security administrator’s toolkit.
Other Tools
This article only discusses tools provided by Oracle. There are numerous other vendors that provide external tools to discover sensitive data including Imperva and Spirion.
If you would like more information about how to keep your Oracle data safe contact us or request an Oracle database health check.