Pete Finnigan's Oracle Security Weblog

My daily work is helping my customers secure their Oracle databases. I do this in many ways from performing detailed security audits of key databases to helping in design of secure lock down policies to creating audit trails to teaching people how to secure their own databases through attendance on my Oracle security classes and much more. Talking to customers either generally or as part of an audit often reveals common Oracle database security issues over and over again.

My efforts in helping securing Oracle is not lead by the goal of securing Oracle itself. My focus is to help secure data. We must locate the data that is critical to the business and understand where that data is held across the organization. The goal is to ensure all copies of that data are secure. Obviously we must use the features of the Oracle database to secure the data in the database BUT the emphasis is not on securing Oracle but securing data.

My motivation is aimed generally on the production database and data. Therefore one major issue I come across often is the fact that I can help advise the customer to use the production database to lock down their data but they regularly advise me that data is also copied to test and development and UAT and sometime external suppliers as well. This is so that the applications and database can be developed and tested. Almost always companies are happy to lock and secure production but do not secure the data in these other databases. This is a problem as the potential risk or threat moves to test and development from production.

Customers are willing to spend money and assign budget to secure and lock down the production database with less efforts targeted at securing a test or development system. Similar is the issue of creating and building audit trail solutions; the client is happy to spend money on production for audit trails but usually not to test and development systems.

My aim is to secure data across all databases BUT often money is spent on production only. What if we could secure production and add audit trails to production and then copy all of that Oracle database security to all test and development systems? More importantly what if we could set up and mask the data once but copy just the masked data to all test and development systems without the clear data ever leaving production? Securing and setting audit trails once and having those configurations copied to every cloned database could be a great benefit to most companies but masking once and copying only masked data to all cloned databases is a marked improvement over the often lack of Oracle data masking seen in the real world in all databases. Data masking in Delphix is a very flexible tool and combined with the virtualized facilities it becomes very powerful.

I am going to be delivering a webinar with Delphix on the 30th March at 10am PST (USA time) and also the 7th April at 10am UK time where I am going to explore these Oracle security issues and more and also look at what Delphix can offer to help solve some of these issues with a detailed look at the problems often voiced as to why customers do not mask data in cloned databases. Please join me for the USA webinar by registering on the Delphix registration page or if you would prefer to join me for the UK/EU webinar then please register on the Delphix registration page for that event.