, November 28, 2002 5:45 PM
Subject: Re: Oracle OS level security
On Thursday 28 November 2002 12:03, Tim Gorman wrote:
My $0.02...
Oracle9i provides the AUDIT_SYS_OPERATIONS parameter, which will audit
only
to the OS audit trail. Thus, anything that SYSDBA does can be
audited
Jared,
Very interested in the thread you hypothetical raised. I'm working in a
pharamceutical site which is subject to FDA and other regualtions part of
which is the whole buisness of audit trails.
We has a Standard Operating Procedure which states that whilst DBA's have a
access to data they
My $0.02...
Oracle9i provides the AUDIT_SYS_OPERATIONS parameter, which will audit only
to the OS audit trail. Thus, anything that SYSDBA does can be audited.
The reason for the OS audit-trail only? Because SYSDBA can always erase a
DB audit trail (even if the act of erasure is still audited).
On Thursday 28 November 2002 12:03, Tim Gorman wrote:
My $0.02...
Oracle9i provides the AUDIT_SYS_OPERATIONS parameter, which will audit only
to the OS audit trail. Thus, anything that SYSDBA does can be audited.
The reason for the OS audit-trail only? Because SYSDBA can always erase a
DB
On Thursday 28 November 2002 03:53, O'Neill, Sean wrote:
We has a Standard Operating Procedure which states that whilst DBA's have a
access to data they will not change it. A recognition of the DBA's
capabilties but stating on paper company trust they will behave
themselves.
Auditors are
--- Jared Still [EMAIL PROTECTED] wrote:
On Thursday 28 November 2002 03:53, O'Neill, Sean wrote:
We has a Standard Operating Procedure which states that whilst
DBA's have a
access to data they will not change it. A recognition of the DBA's
capabilties but stating on paper company
I believe the BBED tool is being phased out.
Regards,
Patrice Boivin
Systems Analyst (Oracle Certified DBA)
-Original Message-
Sent: Tuesday, November 26, 2002 8:09 PM
To: Multiple recipients of list ORACLE-L
Jared:
Any one with a reasonable knowledge of Oracle Data Storage
Internals
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
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.
Hadn't even considered BBED, and I have no idea
what their take is on it.
Guess I'll have to ask.
Jared
On Tuesday 26 November 2002 16:09, K Gopalakrishnan wrote:
Jared:
Any one with a reasonable knowledge of Oracle Data Storage
Internals can use the Data block Editor (BBED) to update
True, and the question suggests the DBA can be properly vetted while the system
administator cannot. I suppose one could try somne type of two-man control. Jared
and his system administrator each know a different half of the root and sysdba
passwordJust how this could be setup is beyond
Jared,
It seems to me that you can use these auditors to your advantage. Tell them
the security risks that you know about, and let them write their report.
You might be able to use the report to coerce management for some changes -
like dedicated Database servers with a limited number of 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:
Jared,
I realize the following is not really an answer, but it may provide
a little food for thought.
Practical:
1. Log miner or other log reading tool could be used to track
changes made through the transaction layer. Some operations can be done with
nologging, but not
Jared - I would be very careful about naming specific tools. Having been an
NRC auditor and been audited a lot of times, there is sometimes too much
specific information, which will leave the auditor with the impression there
is no security at all. They will then feel obligated to flunk your
My experience with NT security in an environment of any significant size is
that it is a hopeless situation. In addition to dealing with admins on the
box with the database, it seems that there is always an application support
person or two that needs to administrator privs on that box too.
by: [EMAIL PROTECTED]
11/26/2002 04:09 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: Oracle OS level security
Jared:
Any one with a reasonable knowledge of Oracle Data Storage
Internals can use
of list ORACLE-L
Subject: RE: Oracle OS level security
Let's face it. The SA's have all the privs in the world.
Finally, with 9i, and connect internal going away, we can prevent
unauthorized connections to the database to prevent data
snooping. But we
all know that there are ways around
Let's face it. The SA's have all the privs in the world.
Finally, with 9i, and connect internal going away, we can prevent
unauthorized connections to the database to prevent data snooping. But we
all know that there are ways around everything in this world.
It comes down to this simple
Dan
Point taken. I was thinking more of being careful with recently hired
employees and consultants that will only be around for a short time.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-Original Message-
Sent: Wednesday, November 27, 2002 10:10 AM
To: Multiple recipients
You may just possibly be the only other DBA besides me who does NOT
want root access!
I know just enough to be dangerous. I have more than enough work to do
without taking over the SA's job as well.
theoretical point 2:
yes, you should trust your DBAs and SAs. But if you, for whatever
reason,
NRC audits, boy those sure are fun to be on the receiving end of. Nothing like
getting comfy on the couch and reading 10CFR for pleasure.
-Original Message-
Sent: Wednesday, November 27, 2002 10:56 AM
To: Multiple recipients of list ORACLE-L
Jared - I would be very careful about
Just a thought.
How about also encrypt the sensitive data. And the one who holds the
key to decrypt it doesn't have access to the system. And the one does
have access doesn't know the key to decrypt. The two will have to
work together to do un-authorized things, but at least it will make it
Excellent point.
I always say, I know enough NOT to be dangerous. Funny, two comments that
are syntactically opposite, really mean the same thing.
-Original Message-
Sent: Wednesday, November 27, 2002 11:45 AM
To: Multiple recipients of list ORACLE-L
You may just possibly be the only
Dave - Good to hear from a fellow-sufferer. It suddenly occurs to me that if
the war on terrorism continues, the feds may mandate something like 10CFR
for computer security. I recall that 10CFR was adapted from something
earlier. Whew boy, I can hardly wait.
Dennis Williams
DBA
Lifetouch, Inc.
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
Jared:
Any one with a reasonable knowledge of Oracle Data Storage
Internals can use the Data block Editor (BBED) to update
anything in your database without the knowledge of the
RDBMS kernel auditing mechanisms.
Agreed,BBED is protected by a password in Windoze ports
and one need to explicitly
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
--- [EMAIL PROTECTED] wrote:
What is BBED? I never heard of it.
From: K Gopalakrishnan [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: Oracle OS level security
Date: Tue, 26 Nov 2002 16:09:27 -0800
MIME-Version: 1.0
Received: from newsfeed.cts.com
]
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: Oracle OS level security
Date: Tue, 26 Nov 2002 16:09:27 -0800
MIME-Version: 1.0
Received: from newsfeed.cts.com ([209.68.248.164]) by
mc8-f17.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov
2002 17:06:39
]
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: Oracle OS level security
Date: Tue, 26 Nov 2002 19:28:42 -0800
MIME-Version: 1.0
Received: from newsfeed.cts.com ([209.68.248.164]) by
mc6-f19.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov
2002 19:57:49 -0800
31 matches
Mail list logo
