Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Oracle OS level security

Re: Oracle OS level security

From: Stephane Faroult <sfaroult_at_oriole.com>
Date: Wed, 27 Nov 2002 11:58:55 -0800
Message-ID: <F001.0050E15D.20021127115855@fatcity.com>


Very nicely put, Dan. I was thinking about words which have deserted modern vocabulary, such as 'duty' or 'virtue' (in the Latin sense). Somewhere along the line you have to trust people.

>
> Dennis,
> I must respectfully disagree with 1. I would suggest that the 'can'
> be changed to a 'cannot'. It is this type of person that will stand up and
> say 'This is wrong.' Therein lies your security.
>
> Dan Fink
>
> -----Original Message-----
> Sent: Wednesday, November 27, 2002 7:19 AM
> To: Multiple recipients of list ORACLE-L
>
> Jared - I think Thomas has a good point. Here is the way I look at it:
>
> 1. Make the server with critical information as secure as possible.
> 2. Restrict command line or console access to the minimum number of people.
> This narrows you down to a few sys admins and DBAs. For them your choices
> are:
> 1. Hire trustworthy professionals, people that can be intimidated by the
> threat of being fired.
> 2. Hire people too stupid to understand how to break into stuff.
> 3. Configure a really paranoid system to keep the people that must manage
> the system from being able to do their job. You could spend a lot of extra
> effort on this one. And it would have to be designed and audited by people
> outside the company.
> Years ago, a company I worked for tried option 3. It was a mainframe
> system with no interactive access. There were three groups of people that
> worked there, keypunch operators, programmers, and computer operators. The
> theory was that to defraud the system would require more than one person. A
> programmer could write a bogus program, but couldn't run it, would need an
> operator. And so on. They even had a separate building entrance for each
> group. Nobody outside of management seemed to think it was all that secure.
>
> Dennis Williams
> DBA
> Lifetouch, Inc.
> dwilliams_at_lifetouch.com
>
> -----Original Message-----
> Sent: Wednesday, November 27, 2002 7:14 AM
> To: Multiple recipients of list ORACLE-L
>
> Jared,
>
> Nice question. I don't have an answer, but a comment.
>
> It all comes down to Risk Management. In my opinion, Risk Management
> entails identifying all known risks to losing or changing data in an
> authorized manner. Once the risks are identified and explained to the
> organization, they decide what needs to be dealt with and what they are
> willing to "risk" based on the probability of the event actually happening.
>
> In your example, you've identified the risk of allowing other people admin
> access on the database server machine. If management is unwilling to revoke
> these privs, then they need to understand the risk that they have accepted.
> The risk they've accepted is that someone could, thru the use of stolen
> passwords, the BBED editor, or simply deleting a database file, cause a
> disruption, loss of service or loss of data to the organization. And there
> is not much you (as the DBA) can do about it.
>
> I'm sure I'm preaching to the choir here. But a lot of what we (DBA's) do
> comes down to communication and education of management, and explaining
> things in terms that they can understand.
>
> Hope this helps.
>
> Tom Mercadante
> Oracle Certified Professional
>
> -----Original Message-----
> Sent: Tuesday, November 26, 2002 6:05 PM
> To: Multiple recipients of list ORACLE-L
>
> 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
>

-- 
Regards,

Stephane Faroult
Oriole Software
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Stephane Faroult
  INET: sfaroult_at_oriole.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 Wed Nov 27 2002 - 13:58:55 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US