Re: Journal Receiver Retention for SOX...

Considerations:

1. I'd ask if you could eliminate open & close journal entries:
http://www.redbooks.ibm.com/abstracts/tips0607.html.  If so, it would
likely put your receivers on a pretty good diet. 

2. When saving to save files, use DTACPR(*YES) or *MEDIUM to reduce the
disk space consumed by the save files.  

3. Consider instead of dumping the receiver to a file, scanning the
receiver for entries you're interested in.  The resulting data file
should be tiny.  If it isn't, you're interested in too much or you've
got problems.

4. If the receivers are still too large, cut to new receivers more
often.  It doesn't reduce the size of what needs processing but it does
reduce your 'batch' size.


As to your retention routine, it's fine.  You may want to consider a
monthly or quarterly DUPTAP of your archive tape.  Then rotate the DUPed
tape offsite.

Seven years is way too long of a retention policy.  According to SOX,
for instance, each company can determine it's own retention guidelines
as long as they don't violate the law.  SOX as law* doesn't really
address log retention; retention is inferred as necessary to demonstrate
that the validity & security of the data has been maintained. 

*IANALNDIPOOTV (I Am Not A Lawyer Nor Do I Play One On TV)

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: security400-bounces@xxxxxxxxxxxx
[mailto:security400-bounces@xxxxxxxxxxxx] On Behalf Of Turnidge, Dave
Sent: Tuesday, August 22, 2006 2:32 PM
To: security400@xxxxxxxxxxxx
Subject: [Security400] Journal Receiver Retention for SOX...

Per the current understanding of requirements put forward by auditors,
we need to analyze changes and actions that are made/taken by users
outside of the actual production applications. That is, changes made by
command from the command line, etc. We then need to retain this data
(journal receivers) for SEVEN years.
 
There are a couple of issues that I would like to have your thoughts on:
 
1) I got bit last week after having set up an "automatic" analysis,
because one of the Journal files became MASSIVE. One of the steps in my
"automatic" methodology is to dump journal receivers to a data file so I
can run those records against an SQL statement to report on those items
that are out of the range that has been set up. What happened was that
disk filled up. 
 
Is there a way to determine that you are about to do something stupid -
like run out of disk - so you can stop it?
 
2) As a part of my retention routine, I have a tape that just sits in
our development system, and I continue adding save files containing
receivers from all our systems. This is not exactly ... safe ... because
if something happened that destroyed that tape, we wouldn't have backup.
I suppose we could back up just a weeks worth of information, but by the
time we got to SEVEN years, we would probably own the storage company...
 
So, how can I backup what will be massive amounts of data, over a LONG
period of time, and still have the data safe?
 
TIA for any input,

Dave
612-371-1163 

 
_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400)
mailing list To post a message email: Security400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/security400.
 
 

This email is for the use of the intended recipient(s) only.  If you have 
received this email in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this email without the author's prior permission.  
We have taken precautions to minimize the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any attachment 
to this message.  We cannot accept liability for any loss or damage caused by 
software viruses.  The information contained in this communication may be 
confidential and may be subject to the attorney-client privilege. If you are 
the intended recipient and you do not wish to receive similar electronic 
messages from us in future then please respond to the sender to this effect.