jared,
no answers... but I did read to the end. Thank YOU, you've given me a
lot to think about and to talk to our hosting company about.
What really scares me is that I have no way of auditing the hosting
company.... who have total access to production.
Rachel
- Jared.Still_at_radisys.com wrote:
> Dear list,
>
> Let me toss a hypothetical situation at you.
>
> Say some auditors looked at some of your primary systems,
> and concluded that they had no assurance that someone with
> admin access to the server had not changed financial information
> to benefit themselves, or to falsify financial records for the
> gain of the company.
>
> Not that they might have any proof that something like that
> had been done, but rather, just not proof that it had *not*
> been done.
>
> I've been pondering this for a bit, and it seems to me that if
> someone had good knowledge of both the OS and the
> database (Oracle), as well as having admin rights on the
> server, there are few things you can do to prevent such a person
> from changing data in the database, and completely
> covering his or her tracks.
>
> The platforms in question are Unix, Windows NT and
> Windows 2000. I've limited it to those as most database
> systems use one of those, and besides, that's all I know. :)
>
> Consider what steps you might take to audit unauthorized
> transactions performed by an admin.
>
> Oracle Auditing could be used, but someone with admin
> access to the server and database could easily alter the
> records created by system auditing.
>
> You could create an audit table, using a trigger to audit
> sensitive tables. A materialized view on a remote database
> could be created on sensitive tables to remotely log all
> actions.
>
> In the case of the audit table, that could easily be disabled,
> and then re-enabled after the nefarious DML had completed.
>
> The materialized views might be more difficult to circumvent.
>
> If the remote end is using a dblink to the server employing a
> password that is *different* than that of it's own account at the
> remote server, it should be impossible for someone to completely
> cover the traces of transactions created to falsify data.
>
> The MV Logs could be dropped, but without access to the MV's
> at the remote server, the MV's would have to be left in place.
>
> These could be used as a reference to look for unauthorized
> transactions
> in the primary server. If this same admin has access to the remote
> server where the MV's are, then this can also be circumvented.
>
> There is also the logs created as when logging in as internal
> or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud )
>
> These can simply be deleted. Some system could be used to save
> these to a remote server, but it would have to run *very* frequently
> to
> be effective.
>
> Oracle password files could also be used. While this can prevent
> someone from logging in as SYS or SYSTEM while in place, all it
> takes is a change to init.ora, and a database bounce to fix that.
>
> Make your bogus data changes, change the init.ora back and
> bounce the database again.
>
> A somewhat clever person could set this up to automatically
> take place the next time the DB is bounced.
>
> The conclusion I have come to is that the only effective method
> that could be used to create an audit trail for such a scenario is
> to create Materialized Views on sensitive tables, and create them
> on a server that admins are guaranteed to not have access to.
>
> Of course, I may be missing something. I'm not always one to
> catch all the details right off. Input, comments, suggestions, far
> out ideas are all welcome.
>
> If you've read this far, thanks!
>
> Jared
>
>
>
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author:
> INET: Jared.Still_at_radisys.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Rachel Carmichael
INET: wisernet100_at_yahoo.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Tue Nov 26 2002 - 20:14:11 CST
