Putting it together: a small business technology review

The Friends of Fairhaven Library run a used-book shop in the lobby of the central library. Volunteers staff it six days a week, and the money it raises pays for children's programs. Its technology grew one gift at a time: two donated laptops, a tablet with a card reader for sales, a consumer Wi-Fi router plugged in years ago, a shared email account, a donor list kept in a spreadsheet, a small website, and a macro someone wrote to total the week's sales. The Friends' chair has asked Lorna whether the library could look it over. Lorna gives the job to Noor, with Jun as her assistant, and tells them to treat it as the final session of the cert club's second half. "Use everything from this course," she says. "Software, data and security. Write down what you find, rank it, and recommend what to fix first." This lesson walks through that review from start to finish.

Step 1: Inventory what exists

Every review starts with an inventory, because you cannot protect what you do not know about. Noor and Jun spend an afternoon in the shop listing every device, account, piece of software and store of data, who uses it and what it is for. They ask volunteers how they actually work, not how they are supposed to work, which is where the most useful findings come from.

Step 2: Review the software

The first lessons of this course help with the sales macro. Opening it, Noor finds a short script in the spreadsheet's macro language, which is interpreted: it runs each time someone presses the button, with no compile step. Reading it as pseudocode, she can see the algorithm: for each row in the week's sheet, if the payment type is cash, add the amount to the cash total, otherwise add it to the card total, then show both totals. It contains one logic error that explains a puzzle the treasurer had mentioned: the condition checks for the word "Cash" with a capital C, so rows typed as "cash" fall into the card total. Nothing ever showed an error message, because the code runs; it just gives the wrong answer.

sales = [("Cash", 12.00), ("Card", 25.50), ("cash", 8.00),
         ("Card", 14.00), ("CASH", 6.50), ("Card", 30.00)]

def weekly_totals(rows, ignore_case):
    cash = card = 0.0
    for kind, amount in rows:
        is_cash = kind.lower() == "cash" if ignore_case else kind == "Cash"
        if is_cash:
            cash += amount
        else:
            card += amount
    return cash, card

for fixed in (False, True):
    cash, card = weekly_totals(sales, fixed)
    label = "Fixed macro   " if fixed else "Original macro"
    print(f"{label}: cash {cash:6.2f}  card {card:6.2f}  total {cash + card:6.2f}")

Original macro: cash  12.00  card  84.00  total  96.00
Fixed macro   : cash  26.50  card  69.50  total  96.00

The fix is simple, but the bigger recommendation is about maintenance. The macro should carry a comment explaining what it does and who to ask, the payment type should be a drop-down list so it is always entered the same way, which is input validation from lesson 2, and a copy of each version should be kept with a note of what changed, a lightweight form of version control. Noor writes all three into her report.

Step 3: Review the data

The donor list is the shop's most valuable data and its biggest risk. It is structured data in a flat file, with the same donor sometimes appearing twice under slightly different spellings, which makes the totals unreliable. It holds personal information about 1,400 people, stored on one unencrypted laptop with no password and copied to a USB stick in a cash drawer. If the laptop is stolen, those details are exposed; if it fails, the list is gone, apart from a stick that may be out of date.

Jun asks whether a database would be better. For 1,400 donors maintained by two or three people, a full database server would be more than the shop needs, but the principles from lessons 6 and 7 still apply. Noor recommends moving the list into the donor management feature of a reputable hosted service designed for small charities, which stores records in a proper database with a unique ID for each donor, prevents duplicates, enforces required fields and keeps an audit history. Access goes only to the two volunteers who manage donations, each with their own account and MFA. The Friends should also check what Canadian privacy law expects of them as an organization holding donor information, including telling donors how their details are used and keeping them only as long as needed.

Lesson 5's point about the value of data shows up here too. The donor list is how the Friends raise most of their money, so losing it would cost far more than replacing a laptop. Investing a little in protecting it is a straightforward business decision. The sales records are less sensitive, because the payment processor handles card numbers and the shop never sees them, but they matter for the treasurer's reports and should be backed up as well.

Step 4: Review security

Security findings are grouped by the CIA triad from lesson 8, which makes it easier to explain why each one matters. Confidentiality is threatened by the shared passwordless laptop account, the unencrypted laptop with the donor list, the Wi-Fi passphrase on the wall and the one password reused across email, website and social media. Integrity is threatened by the macro's logic error and by everyone being able to change everything. Availability is threatened by the lack of backups, the ageing router and the laptop that no longer receives updates, which leaves it open to any new vulnerability.

The authentication findings from lesson 9 are the quickest to fix. Each volunteer who needs the laptops gets their own standard user account with a password, and one person holds a separate administrator account. The shared email moves to individual accounts, or at least to a shared mailbox that volunteers reach through their own sign-ins, with MFA. Every service gets its own unique password, stored in a password manager the Friends can share securely among the two coordinators. The router's default administrator password is changed, its firmware updated or the router replaced, and the Wi-Fi gets a new passphrase that is not on the wall, with a separate guest network if customers are offered Wi-Fi at all.

Device findings from lesson 10 follow. The laptop on the unsupported operating system is upgraded if its hardware allows, or retired and replaced; the other has automatic updates, the built-in anti-malware and firewall turned on, and full-disk encryption enabled with the recovery key stored with the coordinator. Both get screen locks. The website's plug-ins are updated, unused ones are removed and the site's admin account gets MFA. From lesson 11, a short briefing for volunteers covers phishing and phone scams, especially fake invoices and calls claiming to be from the payment processor, and the rule to verify any request for money or passwords by calling a known number.

Step 5: Rank and recommend

A small organization cannot fix everything at once, so findings are ranked by risk. A simple and widely used method scores each finding for likelihood and impact on a scale of 1 to 5, multiplies the two to get a risk score, and tackles the highest scores first, while also noting how much effort each fix takes, because a cheap fix for a high risk is the best place to start.

findings = [
    # (finding, likelihood 1-5, impact 1-5, effort)
    ("No backups of donor list or sales records", 4, 5, "low"),
    ("Unencrypted, passwordless laptop holds donor list", 3, 5, "low"),
    ("One password reused for email, website and social media", 4, 4, "low"),
    ("Laptop on an operating system with no more updates", 3, 4, "medium"),
    ("Router default admin password; passphrase on the wall", 3, 3, "low"),
    ("Website plug-ins a year out of date", 3, 3, "low"),
    ("Sales macro misreads 'cash' typed in lowercase", 5, 2, "low"),
]
ranked = sorted(findings, key=lambda f: f[1] * f[2], reverse=True)
for rank, (name, likelihood, impact, effort) in enumerate(ranked, start=1):
    score = likelihood * impact
    print(f"{rank}. score {score:2d} (L{likelihood} x I{impact}, effort {effort}): {name}")

1. score 20 (L4 x I5, effort low): No backups of donor list or sales records
2. score 16 (L4 x I4, effort low): One password reused for email, website and social media
3. score 15 (L3 x I5, effort low): Unencrypted, passwordless laptop holds donor list
4. score 12 (L3 x I4, effort medium): Laptop on an operating system with no more updates
5. score 10 (L5 x I2, effort low): Sales macro misreads 'cash' typed in lowercase
6. score  9 (L3 x I3, effort low): Router default admin password; passphrase on the wall
7. score  9 (L3 x I3, effort low): Website plug-ins a year out of date

The ranking turns into a short plan for the Friends' board. In the first week: set up automatic backups of the donor list and sales records following the 3-2-1 rule, with one copy in a cloud backup service that keeps earlier versions; encrypt and password-protect the laptops with individual accounts; and change every shared password to a unique one in a password manager, turning on MFA wherever it is offered. In the first month: replace or upgrade the unsupported laptop, secure or replace the router, update the website and fix the macro with a drop-down list for payment type. Within three months: move the donor list to a proper donor management service, brief all volunteers on phishing and scams, and run the first test restore from backup.

Lorna reads the report before it goes to the Friends and adds one note: the review itself should be repeated, because technology, people and threats change. A small business that inventories its technology, protects its most valuable data, uses unique passwords with MFA, keeps devices updated, backs up and tests restores, and trains its people has covered most of what attackers rely on. That is also, Noor realizes, most of the Tech+ security domain in one page, and she files the report with her exam notes.