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

  • From: Pete Finnigan <pete@xxxxxxxxxxxxxxxx>
  • To: cicciuxdba@xxxxxxxxx
  • Date: Mon, 20 Jun 2011 20:48:23 +0100

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"

cheers

Pete

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
PeteFinnigan.com 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
email: pete@xxxxxxxxxxxxxxxx
site : http://www.petefinnigan.com

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 PeteFinnigan.com Limited.  This email is
not intended nor should it be taken to create any legal relations,
contractual or otherwise.

--
//www.freelists.org/webpage/oracle-l


Other related posts: