Chapter 5 — Security literacy | Bachelor's Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 05 published. Map, example, EX013.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["5.1 Core vocabulary"]
  N2["5.2 Risk is relative to an asset and an objective"]
  N3["5.3 Authorized action"]
  N4["5.5 Practical activity"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["5.1 Core vocabulary"]
  N2["5.2 Risk is relative to an asset and an objective"]
  N3["5.3 Authorized action"]
  N4["5.5 Practical activity"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX013"]

[Learning outcomes and connection]
    |
    v
[5.1 Core vocabulary]
    |
    v
[5.2 Risk is relative to an asset and an objective]
    |
    v
[5.3 Authorized action]
    |
    v
[5.5 Practical activity]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX013]

Learning outcomes and connection

You will be able to (1) define asset, threat, vulnerability, impact, control and residual risk; (2) compare two security events and justify different priorities from stated assumptions; (3) recognize the boundary of authorized action; and (4) explain why the same alert can deserve different responses. Chapter 4 taught you to state claims carefully; here you learn the vocabulary those claims use. Chapter 6 adds graph models of access.

5.1 Core vocabulary

An asset is anything of value to the organization: data, a service, a device, a reputation. A threat is a circumstance or actor with the potential to cause harm. A vulnerability is a weakness that a threat could exploit. Impact is the harm if it happens, measured against the organization's objectives (safety, service availability, privacy, finance, law). A control is a measure that reduces likelihood or impact: preventive (multi-factor authentication), detective (sign-in alerting), corrective (restoring from backup). Residual risk is what remains after controls. NIST's Cybersecurity Framework 2.0 organizes these ideas into six functions — Govern, Identify, Protect, Detect, Respond, Recover — and incident response sits mainly in Detect, Respond and Recover while depending on the others.

5.2 Risk is relative to an asset and an objective

"Suspicious sign-in" is not a risk statement. "A possibly stolen credential for an account that can modify the medication schedule of a clinic" is closer: it names an asset, a threat and an impact path. Priority in triage follows from impact and likelihood given current evidence, not from the alert's name.

The pharm-admin account illustrates the point: the alert text is identical to the one on test-kiosk-3, yet the medication schedule it can change makes the potential harm far greater. Write the objective that would be damaged, such as patient safety or service availability, beside the asset; a reader who disagrees with your priority can then argue with a stated objective instead of with your instinct.

5.3 Authorized action

A responder acts on behalf of an organization within a defined scope: which systems, which data, which actions. Authorization comes from policy and from named people (system owners, incident lead, legal or privacy officers). Investigating outside scope — reading an employee's personal mailbox without approval, scanning a third party's network, "hacking back" — can be unlawful and can destroy the legitimacy of the whole response. When in doubt, the correct action is to stop and escalate, recording the question and the answer.

5.4 Worked example (synthetic): same alert, two priorities

Fictional. Two alerts fire at 07:55 at Harbourline: "sign-in from new country" for (a) test-kiosk-3, an account on an isolated demonstration tablet with no access to patient data, and (b) pharm-admin, an account that can change dispensing schedules in the pharmacy system.

Assumptions (stated): both alerts come from the same detection rule; neither account usually travels; (a) is segregated on a guest network; (b) has no MFA because of a legacy integration.

Analysis: likelihood of misuse given the alert is similar for both — the same rule fired. Impact differs greatly: (a) could at worst deface a kiosk; (b) could alter medication timing, a patient-safety impact. Controls differ: (a) is segregated; (b) lacks MFA. Priority: (b) is high, with immediate contact with the pharmacy system owner to verify the sign-in and, with approval, revoke the session; (a) is low, handled in the queue. What would change it: evidence that (a)'s tablet was connected to the clinical network would raise its priority.

5.5 Practical activity

Pick three systems you use and, for each, write one sentence of the form "If [threat] exploits [vulnerability] in [asset], then [impact on objective]; current controls are [...]".

For each sentence, add one detective control you would expect to notice the threat, and state whether you know it exists or are assuming it. Then rank the three by impact and write one line explaining the order. Swap with a classmate: if they rank differently, find which assumption you disagree about. Keep the systems generic, such as a student email account, and do not test any control on a real service; the exercise is about stating risk, not probing for it.

5.6 Common errors and limits

Prioritizing by alert name or tool severity rather than by asset impact.
Confusing vulnerability (weakness) with threat (actor or event).
Treating residual risk as zero after a control is deployed.
Assuming authority because you have technical access. Technical capability is not permission.
Writing risk statements without an objective, so nobody can tell why the asset matters.
Copying the priority of an earlier alert with the same name, as if test-kiosk-3 and pharm-admin carried equal stakes.
Leaving assumptions unstated, which prevents a reviewer from seeing what would raise or lower the priority.

Exercises — chapter 5

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX013 — Vocabulary mapping. Inputs: "A former contractor's VPN account was never disabled; the VPN allows access to the file server holding staff payroll." Steps: identify asset, threat, vulnerability, impact, a preventive and a detective control, and residual risk after disabling the account. Rubric: 3 = all correct and residual risk acknowledges other un-reviewed accounts and past access; 2 = one confusion; 1 = generic; 0 = none.

EX014 — Priority with assumptions. Inputs: §5.4 changed so that (b) has MFA and the sign-in passed MFA from a known device. Steps: reassess (b)'s priority and say what evidence still needs checking. Rubric: 3 = lowered but not dismissed, checks MFA method (push fatigue, device registration date), owner confirmation; 2 = changes priority without checks; 1 = unchanged without reasons; 0 = none.

EX015 — Scope boundary. Inputs: during triage of (b), a colleague suggests logging into the pharmacist's personal cloud email to see if the password was phished there. Steps: explain why this is out of bounds and list two authorized alternatives. Rubric: 3 = identifies lack of authorization and privacy/legal issues, proposes asking the user (with HR/privacy as needed) and reviewing organizational mail and IdP logs; 2 = partial; 1 = endorses; 0 = none.

Chapter synthesis

Risk is asset-specific: the same alert means different things for different assets and controls. State assumptions, prioritize by impact and likelihood, and remember that access is not authorization.