Oracle-L: RE: Oracle OS level security

From: Fink, Dan <Dan.Fink_at_mdx.com>
Date: Wed, 27 Nov 2002 08:09:36 -0800
Message-ID: <F001.0050DA04.20021127080936@fatcity.com>

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:

Make the server with critical information as secure as possible.
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:
Hire trustworthy professionals, people that can be intimidated by the threat of being fired.
Hire people too stupid to understand how to break into stuff.
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

--

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).
--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Mercadante, Thomas F
INET: NDATFM_at_labor.state.ny.us

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).
--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: DENNIS WILLIAMS
INET: DWILLIAMS_at_LIFETOUCH.COM

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------