$ cat threat-model.md
Threat model: a multi-branch public library network
Please read first. This is an illustrative reference model built from common patterns in public library networks. It is a learning exercise. It does not describe the environment of any real organization, including any employer of mine, and the ratings are judgment-based, not measured data. For background on the library whose public structure inspired the extra factors in section 3, see The Boston Public Library, explained.
Public libraries are an interesting security problem. They hold sensitive patron data, serve thousands of anonymous visitors on shared networks, run on small teams and tight budgets, and depend on outside vendors. This write-up walks through how I would approach a threat model for a system like that: what to protect, where the trust boundaries are, what is most likely to go wrong, and what I would do first.
1. Scope and assumptions
- System modeled: a central library and a few dozen branches, linked to a core data center or cloud environment, plus a connection to partner libraries in a consortium.
- Typical components: public Wi-Fi and patron computers, staff workstations, self-checkout and print or payment stations, an integrated library system (ILS) with the patron database, a public website and catalog, digital-lending vendors, and branch routers and firewalls.
- Security goals: protect patron privacy, keep services available to the public, and keep staff accounts and the ILS trustworthy.
- Out of scope: physical building security (apart from rogue hardware), HR processes, and bugs in specific vendor products.
2. Architecture and trust boundaries
Green arrows are allowed flows. The red dashed arrow is blocked on purpose. Numbered circles mark the four trust boundaries listed below.
- Boundary 1, Internet to public services: only the web and vendor ports are exposed, and a web application firewall sits in front of the site.
- Boundary 2, public zone to everything internal: default deny. Patron devices can reach the internet and nothing else.
- Boundary 3, branches to core services: staff reach the core with MFA, kiosks reach only the specific ILS functions they need, and the link is an encrypted WAN or VPN with monitoring.
- Boundary 4, partners and vendors: a narrow, logged connection with named accounts, MFA and no standing broad access.
3. The wider footprint: extra factors
The first diagram shows the network. A large urban library system is more than a network, though. Large systems like the Boston Public Library, whose structure is described on its own public website, also run special collections, a statewide digital archive, partner nonprofits, shared consortium services and youth programs. Each adds factors a basic model would miss. I added five threats (T11 to T15) for them. This still describes the shape of an organization like this, not any real organization's technology, controls or weaknesses.
Dashed boxes are separate organizations or networks that connect to the library with their own security maturity. The tags under each box point to threats in the register.
| Part of the footprint | Extra factor | Threats |
|---|---|---|
| Special collections and digitization | Irreplaceable originals and their digital copies. If digital records are altered or deleted, trust in the collection suffers. | T11 |
| Statewide digital archive | One platform holds other organizations' materials from many contributors, so integrity and availability matter well beyond the library itself. | T11, T12 |
| Shared network of public, school and college libraries | Members differ in staff, budgets and security maturity. One weak member can expose the shared catalog or shared accounts. | T12, T4 |
| Statewide services (e-card, databases, interlibrary loan) | Accounts for residents across a whole state, plus licensed vendor platforms and proxy logins. | T4, T12 |
| Map center and other partner nonprofits | A separate organization with its own systems, data sets and web properties that carry the library's name. | T4, T11 |
| Business library and makerspaces | Co-working, media tools and mentoring involve visitors' own devices and sensitive business information. | T3, T7 |
| Teen and children's spaces | Minors' registrations, volunteer records and program data need stricter handling. | T13 |
| Fundraising affiliates (fund, friends, associates) | Donor, event and payment data sit with separate nonprofits, and scammers can pose as them. | T14, T15 |
| High visibility and public programs | A well-known civic institution draws attention, from phishing that uses its name to website defacement. | T15, T1 |
4. What needs protecting
Highest value
- Patron records and borrowing history (privacy-sensitive)
- Staff identities and admin accounts
Must stay available
- ILS and checkout at every branch
- Public website and catalog
- Internet access for patrons
Hard to rebuild
- Configuration and directory data
- Backups themselves
- Public trust in the library
5. Threat register
I used STRIDE to look for threats at each trust boundary, then mapped each to a MITRE ATT&CK technique and to NIST SP 800-53 control families. Priority 1 means address first. Control IDs are pointers for follow-up, not a compliance claim.
| ID | Threat | STRIDE | ATT&CK | Priority | Main controls (800-53) |
|---|---|---|---|---|---|
| T1 | Phishing steals a staff or admin password | Spoofing | T1566, T1078 | 1 | Phishing-resistant MFA such as passkeys (IA-2), email filtering (SI-8), awareness and simulations (AT-2) |
| T2 | Ransomware spreads from one staff PC to file servers and the ILS | Tampering, Denial of service | T1486, T1021 | 1 | Segmentation (SC-7, AC-4), endpoint protection (SI-3), least privilege (AC-6), tested offline backups (CP-9, CP-10) |
| T3 | A compromised public device moves sideways into internal networks | Elevation of privilege | T1046, T1021 | 1 | Default-deny public zone and client isolation (SC-7, AC-4), locked-down kiosk images (CM-7), reimage after each session |
| T4 | A vendor or consortium connection is abused to reach core systems | Spoofing, Tampering | T1199 | 2 | Vendor risk review before purchase (SA-9), narrow information exchange agreements (CA-3), named accounts with MFA and logging |
| T5 | An internet-facing website or vendor portal is exploited | Tampering, Elevation of privilege | T1190 | 2 | WAF and DMZ isolation (SC-7), patch deadlines by severity (SI-2), regular scans and a yearly penetration test (RA-5) |
| T6 | Staff or patron traffic is intercepted on shared Wi-Fi | Information disclosure | T1557 | 2 | Separate staff network with 802.1X (AC-18), encrypted sessions (SC-8), no staff traffic on public Wi-Fi |
| T7 | An insider looks up patron records without a reason | Information disclosure, Repudiation | T1078 | 2 | Role-based access (AC-2, AC-6), logging and review of record access (AU-2, AU-6), privacy training (AT-2), data retention limits |
| T8 | A rogue device is plugged into a branch network port | Spoofing, Tampering | T1200 | 3 | Network access control and 802.1X (IA-3), disabled unused ports, asset inventory (CM-8) |
| T9 | A denial-of-service attack or link failure takes services offline | Denial of service | T1498 | 3 | DDoS protection for the public site (SC-5), redundant links for large branches (CP-8), an offline checkout mode (CP-2) |
| T10 | Weak logging means an attack goes unnoticed for weeks | Repudiation | none (a gap) | 1 | Central logging and alerts on admin logins and mass downloads (AU-6, SI-4), tested response plan (IR-4, IR-8) |
| T11 | Digitized collections or repository records are altered, corrupted or deleted | Tampering, Repudiation | T1565, T1485 | 2 | Integrity checks on stored files (SI-7), an offline or immutable preservation copy (CP-9), restricted and logged edit rights (AC-6, AU-2) |
| T12 | A weak member of a shared library network exposes the shared catalog or accounts | Spoofing, Elevation of privilege | T1199, T1078 | 1 | Minimum security baseline for every member (SA-9), separation between members (AC-4), named admin accounts with MFA (IA-2), logging per member (AU-6) |
| T13 | Minors' and teens' registration, volunteer or program data is exposed | Information disclosure | T1213 | 2 | Collect only what is needed, retention limits (SI-12), role-based access (AC-6), staff privacy training (AT-2) |
| T14 | Donor, event or payment data held by an affiliated nonprofit is stolen, or scammers impersonate it | Information disclosure, Spoofing | T1566, T1657 | 2 | Review how affiliates handle data (SA-9), written data-sharing terms (CA-3), payments through a certified processor, email authentication against spoofing (SI-8) |
| T15 | A high-profile institution is targeted for defacement, hacktivism or brand impersonation | Denial of service, Spoofing | T1491 | 3 | WAF and DDoS protection (SC-5, SC-7), lookalike-domain monitoring, a tested communications and response plan (IR-4, IR-8) |
Priority is my judgment for a typical environment, based on likelihood and impact. In a real review I would replace it with local incident history and asset values.
6. What I would do first
First 30 days
- Roll out phishing-resistant MFA to admins, then all staff (T1)
- Prove a backup restore works end to end (T2)
- Test from a public device that nothing internal is reachable (T3)
- Alert on admin logins and new accounts (T10)
- Set a minimum security baseline for shared-network members (T12)
Days 30 to 90
- Separate kiosks and devices from staff networks (T2, T3)
- Review all vendor and consortium access (T4)
- Set patch deadlines and a scan schedule (T5)
- 802.1X on wired staff ports (T8)
- Add integrity checks and an offline copy for digital collections (T11)
- Review how affiliates handle donor and payment data (T14)
Later
- Run a ransomware tabletop exercise (T2)
- Review DDoS protection and link redundancy (T9)
- Write data retention rules for patron records (T7)
- Repeat this model yearly
- Set handling rules for minors' data (T13)
- Prepare a response plan for defacement and brand impersonation (T15)
7. Residual risk and what I would test
This model rests on assumptions that I would check before trusting it:
- The public and staff networks are really separate. I would test with a scan from a public device.
- Backups restore within the time the library can tolerate. I would run a timed restore.
- Vendor access is limited to what each vendor needs. I would review accounts and logs.
- Staff recognize phishing. I would measure with simulations and track reporting rates over time.
Even with all of these controls, some risk remains: a determined attacker, a zero-day flaw, or a mistake by a tired person. The goal is to make attacks hard, limit the damage when one succeeds, and notice quickly.
8. Method
- STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) to find threats at each boundary.
- MITRE ATT&CK to describe how real attackers carry out each threat.
- NIST SP 800-53 control families to point to the safeguards.