Capstone: a security review of a small business

This capstone brings the course together. Sam's security review of Ridgeline Coffee Roasters began with a phishing email in lesson 1 and has touched every topic since: threat actors, attacks, controls, cryptography, certificates, identity, networks, endpoints, monitoring and incident response. Now it is time to finish the review the way a professional would: with a structured assessment, a risk register, a prioritized roadmap and a short report that the owner can act on. The same method works for any small organization, from a dental office to a hardware store, and it is a good model for the first security review you carry out yourself.

Scoping the review

Every review starts by agreeing its scope: what is included, what is not, who must be involved and what the result will look like. Ridgeline's review covered its people and processes, the office, cafe and roastery, every device in the inventory, the network, and the cloud services the business depends on: Microsoft 365, the online shop, the point-of-sale and payment provider, the payroll provider and the bank. It did not include testing the providers' own systems, which is their responsibility under the shared responsibility model; instead the review checked how Ridgeline configured and used those services. Rosa agreed that the result would be a risk register, a roadmap and a two-page summary, and that Sam would present it at a staff meeting.

A review is not an attack. Sam's review used conversations, walk-throughs, configuration checks, logs and the dashboards of Ridgeline's own services, all with Rosa's written permission. Any active security testing, such as scanning the network for vulnerabilities, requires explicit authorization from the owner of every system involved, and is always kept within the agreed scope.

Gathering information

Sam gathered information in four ways. Interviews with each person asked what they do, which systems and data they use, what would hurt most if it stopped or leaked, and what they find awkward about security, since awkward controls get bypassed. A walk-through of each site looked at doors, screens, cables, card readers, the network closet and the shelf where the NAS sits. A technical check of each device compared it with the baseline from lesson 9, and the cloud services were checked for MFA, admin accounts, sharing settings and alerts. Finally, a document review looked for the policies and records that should exist: the inventory, the backup log, the leaver checklist and the incident plan.

The interviews produced several of the most important findings. Anita mentioned that the bank sends a code to her phone for large payments, but that she sometimes reads the code to Rosa over the phone when Rosa approves from home, which would let a caller pretending to be Rosa capture it. Kai mentioned that the roaster's temperature logger runs an old version of its software that the maker no longer updates. Mei mentioned that baristas share a single point-of-sale login for speed during the morning rush.

Assessing controls area by area

To keep the review complete, Sam worked through a checklist drawn from the CIS Controls and the Canadian Center for Cyber Security's baseline controls for small organizations, grouped into areas. For each area the question was simple: is the control in place, partly in place or missing? A score per area shows at a glance where the business is strong and where it is weak.

areas = {
    "Accounts and MFA": ["yes", "yes", "partly", "no"],
    "Network": ["yes", "yes", "yes", "yes"],
    "People": ["yes", "partly", "partly"],
}

def area_score(checks):
    points = {"yes": 2, "partly": 1, "no": 0}
    return 0

def weakest(areas):
    return None

for name, checks in areas.items():
    print(name, area_score(checks))
print("weakest:", weakest(areas))

The risk register

Each finding becomes an entry in a risk register: a table listing the risk, the asset and threat involved, its likelihood and impact scores from lesson 4, the current controls, the proposed treatment, the owner and a target date. The register turns a pile of observations into decisions, and it stays alive after the review: Ridgeline will update it every quarter and after any incident. Sam also estimated the effort for each fix on a three-point scale, so that quick wins with high risk scores could be scheduled first.

register = [
    # (risk, likelihood, impact, effort 1 low to 3 high)
    ("Bank codes read aloud over the phone", 3, 5, 1),
    ("Shared point-of-sale login", 4, 3, 1),
    ("Unsupported roaster logger software", 3, 3, 3),
    ("Router logs not reviewed", 3, 2, 1),
    ("No staff phishing refresher this year", 3, 4, 1),
]
rows = []
for risk, likelihood, impact, effort in register:
    score = likelihood * impact
    phase = "this month" if score >= 12 and effort == 1 else "next 3 months" if score >= 9 else "this year"
    rows.append((score, effort, phase, risk))
for score, effort, phase, risk in sorted(rows, key=lambda r: (-r[0], r[1])):
    print(f"{score:>2}  effort {effort}  {phase:<13} {risk}")

15  effort 1  this month    Bank codes read aloud over the phone
12  effort 1  this month    Shared point-of-sale login
12  effort 1  this month    No staff phishing refresher this year
 9  effort 3  next 3 months Unsupported roaster logger software
 6  effort 1  this year     Router logs not reviewed

register = [
    ("Bank codes read aloud", 3, 5, 1),
    ("Shared point-of-sale login", 4, 3, 1),
    ("Unsupported logger software", 3, 3, 3),
    ("Router logs not reviewed", 3, 2, 1),
]

def phase(likelihood, impact, effort):
    return "this year"

def plan(register):
    result = {"this month": [], "next 3 months": [], "this year": []}
    # add each risk name to the right list
    return result

print(plan(register))

Treatments for the main findings

For the bank codes, the treatment was a process change and a technical one: Rosa now approves payments from her own bank login on her own phone, with its own second factor, so that no code is ever read aloud, and staff were reminded that no genuine caller, including Rosa or the bank, will ever ask for a code. For the shared point-of-sale login, the provider supports individual staff PINs that take a second to enter; each barista now has one, which restores accountability for refunds and voids without slowing the morning rush. For the roaster logger, replacement software is planned for the spring equipment budget, and until then a compensating control keeps the logger on the roastery segment with no internet access and its data copied nightly to the NAS. The router logs were added to Sam's monthly review, and a short phishing refresher, built around the original payroll email, was scheduled for the next staff meeting.

Some findings were accepted. The guest Wi-Fi occasionally slows on busy Saturdays, which is an availability nuisance with no effect on Ridgeline's own data, so Rosa accepted it and it was recorded with a review date. The review also recognized what was already working well, which matters for morale and for knowing what to keep: the segmented network, the tested and protected backups, the incident plan proven in a real incident, and staff who report problems quickly.

Writing the report

Security reports fail when they are written for other security people. Rosa needs to know what matters, what it will cost, what she must decide and what happens next; she does not need a list of protocol names. Sam's two-page summary followed a simple structure. It opened with a one-paragraph overall picture: Ridgeline's security has improved a great deal this year and is now good for a business of its size, with three gaps to close. It then listed the top risks in plain language, each with its business impact, the recommended fix, the cost and the owner. It summarized the roadmap by phase, named the decisions Rosa needed to make, and ended with what was already working well and the date of the next review. The full risk register and the area-by-area checklist went in an appendix for Jordan and Sam.

Presenting the results to the whole staff, briefly and without blame, was the last step. People follow security practices far more reliably when they understand the reasons, and the staff meeting gave Mei a chance to explain why the shared login had seemed necessary, which helped choose a fix that worked for the cafe.

Keeping security going

A review is a snapshot, and security is a continuing practice. Ridgeline's calendar now holds the routines built throughout this course: weekly checks of updates, backups and the security dashboard; the monthly backup restore test and log review; quarterly access reviews and risk register updates; a yearly tabletop exercise, staff refresher and full review; and the leaver checklist whenever someone leaves. Changes trigger reviews too: a new service, a new device or a new kind of data all prompt the question of what could go wrong and which controls are needed.

For you, this course is the foundation for the specialist courses that follow in the IT programs: network security, security operations, incident response and forensics, vulnerability management, cloud security, and governance, risk and compliance. It also covers the core of the CompTIA Security+ exam objectives. The habits it teaches, understanding what matters, thinking about how it could be harmed, choosing sensible controls, watching for problems and being ready to respond, apply at every level of the field.