How secure should your Oracle databases be?
These are interesting questions that we will cover in this three part post. This first part is going to cover the high level discussions / strategy and issues related to that. The second part will cover the process of reviewing what you have now and then the third part is going to look at the ongoing strategy to fix and secure all databases in the organisation.
You do not need a percentage secure figure or some other artificial measure of data security. These figures can be useful though to trace progress but if a database in your opinion is 75% secure what does that really mean?.
If it is measuring 75% secure this week and 71% last week and 69% the week before then that's useful as an indicator that progress is going in the right direction.
Some companies use standards like the CIS Benchmark to secure their database against. In the absence of anything else this is a starting point. Checklists like CIS focus on defaults and simple hardening. Imagine if someone applied all of the CIS to all of their databases; This would be a large task and in this case as a simple score they could claim 100% or high compliance against CIS and think that they are secure BUT imagine also that passwords are found or guessable or all data is granted SELECT, INSERT, UPDATE and DELETE to PUBLIC on all tables. This means that CIS does not protect the data. Actual data security and design measures are needed. Yes, the databases are hardened BUT the design of the database and application and data model are weak and the data can easily be compromised and hardening of the core database does not protect it.
There are multiple layers that we must consider when securing any Oracle database:
- Patching We must apply the security patches released by Oracle BUT their application in general does not affect the security of data itself
- Hardening This is the revokes, defaults etc from documents such as CIS or Stig or NIST. These are useful to harden the base Oracle software BUT they do not in general secure actual data
- Data Security
- Access Controls We must design security to allow access to the database to only those authorised and only when needed
- User Security Each user must have least privileges only and suitable password management and controls
- Data Access Controls All data must be designed and code and data separated in separate schemas and permissions created between data and code and users and roles
- Context Based Security The use of context based security can be added to allow more fine grained control to access to data, users and permissions. This can be by using Oracle technologies such as Database Vault or VPD or OLS etc or can be custom coded with triggers, code and more
- Audit Trails Each layer of the database should also have suitable audit trails designed and enabled to allow use of the database to be properly monitored
Of course other layers should also be considered from a security perspective such as the underlying Operating System and networking also also if necessary application layers
The security of data in Oracle databases is also affected by the number of databases - i.e. if you have 1,000 databases and 200 issues to secure in each that is 200,000 items to secure across the estate. This is excessive. The available budget to secure all data and the time available and number of people available to work on it must also be considered.
Inevitably this means that we need a security policy / design that is layered and is achievable across the estate.
One other factor to take into account is existing processes and working practices. Even if we change the security at a hardening level or re-design the actual data security if staff/users all share the schema password or SYS password that security work is useless.
We need an all-encompassing security design for data in an Oracle database including patching, hardening, data security, other layers and also process.
What is really needed at a high level is a risk assessment to create a valid list of all possible threats to the database and a valid list of possible vulnerabilities in the database and finally a list of counter-measures that can be used to mitigate the threats via exploiting the located vulnerabilities.
Join me soon for part 2 where I will discuss the actual audit process itself
#oracleace #sym_42 #oracle #database #security #audit #hardening #patching #vulnerability
