Re: Securing Oracle, where to start? what to read?

From: Pete Finnigan <>
Date: Mon, 20 Jun 2011 20:48:23 +0100
Message-ID: <>

Hi Alan,

David Knox's books are excellent but they focus on product/implementation of techniques etc. This is good but not the complete picture.

Securing Oracle consists of three distinct peices

  1. patching - a boolean decision - apply = TRUE/FALSE if FALSE little or no workarounds
  2. hardening - things like the Stigs mentioned, the CIS benchmark, the SANS step-by-step, the ISACA book. The content of the STIG is OK but i dont like the approach of installing checks in a database. The CIS has been updated some time ago but unlike hacking, hardening doenst go out of date as fast. Links to SANS, SCORE, CIS, Stig etc are available via my white papers page
  3. The bigger issue is to secure the actuial data and access. you are really here doing the design work and implementation that should have been done when people focused on SLA's and performance and functionallity. There are no simple step-by-steps to do this. You must understand where your data is and who can access it and how. This is where you can bring in hacking techniques discussed in David Litchfields books. The OHH is the later one and the better one. They are out of date but the "mind set" is still very valid. You must get some ideas of how people may attack you and then work out how to protect/secure. A strategic solution should be combined with some detailed/critical technical fixes at the data level. One of the big problems with Oracle databases is that "people" not the software take the data out of the database and leave it all over the place, and people access the data in as many varied ways as you can imagine so it means you have to think outside the box to come up with lots of solutions.

Security is unforunately not cheap because it takes a lot of time to do it right.

Going back quickly to David Knox's books is the realisation after looking at a large amount of databases is that these great security solutions often free with your license are hardely ever used. Its a pity; security should be an equal part of the design.

Finally check out David Litchfields papers on forensics and his v3rity tool for some ideas on how to check "after the fact"



Guillermo Alan Bort wrote:
> List,
> After a few years in the field of database administration I've come
> to realize that I am utterly unprepared to deal with an attack on my
> databases. Luckily enough I haven't had to test that, but as it is I
> have no experience and I feel that if the day ever came that I had to
> either find out how an attack happened (post-mortem) or deal with one in
> real time I would be outwitted by most attackers. Furthermore, I fear
> that our security guidelines are outdated and probably rather pointless
> by now. I'd like to start reading up on this specially about real life
> attacks on database security and ways to secure the database that grant
> the best possible security and minimizes pain for the users.
> Does anybody have any good books/white papers/websites to recommend?
> Of course, I'm already familiar with Pete Finnigan's web
> www.*petefinnigan*.com. And there are a few of the white papars
> published there as well as the tools that look very interesting.
> Thanks in advance
> Cheers
> Alan.-


Pete Finnigan
Director Limited

Specialists in database security.

Makers of PFCLScan the database security auditing tool.

If you need help to audit or secure an Oracle database, please ask for
details of our training courses and consulting services

Phone: +44 (0)1904 791188
Fax  : +44 (0)1904 791188
Mob  : +44 (0)7742 114223
site :

Registered Office: 9 Beech Grove, Acomb, York, YO26 5LD, United Kingdom
Company No       : 4664901
VAT No.          : 940668114

Please note that this email communication is intended only for the
addressee and may contain confidential or privileged information. The
contents of this email may be circulated internally within your
organisation only and may not be communicated to third parties without
the prior written permission of Limited.  This email is
not intended nor should it be taken to create any legal relations,
contractual or otherwise.

Received on Mon Jun 20 2011 - 14:48:23 CDT

Original text of this message