Re: object privilege granted to public a sox problem? (and others)

It has been quite sometime since I had to deal with this type of thing. Many of these things can be accommodated. It took a lot of work and research and a massive education effort for both myself and the security inspector.

You might want to take a look at resources like http://iase.disa.mil/stigs/checklist/index.html ... Security Technical Inspection Guides (STIGs), and Security Readiness Reviews (SRRs) can help immensely. These do not address SOX requirements specifically by name, but do answer a number of the same questions that Sarbanes-Oxley poses.

R,

Gus

On Fri, Nov 14, 2008 at 6:19 PM, Bellows, Bambi (Comsys) <bbel5_at_allstate.com> wrote:
> That's pretty rich. Sorry, you have to restrict ALL_TABLES. Yeah, uh-huh.
> Also, you have to disable root. And take away the dba group. Not going to
> happen.
>
>
>
> If you're having problems with your audit, here's my suggestion: tell the
> auditors that, in Unix, an audit flag is thrown on files which are 777 or
> 4777 because anyone can change the contents of a file. This is equivalent
> to having universal write privileges on tables. However, 744 is a perfectly
> reasonable privilege level, because anyone can read the contents of a file,
> but only the owner can *change* said contents. In the same way, *some*
> underlying Oracle dictionary objects allow for universal read, but not
> universal write. Applying the same principles that allow your computer
> system to go on functioning normally, the database should pass its audit.
>
>
>
> HTH,
>
> Bambi.
>
>
>
> On Fri, Nov 14, 2008 at 3:53 PM, Douglas Cowles <dcowles_at_us.ibm.com> wrote:
>
> I appreciate everyone's responses to the extproc problem I had yesterday.
> I have a further question since many of you seem to know something about sox
> recommendations. I don't know whether the appdetective application is
> flagging just SOX recommendations or not but some of them seem quite
> daunting to implement and seem contrary to Oracle's own database philosophy.
> This isn't to say they're wrong I'm just looking for some advice.
>
> For example.. it flags "Object privilege granted to public" - This flags
> over TWO thousand violations - everything from
> Execute on OWA_COOKIE to
> select on ALL_TABLES, ALL_CONSTRAINTS.. standard vanilla stuff etc., I
> mean select on all_tables is a big security violation? I mean I guess so
> but how well are my patches and upgrades going to go if I revoke all 2000
> object grants to public? I'd post the whole list but it would just be
> annoyingly long.
>
> Is this a SOX requirement? Should this be risk accepted instead? In which
> case, does anyone have a good way to put that?
>
> Again, another one is "System privilege granted to public" 128 violations -
> this includes stuff like "CREATE PROCEDURE" granted to perfstat, or
> "EXECUTE ANY PROCEDURE" granted to OUTLN. I mean I guess I can see some
> of this but other stuff seems like I could be in a corner if I revoke it
> all.
>
> Most of this stuff is Oracle standard - maybe the idea is it's too loose.
> Any thoughts?
>
>
> Doug Cowles
>
>
> --
> Andrew W. Kerber
>
> 'If at first you dont succeed, dont take up skydiving.'

--
http://www.freelists.org/webpage/oracle-l