Re: Security Audit Journal receiver -- MIDRANGE-L

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