RE: Audit Journal Novice

[Al Mac <macwheel99@xxxxxxxxxxx>]

I get lots of education from the five and take on questions other people 
ask, then I dig into our system to correlate further.  Couple questions of 
clarification for me:

(a) Entries in the Audit Journal are not neccessarily a problem, rather 
they show unusual events that we probably ought to be aware of ... e.g. 
Hacker tried to get in but failed.

(b) Tools to make it easier to evaluate the data ... we need to study the 
manuals, a lot, explore what we can get out of various commands, then after 
we get comfortable using whatever we learned, study the manuals again, a lot.

I had originally started Security Auditing on our system because of 
conflicting stories regarding alleged BPCS Security Holes.  Now, thanks to 
various new owners, managers mandates, there are more areas where we 
somewhat discomforted.  Also some weird stuff intermittent, desire more 
info in context when it happens.

Al Mac
long time Jack of many 400 areas, Guru Master of not nearly enough

Patrick wrote:
> Chad,
>
> The best way to find what auditing values are causing a particular entry is
> in the Security Reference manual in the info center.  Expend Security and
> this manual can be selected. You can download the PDF or view it on line.
> On line viewing is pretty fast.
>
> Chapter 9 has the information you want.  Just select that chapter from the
> bookmarks after you display it and scroll down.  There are several tables.
> Because GR records can be cut due to several different Action and Object
> auditing settings, there is more than one of these values that may cause an
> entry (depending on the TYPE field in the GR record).  Just look for "GR"
> in the second column of the table that starts on page 241 (the V5R4 version
> of the manual) and spans several pages.   You'll find GR several times.
>
> I don't remember what I saw on the detailed entry that was posted to the
> forum, but I suspect that the entry was cut because someone tried to add,
> remove, or change the exit point program associated with the FTP exit point
> named in the GR record.  This could be caused by at least one of the
> security related action auditing values or by turning object auditing on
> for the
> "QUSRSYS/QUSEXRGOBJ *EXITRG object "  The info in the table should give you
> an idea of what to look for.
>
> Correction-----
> Upon further review, the "aside" in my previous post has been overturned!
> After investigating more details on Chad's question, I realized that the GR
> entries are NOT the ones we created for handling the development process
> problems (blush).  Entries starting with "X" were created for this reason.
> So you were all witnesses to the second mistake I have ever made.  It looks
> like it may be snowballing on me :-)
>
> Patrick Botz
> Senior Technical Staff Member
> IBM Lab Services, Rochester
> Security Architecture & Consulting, i5/OS Security Architect
> (507) 253-0917, T/L 553-0917
> CTC Fax # 507-253-2070
> email: botz@xxxxxxxxxx
>
> For more information on CTC, visit our website at
> http://www.ibm.com/eserver/services
> http://www.ibm.com/servers/eserver/services