Mark,
Funny you should mention this...
About 2 years ago, I was having a discussion with the CFO of an energy
company located here in Denver. We were talking about Sarbanes-Oxley.
Since the law provides for the CEO and CFO to be imprisoned and/or
fined for violations, she declared, "I am *NOT* going to go to jail
because of some crooked IT person." There were about 15-18 people
around to hear this, mostly academic types, all looking grave.
I was a little incensed by this trash talk, and when that happens I
tend to speak more quietly than normal. I asked her, "In all of the
news stories about companies like Enron, MCI, Qwest, and similar, did
you ever see a single IT person led out of the building in handcuffs?
Did you ever read about a single IT person involved in any way in any
of those scandals? Nope. Because IT people are the most trustworthy
people anywhere. It's people from accounting and the financial side of
the house who are being caught, indicted, convicted, and sentenced.
But with all this Sarbanes-Oxley nonsense, IT is first to be forced to
fix what isn't broken."
She was taken aback, and then parried, "Well, what about white-hat
hackers? You can't say that they're trustworthy-- they're felons!"
I had to laugh, "They were hired for their dishonesty. They are doing
exactly what they were hired to do, which still makes them far more
trustworthy than any typical financial executive scheming another shell
game to rip off investors."
She was pretty upset. It's interesting how people have gotten
entrenched into their ideas. She remains absolutely convinced that her
biggest risk of going to jail under SOX is not from the people with
whom she works every day, but the "nameless, faceless" IT drones who
"control everything" and "have their fingers in everything".
Scary, eh?
Having said all that, it makes good sense to tighten up file
permissions on Oracle database files so that "world" has no read,
write, execute permissions at all. Then, you can read papers about
BBED and "dd" and write nefarious "C" programs to your heart's content,
but without an account with DBA privileges, you ain't going nowhere...
Just my US$0.02...
-Tim
Mark W. Farnham wrote:
While
I agree, in some
corners this runs into the whole Sarbanes Oxley catastrophe where the
folks who
facilitated the apparently false financial reports of Enron are amongst
the
beneficiaries of the CPA consultant full employment act to make life
miserable
to the most honest and honorable rank and file group of people on the
planet
(DBA/sysadmins).
So
then the game
shifts to “how can we prevent the DBAs and sysadmins from discerning
real
data?”
I
am not claiming to
know a good universal answer. Starting by hiring Dirty Harry as your HR
director wouldn’t be a bad start though.
I’d
wink, but
the overhead to American business is so sad it nearly brings me to
tears.
mwf
Kevin makes
a fair point. I don't
know about other shops, but our production database servers are
dedicated to
being database servers. The only users who are given logins are
sysadmin
and dba. I can't think of any valid reason that anyone else would need
login access on a production database server. If you limit the
users who have access to the servers at all, then you really don't have
to
worry about the myriad of possible local attacks.
--
Mark
J. Bobak
Senior
Oracle Architect
ProQuest
Information & Learning
There is nothing
so useless as doing efficiently that which
shouldn’t be done at all.
–Peter F. Drucker, 1909-2005
From:
oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Kevin Closson
Sent: Thursday,
February 08, 2007
4:00 PM
To: freelists
Subject: RE: Using DD
to Read Data
from Oracle Datafiles
If you are
worried about a user getting to
the dd(1) command, you should probably worry about then compiling C
(libc), or
having shell access at all, no?
So,
You can make sure that
1. any normal user can't get to the raw (or cooked) datafiles.
2. They don't have access to 'dd' command
in addition to whatever else that you are doing.
--
http://www.freelists.org/webpage/oracle-l
Received on Thu Feb 08 2007 - 21:32:41 CST
