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 [email protected] 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 <[email protected]>: > >> 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 >> > >
