Pete Finnigan's Oracle Security Weblog

It has been a long while since my last blog post. I have been very busy with Oracle security consulting, data security audits, teaching training courses and of course with my companies Database Security Scanner - PFCLScan. Oracle security has not stood still for me even though i have not been blogging.

I was speaking yesterday at the UKOUG SIG event in Blythe Valley Park. This was a good event, some good discussions outside of the speaking room and some good questions in my presentation. I gave the talk that i did at the Oracle Security day in Bletchley Park; I have updated it a bit but essentially the message is the same. This is "secure the data" not "Oracle security"; of course you must use Oracle (the software) to secure your data as part of the solution but the main stay in securing data is to know exactly what data you want to secure, where it is and then decide how best to spend your money to reduce the risk that your identified data maybe stolen. This involves setting down a data security policy, developing strategic and tactical solutions, bringing in compliance (mandatory, recommended and non-compliance processes) and targetting resources on available database features and functions or combining third party Oracle security products.

One area I talked about was using proxy accounts to reduce the privilege expansion often seen by having multiple powerful DBA accounts in the database and also using proxy accounts to allow third parties to utilise your schema accounts without giving them the password whilst also being able to audit their actions isolated from others actions whilst connected to the schema acccount. This is a great use for proxy accounts and solves a privilege and accountabilty issue. I demo'ed a short SQL*Plus script yesyerday to show how this may work in these scenarios. The script is tst_proxy_DBA.sql. I also have a second script tst_proxy_mult.sql that simply demonstrates that using proxy is not a one-to-one relationship between database accounts. A single database account can proxy through multiple other databases accounts (not at the same time) and conversely multiple accounts can proxy through the same account. Note: to run these scripts you will need to edit the connection details in them to not use my database alias (orcl) and my IP address. Also change the SYSTEM password to your own.

I met with Arjen Visser the CEO and CTO for DBVisit on Monday in York who make two products DBVisit Standby DBVisit Replicate where the first is a standy alternative that also works with Oracle database standard edition and the second is in DBVisits words "Affordable replication". Arjen gave me a demo of his software and I also did a demo of PFCLScan our database security scanner and we had a really good discussion about software development, Oracle and Oracle security. It was a really nice couple of hours.

Over the last few months I have also done some work on our PL/SQL source code protection software PFCLObfuscate over the last few months to set up a website for it (it is not complete yet but work in progress) to showcase the products features and uses and also to offer online sales. The shopping cart is also work in progress but if anyone is interested in the product please contact me via email (address is in petefinnigan.com contact page). The idea of the product is to allow people to more safely ship PL/SQL products or software associated with an application to make it harder for anyone else to get at the IPR (Intellectual Property) of the code.

Also around a month ago I was contacted by email (I won't say who as he didn't know I would talk about this here) by someone who wanted 11g password features added to my PL/SQL Password Cracker. I promised to do that but time has passed by so fast and other things took over. I started to have a look at the code last night and rationalised the versions I had for consulting and also the current one for download on my site. I have changed the functionallity slightly and added over 500 more distinct default passwords that i have "gleaned" from various sources including every Major Oracle installation from 7.0.1.6 to 11.2.0.1 by grepping installations for passwords. I have also searched Oracle documentation, Metalink, OTN and more for default passwords. This resulted in literally thousands of passwords found which were rationalised into distinct passwords and added to the PL/SQL cracker. I am adding facilities to also crack case sensitive passwords to the PL/SQL password cracker and won't make promises yet but i will release a new version of it soon; watch out!

Finally over the last year the UK has been under threat of the so-called Cookie Law. The European Union dictated that each EU member state should have implemented their own law for this by May 25th 2011; the UK was the only EU country who did this but then gave a one year amnesty for companies/web site owners to plan how they will comply and also to comply. The law at a high level means that you (as a UK/EU website owner) need to audit your site and know what cookies are used and stored on your users devices. Then you must add prominent notice to your site explaining what cookies are and if required (because of your audit results) add consent mechanisms to your sites to ask users permission to download cookies. To cut a long story short i implemented some tools to audit our sites for cookies and also implemented policies and prominent notices. As a result of now having tools to audit websites for cookies and also having experience of audits anyway from the data security world and also now of auditing for cookies we have done some cookie audits for website owners here in the UK and we are also offering to do the same for anyone else running a UK/EU website so that they can be compliant with this new law. Details of the service are on our Cookie Law Audit Site PFCLCookie. If you need help we are now experts in this law, tools to use, solutions and of course in performing audits.