Authored by: Tim Boles
This series of articles provides an overview of aspects for Oracle database security that experts believe to be the most efficient, in terms of time, effort and costs to implement. I call these “Quick Wins.”
Database Parameters
One area of Security often overlooked by Database Administrators is the initialization parameters. A database may go through one or more migration or upgrade in its lifetime. These major types of activities often result in parameters remaining unnecessarily set. Hidden (underscore) and deprecated parameters are the most likely to have security implications, and need to be reviewed.
Hidden Parameters
Hidden parameters should be left on the default value, unless set at the recommendation of Oracle support. If a database is upgraded or migrated, those hidden parameters need to be analyzed to determine if they are still necessary. It is easy to check for hidden parameters that are explicitly set by doing a simple SQL query against the V$PARAMETER view (Figure 1).
NOTE: Parameters explicitly set to the default value will also be part of the query results.
Select name, display_value
from v$parameter
where name like '/_%' escape '/' and isdefault='FALSE';
Deprecated Parameters
Deprecated parameters may be removed in future versions of the database. Therefore, it should be a priority to evaluate deprecated parameters set to none default values and to work toward moving away from them. Again, use the V$PARAMETER view, and find
Select name, display_value
from v$parameter
where name like '/_%' escape '/' and isdefault='FALSE';
deprecated parameters explicitly set within the initialization parameter file (Figure 2).
These deprecated parameters may have security implications if set to non-default values. The parameters O7_DICTIONARY_ACCESSIBILITY and UTL_FILE_DIR are two of the highest offenders in these scans. These two parameters provide a higher level of access to the database dictionary and system files than is recommended by Oracle. There are better and more secure ways of dealing with these types of access. It may take working with vendors and software developers to move away from utilizing these two parameters, but doing so should be a priority.
Other Parameters That Effect Security
We cannot cover all the parameters that affect the Security of the database in this short blog. The table in Figure 3 shows 10 of the more predominate ones. Database administrators should know the values to which they are set and the implications the parameters have on database security.
Figure 3: Parameters that effect Security (* signifies a deprecated parameter)
Summary
Reviewing database parameters is an easy, quick way to increase the security posture of your database. As with any database change, there is always some risk, so be sure to test the changes in non-production environments before attempting them in production. At Spinnaker Support, we encourage all organizations to take this initial first step in minimizing the risk of unwanted exposure to your organization’s data.
If you decide to join our client list, you will be provided with a Security Assessment that includes reviewing your system against not only the CIS Benchmarks but also against DISA-STIGs, Oracle Security documentation, and other benchmarks. We will use our findings to guide you in improving your security posture and removing attack vectors that cybercriminals use to attack systems.
For more information, please visit https://www.spinnakersupport.com/third-party-support/security-vulnerability/
