RE: Security Audit Journal receiver

Sanjiv,

We do this in a commercial product that replicates Security Audit
Journal receiver entries to a remote console in near real time.  We
interface to the ISS (Internet Security Systems) SiteProtector console,
which is a natural place for Auditors to review such data, and can
easily be secured from OS/400 administrator types.  

If you would like to know more, please contact me offline.

jte



--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Sanjiv
> Sent: Thursday, January 13, 2005 3:42 PM
> To: Midrange Systems Technical Discussion
> Subject: 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.
> >
> >
> --
> 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.