[Koha-devel] Fwd: Questionaire regarding Patron Privacy and Security

Chris Cormack chris at bigballofwax.co.nz
Mon Nov 10 20:50:40 CET 2014


Forwarded with Marshall's permission

Would you be able to help me fill this out?

Galen has already made a good start which I have pasted at
https://etherpad.mozilla.org/YiC0J8efmw

Also the Evergreen community are working on their response at
https://docs.google.com/document/d/1RgTnQOITvm3B_yzBOTfAuPZgDZig7xQ3N7Euib8rONc/edit

Thanks

Chris

---------- Forwarded message ----------
From: Marshall Breeding <marshall.breeding at librarytechnology.org>
Date: 11 November 2014 02:55
Subject: Questionaire regarding Patron Privacy and Security
To: Chris Cormack <chris at bigballofwax.co.nz>


 As you know, libraries are increasingly concerned with protecting the
privacy of their patrons and in strong security.  For an upcoming panel for
CNI I have been charged with gathering data regarding how library
management systems handle patron privacy and security.



It would be great if I could have responses by November 21, 2014.



Could you provide responses for the Koha?  You are the one that comes to
mind among those in the Koha community, but if there is someone else that
you think should respond, please let me know. I really appreciate your help.




I am interested in gathering some information regarding the current
capabilities or options that systems offer today, looking forward to
further progress in this arena toward more secure treatment of
patron-related transactions.  Given increasing concerns, I would expect
that each company is working on providing a more secure environment.



This data initially will be used for a briefing at the upcoming CNI Fall
2014 Membership Meeting, December 8-9, 2014:

http://www.cni.org/events/membership-meetings/upcoming-meeting/fall-2014/project-briefings-breakout-sessions/



I also anticipate that this information would be helpful for other
discussions, presentations, or reports.



In addition to information provided by the developers of systems, I may
also work with systems administrators of the various products for their
perspectives on these security-related capabilities and options.



I would greatly appreciate it if you could have your technical or product
managers provide responses to these specific questions.  It would also be
helpful to have any additional comments or perspective whether these seem
to be the best areas of concern regarding patron privacy, if there are
alternative strategies that you are pursuing.  I would also be interested
to hear whether this topic has been raised also by your customers or users
through enhancement requests or other product roadmap priorities.



Does your online catalog or discovery interface:

·         Enforce encryption through SSL for all transactions involving
patron activity

·         Offer the library an option to enable SSL for all transactions
involving patron activity

·         Enforce encryption for specific pages or transactions involving
patron details or login credentials

·         Offer the library an option to enable SSL for specific pages or
transactions involving patron details or login details



Does your client or interface for delivering functionality to library
personnel:

·         Enforce encryption through SSL or other encryption mechanisms for
all transactions

·         Offer the library an option to enable SSL or other encryption
mechanisms for all transactions

·         Enforce encryption for specific pages or transactions involving
patron details

·         Enforce Encryption for specific pages involving authentication of
library personnel accounts

·         Offer the library an option to enable SSL for specific pages
involving patron details

·         Offer the library an option to enable SSL or other encryption
mechanisms for specific pages involving authentication of library personnel

·         Enforce encryption for transactions involving institutional
financial data (acquisitions, patron fines, etc)

·         Offer the library an option to enable SSL or other encryption
mechanisms for financial transactions



How does your platform or system deal with the security of the storage of
specific types of data:

·         Does your system store patron passwords or PINs as unencrypted
text

·         Does your system store patron passwords or PINs as salted hash or
similar mechanisms

·         Does your system encrypt patron details as they are recorded and
stored?



Are logs or other system files that include patron search or reading
behaviors encrypted?



Describe any other security measures in place that protect patron privacy
as it is transmitted over local networks or the Internet from interception
by any third party.  One specific scenario that has been a topic of concern
involves the presentation of e-book discovery and lending transactions via
library catalogs or discovery interfaces.



Describe any integration with third party organizations that could
potential expose patron details, search, or reading patterns and measures
that you have provided to strengthen privacy and security.



Do the APIs allow or require encryption in requests or responses that
include patron-related data?

What limitations to security impact your system imposed by the APIs or
protocols managed by external or third-part products?



Would your company be interested in a standardized specification for the
treatment of patron or financial data, similar to the way that PCI provides
a compliance framework for e-commerce transactions?



I really appreciate your help with this project.  Please confirm that you
will be able to respond and let me know if you have any questions or
concerns.



-marshall





Marshall Breeding

http://www.librarytechnology.org

marshall.breeding at librarytechnology.org

http://twitter.com/mbreeding

http://www.linkedin.com/in/breeding

http://scholar.google.com/citations?user=NnvfJ5cAAAAJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20141111/1a767d08/attachment.html>


More information about the Koha-devel mailing list