Pete Finnigan's Oracle Security Weblog

I started to ask a question a few blog posts ago about how does the 12cR1 database affect database security audits. I have decided to come back to it now as it is a good chance to do so. I earn my daily crust by performing security audits of Oracle databases and also producing PFCLScan, our Oracle database security scanner so I am interested to understand how an audit may change. Currently when I do an audit I focus on the security of the data itself so I am interested in assessing the database, the server its hosted on and the Oracle networking. I am particularly interested in how and why people and job descriptions (i.e. all the real people who interactively access the data and also all the processes that access the data). Security of data falls into three main groups, 1) patching, 2) hardening and baseline security and the most important is 3) the security of the data itself. When we do an audit we use custom tools including PFCLScan to assess the database but also dig into the server and the database by hand to assess how and why the data can be accessed, leaked or be stolen. This is a very detailed Oracle database audit service and a lot of clients get a deep understanding if the true security of their data in their own databases. If you would like to know more about this service then please contact me.

In terms of doing that database audit service now on Oracle 10g, 11g or rarely earlier this is fine. We simply ask to assess a production database as looking at test systems is not realistic. If you wish to test simple baseline hardening then any system including a test system (suitably hardened) would be fine BUT the focus for your audits is to secure the actual data, therefore we need to see a live production system and ideally one used for some time to get some idea of exactly how it is used and abused and how real the threats are to data.
Bring in 12c and we now have the complexity of pluggable databases and how does this affect a security audit (The question I asked myself a few blog posts ago). In simple terms pluggable databases and containers and the ability to provision databases very quickly and remove them quickly gives a speedier version of what exists now. In the current time multiple databases may be hosted on the same server (same as 12c) and maybe they also share the same Oracle home (same as 12c). The current 11g and lower is more complex in terms of managing and patching as a shared SYSDBA account means that if database A is breached then database B is also breached. It is more complex because its separated. In 12c it is the same problem, there is now one database sharing pluggable databases and there is also one SYSDBA account the same as before (except that now it is truly shared across multiple databases) before it was shared at the OS and DB level if a shared home was used, if two databases on the same server had two Oracle homes then there was separation provided that the OSDBA Unix group (assuming Unix) was not shared.

The biggest issue is data and security of data and that is the same (as an issue) whether you have pluggable databases or not or consolidated databases or not. The application functionality and data and its access controls is the same whether it is deployed as a pluggable database or not. The biggest problems I come across from a security perspective is access to data by the wrong people or badly designed applications that assume that the application controls the security and not the database and worse applications and people that leak data to outside the database or DBA’s that copy databases into test systems and more (if pluggable architectures going to make this easier? �" Yes I think so, that is not good). The fact that an application and its schemas is in a pluggable database or in a standalone database does not make a vast difference. For some reasons the pluggable database architecture will make the data less secure. It will promote database applications to run in the same servers, backups are likely to be held on the same servers, DBA’s are more likely to share data selected from the database into the same directories where they may not have done in the past. The biggest concern is the use of shared or common accounts and privileges. In one sense this could make privilege design and management simpler but on the other hand it will affect security. Whereas each separate database may have had “in effect” common accounts the passwords could be different, now they are truly shared; This could be better to manage but it means if the password is breached in one place it is breached in all places.

Shared or common privileges also don’t make sense in the application world, maybe for DBA bit not even for application administrators as each application is different. You could create a common account and grant it the lowest common denominator privileges in the root container and then add specific privileges for each application in each pluggable database but we all know that in reality that will never happen and the common account will become known to many groups and it will have excessive privileges. A common account approach is good in some senses but i feel separate accounts are always best at the pluggable level. Least privilege can never be achieved otherwise.

The bigger shared account issue is the issue that default schemas are shared; this means that they must be locked and protected and also that more fundamentally default schemas should not end up in pluggable databases again because of a lowest common denominator issue based around templates.
The mechanism that is part of 12c should also be considered, is the 12c mechanism better than two databases on the same server, same home? hard to argue without much more details on how exactly 12c works but it is likely to be code changes in the core kernel and also label security and DV, the fact that the DV/OLS like functions do protect data means possibly yes 12c is better, but shared operating system access means possibly no. This is a common issue i come across now before 12c, if consolidation has occurred it is important that shared databases are at the same functional and risk levels and that operating system access is controlled and locked down.

If 12c is broken, do we care? should we worry? Maybe? The fact of life is that someone will break it somehow but its not out concern as such, we must hope Oracle patches quickly and we must apply those. Its our responsibility to ensure that we use 12c securely and the biggest factor is that databases and applications should include security and whether you use 12c, 11g or consolidate really is a matter for the design stage and must be included. 12c Just makes the consolidation process easier but we should not assume secure! The cross over between pluggable databases has been considered well but its the cross over that we as customers create that is the problem and I do not see that changing just because 12c is used. We have to consider data, where is it, who can access it and create isolation.

My biggest worry would be sites using 12c to provide cloud like database services. Again this is not an issue of 12c per-se but an issue of the designers, developers and DBA’s. Provided proper separation is designed between pluggable databases there should not be an issue; so again fundamentally it comes down to shared or common accounts and privileges or even shared services.

In terms of a security auditing a 12c database it is really no different to auditing an 11g database except for shared accounts (essentially within one database �" the problem still occurs in 11g except that as an auditor we may not see it if the sharing is across multiple databases that we have not seen). If we have separated databases then we can have separated accounts with different passwords. We will lose the fast deployment but gain a little security with isolation. We can do this with 12c to some extent; our own created shared accounts should not exist without very careful thought. We should create local DBA accounts and admin accounts, shared accounts mean that if the password is breached in one pluggable database the whole of the container and all other pluggable databases are breached. This is really no different to non-12c except that we have an opportunity as an auditor in 12c to actually see the problem by viewing common accounts and privileges in each container.

In terms of auditing production system A on 11g or production system A on 12c its really no different except as I say we can consider the common issues as they are now available in the plug database where they would not have been in 11g.

Oracle 12c looks great, the idea is great, in terms of security the biggest issues are still customer deployments and designs not 12c. 12c allows us to see the shared issue locally where we would not have done so with 11g. It is going to be fun to review production 12c databases. The biggest concerns i would have would be inappropriate consolidation and sharing of privilege and users.