The first is that we must secure the data - That is, we identify the data to be secured and we ensure it is secure within the Oracle database using standard database controls and also context based security controls as necessary. This means we are securing data and not Oracle. It is not Oracle security and it is not Oracles responsibility to secure your data; It is your responsibility. In the same way that you design tables, views, screens and whatever you must also design security BUT people do not take the security of data held in an Oracle database as seriously as it should be taken.
The second is that we must also secure the Oracle platform (Database; OS and network specifically related to Oracle) so that the platform is not used as a jump off point to attack the rest of the company network simply because the Oracle platform is large and often default in nature.
So we tend to have two main areas to think about; hardening against platform risks and security of the data specifically. In considering these main areas we can compartmentalise Oracle security into three areas:
1) Patching - covers 1-10% of the task of securing the database - in auditor terms, i.e. its patched or its not patched
2) Hardening - covers 30% of the task of securing the database - in general hardening will not secure the actual data itself but will help with platform level risks BUT some hardening can contribute to the security of the data itself such as adding context based network access
3) Design work - covers 60% of the task of securing the database - This covers data design around access controls for data access, least privilege design of users and context based security as well as audit trail design, secure coding and much more.
What has become clear to me over the years has been the fascination and obsession with applying Oracle CPU and similar security patches and the obsession with testing if a complete patch has been installed by creating checksums of each individual PL/SQL package and more and then testing against these. Patches for me have always been more about is there a proper policy and is it adhered to and are patches applied regularly. Don't get me wrong, security patches are important but in general all of the attack vectors to access data when you should not or steal weak credentials or take advantage of excessive rights and much more are not fixed by applying a patch. The patch is important but it would not fix the other issues.
We must have a holistic approach to securing data and also to securing the platform.
If you would like to learn more and to book a private training class or ask for details about my training courses then please email pete at petefinnigan dot com. Also if you would like to perform a security audit of one or more Oracle databases then have a look at our database security scanner PFCLScan and ask me for details again by emailing pete at petefinnigan dot com. Our engagement license for PFCLScan is fantastic value as you can scan as many databases as you wish from one installation of PFCLScan for 30 days and its just £110 GBP (plus VAT if applicable). Talks to us!