[OPEN-ILS-DEV] Feature proposal: SSN-censoring functionality

[Justin Hopkins]

I also believe that storing SSN's is a Very Bad Thing. This may be because I'm coming from an overwhelmingly enterprise/academic environment where FERPA is taken very seriously, but in general I treat SSN's as I would credit card numbers or personal medical information. I don't see reason for needing to use them in an ILS. Doing so immediately makes your system worthwhile for any potential attackers and puts your organization in the position to have to make a painful disclosure to your public should there be a breach.

Regards,
Justin Hopkins
IT & Web Services Coordinator
573-808-2309
justin at mobiusconsortium.org




On Aug 13, 2012, at 10:30 AM, Thomas Berezansky wrote:

> The more I look at the list of issues you present, the more I am convinced that storing SSNs as they currently are is a *bad* thing. Perhaps storing them in general is a bad thing?
> 
> Disclaimer: MVLC has local laws preventing us from even considering storing SSNs or Drivers License numbers, so we don't store that information at this time.
> 
> "Sanitizing" the data as it comes out requires flagging it as to be ignored going back in, unless non-sanitized data comes back. This will really screw with the code paths for patron editing and retrieval. Note that currently the *only* place I know of with protection for US-style SSNs is the patron sidebar view. Hitting "Edit" shows you the full thing anyway.
> 
> A better solution may be to define a new table for storing one or more pieces of data for identifying the patron. Permissions can then be used to allow enforcement of who is allowed to see the information, complete with whether or not they can see the un-sanitized data. (This could, in theory, allow Massachusetts libraries to store this data and still comply with the law.)
> 
> Each piece of information to be stored in that manner could then have one or more regular expressions for sanitizing. I would implement that as one or more search/replace sets, with capture group(s) being used in the replacement.
> 
> If these data pieces are never exposed via things like pcrud then they will be very difficult to get out of the database.
> 
> Two remaining issues I see off the top of my head are:
> 
> Reporter - It tends to bypass permissions.
> 
> Patron Editing/Registration - Do you show the full value by default, or provide a change/update interface that can load the full value (provided you have permissions to see the un-sanitized current value)?
> 
> Thomas Berezansky
> Merrimack Valley Library Consortium
> 
> 
> Quoting Kivilahti Olli-Antti <olli-antti.kivilahti at jns.fi>:
> 
>> Goood moorning Evergreeners!
>> 
>> As a fruit of our migration planning work, I present to you... the schematics to an internationalizable SSN-censorer!
>> 
>> Currently Evergreen only hides the sensitive letters from a us-standard SSN number. It seems to be that almost every nation has their own SSN-format. While we have been looking for ways to improve this handicap in Evergreen we have given great concern to make this modification as internationalizable as reasonable.
>> A challenge in designing a solution is the fact that even inside one installation, we can have SSNs from multiple SSN-formats.
>> In our case it seems to be that such cases are rare. Maybe <2% of our clientele has a SSN of other formats than Finnish (then Swedish or Russian, and fringe cases). I believe the case is same in the states as well. For this reason I am planning to have filtering done according to SSN-format relevancy.
>> We have a list of SSN-filters, and the top one is the most used one. If it won't match the given SSN, then we try the next relevant one, until a match is found or error is given to add a new filter.
>> Here are the more detailed steps to complete the task, in other words, the implementation plan.
>> http://193.65.112.189:8080/browse/EGDEV-28
>> The task is waiting for planning review and feedback from the community.
>> 
>> This functionality will be implemented by The Regional Library of Joensuu as a high priority modification during our migration period to Evergreen.
>> 
>> --
>> Olli-Antti Kivilahti
>> Open Library 2013
>> Library of Joensuu
>> 
> 
>