Millions trust the likes of eBay and Amazon.com with their credit cards and other personal information. Do your library's automated systems do enough to safeguard the privacy of your patrons?
Libraries are confronting new challenges in these times of heightened security awareness and privacy concern. Concerns about protecting the privacy of users and staff should drive librarians to carefully review all aspects of how they handle sensitive information across network and computer systems. The need to simultaneously preserve patron privacy, protect networks against security threats, and defend users from spam, scams, and identity theft is enough to drive any systems librarian or network administrator crazy. Let's take a look at some of the practical things that we can do to preserve our sanity and deal with these harsh realities.
First, what kinds of information should libraries be worried about? The most obvious concern would be credit card numbers or other identifiers that might lead to immediate financial loss if compromised. Fortunately, most libraries don't regularly deal with patron credit card numbers, but given the trend to incorporate e-commerce in our automation for payments of fines and fees, this area may be more of a concern in the near future. Social security numbers warrant special attention. While formerly popular as a way to identify patrons, especially among academic libraries, such use is decreasing; attitudes are changing in regard to widespread use of this number, and regulations are protecting individuals from having to reveal it. But if your library uses Social Security numbers in any way, they should be handled with the same level of care as credit card numbers. The main category of information that libraries regularly handle in their automated systems involves the names, physical and e-mail addresses, and phone numbers of our patrons as well as data about what they read. Our users should have confidence that we are taking all reasonable measures to safeguard what information we have about them.
Tune ILS to Ensure Privacy
Privacy protection, a value long held by librarians, has come to the forefront in recent times. The basic principal involves not preserving information that reveals the research and reading habits of library patrons. Library automation systems, however, are quite good at retaining this type of information, unless they are specifically configured not to. Consider a basic circulation transaction. A patron record, replete with personally identifiable data, links to an item record that describes a specific item of content. A link is made between the item and patron databases that persists as long as the item is charged out. But other things also happen. In order to ensure that all charges can be recovered in case of a database problem, the transaction is also written to ajournai or log file. So then there are two places that store the patron's reading choices. Later in the day, a tape backup is made of the databases and the log files, bringing the total instances to at least four. Cumulative weekly and monthly backups continue the proliferation of copies of this transaction. From a systems management point of view, having so many copies of a transaction is a very good thing. From a privacy perspective, it presents challenges.
While it's a given that there will be computer records that tie a patron record to an item record while the item is charged out, what happens when it is returned? The discharge operation of an automated system essentially breaks the link between them. Some systems retain the patron number of the last charge in the item record. While this feature might come in handy in case the book turns out to be damaged, the fact that the last use of an item can still be tracked to a particular patron might be troubling from the privacy-protection vantage point. Alternative configuration options that do not retain this information are usually available. Even after the item has been charged, the transaction logs still contain the transaction data for both the initial charge and its discharge. Most systems retain transaction logs for fairly lengthy periods to support system activity reports. It's often possible to configure the system so that personal information is not permanently recorded, or to run utilities that scrub this information out of the files after the fact. Also, don't forget about the backup tapes that also contain this data. While long-term retention of backup tapes seems a good practice from a systems administration perspective, a tape rotation cycle designed to ensure only short-term longevity of files with sensitive data may better suit libraries that are concerned with privacy protection.
In general, it's a good practice these days to perform a systematic analysis of your ILS to determine all the different ways it records identifiable patron data, and to then make any needed changes in the configuration of the system.
Tight Security Aids Privacy
Computer security has an enormous bearing on protecting the privacy of sensitive information. Increasingly, the specific intent of viruses and worms seems to focus on gaining access to personal information. When a computer becomes compromised through a worm or virus, an unauthorized intruder gains access to information throughout the computer system. By now we're all familiar with the tactics of the recent attacks to hijack systems to make them unwitting mail servers for the distribution of spam, and to steal e-mail addresses from address books, browser caches, and other repositories of personal information. In today's environment of ever-more-aggressive malware, little or no margin of error exists for insecure systems or unsafe computing practices, such as opening unsolicited mail attachments. Space doesn't permit me to go into detail on strengthening your library's basic security practices, but you might refer back to my May 2003 column for pointers.
Encrypt Sensitive Data Passed Through Networks
Sensitive personal information should never be transmitted across networks "in the clear." One of the technical characteristics of the Ethernet protocol used on almost all networks is the ease with which someone can eavesdrop to gain access to any information that is transmitted without first being encrypted. Ethernet encapsulates information into little data envelopes, known as "data-grams" or "packets," complete with return and destination network addresses. All the packets are then broadcast onto the local network segment with the intent that only the intended recipient receive and view its contents. While it's not polite to read someone's data packets, it is technically possible to do so. In normal operation, a node on the network opens only the packets with its own address indicated in the packet header as the recipient. It's not hard, however, for a device on the network to operate in "promiscuous mode," whereby it can open and view the contents of the packets transmitted on a network segment.
Given this ease of eavesdropping when data is sent across a network without first being encrypted ("sent in the clear"), one can assume that it can be intercepted and read by those other than the intended recipients. Concerns are heightened with wireless networks where physical access to the network isn't necessarily required for eavesdropping. Fortunately, there are lots of ways to protect network traffic from such eavesdropping-most of which involve using encryption.
Virtual Private Networks (VPNs), for example, set up an end-to-end encrypted channel that is immune from eavesdropping. With strong encryption, even if the data packets are intercepted, they cannot be viewed without the right security credentials. VPNs typically consist of software installed on an individual's laptop or home computer that communicates with a security module installed on a server or firewall in the organization's internal network to first authenticate the user and to then encrypt the session as it passes through the Internet. VPNs are popular in the corporate world as a way to allow mobile employees to securely work with sensitive information when connecting to their corporate networks via the public Internet. In a library setting, you might consider VPNs when computers performing circulation or administrative functions that are likely to expose sensitive data connect to the central server of the ILS via the public Internet. In practice, most libraries haven't adopted this level of security for access to their automation systems, but as security concerns heighten, it increasingly merits consideration.
Securing Your Web OPAC
How safe are our Web-based catalogs? Do they follow standard practices for securing private data? Unfortunately, most don't. The ever-growing trend toward personalized Web OPACs, which offer personalized services based on previous selections made by each user, raises concerns for the security of that information. Web sites can be configured to use secure Sockets Layer (SSL) to authenticate identity and to encrypt data transmitted over the Internet. We're all familiar with the padlock that appears on the status line of our Web browsers when interacting with a server operating with SSL. Since encryption and decryption consumes lots of computing cycles, they are often used sparingly. When ordering merchandise from your favorite online Web site, for example, it operates in the clear while logging your shopping selections, switching on the padlock as it enters SSL only for the part of the transaction in which it processes your credit card.
Most Web-based library catalogs do not operate using SSL to encrypt sessions between the library patron and the library's server. The part of a library user's session that involves browsing through bibliographic records probably doesn't warrant encryption. But once the patron begins to use the personalized features offered by most library OPACs, security concerns arise. The library should especially consider enabling SSL for parts of the session that involve the actual sign-on with the library card number and a password or PIN, and any screens that involve the display of the patron's personal record.
Automation systems vary in their ability to make use of SSL in their Web OPAC modules. Depending on your vendor, it may or may not be available and it may involve additional cost. In the evolution of Web OPACs from simple search-and-retrieval systems to personalized information delivery services, they should also adopt a more sophisticated approach to security and privacy.
Security and privacy just can't be taken for granted in today's environment. It takes a proactive effort to ensure that the technical operation of the various systems within the library's environment is consistent with the library's policies and expectations regarding patron privacy.
