All valid questions.
While the information captured must be complete (showing the complete session
in question from initiation to completion), the storage of the information
should be in a 'compressed' form. The reasoning is to try to save on storage
space as well.
Your question about application testing eluded to a bigger question. How can
one 'selectively' monitor/audit transactions/MQ/APPC etc traffic. Any solution
worth its weight should allow for this. Certain terminals/regions etc. may have
different needs for auditing vs. others.
Then there is the question about test data. One must also make sure that, if
production data is being copied to a test/qa/user acceptance testing area that
the data be 'scrubbed' beforehand, or once again one can have issues of data
exposures
And least we forget the legal requirements that are all 'forced' upon us.
Whether its abiding by laws (an example is PIPEDA in Canada, or the EU
directive) or court required chain of evidence rules all must be taken into
account.
So the reason behind my previous post. While capturing logs will show that what
changes/deletion etc happened, it will not prove beyond any reasonable doubt
that a breach has occurred, or who was the culprit. Browsing the data is as
important action to monitor as changing/ deleting the data is. Because at the
end of the day, its still exposing personnel information to individuals that
may not have authority to do so..
All concerns. Let me know if you want to talk more about this
Robert Galambos CIPP/C
Compuware Senior Technical Specialist
IBM Certified Solutions Expert -
DB2 UDB for OS/390 Database Administration
Certified Information Privacy Professional/Canada
[EMAIL PROTECTED]
Tel: +1 905 886 7000
Toll Free: +1 800 263 7189
Fax: +1 905 886 7023
Quebec: +1 877-281-1888
Compuware Canada
Service is our best product
Les renseignements contenus dans le présent message électronique sont
confidentiels et concernent exclusivement le(s) destinataire(s) désigné(s). Il
est strictement interdit de distribuer ou de copier ce message. Si vous avez
reçu ce message par erreur, veuillez répondre par courriel à l'expéditeur et
effacer ou détruire toutes les copies du présent message.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of
Clark Morris
Sent: Monday, May 12, 2008 4:15 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: HIPAA auditing (was:RE: VSAM / COBOL question - redux (fwd))
On 12 May 2008 10:35:48 -0700, in bit.listserv.ibm-main you wrote:
>You are correct that this auditing must be done. This "Application Auditing"
>must include not just what a RACF log would show - that someone had access to
>a file, but to show exactly what the user saw. It is one thing to know that
>someone logged in, accessed a sensitive file and logged out later in the day,
>but the requirements are to be able to know what they were doing and which
>sensitive information they saw. You would need to be able to see they same
>screens they saw. This "Application Auditing" is possible and goes beyond
>what logs can do.
How much data needs to be stored in order to accomplish that? What
are the implications for application testing? Does this mean that test data
correction must include obfuscation of identifiable data?
Clark Morris
>
>
>
>Robert Galambos CIPP/C
>
>Compuware Senior Technical Specialist
>IBM Certified Solutions Expert -
>DB2 UDB for OS/390 Database Administration Certified Information
>Privacy Professional/Canada [EMAIL PROTECTED]
>
>
>Tel: +1 905 886 7000
>Toll Free: +1 800 263 7189
>Fax: +1 905 886 7023
>Quebec: +1 877-281-1888
>
>Compuware Canada
>
>Service is our best product
> Les renseignements contenus dans le présent message électronique sont
> confidentiels et concernent exclusivement le(s) destinataire(s) désigné(s).
> Il est strictement interdit de distribuer ou de copier ce message. Si vous
> avez reçu ce message par erreur, veuillez répondre par courriel à
> l'expéditeur et effacer ou détruire toutes les copies du présent message.
>
>
>The contents of this e-mail are intended for the named addressee only. It
>contains information that may be confidential. Unless you are the named
>addressee or an authorized designee, you may not copy or use it, or disclose
>it to anyone else. If you received it in error please notify us immediately
>and then destroy it.
>
>From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
>Behalf Of McKown, John
>Sent: Friday, May 09, 2008 8:25 AM
>To: IBM-MAIN@BAMA.UA.EDU
>Subject: HIPAA auditing (was:RE: VSAM / COBOL question - redux (fwd))
>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List
>> [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth E Tomiak
>> Sent: Thursday, May 08, 2008 7:10 PM
>> To: IBM-MAIN@BAMA.UA.EDU
>> Subject: Re: VSAM / COBOL question - redux (fwd)
>>
>> My understanding of HIPAA is access to data is not denied to
>> everyone, knowing who accessed it is the requirement. For
>> 'confidential' data, logging who accessed it even if they are
>> AUTHORIZED is done in some hospitals. Think audit trail. And of course they
>> try to limit access.
>> But if the developers have access to production does it matter what
>> file it is in, they still accessed it.
>> Proper logging would then have to log everyone that accesses the
>> copies. And th snowball starts rolling. Once you give access to
>> someone, it is hard to control what they do with it.
>>
>
>We do log all access to this data. We produced TONS of SMF data for
>this (RACF auditing). Actually, we UAUDIT every ID which has any
>possibility of accessing this data (e.g. TSO, ftp, HTTP, ...)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at
http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
