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.
I subscribe to Bruce Schneier's mailing list and in the most recent newsletter he replays an article that he wrote on xconomy.com about the fact that credential stealing is a more important attack vector than a zero day exploit or finding un-patched systems. The article is called Credential Stealing as Attack Vector. I teach the same idea in my two day class - How to Perform a security audit of an Oracle database as I cover simple ways that people attack databases and for me its obvious that if you can steal credentials or find credentials or even guess credentials because of weak passwords then that's a simpler and more effective way to steal data than a pure skilled exploited attack. Also because its simpler you need less skills in some senses to carry out the attack. Clearly we must focus on credentials, password management, storage of hashes, context based access to the database (network restrictions at the net level or database level) and more. A two page flyer for my class is also available to download.
If you would like training then please email me at pete at petefinnigan dot com for more details.
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!
I have added a link to the new Oracle Security in non-production paper to my Oracle security white papers page and I have also updated the text for the masking paper and also the link as what I had originally from Delphix was a temporary link. Please have a look at both papers (Note: Delphix require you to do a simple registration to get the pdf papers)