Cybersecurity Awareness Month News Update: School Cybersecurity, Passwords, and Crying “Hack!”

A small gray tabby kitten paws at the Mac laptop screen displaying the Google search home page, with its hind paws standing on the keyboard.
Image source: https://www.flickr.com/photos/tahini/5810915356/ (CC BY 2.0)

There’s never a dull moment in Cybersecurity Awareness Month, with last week being no exception. Here are some news stories you might have missed, along with possible implications and considerations for your library.

K-12 cybersecurity bill signed into law

You might remember reading about a new federal cybersecurity bill being signed into law. You remembered correctly! On October 8th, the K-12 Cybersecurity Act of 2021 was signed into law. The Act doesn’t have a set of standards to comply with for schools looking for such a list. Instead, the Act tasks the Cybersecurity and Infrastructure Security Agency (CISA) to study cybersecurity risks in K-12 educational institutions and what practices would best mitigate cybersecurity risks. The recommendations will be published along with a training toolkit for schools to use as a guide to implement these recommendations at their institution.

School libraries collect and store student data in several ways – the most common example being the patron record in the ILS. School libraries also heavily rely on third-party content providers, which in turn collect additional student data on both the library’s side and the third-party vendor’s side. School library workers, stay tuned for updates on the study and recommendations! While it’s unsure if the study will include school library systems and considerations into assessing cybersecurity risks, it’s more than likely that any recommendations that come from the study will affect school libraries.

Sharing all the passwords

You should be using a password manager. You might already be using one for your personal accounts, but are you using a password manager for work? If you’re still sharing passwords with your co-workers through spreadsheets or pieces of paper, it’s past time for your library to use a password manager. Several password managers, such as LastPass and Bitwarden, have business or enterprise products that are well-suited for managing passwords in the office. Not all password managers can share passwords and other sensitive information outside of the app, particularly if the other person doesn’t have an account with the same manager that you are using. There will be times where you want to share a password with someone outside your organization – a typical example is when a vendor needs to log into a system or app to troubleshoot an issue. But, for the most part, the password manager only supports secured sharing between people with accounts in the organization, so you’re stuck with sharing passwords in less secure ways.

However, if you are a 1Password user or your library uses 1Password’s business product, you no longer have this problem! 1Password users can now send account login information – including passwords – to anyone, including those who do not have a 1Password account. This new feature allows 1Password users to create a sharable link, with options to restrict sharing to specific people (email addresses) and when the link expires (anywhere between 30 days to after one person views the link)— no more calling the vendor, no more having staff email passwords in plaintext. Nonetheless, if your library wants to make use of this new feature, it’s best to give staff guidance as to how to create the links, including how to restrict access and expiration settings, along with training and documentation.

When a “hack” isn’t a hack

This news update is more of a “cybersecurity education 101” than news, considering the level of 🤦🏻‍♀️ this story contains. A very brief overview of what happened in Missouri last week:

  1. A reporter from the St. Louis Post-Dispatch found that a Department of Elementary and Secondary Education’s website contained the social security numbers (SSNs) of school teachers and administrators for the public to access through the HTML source code for the site.
  2. The newspaper notified the department about the security flaw, and the department took down the site in question.
  3. After the site was taken down, the newspaper published a story about the exposed SSNs on the now-defunct site.

Okay, so far, so good. Someone found a serious cybersecurity issue on a government website, reported it to the department, and waited to talk about the issue until the issue was addressed publicly. That’s pretty standard when it comes to disclosing security flaws. Let’s move on to the next item in the summary.

  1. The Governor of Missouri and other government officials responded to the disclosure, saying the reporter was a hacker and that the “hacker took the records of at least three educators, decoded the HTML source code, and viewed the social security number of those specific educators.”

🤦🏻‍♀️

There is a difference between hacking and exposing personal data on a publicly accessible website. The system was hacked if the reporter bypassed security measures to obtain sensitive data in an internal system, such as using stolen account logins to access the system. If the reporter clicks on the “View Source” menu option in their browser and finds sensitive data right in the source code of a publicly accessible website, you have a security vulnerability resulting in a data leak!

The takeaways from this story:

  1. Do not hard-code sensitive data in your code. This includes passwords for scripts that need to access other systems or databases.
  2. Review locally-developed and third-party applications that work with sensitive data for potential data leaks or other ways unauthorized people can improperly access the data.
  3. Do not punish the people who bring security issues to your attention! Like we discussed in our Friendly Phishing post, punitive actions can lead to a reduction in reporting, which increases security and privacy risks. Other reporters or private citizens who are watching the Governor take action against the reporter might be dissuaded from reporting additional data security or privacy issues to the state government, increasing the chance that these issues will be exploited by bad actors.
  4. If the data was sitting on a publicly available site for someone to access via F12 or View Source on their browser, it is not a hack. Let this be a lesson learned, lest you want to end up being ratio’ed like the Governor of Missouri on Twitter.