Re: Security Audit Journal receiver

What the should "not have access" means is that Audit team wants that
the Systems Admins should not have capbilities to delete the System
security receivers. They should be able to read it

What they want is that if some Sys Admin has a bad intention of doing
something on the systems that should be recorded in the Journal
receiver . It should not happen that System Admin Changes Journal
receiver , does something bad to system , changes system journal
receiver and deletes the old one ....Hence in that case only the new
receiver will have the first entry of delete or change. But who has
done what on the system nobody knows as those receivers would have
been deleted

What Audit team are looking is to prevent the System admin which have
all the God rights on system from ding anything bad. If System
security receivers are somehow replicated online to some other system
like Unix then one can know as what had happened

Thks 


On Thu, 13 Jan 2005 09:55:40 -0600, Patrick Botz <botz@xxxxxxxxxx> wrote:
> I'm curious as to what "should not have access" means?  I see over and over
> again that internal auditors make many assumptions about computer systems
> and OS400 in general.  The most common one is that an administrator on
> OS400 has the same capabilities as an administrator on uni*, linux,
> windows, etc.
> 
> My experience has been that auditors do not want administrators to be able
> to change the system audit journal; reading the contents is not an issue.
> Assuming this is true in your case, you can read on.
> 
> Assuming
> a) your internal auditors are concerned about only the system audit journal
> -- as opposed to applications that use journals for application audit
> information;
> b) the system administrator does not have a Service Tools user profile and
> password which has display/alter/dump privileges
> then the following is true:
> The only thing a system administrator can do with the system audit journal
> receiver is to read it and delete it.  If they delete the receiver, when
> auditing is turned back on, the first entry in the new receiver will
> indicate that the previous journal receiver was deleted.
> 
> Here is an example audit record you would see if the adminsitrator deleted
> a journal receiver and created a new one:
> Display Journal Entry
> 
> Object . . . . . . . :                   Library . . . . . . :
> Member . . . . . . . :
> Incomplete data . . :   No              Minimized entry data :   No
> Sequence . . . . . . :   134572
> Code . . . . . . . . :   J - Journal or receiver operation
> Type . . . . . . . . :   PR - Previous journal receivers
> 
>              Entry specific data
> Column      *...+....1....+....2....+....3....+....4....+....5
> 00001      'QC2RCV0513QSYS      '
> 
> Another thing I have seen some auditors concerned with is the administrator
> turning auditing off, doing bad stuff, and then turning it back on.
> However, the system also adds an entry to the journal indicating that the
> administrator turned it off. If the security policy is that the
> administrator is not allowed to turn auditing off (or, perhaps, without
> prior approval or additional safeguards), then this can be an effective
> deterent.
> 
> Another little known fact is that since V5R2, an organization can prevent
> even a system administrator from being able to change security related
> system values.  To do so, you need to make sure that the administrator does
> not have a service tools useriD/password with anything other than basic
> privileges. Then you need to change a security setting in SST that controls
> whether a service tools user with a default and expired password is allowed
> to change their own password. This last step prevents QSECOFR (OS400)  from
> being able to reset the QSEOFR service tools QSECOFR userID (which sets the
> service tools userID to the default password and expires it) and then
> starting SST which will allow him/her to provide the default password and
> change it to a new one.
> 
> Given my assumptions about what your internal auditors are concerned about,
> I would not be surprised if your internal audit team would be satisfied
> once they understood these capabilities.
> 
> Patrick Botz
> Senior Technical Staff Member
> eServer Security Architect
> (507) 253-0917, T/L 553-0917
> email: botz@xxxxxxxxxx
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>