Re: Implementing masking either via RCAC or encryption fieldproc

Kinda misses the point of RCAC though Buck because it relies on the programmer not screwing up as opposed to being able to point the auditors (for SAX or whatever) at a system function.

I personally believe that a better approach to the CHAIN type problem mentioned earlier is to use SQL to retrieve the data - joining on that value would allow the data to be retrieved even though the program cannot actually see the full value.

This is part of the problem we alluded to in our blog posts. You can't really just use RCAC to deal with a specific issue within an existing application - some reengineering is also required.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Feb 19, 2018, at 2:43 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 19 February 2018 at 13:12, Jay Vaughn <jeffersonvaughn@xxxxxxxxx> wrote:

Consider a pgm that does the following... (for a masked user)...
1.) a loanholder ss# is retrieved via chain i/o for one reason or another
2.) it is returned, of course masked (999999234)
3.) then suppose that same pgm needs to chain to another file with the
returned masked value (say for instance a transactional file keyed by ss#
(non-encrypted))...
4.) finally the masked return value needs to be displayed on a
screen/report in its masked form

This is why FIELDPROC was not a good fit for us. We went with storing
the un-masked primary key in a hidden field and putting the masked
field on the display. Pass the real/hidden one to follow-on processes
via call/parm. Database tables always contain the un-masked value.
We are aggressively removing such numbers from the database
altogether. SSN really should not be a primary key to any table;
we've been replacing it with a surrogate key.

An alternative we discarded was to create a separate 'true' SSN field
and replace all the existing SSN fields with a randomly generated key,
so that the default that everyone got to see was the meaningless
random number. It would then take special programming (and access to
the proper VIEW) to be able to see the real SSN. That has similar
advantages to FIELDPROC in that every existing program sees the
'random/masked' value and it leaves all the primary keys in all those
daughter tables intact. Write one sub-procedure to extract the real
SSN and keep that locked down. You can even encrypt the SSN at rest
so that no one can read it without going through your subprocedure.
We thought this was too much work for the few places we display the
SSN any more.

--buck
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD