By Galen Charlton
Crossposted from ChoosePrivacyWeek.org

One trope of data security discussions envisions a perfectly secure database as one that exists on a computer that is turned off, encased in concrete underground, and under the supervision of a very cranky cat who refuses all visitors. The flaw in this vision is clear: a database that can never be queried is of little use.

Assuming that the database should exist in the first place — and that’s an assumption that bears critical examination if the database stores information about library patrons — it can and will be queried. We’re long past the days where access to library catalogs was only through hardwired terminals and tape drives.  Nowadays it is almost more difficult to set up a server without network access than with, and most ILSs and discovery interfaces will exchange data with other systems and services. The Library Privacy Checklist for Data Exchange Between Networked Devices and Services lists actions that libraries can take to improve the security of such interactions.

At this point, I could suggest that you stop reading this post and immediately check your systems and procedures against the checklist and rectify any deficiencies. While that’s a good idea, I’d like to make a broader point first: there is no long-term protection of patron privacy without a process that includes iteration.

The long term particularly matters for data exchanges. For example, if a library contracts with an ebook provider and uses SIP2 (hopefully tunneled over SSH or TLS) to authenticate patrons to the ebook service, such a data exchange channel may last for years. With any luck, once the library gets past the initial configuration steps, the data exchange will continue to function without requiring any intervention. No muss, no fuss — and therein lies a trap.

The press of system administration work being what it is, systems and services that trigger the monitoring alerts are often the ones that get attention. A system that continues to just work can fade into the background. As time passes, ciphers that were initially strong can become weak; log files that never get consulted can accumulate more and more personally identifiable information; an attacker can guess a password and quietly gain access. If a service is cancelled, the credentials it used to gain access to patron data may continue to work.

If the library stays on top of software and configuration updates and periodically verifies that data exchanges remain securely encrypted, foundational question can still get ignored. Is the data exchange still necessary? Are there data elements about patrons that could now be excluded from the exchange? Is the data exchange partner now able to support better protocols, particularly for patron authentication?  Has the data exchange partner updated their privacy and data protection policies?

Even in the case of gimlet-eyed cat staring a block of concrete, security is a process, not a static condition. After all, somebody might show up one day carrying a bag of catnip and a jackhammer.

Security improvement processes necessarily requires iteration. Two virtues of the privacy checklists: they are short and they identify several levels of priority for actions to make. They could have been made much longer and much more detailed, but at the risk of causing paralysis. No one checklist can show the path to perfect security able to repel both script kiddies and national intelligence agencies, and even it could, the condition of perfect security would last as long as the next technological advance.

However, security can always be improved; this is a burden, as the need to work to protect patron privacy never ends, but it is also freeing, as it allows for wins along the way. Using unencrypted SIP2 over the Internet is a problem and exposes patrons to both leakage of their directory and transaction information and compromise of their login credentials — but it is also a solvable problem. After that, you can tackle turning of TLS 1.0 on the library website — then tune your ILS’s SIP2 protocol responses to stop sending the patron mailing address unnecessarily.

Look for problems, check your assumptions about what patron information needs to be shared, then fix — then repeat.

Now please stop reading this post and consult the checklists — then set a reminder to check them again next year.

Galen Charlton is Infrastructure Manager at the Equinox Open Library Initiative and a contributor to the Evergreen and Koha open source ILS projects. He can be found on Twitter as @gmcharlt.