In Case of Emergency

A pull fire alarm with a sign next to it stating "Exit Alarm Only - this alarm does not summon the fire dept In case of Fire call 911"
Image source – https://www.flickr.com/photos/laurablume/5356203877 (CC BY ND 2.0)

Last Wednesday’s attempted insurrection at the US Capitol left many in various states of shock, despair, anger, and grief. As the fallout from the attempt continues to unfold, we are starting to learn more about the possible cybersecurity breaches that resulted from the attempt. Cybersecurity professionals, who are still trying to investigate the extent of the damage done by the SolarWinds attack weeks before, are now trying to piece together what could have been compromised when the mob entered the building. Stolen laptops and other mobile devices, unlocked desktop computers, paperwork left on desks – the immediate evacuation of congresspeople and workers meant that the mob had potential access to sensitive or confidential information as well as sensitive internal systems.            

Leaving a desk, office, or service point immediately to get to safety is a real possibility, even for libraries. Active shooter training has become standard for many US organizations, joining common fire and severe weather drills where staff leave their workstations to head to safe areas. Other library workers have personal experience leaving their work station to get to safety; in one instance, someone I knew barricaded themselves in a work office with other library staff after a patron started attacking them at the information desk. Physical safety comes first. Nonetheless, this leaves information security and privacy professionals planning on how to mitigate the risk that comes with potential data and security breaches in these life-threatening emergencies.

Incident response planning and several cybersecurity strategies help mitigate risk during emergencies where staff immediately leave work areas. Preventative measures can include:

  • Encrypting hard drives on computers and mobile devices
  • Requiring multifactor authentication (MFA) for device and application access
  • Installing remote wipe software to wipe devices if they are reported missing or stolen
  • Not writing down passwords and posting them on computer monitors, keyboards, desks, etc.
  • Conducting an inventory of library staff computers and mobile devices (tablets, phones, etc.)
  • Setting up auto-lock or auto-logoff on staff computers after a few minutes of inactivity
  • Storing confidential or sensitive data in designated secured network storage and not on local hard drives or USB drives
  • Limit access to systems, applications, and data through user-based roles, providing the lowest level of access needed for the user to perform their daily work
  • Storing mobile devices and drives as well as sensitive paper documents in secured areas when not in use (such as a locked desk drawer or cabinet)

After the emergency, an incident response plan guides the process in responding to potential data breaches: containing the damage, removing the attacker from doing more damage, and how to repair the damage. The incident response plan also provides communication plans for users affected in the breach as well as any regulatory obligations for reporting to a government office or official.

All of this will involve a considerable amount of resources and time; however, the time spent in planning and in training (think the tabletop exercises mentioned in our post about gaming in cybersecurity training) will be less time spent after the fact where emotions and stress are running high, resulting in things being missed or falling through the cracks after the emergency.

Into the Breach!

Welcome to this week’s Tip of the Hat!

Last week brought word of two data leaks from two major library vendors, Elsevier and Kanopy. Elsevier’s leak involved a server storing user credentials, including passwords, that was not properly secured. Kanopy’s leak involved an unsecured database storing website logs, including user activity. Both leaks involved library patron information, and both leaks were caused by a lapse in security measures on the part of the vendor.

As the fallout from these two breaches continues in the library world, now is as good of a time than any to talk about data breaches in general. Data breaches are inevitable, even if you follow security and privacy best practices. What matters is what you do when you learn of a possible data breach at your library.

On a high level, your response to a possible data breach should look something like this:

  1. Determine if there was an actual breach – depending on the nature of the breach, this could be fairly easy (like a lost laptop with patron information) or requires more investigation (like looking at access logs to see if inactive accounts have sudden bursts of activity).
  2. Contain and analyze the breach – some breaches can be contained with recovering lost equipment, while others can be contained by shutting off access to the data source itself. Once the breach is contained, you can then investigate the “who, what, when, where, and how” of the breach. This information will be useful in the next steps…
  3. Notify affected parties – this does not only include individual users but organizational and government agencies as well.
  4. Follow up with actions to mitigate future data breaches – this one is self-explanatory with regard to applying what you learned from the breach.

The US does not have a comprehensive federal data breach notification law. What the US does have is 50+ data breach notification laws that vary from state to state. These laws have different regulations pertaining to who needs to be notified at a certain time, and what information should be included in the notification. If you are also a part of a larger organization, that organization might have a data breach incident response procedure. All of the above should be taken into consideration when building your own incident response procedure.

However, that does not address what many of you might be thinking in light of last week’s data breaches – how do you prevent having your patrons’ information breached in a vendor’s system? It’s frustrating when your library’s patron information is left unsecured with a vendor, be it through unencrypted passwords and open databases containing patron data. There are a couple of steps in mitigating risk with the vendor:

  • Vendor security audits – One practice is to audit the vendor’s data security policies and procedures. There are some library related examples that you can pull from: San Jose Public Library performed a vendor security audit in 2018, while Alex Caro and Chris Markman created an assessment framework in their article for the Code4Lib Journal.
  • Contract negotiations – Writing in privacy and security clauses into a vendor contract introduces a layer of legal protection not only for your patrons but to your organization as a whole, with regards to possible liability that comes with a data breach. Additions can clarify expectations about levels of security surrounding patron data in vendor systems as well as data breach management expectations and roles between the vendor and the library.

Ultimately, it’s up to the vendor if they want to follow security best practices and have a data breach incident management procedure (though, if a vendor chooses not to implement security protocols, that could adversely affect their business). Nonetheless, it never hurts to regularly bring up security and privacy in contract negotiations and renewals, procurement processes, and in regularly scheduled vendor rep meetings. Make it clear that your library considers security and privacy as priorities in serving patrons, and (hopefully) that will lead to a partnership that is beneficial to all involved and leaves patrons at a lower risk of having their data breached.

Phew! There’s a lot more on this topic that can be said, but we must leave it here for now. Below are a couple of resources that will help you in creating a data breach incident response plan: