RE: Track all records read from a table

Charles,

I don't disagree however I'm a bit of a purest when it comes to things like
the audit journal. I don't think anyone should be putting anything in there
that IBM does not already do, since that's more or less a system level
journal and receiver. I would create my own security journal and log my
application security events into that one.

It keeps the auditors eyes from exploding (since 99.5% of them have no clue
what they are looking at) when it does not match the script they are
following.

--
Jim Oberholtzer
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Charles Wilt
Sent: Wednesday, March 23, 2016 2:32 PM
To: Midrange Systems Technical Discussion
Subject: Re: Track all records read from a table

The only reason to use a read trigger is for compliance purposes.

That being the case, a journal is a better choice from an auditing
standpoint.

Sure you could write to a log file that is journalled, but why not just
write to the journal.

I suspect that such entries should be sent to the system audit journal; as
the system layers on some extra security/restrictions to that object. But
IBM's docuentation say "The auditing journal QSYS/QAUDJRN is intended solely
for security auditing. Objects should not be journaled to the audit journal.
Commitment control should not use the audit journal. User entries should not
be sent to this journal using the Send Journal Entry (SNDJRNE) command or
the Send Journal Entry (QJOSJRNE) API."

However, John Earl has an example where he's logging security related stuff
to the audit journal.
http://www.securemyi.com/nl/articles/johnearl1.html

I also found a reference that discusses some code of Wayne Evans using
SNDJRNE to the audit journal.

Volume of entries might be a concern, but the volume would be the same
regardless of which journal they go to. The record keeping requirements
probably fit better with the audit journal.

Charles








On Wed, Mar 23, 2016 at 1:32 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Nathan, my thinking on using a journal for this is that would put
all

file

activity on the same place.

Okay, but wouldn't that be a disadvantage for you? Querying journals
is harder than databases.

Reads, updates and deletes.

My understanding is that only database changes are recorded when you
start journaling on database files - not reads. You'd still need a
trigger to "send" reads to journals, using a system API.

If the question that is being asked is who did anything to this file
having it all in one place makes sense.

Yes. But wouldn't it make more sense to record reads, inserts,
updates, and deletes in a database for query purposes?

Also in my specific case an end user would never be asked to query the
read

log, that would only be taken by someone with security officer

privileges.


I don't see how that might be relevant. Security officers have more
skills; more tools?

If the only question to be answered is who read a record and that
end users needed to get at the data then a database makes more
sense. I was also thinking that writing to a journal would be much
faster than writing to a database.

I haven't tested the performance. But my suspicion is that writing to
a log file would perform better than using an API to send record
images to to journal.
--
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
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.

Please contact support@xxxxxxxxxxxx for any subscription related questions.