Pete Finnigan's Oracle Security Weblog

How do you know how secure your Oracle databases are?

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

My company PeteFinnigan.com Limited is 21 years old today!!

It seems that time has gone so fast. When I started the company my oldest son was a baby and now he is almost 22 years old and works here in our offices doing marketing.

I wanted to focus on helping people secure data in their Oracle databases. I think I have achieved this goal very successfully. We (and I) help people in many ways secure data in their Oracle databases and sometimes other databases. We specialise in securing data in Oracle databases but the ideas and techniques and knowledge we use also transcends other databases.

We do:

• Oracle Security Audits :We do a detailed review of customers Oracle databases and present the best cost effective strategy for them to secure their data


• Consult in all areas of Oracle security :We have consulted in so many areas of securing Oracle over the years and still do. Anything that relates to Oracle security we have helped with including audit trail designs, encryption in the database, use of HSM, Oracle key Vault, Database Vault, VPD, OLS, Masking and many many more...


• Specialist consulting; part of your team :We also are the Oracle security specialist in some companies teams. We work on a call off basis so that you can include us as needed in your projects and we bill to the minute. We work with a small number of companies doing this now and we keep it small to be able to fully support the clients. Talk to us if you would like a very cost effective way to have an Oracle security expert as part of your team when needed


• Securing PL/SQL : We do PL/SQL security code reviews and also help customer protect their PL/SQL with obfuscation


• Development consulting :We help companies in the development of software in the area of Oracle security with consulting and sometimes development help


• We have multiple software products :
  
  
  
  • PFCLScan :Scan your database for security issues and vulnerabilities
  
  
  • PFCLCode :Review your PL/SQL code for security flaws
  
  
  • PFCLObfuscate :Protect your PL/SQL
  
  
  • PFCLForensics :Manage a database data breach, perform live response and perform forensic analysis
  
  
  • PFCLCookie :Assess a website for cookies used
  
  
  
  


• Oracle Security Training :We have over ten days of expert training in all areas of securing data in an Oracle database


• Blogging, Speaking and presenting :We like to give away expertise for free via blogging, presenting, our website and free scripts and tools

What about the next 21 years of helping people secure data in an Oracle database (or other database)?

The one thing I can say about the last 21 years is that when I started there was literally no one else doing what I did which was specialising in deep detailed help and advice to secure data in Oracle. There was little to no evidence of much Oracle security going on. Security patches had not long started at that point; there were limited hardening advice and most people did not do a deep job on designing and securing databases. I remember cold calling companies back in 2023 and being able to speak to the right person and they were in the most part interested in what I had to say and offer BUT there was no budget to secure Oracle databases; the budgets went on network security and desktop security.

Most databases back then I did get to see had no security and most were the reverse of secure; i.e. everyone used SYS and SYSTEM and schemas, passwords not protected or changed in more than 10 years, no schema level security design, no hardening and ....

There was also often a kick back against security of Oracle often for fear it would break the running system and often because a lot of people didn't want to give away their elevated access. Some didn't want me to see and report on the bad practices as they knew deep down they were bad practice.

One thing back then was there were very few specialists in securing Oracle and amazingly after 21 years there are still not many out there. Why is this?, I have taught a lot through training but I guess security of Oracle is still regarded as the last task to be done in ten minutes before a new database / application goes live? so we are not needed?

I still see databases now that look like they did 21 years ago BUT the attitude and willingness to secure and learn has changed drastically in customers

The world has changed in the last 21 years; much more data theft and identity theft. Data in databases has become the new target; the new gold rush!!


#oracleace #sym_42 #oracle #database #security #databreach #forensics #plsql #securecode #obfuscate