Hello, my name is Chad Hughes. I am a Principal Program Manager in Oracle's Global Product Security Group. One of my responsibilities is to help our product teams define secure configuration baselines for our products. In other words, I am helping our development organizations define what our default configurations should look like in order to be more secure out-of-the-box.
Our objectives with providing basic hardened configurations are to:
Enable non-security experts to deploy our products in a more secure configuration without the immediate need for advanced security experience and knowledge.
Reduce the number of possible attack vectors by limiting the exposed surface area, thereby reducing the risk of successful attacks (for example by limiting the number of unneeded ports left open or activated default accounts).
Minimize unused functionality being left enabled by default, as unused functionality may facilitate future vulnerabilities and provide additional exposure surface area. This is also important in older products that are no longer supported and which have not been recently patched.
Customers typically prefer an "opt in" approach, which starts with a secure configuration by default, and adds or modifies functionality as required by each customer, over the potentially more error-prone process of stepping through configuration-hardening checklists which remove or change default functionality to make it secure. For some organizations, stepping through long hardening checklists requires bringing in external consultants and lengthening normal deployment cycles.
One of the most important tenets of default secure configuration is that applications should run with the least privileges required and always apply appropriate protection for sensitive resources. The principle of least privilege requires that users, groups of users, and entire applications be given no more privilege than necessary to perform a job. This also means that what is not explicitly permitted should be denied. Ensuring least privilege requires identifying what job a user, group, or application is trying to do, determining the minimum set of privileges required to perform that job, and restricting the user, group, or application to a domain with those privileges and nothing more. Least privilege efforts also include eliminating unused default user accounts, expiring default passwords or prompting for password changes on install, and reducing unnecessary default execute grants to public.
I am often asked why Oracle's recommendations for secure configuration are different than those from the Center for Internet Security (CIS) and other third parties, who create Oracle database configuration hardening, or lock-down guides.
CIS calls their guide a "benchmark," which is essentially a checklist of user-configurable changes that can be made to the Oracle database. After applying the benchmark, customization is often required and tends to vary by application, company, and industry.
The Oracle database default configuration is different than third party recommendations. The main reason there are differences is that third parties and Oracle do not necessarily share the same approach to application hardening. There are many good reasons for different approaches.
Let's start with the assumptions made surrounding the targeted environment. CIS makes assumptions about what the architecture of a typical database application might look like. In practice, these assumptions may not be appropriate for some Oracle and third party applications. CIS typically recommends changing the default values of configuration parameters, or disabling specific default functionality. Oracle or third party applications may assume the default values of those parameters, and/or existence of default functionality, and would therefore be broken if the defaults were changed in accordance with CIS's recommendations.
Most sophisticated CIS Benchmark consumers probably expect this limitation. These consumers understand the risks of breaking their applications and still want the strongest hardening advice available. They are often fully capable of self-supporting any impact on their systems due to their actions. They know how to test incremental changes in their own Development and Quality Assurance environments, and when something breaks they know how to reverse changes. They may also prefer starting with a stronger starting baseline that they loosen up, rather than a loose baseline, which they need to further harden.
Compared with the CIS Benchmark, Oracle provides a smaller number of security recommendations in its secure configuration guidelines. Oracle's recommendations have to go through extensive Quality Assurance to test their effect on Oracle's products and packaged applications. This provides assurance that Oracle's recommendations will work at least with our products without extensive customer testing. The CIS Benchmark for Oracle does have the notion of "Level 1" and "Level 2" strength notations to help identify those recommendations that could prove to be more problematic, but CIS does not perform extensive application testing to identify which applications will be affected by their benchmark recommendations.
CIS Benchmark consumers tend to approach hardening their environment by starting from a more aggressively locked-down state and loosen up the configuration from that state, incrementally, by testing each step. This approach is often considered a best practice, as it can be an effective way to determine and assure true enforcement of the least-privilege principle. For some customers, however, this methodology can be prohibitively expensive and may not produce a positive cost/benefit value. It is truly impossible to define a one-size-fits-all approach to least-privilege configuration, as every customer has varying least-privilege requirements, even within the same industry and applications. Furthermore, every customer's risk-profile, and tolerance to risk, is unique.
In summary, Oracle's security recommendations are different than the core CIS recommendations because Oracle tries to strike the most effective balance between the application of an "ideal" security theory (which may be prohibitively expensive) and real customer cost/benefit requirements and practices. Our customers expect that our default configuration is tested, supported, and will not break various typical deployments of Oracle and third party applications.
Different goals, support obligations, motivations, and consumer expectations require different approaches to producing configuration-hardening recommendations and in determining the default configuration. These differences are appropriate and expected. From a customer standpoint, both approaches have value because they are serving different purposes.
Chad Hughes, CISSP
