Tip of The Hat

Posted on

Silent Librarian and Tracking Report Cards

Welcome to this week’s Tip of the Hat! We at LDH survived the full moon on the Friday the 13th, though our Executive Assistant failed to bring donuts into the office to ward off bad luck. Unfortunately, several universities need more than luck against a widespread cyberattack that has a connection to libraries.

This attack, called Cobalt Dickens or Silent Librarian, relies on phishing to gain access to university systems. The potential victims receive a spoofed email from the library stating that their library account is expired, followed by instructions to click on a link to reactivate the account by entering their account information on a spoofed library website. With this attack happening at the beginning of many universities’ semesters, incoming students and faculty might click through without giving a second thought to the email.

We are used to having banking and other commercial sites be the subject of spoofing by attackers to obtain user credentials. Nonetheless, Silent Librarian reminds us that libraries are not exempt from being spoofed. Silent Librarian is also a good prompt to review incident response policies and procedures surrounding patron data leaks or breaches with your staff. Periodic reviews will help ensure that policies and procedures reflect the changing threats and risks with the changing technology environment. Reviews can also be a good time to review incident response materials and training for library staff, as well as reviewing cybersecurity basics. If a patron calls into the library about an email regarding their expired account, a trained staff member has a better chance in preventing that patron falling for the phishing email which then better protects library systems from being accessed by attackers.

We move from phishing to tracking with the release of a new public tool to assess privacy on library websites. The library directory on Marshall Breeding’s Library Technology Guides site is a valuable resource, listing thousands of libraries in the world. Each listing has basic library information, including information about the types of systems used by the library, including specific products such as the integrated library system, digital repository, and discovery layer. Each listing now includes a Privacy and Security Report Card that grades the main library website on the following factors:

  • HTTPS use
  • Redirection to an encrypted version of the web page
  • Use of Google Analytics, including if the site is instructing GA to anonymize data from the site
  • Use of Google Tag Manager, DoubleClick, and other trackers from Google
  • Use of Facebook trackers
  • Use of other third-party services and trackers, such as Crazy Egg and NewRelic

You can check what your library’s card looks like by clicking on the Privacy and Security Report button on the individual library page listing. In addition to individual statistics, you can view the aggregated statistics at https://bit.ly/ltg-https-report. The majority of public library websites are HTTPS, which is good news! The number of public libraries using Google Analytics to collect non-anonymized data, however, is not so good news. If you are one of those libraries, here are a couple of resources to help you get started in addressing this potential privacy risk for your patrons:

Posted on

What’s The Name of Your Pet?

Welcome to this week’s Tip of the Hat!

Our Executive Assistant argues that we at LDH shouldn’t use her name to answer the question in today’s newsletter title. She is, after all, our Executive Assistant, and not a pet. However, the EA’s objection also has merit for information security reasons. Today we visit our information security neighbors to explore one risk to library staff and patron account privacy – the dreaded security question.

Where did you meet your best friend?
This topic was inspired by a recent popular tweet:

normal people: it’s my birthday

infosec experts: THAT WAS HIGHLY SENSITIVE INFORMATION. DO YOU HAVE ANY IDEA HOW EXPOSED YOU ARE

normal people: my dogs name is Jack

infosec experts: YOU’RE GONE. DONE FOR. IT’S OVER
— Katerina Borodina (@kathyra_) September 3, 2019

Common security questions can be easily cracked by a quick search of your online activity. Social media is a gold mine of this type of information, including information about pets, childhood, school, family, or even your favorite color and sports team. Some companies provide less common security questions that would prove harder to crack, though most companies do not stray from the common security questions.

Library staff are in a particular bind in a couple of situations involving security questions. Some vendor products require security questions for account creation, and some libraries are only allowed one institutional “admin” account to share among staff. We bet you a nice cup of quality tea that at least one of the security question answers for that account is a variation of the following words:

  • Checkout or check-in
  • Dewey
  • Books, including bookworm
  • Cat
  • Reading
  • Library
  • Your library’s, organization’s, or department’s name, physical location, mascot, school colors, etc.

Perhaps the person who created the account decided to use their own personal information to answer the questions, which doesn’t get changed when that staff person leaves the library. Resetting the account now becomes trickier, particularly if this staff personal information wasn’t documented. However, if that person posted some of the information on a public site, that staff account is now at a higher risk of being compromised by a threat actor, looking for a way to get into the system.

In either case, library staff accounts that require security questions provide unique security challenges that also carry some privacy risks for both staff and patrons.

What is your favorite color?

By now you’ve heard the advice to not post private information publicly from InfoSec. That doesn’t help much when you have a shared account for library staff. Ideally, you shouldn’t have shared accounts – application permissions and privileges should be granted to individual user accounts. These user-level permissions and privileges should change anytime there is a change in staff or staff responsibilities. Some vendors allow for such user permission granularity, and if your vendor doesn’t support that level of permission control, start asking them to do so!

There is also the fact that security questions themselves are inherently insecure as a way to keep user accounts secure; however, many companies still rely on these questions to authenticate users or for password resets. If you are creating a library staff account for a vendor product or service, and the vendor is requiring you to answer common security questions as part of the account creation process, a good place to start is to randomize your answers.

When we say “randomize” we do not mean swapping out your personal information for information about your workplace but provide an answer that would make no sense in answering the question. For example, “What was your first car?” could have the following answers:

  • A: Treehouse
    • A single word or a simple phrase that is not apparently related to you, the organization, or the question itself
  • A: ur0wIBHRGp9IBi
    • A random string of characters generated from a password generator
  • A: decimallemonBritish
    • A random passphrase generated from a passphrase generator

The more random you get with your answer, the better. To ensure that you are getting closer to a random answer, use a password or passphrase generator. Most password managers have random generators, and some even have the option to create passphrases. If you have multiple accounts that require security question answers, do not use the same answer twice; instead, generate new answers for each account, even if the account shares the same questions with other accounts.

Lastly, document the answers in a secure place. Many password managers have a secure notes function in which you can document your security answers for each account. Make sure that the place you store your answers is encrypted and accessible to only those who need access to those answers in the case that they need to reset the password or access the account. In most cases, that would mean only you, but if your department uses a password manager to manage department accounts, this would be the place to store them as well.

As long as companies require you to answer security questions, you need to mitigate the many risks that come with such questions. Randomizing answers is the first place to start, and not using personal information attached to any staff members or the workplace is another critical step. If all else fails, you can always change your pet’s name to 9AtTsCbWqRww7C…

Posted on

Leaving Platforms and Patrons Behind

Welcome to this week’s Tip of the Hat!

Remember when the online library catalog was just a telnet client? For some of you, you might even remember the process of moving from the card catalog to an online catalog. The library catalog has seen many different forms in recent decades.

The most recent wave of transitions is the migration from an old web catalog – in most cases an OPAC that came standard with an ILS – to a newer discovery layer. This discovery layer is typically hosted by the vendor and offers the ability to search for a wider array of collections and materials. Another main draw of the discovery layers in the market is the enhanced user experience. Many discovery layers allow users to add content to the site, including ratings, comments, and sharing their reading lists to others on the site.

While being able to provide newer services to patrons is important, this also brings up a dilemma for libraries. Many discovery layers are hosted by vendors, and many have separate Terms of Service and Privacy Policies attached to their products outside of the library’s policies. The majority of library catalogs that the discovery layers are meant to replace are locally hosted by the library, and fall under the library’s privacy policies. Libraries who made the transition to the discovery layer more often than not left their older catalog up and running, marketed as the “classic” catalog. However, the work necessary to keep up two catalogs can be substantial, and some libraries have retired their classic catalogs, leaving only the discovery layer for patrons to use.

The dilemma – How will the library provide a core library service to patrons objecting to the vendor’s TOS or privacy policy when the library only offers one way to access that core service?

We can use the Library Bill of Rights [LBR] interpretations from ALA to help guide us through this dilemma. The digital access interpretations of the LBR provides some guidance:

Users have the right to be free of unreasonable limitations or conditions set by libraries, librarians, system administrators, vendors, network service providers, or others. Contracts, agreements, and licenses entered into by libraries on behalf of their users should not violate this right… As libraries increasingly provide access to digital resources through third-party vendors, libraries have a responsibility to hold vendors accountable for protecting patrons’ privacy. [Access to Digital Resources and Services: An Interpretation of the Library Bill of Rights]

Moving core services to third-party vendors can create a barrier between patrons and the library, particularly when that barrier is the vendor’s TOS or privacy policy. The library then needs to decide what next steps to take. One step is to negotiate with the vendor regarding changes to the TOS and privacy policy-based to address patron concerns. Another step is a step that several libraries have opted for – keeping the classic catalog available to patrons alongside the discovery layer. Each step has its advantages and disadvantages in terms of resources and cost.

The classic catalog/discovery layer dilemma is a good example of how offering newer third-party platforms to provide core library services can create privacy dilemmas for your patrons and potentially lock them out from using core services. If your library finds itself making such a transition – be it the library catalog or another core service platform – the ALA Privacy Checklists and the interpretations of the LBR can help guide libraries through the planning process. Regardless of the actions taken by the library, ensuring that all patrons have access to core library services should be a priority, and that includes taking privacy concerns to account when replacing core service platforms.

Posted on

Threat, Vulnerability, or Risk?

Welcome to this week’s Tip of the Hat!

“Animal, plant, or mineral?” Most folks can, with a healthy amount of confidence, say that something is one of those three, as well as explain the differences between the three categories. It’s also a fun game to keep younger kids occupied for your next long trip.

Today we are going to introduce a variation of the game for us adults – “Threat, vulnerability, or risk?” Information privacy and security use these three terms with assessing the protection of data and other organizational assets, as well as potential harms to those assets and the organization. Many people use these terms interchangeably in daily conversations surrounding Infosec and privacy. There are differences between the three, though! To understand what it means when someone says “threat” instead of “vulnerability”, we will go over some definitions to help you differentiate between the three terms:

A Threat is a potential scenario that can cause damage or loss to an organizational asset. You might have heard the term threat actor, which refers to a specific someone or something that could be responsible for creating said harm to the organization. Note well that you do not have to demonstrate malicious intent to be a threat actor. Sometimes threat actors do not act out of malicious intent but are still a threat due to them exploiting a vulnerability in the organization.

Vulnerability refers to the weakness in any system or structure that a threat can use to cause harm to the organization. People focus on technical vulnerabilities; however, the non-technical vulnerabilities, aka your fellow humans and organizational structures, are as important to identify as your technical vulnerabilities.

Risk is the potential of damage or loss resulting from a threat taking advantage of a vulnerability. Many use an equation to calculate the amount of risk of a particular scenario: Risk = Threat x Vulnerability x Cost, with Cost being the potential impact on the target by a threat.

Let’s explore these terms further with our library hat on:

What can be considered a threat?

  • Untrained/undertrained staff not following law enforcement request procedures
  • A staff member gains unauthorized access to sensitive systems or data, and modifies, exports, or deletes data to inflict harm or for their gain
  • A data breach of a vendor-hosted database

What can be considered a vulnerability?

  • Lack of access to regular privacy training and resources for staff
  • Lax or lack of system user access policies and procedures
  • Lack of or insufficient vendor privacy and security practices
    Improper collection and storage of sensitive data by systems

What are the possible types of risk in any given scenario?

  • Legal – possible legal action due to noncompliance with applicable local, state, federal, or international regulations surrounding particular types of data
  • Reputational – “The Court of Public Opinion”; loss of patron trust; loss of trust in the vendor
  • Operational – the inability to perform critical tasks and duties to ensure uninterrupted access to core services and resources

By knowing the differences between threat, vulnerability, and risk, you can better assess the scenarios that can put your organization at higher risk of legal, reputational, or operational harm. You can also proactively mitigate these risks by addressing the vulnerabilities that can be exploited by the threats you can identify. Take some time this week to walk through the “Threat, vulnerability, or risk?” game with your colleagues, and you might be surprised by what you will find about your organization.

Posted on

Ransomware, CS and Privacy, and #FollowMonday

Welcome to this week’s Tip of the Hat! Summer is in full swing this August, and the Executive Assistant is contemplating where would be the coolest place in the office to park herself to work. While she roams the office and while I make sure she doesn’t make a small blanket fort connected to the office refrigerator, here are a couple of quick links and updates in the privacy and library worlds to start your week.

A refrigerator with its door open, and a green tent set up in front of the open door.
Ransomware strikes another library system

Last month, the Butler County Federated Library System in Pennsylvania became the latest library system to succumb to ransomware. As a result, the system has gone back to using paper to track circulation information. Like other ransomware attacks, the system might have to rebuild their online infrastructure if they are unable to retrieve the ransomed data.

If your library hasn’t been hit with ransomware yet, the best defense against ransomware is to prevent it from taking over your system. Awareness programs and information security training can help with educating staff about the ways that ransomware and other viruses and malware can infiltrate the library system, and regular reminders and updates can also help keep staff current on trends and new infosec practices.

Training can only go so far, though, and having a plan in place will not only help mitigate panic when ransomware takes over a system, but also mitigate any overlooked vulnerabilities concerning patron data privacy. For example, while libraries have used paper for decades to track circulation information, automation in the last few decades has taken over this process. Making sure that staff are trained and have current procedures in handling sensitive patron data in paper format – including storage and disposal – can help protect against inadvertent privacy breaches.

H/T to Jessamyn West for the link!

Is it time for Computer Science curriculums to prioritize privacy?

In an op-ed in Forbes, Kalev Leetaru argues that CS curriculum should follow the way of library and information science and emphasize privacy in their programs. Near the end of the article, Leetaru illustrates the struggle between privacy and analytics:

Privacy naturally conflicts with capability when it comes to data analytics. The more data and the higher resolution it is, the more insight algorithms can yield. Thus, the more companies prioritize privacy and actively delete everything they can and minimize the resolution on what they do have to collect, the less capability their analytics have to offer.

This represents a philosophical tradeoff. On the one hand, computer science students are taught to collect every datapoint they can at the highest resolution they can and to hoard it indefinitely. This extends all the way to things like diagnostic logging that often becomes an everything-or-nothing concept that has led even major companies to have serious security breaches. On the other hand, disciplines like library and information science emphasize privacy over capability, getting rid of data the moment it is safe to do so.

What do you think? Would emphasizing privacy in CS programs change current data privacy practices (or lack thereof) in technology companies?

#FollowMonday – @privacyala

Keeping up with all the latest developments in the privacy field is a challenge. There is so much happening that it can be a full-time job to keep up with all the developments. ALA’s Choose Privacy Every Day Twitter account can help you sift through all the content in a nicely packaged weekly post of the major developments and updates in the privacy world, be it in libraries or out there in the world. You can find out about new legislation, tools to help protect your patrons’ privacy, and yes, there is a section to keep up with the latest data breaches.

Posted on

Privacy in the News: LinkedIn and the “Like” Button

Welcome to this week’s Tip of the Hat! We have various updates from around libraryland and beyond, so let’s start the week by catching you up on important news and developments.

LinkedIn Learning Stalemate

Last week we learned that negotiations between ALA representatives and LinkedIn Learning stalled over the proposed changes the company plans to implement later this year that would require users to create a LinkedIn profile to access LinkedIn Learning resources. ALA released a public statement to LinkedIn Learning to reconsider their changes, while a petition on EveryLibrary is collecting signatures of libraries and library staff who will not renew (or will consider not renewing) their contracts with LinkedIn Learning in light of this upcoming change. The list of libraries committed to not renewing the service grows, with state libraries getting into the fray.

The story has also found its way to various news outlets:

LinkedIn Learning has directed those seeking comment for the recent statements from ALA and libraries to a blog post from June 2019, which doesn’t give much in the way of addressing the concerns raised in the recent weeks.

Time to rethink the embedded “Like” button?

Today, the Court of Justice for the European Union delivered a ruling that could have ripple effects in the US. The Court ruled that websites that embed the Facebook “Like” button are responsible for the privacy of the users on the website. According to the Court, a website that has the “Like” button must follow the same consent and data processing regulations laid out in European law, even though that data is being transferred to Facebook. This is not the first time that the embedded “Like” button has gotten into trouble in the EU – a recent example comes from 2016, where a German court ruled that a site with the embedded button violated user privacy.

Many libraries and vendor products include the “Like” button on websites, catalogs, and other patron-facing applications and services. Embedding social media buttons such as the “Like” button already presents several privacy issues. For example, this 2013 article from Mother Jones explains how companies can track users through websites that have the “Tweet” button embedded into their pages. These buttons and widgets collect patron information and this information can be sent back those social media sites even if the patron doesn’t use the buttons on the page.

With US states looking toward the EU and GDPR as a foundation to build their own state data privacy laws, this ruling may influence how US law interprets the responsibility for user privacy when a website embeds social media buttons that have been known to track users. Even if no laws come to pass, it would still be worthwhile to revisit your organization’s use of these types of social media buttons on your websites and if that use aligns with your privacy policy and patron privacy expectations.

Posted on

Caring Who Is Sharing Your Patron Data

Welcome to this week’s Tip of the Hat! Last week Tom Boone stated his intent to boycott two vendors – Thomson Reuters and RLEX Group – at the American Association of Law Librarians annual conference based on the current business relationships that both companies have with U.S. Immigration and Customs Enforcement [ICE]. While the objections are based on the relationships themselves, the boycott posts brings us back to a question posed by Jason Griffey about LexisNexis’s interest in assisting ICE in building an “extreme vetting” system for immigrants to the US – what role would data collected from libraries that subscribe to those vendors’ products play in building such a system? For this week’s letter, we’ll broaden the – what do vendors do with library patron data and what say do libraries have in the matter?

Patron data is as valuable to vendors as it is to libraries. To vendors, patron data can be used to refine existing services while building newer services based off of patron needs and behaviors. The various recommendation systems in several library products are powered partially by patron borrowing activity, for example. Nonetheless, while vendors use patron data for their products and services, many vendors share patron data with other service providers and third-party businesses for a variety of reasons. For example, some vendors run their applications on commercial cloud servers, which could mean storing or transferring patron data to and from these servers. Depending on the agreement between the vendor and the commercial cloud service, the service might also have access to the data for performance tracking and analysis purposes.

How do you find out what vendors are doing with your patron data? One of the first places to look is their privacy policy. Like libraries, vendors too should inform patrons how they are handling patron data. The library should have a separate privacy policy that indicates how library data is shared with vendors, but vendors also need a privacy policy that clearly communicates to patrons using the vendor service on how the data is handled by the vendor, including any sharing of data with service providers or other third parties. LexisNexis’ privacy policy provides some of this information in their How We Use Your Information and Sharing of Your Information sections (which, BTW, you should read if you do use LexisNexis!).

If you can’t find the information you need in the privacy policy, the vendor contract might have some information regarding the collection, use, and sharing of patron data by the vendor. The vendor contract can also serve another purpose, particularly when you are at the contract negotiation or contract renewal stages. The contract can be a good place to lay out expectations to the vendor as to what level of data collection and sharing is permissible. Some data sharing is unavoidable or necessary, such as using aggregated patron data for analyzing infrastructure performance, so if you come to the negotiation table with a hardline “no reuse or sharing with third parties” position, you will most likely be making some compromises. This is also a good place to bring up the question about “selling” vs “sharing” data with service providers – while some vendors state in their privacy policy that they do not sell patron data, they might not mention anything about sharing it with others. Setting expectations and requirements at the point of negotiations or renewal can mitigate any surprises surrounding data use and sharing down the road for all parties involved.

Having the discussion about patron data use and sharing by the vendor will not only allow you to find out what exactly happens to your patrons’ data when they use vendor products, but it also opens up the opportunity for your library to introduce language in the contract that will protect your patrons’ data. You can do this through line edits, or through a contract addendum that has been vetted by your local legal team. Before going to the negotiation table with your proposed changes and requests, you will need to determine what points will you be willing to compromise on, and which points are dealbreakers. Ideally negotiations provide a workable outcome for all, but in reality, sometimes the best outcome for your patrons and staff is to leave the negotiations. Not giving a vendor your library’s business is a valid option – an option that could signal to the vendor that some of their practices need to change if enough libraries choose to follow suit.

Posted on

CRMS 101

Welcome to this week’s Tip of the Hat! Today we have a brief overview of an acronym that is becoming a popular tool in libraries – the customer relationship management system [CRMS] – and how this new player in the library field affects patron privacy. While some folks know about CRMS, there might be others that are not exactly sure what they are, and what they have to do with libraries. Below is a “101”- type guide to help folks get up to speed on the ongoing conversation.

What is a CRMS?

A customer relationship management system [CRMS] manages an organization’s interactions with customers with the goal to grow and maintain customer relationships with the organization. CRMS products have been used in other fields outside of librarianship for decades, mostly in commercial businesses, but the increased importance in data analysis and improving customer experiences has led for wider adoption of CRMS products in other fields, including libraries.

What is a CRMS used for?

Many organizations use CRMS products to track various communications with customers (email, social media, phone, etc.) as well as data about a customer’s interests, demographics, and other data that can be used for data analysis. This analysis is then used to improve and customize the user experience (targeted marketing, personal recommendations, and invitations, etc.) as well as making business decisions surrounding products, services, and organization-customer relations. This analysis can also be used to create user profiles or for market segmentation research.

What are some examples of CRMS?

There are many proprietary and open source options, though Salesforce is one of the most recognized CRM companies in the overall field. In the library world, several library vendors sell standalone CRMS products, such as OrangeBoy’s Savannah. Other library vendors have started offering products that integrate the CRMS into the Integrated Library System [ILS]. OCLC’s WISE is one such example of this integration, while other library vendors plan to release their versions in the near future.

What data is collected in a CRMS?

A CRMS is capable of collecting a large quantity of very detailed data about a customer. Types of patron data that can be collected with a library CRMS includes (but not limited to):

  • Demographic information
  • Circulation information like total checkouts, types of materials checked out, and physical location of checkouts
  • Public computer reservation information
  • Electronic resource usage
  • Program attendance

In addition to library supplied data, other data sets from external sources can be imported into the CRMS ranging from US Census data to open data sets from cities and other organizations that could include other demographic information by geographical area (such as zip code) or by other indicators.

How is patron privacy impacted by CRMS?

The amount of information that can be collected by a CRMS is akin to the type of information collected by commercial companies who sell services and products. By creating a user profile, the company can use that information to personalize that customer’s experience and interactions with the company, with the ultimate goal of creating and maintaining return customers. Traditionally libraries do collect and store some of the same information that CRMS products collect; however, it is usually not stored in one central database. Creating a profile of a patron’s use of the library leaves both the library and the patron at high risk for harm on both a personal and organizational level. This user profile is subject to unauthorized access by library staff, data breaches and leaks, or intentional misuse by staff or by the vendor that is hosting the system. This user profile can also be subject to a judicial subpoena, which puts patrons who are part of vulnerable populations at higher risk for personal harm if the information is collected and stored in the CRMS.

Further reading on the conflict between the CRMS, data collection, and library privacy:

What can we do to mitigate privacy risks if we use a CRMS?

If your library chooses to use a CRMS:

  • Limit the type and amount of patron data collected by the system. For data that is collected and stored in the CRMS, consider de-identification methods, such as aggregation, obfuscation, and truncation
  • Perform risk assessments to gauge the level of potential harm connected by collecting and storing certain types of patron information as well as matching up patron information with imported data sets from external sources
  • Negotiate at the contract signing or renewal stage with the vendor regarding privacy and security policies and standards around the collection, storage, access, and deletion/retention of patron data, as well as who is responsible for what in case there is a data breach
  • Perform regular privacy and security audits for both the library and the vendor

We hope that you find this guide useful! Please feel free to forward or pass along the guide in your organizations if you are having conversations about CRMS adoption or implementation. LDH can also help you through the decision, negotiation, or implementation processes – contact us to learn more!

Posted on

Gone Phishin’

Welcome to this week’s Tip of the Hat!

Our Executive Assistant has been waiting for the opportunity to spend some of her summer days fishing at one of Seattle’s many fishing spots. LDH, unfortunately, cannot claim that fishing is a work-related activity; however, dealing with the different types of “phishing” activities do fall under the realm of keeping data private and safe.

Phishing, like fishing, is a complex process, most of which is done behind the scenes. The general goal of email phishing is to gain a piece of sensitive information or system access from the target. To achieve that goal, the phishing email needs to pull off certain steps, the first being to appear official. This doesn’t work very well if you have encountered a phishing email for a company that you don’t do business with, but an email that is designed to look exactly like an official email from a company that you do business with (or even work for) can lead to a false sense of security.

Phishing relies heavily on exploiting human traits and biases. Having an email look authentic is one way. Even if the email doesn’t look authentic, if it tells you that your account has been compromised, or if you have won an award, you might not think twice before acting on the email. For example, if someone claiming to be from your IT department asks for your password because they need to access your computer to perform critical security updates, your initial reaction is to be helpful and to provide the information. If a bank email told you that your account has been suspended, you might not be thinking about if the email was legitimate – you might be thinking about bills that are set up to auto-pay with the account, and that you need to make sure all those payments go through. You click on the link and become another fish caught by the phisher.

Avoiding phishing attempts involves several tactics. The best way of dealing with phishing emails is to never have them pop into your inbox in the first place. Junk and spam filters can do most of the work, along with specialized applications and software. When you do get an email from a company that you do business with, the best first step to take is to stop and think before acting on the email’s requests:

  • Check the links – Some phishing attempts will come from a domain name similar to the actual company, but something just doesn’t quite fit. For example, the link companyA.examplesite.com might make you think that it’s a legitimate Company A URL – in reality, the main site is examplesite.com.
  • Check the sender field – If you are getting an email claiming to be from Company A, but the sender’s email address is not from Company A, the email is most likely not from Company A.
  • Check the message – does the message include any of the following?
    • Misspellings, bad grammar, poor formatting?
    • Messages claiming that your account was suspended or compromised and that you need to download a file, click a link, or send your login credentials via email to resolve the issue?
    • Messages claiming that you won a prize or award and that you need to click on a link or send over information to claim the prize?
    • If the email writer who is requesting your login information claims to come from your organization or from IT?

If you go through the checks and are still not 100% sure if the email is legitimate, do not click on any links, download or open any attachments, or reply back to the email. Contact the company through other means – opening a browser tab and accessing the company website via bookmarked tab or typing in the main company URL (NOT from the email!) is a safer way to obtain contact information as well as logging into your account.

Phishing has gotten more elaborate throughout the years, finding new ways to exploit human characteristics. Spear phishing and whaling are just two of the ways phishing has evolved. Nonetheless, if we all stop and think before we act on that email telling us to send over our information to claim our free fishing trip, more phishers will end their phishing trips with no catches.

Posted on

Data Analytics @ Your Library: An Executive Summary of the Santa Cruz Report

Welcome to this week’s Tip of the Hat!

Last week was a busy week in the world of library privacy, and not just because there were a variety of privacy-related presentations and events at ALA Annual. While folks were wrapping up and traveling back from DC, a Santa Cruz county civil grand jury published a report that will shape the library and vendor data analytics landscapes. Running short on time due to ALA travel last week and this week’s holiday schedule? Here’s an executive summary so you can get a head start on thinking about how to approach the report at your own organizations.

What was the report about?

The report, “Patron Privacy at Santa Cruz Public Libraries: Trust and Transparency in the Age of Data Analytics,” is the result of an investigation by the Civil Grand Jury about the Santa Cruz Public Library’s (SCPL) use of a commercial analytics program, Gale’s Analytics on Demand (AoD), to analyze patron data.

Who wrote the report?

The report was written by the Civil Grand Jury. The county of Santa Cruz has a Civil Grand Jury comprised of 19 private citizens. One of their roles in the county is to examine and investigate government operations and to recommend actions to improve said operations. The Consolidated Final Report for 2018-2019 lists other investigations undertaken by the Jury, including detention facilities and public defense contracts.

What did the report find?

The report found that the Santa Cruz Public Library did not adequately inform patrons about the use of AoD at SCPL or do a thorough privacy risk analysis on using AoD at SCPL. The major themes in the Grand Jury’s findings are:

  • Mismatch between use of AoD and SCPL confidentiality and privacy policy
  • Lack of communications between SCPL and library patrons regarding use of data analytics, including giving the patrons the option to give consent to the library to use their data for data analytic use
  • Failure on SCPL’s part to thoroughly investigate the risks, effectiveness, and best practices in using data analytics in processing patron data
  • Lack of contract language with the vendor that protects the interest of both SCPL and library patrons

What are the recommendations?

The Grand Jury recommendations to SCPL include:

  • Updating the SCPL confidentiality and privacy policy to reflect the use of data analytic tools to process patron data
  • Create a system that allows patrons to consent to having their data used for data analytics
  • Follow professional and industry best practices around patron privacy
  • Create a data privacy officer role whose responsibility will be implementing and enforcing the privacy policy
  • Review and amend vendor contracts to protect the interests of both the library and library patrons

What’s next?

ALA will most likely release a response to the report in the near future; however, the next major updates will most likely come at the time where the library will submit their responses to the Grand Jury’s finding and recommendations later in the year.

We use analytics software – based on this report, what do we do?

The recommendations provide a good outline to where to begin. If you need a place to start, here are four key actions to focus on:

  • Review privacy policies – does your policy clearly tell patrons that you use analytics to process patron data?
  • Review current patron communications – how are you communicating with patrons about how the library uses their data? Can your patrons give consent to having their data processed by analytics software? Is there a way they can opt-out?
  • Review your privacy practices – Go through the ALA Library Privacy Checklists and make a plan of action for any areas in the Priority 1 Actions sections of the lists that your organization has not implemented
  • Review vendor contracts – pay close attention to areas in which contracts can be amended to shore up patron privacy protections including reflecting local and state regulations surrounding patron data and responsibilities of the vendor in the event of a data breach.

Feel free to forward this summary to folks in your organization! We highly recommend giving the full report a read, but we recognize that time is sparse during the summer season, so we hope that the above summary can help you start conversations at your organization. LDH will keep you updated as the official responses from SCPL, ALA, and others are published in the coming months.

As a reminder, LDH Consulting Services can assist your organization in reviewing privacy policies and practices in addition to risk assessments, staff training, and data inventories. If you have any questions, or would like to discuss how LDH can help your organization’s privacy practices, give us a ping!