[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: UAUDIT question (bad)
From:       Walt Farrell <wfarrell () US ! IBM ! COM>
Date:       2008-09-26 18:58:30
Message-ID: 48DD30D6.8080404 () us ! ibm ! com
[Download RAW message or body]

On 9/26/2008 12:23 PM, Trish Abbs wrote:
> I recommend putting uaudit on Systems programmers.    Then change audit
> settings (RACF) to track sensitve datasets and resources, not people.
> Have a restricted batch ID that has 'auditor' and run daily reports against
> SMF records, for just those audited profiles.   If you have Vanguard
> products, they provide a report that looks at APF, LLA and other sensitive
> libraries auto-magically.  Then they provide a place to list other datasets
> that you would like to include in your reports.
>
> Ex:   A SYSPROG has a requirement to add a new library for APF
> authorization which requires update to  SYS1.PARMLIB and the ability to
> issue dynamic activation of this new library.   Change your audit settings
> in RACF for dataset profile protecting SYS1.PARMLIB, then protect and audit
> the FACILITY class that allows dynamic activation of a new APF authorized
> library.     User must have UPDATE authority to access these.
Sorry, Trish, but I don't understand something you've said.  You started
out with "put UAUDIT on system programmers" but then switched to "then
audit resources, not people".  And your example showed auditing
SYS1.PARMLIB and the FACILITY resources that control updating the APF
list.  I certainly agree with doing that, and (in general) with "audit
resources not people".

But why, then, put UAUDIT on the system programmers?  If you've audited
the resources, why use UAUDIT for the system programmers?

--
    Walt Farrell, CISSP
    IBM STSM, z/OS Security Design
[prev in list] [next in list] [prev in thread] [next in thread]