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. > [EMAIL PROTECTED] > > -----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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
