Happy belated new year to all my readers; I hope that you all have a very happy and successful new year in 2011.
I had been thinking whilst sitting day dreaming on many many flights over the last few months that it would be nice to write a new book but its hard work of course.
I keep getting asked by people more and more either in person whne teaching or via email etc why I don't do an update of the Oracle security step-by-step guide I did for SANS a long time ago; well two things, SANS dont publish books anymore and also they own the copyright so I couldn't update that book even if i wanted to. Also I don't think I would want to do a simple update anyway as my views on securing data (note I said data and not Oracle) are more focused on three areas not just simple hardening as only covered by the SANS step-by-step; my three areas are:
1) The security patches - small percentage of the whole as at the end of the day from a security auditors point of view you either apply the current patch or you dont. Dont worry I fully get all the financial/time issues around info/regression testing/ downtime ......
2) core hardening - This is what the SANS book focused on. changing well know settings such as utl_file_dir, os_authent_prefix, roles, privileges, default users and more to secure settings
3) The most important part (IMHO) is the bit that should have been done as part of design and implementation; that is to include security of the data and users as part of the application design. Its my experience that mostly this is not done or if it is done its not done any detail or to any depth at all or not very well. This is the area of user design, privilege design, data access design, security design within the database.
The first item accounts logically for a small percentage of security issues within the database when viewed from effort/cost not exploitation (at the end of the day you can apply a patch or not - its that simple BUT not from a cost time factor, i appreciate) - its debatable from exploitation angles as well whether this is also true because there are also other limiting factors such as "who" can make direct connections to the database to exploit a public issue. The general hardening accounts for a bigger percentage but certainly not all of the work needed to secure data - the biggest problem with general hardening is that; its general - the hardening guides and books known nothing otu your data or your design.
I would say point 3 the design work and the security that "you as the customer" should have implemented is the bigger part of securing your database. This is probably 60% - 70% of the whole of the work to secure your data. Anyway this is why I think a hardening book like the step-by-step has less value these days. I believe to make data secure the whole approach must be considered.
I said in a recent blog post that I have a back log of items to post about - indeed i have collected these into a list and i hope to find time to talk about a few of these over the coming months but i am already booked out quite a lot of my time on training and consulting into the middle of the year and I am also supporting our product PFCLScan so blogging is going to be fun toi fit in BUT i am determined to do so. I want to try and get back to writing like i did a few years ago with papers like the "exploiting and protecting Oracle" paper i did for Pentest. I liked to write in that style and i have a good list of subjects!
I have just updated the training page and added in the registration links for the class I am going to teach on "how to perform a security audit of an Oracle database" with Opitz Consulting in Thalwil in Switzerland in February. If you can make it there for the class it would be great to meet you there. I have not taught in Switzerland before so I am looking forwards to being there. The Opitz registration page is here please take a look.