Pete Finnigan's Oracle Security Weblog

I will be at the Amis conference next Friday in Leiden not far from Amsterdam in Holland. The conference is held over two days, June 2nd and 3rd But I will be there just on the Friday due to other commitments. I will be doing a one hour and forty minute master class on Database Vault and also what you can do to get similar protections if you do not have Database Vault. I don't mean simply trying to replicate the functionality of Database Vault BUT what can we do with standard controls and good design to achieve similar effects. I will also cover the simple fact that you must also decide and design what to do with Database Vault as its just another application in the database and it must be deployed securely and you also must secure your database first with good design, data access controls and user designs and more. The Amis conference is Next week and details in this link.

I spoke yesterday about compartmentalising Oracle Security and one element that comes out of this is the need to consider what you are trying to achieve; secure actual data and also secure the platform. In general applying security patches will not secure specific data from attack by someone who gains access via a logged on account or by abusing an applications source code (SQL Injection for instance). Hardening a database also will not make specific data any more secure from the same vectors. Hardening and patching are important but in general they will not secure data anymore that it already is secured because that is controlled by object permissions, object owner and system ANY type privileges. Also factor into this the account used to connect end users via an application.

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 http://www.xconomy.com/boston/2016/04/20/credential-stealing-as-attack-vector/# - (broken link) 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.

I have been teaching security classes about Oracle Security for many years and they are very popular and I teach many classes per year around the world; mostly in the UK and EEC but I also venture to the Middle East and also as far as Mexico and Singapore and upcoming also probably to Australia and India - basically please where I can get to hassle free (no lengthy visa process in advance or no visa at all). I also teach regularly on-line to customers particularly in the USA (remember the visa process!). One the key messages I use in my classes is that securing Oracle is a complex task and we must understand that there are two things to be done;

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 was asked by Delphix earlier this year to review their product with a particular focus on Oracle security of course. I wrote two papers; the first about Data Masking and Delphix and the second about securing data in non-production databases by taking the already secured production (assuming that it is secured of course) and then using Delphix to clone to non-production. If production already has a template of security then this is a great method as we get non-production already secured with just a small number of additional tasks that may need to be done in each clone database. In my experience most non-production databases are not secured to the same level as production and also often lack controls such as audit trails so taking a clone is a good way to not only replicate a database but also to replicate security.

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)