Call: +44 (0)7759 277220 Call
Blog

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "Oracle TDE and Oracle ACE and Website"] [Next entry: "Easily Locate Security Issues in your PL/SQL Code"]

Compare the Database Security of Oracle Database 11g, 12c, 18c, 19c, 21c and 23c/ai



We have recently added around 750 new checks to our Oracle database scanner PFCLScan for our new version 2024 release that can be used to locate security issues in any Oracle database. We now have around 2000 security checks that can be run against any Oracle database to check its security posture.

We support scanning databases up to the latest 23c and as far back as Oracle 9iR2. Yes, although rare now, we do still get some customers running 9iR2 and 10g. Our normal focus on 19c as that seems to be the predominate database that our customers scan and work on and we see some on 21c and as I said some older but mostly 19c.

I will describe the scans and the results shortly but first some words about the test databases.

I wanted to compare the security of 6 different databases using the same scan checks and reports so that at least is consistent. The problem is not all databases are equal. We have legacy databases; we have multitenant databases, we have Enterprise Edition Databases, we have free editions such as XE and FREE. We also have Standard Edition. Each database that I tested is running on Oracle Virtual Box and some are local to the scanner on the same laptop and some are on our office server running via Oracle Virtual Box. Each database is running on different virtual hardware; the worse case being the 23c Free running on the limited spec allowed by the Oracle supplied image. Some are running on multi-processor with much more RAM.

Each database is similar in state; in that we created these test instances to test our software products and they are not production systems. Some have limited amounts of test applications and data and some are vanilla.

For the multitenant databases we connect to the PDB and scan but as a multitenant database must also have a CDB we should probably also consider the state of security of the CDB BUT as we wanted to compare database for database we will just look at the PDB in each database.

Also remember that in 11g or indeed a legacy install in an older multitenant database the password hashes for each user are stored in the same database, in early multitenant the password hashes for common users are available in the PDB but not in later databases so for the password cracking for instance we cannot crack common user passwords in the PDB.

We must also consider versions and features. A smaller number of features and parameters that affect security are deprecated or removed in later databases BUT new features and settings that can affect security are added in later versions.

So, if we take all of the versions, types, settings, legacy, multitenant, what's installed and more into account comparing 11g with 23c is clearly not like for like BUT its good enough to try and draw some conclusions.

The databases tested are 11g (standard Edition 2 - Legacy), 12.2c (Enterprise Edition, multitenant), 18c (Enterprise Edition, multitenant), 19c (Enterprise edition, multitenant), 21c (XE, multitenant) and 23c (FREE also multitenant)

We are not the same as CIS or DBSAT. We check a lot more things in the database; indeed we check much much more than CIS but we do cover similar areas but in more depth. We also check differently in some cases. Where standards often call for execute not to be granted to PUBLIC for a specific PL/SQL package such as UTL_FILE we check for everyone its granted to as that matters in terms of trying to lock down and secure your data in an Oracle database.

In general we want to understand a number of layers in securing an Oracle database; patch status, hardening, actual data security and of course context based security as well as audit trails. We cover all of these areas not just hardening

we use the Oracle user SYSTEM to connect for these tests BUT you simply need an Oracle database user that has CREATE SESSION, SELECT ANY DICTIONARY and SELECT ON SYS.USER$.

So, back to the tests. I connected to and scanned each of the 6 databases separately and then ran two reports; the single page summary report that gives a score for the whole database and also breaks down the issues into categories and gives scores for each. Rather than print in line here 6 reports I have summarised the scores into Excel and show an extract here:
PFCLScan scores from auditing multiple database versions



If we first look at how the overall score for each database version changes over versions we can more easily see this in a graph:
PFCLScan overall database security score from auditing multiple database versions



This is interesting; taking into account the versions of database, data and types of database described above. Even if we consider the databases are EE, XE, STD, FREE and different versions the core security only really changes in terms of a very small number of function, features and parameters removed over time and more features, parameters and functions added over time. The graph shows that the security got better from 11g to 18c and then dropped again with 19c quite a bit and then improved for 21c and dropped again slightly for 23c.

What we cannot see easily is although the databases changed, the security parts changed in terms of quantity we cannot see how much changing settings from insecure to secure changed the overall picture; my feeling would be not a lot as the quantity change is likely to be much bigger and drown out limited setting changes BUT a much more detailed analysis would be needed and also on clean same edition just installed databases with no customer data / code / users added BUT I don't have that here today to test with; maybe in the future

How did I calculate these scores?

Each check executed against the database has a severity and also category. Checks that are severity 1 (critical) have a higher weight than checks that are severity high (2) and so on. We know how many checks are run per database and how many fail and pass per severity so we can calculate the percentage pass rate (the % secure) for the overall database and also the percentage pass rate at the category level

Next is a breakdown of the percentage pass rate per category for each database version tested:
PFCLScan score per category from auditing multiple database versions



The output is interesting and again shows how security, lets call it default security as we did little of our own work to these databases. If we look at patches each version is very similar with 19c and 21c coming out slightly better. This is mostly due to the state of the database as installed. In all cases from 11g through to 23c all databases were either a pre-packaged rpm from Oracle or a "yes, give me a default database" on install. This is because these are not production and are used only for development and test.

If we look at audit trail, 11g was around 60% pass rate, 12.2 got worse, 18c similar and then there was an improvement from 19c and 21c but this dropped off again with 23c. The dropping off with 23c could be the de-support of standard auditing.

Password security is interesting; the overall state is similar across all 6 database versions but it got clearly better from 11g to 18c, dropped a little with 19c and 21c and came back again slightly with 23c. These figures and skewed and comparing 11g to the later versions is slightly unfair as in 11g all passwords are in a single instance but for 12c to 23c we have looked at the PDB only but the CDB also has a set of passwords and after 12.1.0.2 the hashes for common users are not in the PDB.

Hardening is interesting; if we look at the trend, its clearly going down from 11g to 23c with a slight blip up for 18c. Hmm, is hardening getting worse as a default? most likely this is because the default improvements are very small but the number of things added that can affect security has grown over the versions and years and clearly more are not default in the most secure state.

User security is all over the place. in 11g it was much worse, 12 and 18 improved a lot, 19c dropped back to 11g levels and 21 and 23 improved again. Why? as we said above a few reasons; the 11g was legacy only from 12c we are only taking into account the PDB and also we must consider algorithms and default status of default accounts.

Data security is pretty level but clearly dropping slightly over the years and versions BUT there is little to no data in these test systems and my experience on real systems is that this area is usually the worst for customer databases as the security tends to be non-existent at the data level and/or its legacy style designs.

External access again is relatively flat across versions but as you can see the trend is downward slightly as we go from 11g to 23c

Vulnerabilities is all over the place, 11g is low as is 19c and 21c but the others fair better

Data Security is the most important area of course in all of this; we are of course trying to secure data BUT this test does not cover data well as my test systems do not have real applications in them

A sample top half of a single page score report is shown here:
PFCLScan single page score report for 23c




Ask me for more details of PFCLScan 2024, ask for me to demonstrate the product live to you on webex or simply ask me if you would like to buy a license or if you would like us to audit your database for you.

#oracleace #sym_42 #ukoug #oracle #database #security #securityscan #vulnerabilities #datasecurity #databreach #datahacking #lockdown