Cybersecurity Fundamentals: CIA Triad and Threat Modelling

A volunteer coordinator at a neighbourhood food bank builds a small web app so helpers can sign up for weekend shifts. It stores names, phone numbers, which volunteers have a police-check on file, and the delivery addresses of households who receive parcels. Nobody on the team is a security specialist. Where do you start? Not with firewalls or tools. You start with a question: what are we protecting, and from whom?

Three words that cover most security goals

Almost every security requirement can be sorted under one of three properties, usually called the CIA triad. It has nothing to do with the intelligence agency. It is a checklist for noticing what kind of damage a failure causes.

The properties pull against each other. Locking everything down hard protects confidentiality but can hurt availability if volunteers cannot log in. Making data instantly available to everyone helps availability and wrecks confidentiality. Security work is mostly choosing a sensible balance for the specific data you hold, not maximising all three.

Assets, actors and entry points

A threat model starts by writing down four things in plain language. Assets are what you would be upset to lose or expose. Actors are the people and systems that touch the assets, including the ones you do not trust. Entry points are the places where data crosses a boundary: a form, an API endpoint, an uploaded file, an admin login, an email address that password resets are sent to. Trust boundaries are the lines where the level of trust changes, such as browser to server or server to database.

Most mistakes come from forgetting an entry point. Teams remember the login form and forget the CSV import that an admin uses, the spreadsheet where someone exports the volunteer list every Monday, or the shared inbox that receives password resets.

A worked threat model on one page

Here is what the food bank team might write after a 45-minute whiteboard session. Likelihood and impact are scored 1 to 3 by judgement, not measurement. The point is to force a conversation and an order of work, not to compute a precise number.

ASSETS
  A1  Household delivery addresses (sensitive)
  A2  Volunteer phone numbers and police-check status
  A3  Shift sign-up availability (must be up on delivery days)

ENTRY POINTS
  E1  Public sign-up form          E3  Admin login
  E2  Volunteer login              E4  Weekly CSV export to coordinator's laptop

THREATS                                      L  I  Score
  T1  Volunteer guesses a URL and reads
      another household's address              3  3   9   (A1 via E2)
  T2  Reused password from another breach
      lets someone into the admin account      2  3   6   (A1, A2 via E3)
  T3  Exported CSV left on a lost laptop       2  3   6   (A1, A2 via E4)
  T4  Sign-up form flooded with fake entries   2  2   4   (A3 via E1)
  T5  Server disk fills up, site is down       1  2   2   (A3)

PLAN (cheapest effective control first)
  T1  Check ownership/role on the server for every address lookup
  T2  Turn on multi-factor sign-in for admins; block known-bad passwords
  T3  Stop exporting addresses; export only first names and shift times
  T4  Simple rate limit plus a hidden-field check on the form
  T5  Disk usage alert at 80 percent

Once the scores are on paper, ordering them is mechanical, and you can let a few lines of code do it so the list stays sorted as it grows. Multiply likelihood by impact, break ties by impact, and print the queue.

threats = [
    ("T1", "Volunteer guesses a URL and reads another household's address", 3, 3),
    ("T2", "Reused password lets someone into the admin account", 2, 3),
    ("T3", "Exported CSV left on a lost laptop", 2, 3),
    ("T4", "Sign-up form flooded with fake entries", 2, 2),
    ("T5", "Server disk fills up and the site goes down", 1, 2),
]

ranked = sorted(threats, key=lambda t: (t[2] * t[3], t[3]), reverse=True)
for tid, text, likelihood, impact in ranked:
    print(f"{tid}  score {likelihood * impact}  (L{likelihood} x I{impact})  {text}")

T1  score 9  (L3 x I3)  Volunteer guesses a URL and reads another household's address
T2  score 6  (L2 x I3)  Reused password lets someone into the admin account
T3  score 6  (L2 x I3)  Exported CSV left on a lost laptop
T4  score 4  (L2 x I2)  Sign-up form flooded with fake entries
T5  score 2  (L1 x I2)  Server disk fills up and the site goes down

Look at what the exercise produced. The highest-scoring threat is not a clever hack. It is an ordinary logic gap that a curious volunteer could stumble on. The fix for T3 is not a product at all; it is deleting data you did not need to export. Good threat modelling regularly finds that the best control is to collect or copy less.

Defence in depth and least privilege

No single control is perfect, so you stack them. If the ownership check in T1 has a bug, a second layer (logging each address lookup, alerting on a volunteer who reads 200 addresses in a minute) turns a silent leak into a noticed one. This layering is called defence in depth. Its companion is least privilege: every person, service and token gets only the access it needs for its job. A volunteer needs their own shifts. They do not need the household list, so the database user the sign-up page uses should not be able to read it either.

Common mistakes

• Modelling only the login page. Symptom: the first real incident comes through an export, an integration key in a repo, or a forgotten admin route. Fix: list every entry point, including offline ones.
• Treating all data as equally sensitive. Symptom: encryption and approvals everywhere, so people route around them with personal spreadsheets. Fix: mark one or two assets as sensitive and spend your effort there.
• Scoring with false precision. Symptom: a long debate about whether a threat is 4.2 or 4.6. Fix: use low/medium/high, and move on once the order is clear.
• Writing the model once and filing it. Symptom: a new import feature ships and nobody asks what changed. Fix: attach a short threat-model question to every design review.

How this shows up in real projects and interviews

Interviewers for junior roles rarely ask for the CIA triad as a definition. They ask something like "a user can see another user's invoice, which part of the triad is that and how would you fix it?" The answer is confidentiality, with a server-side authorisation check as the fix. In project work, a one-page model like the one above is often all a small team needs. Larger teams use structured methods such as STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) as a prompt list so no category is forgotten. If you are preparing for job interviews more broadly, common interview mistakes to avoid is a useful companion.