M01-02 · Asset, threat, vulnerability and risk

1. What does each term ask?

• Asset: what has value and needs protection? This includes computers, information, services and resources supporting work. NIST: Asset
• Threat: what circumstance or event could cause harm? Examples include unauthorized access, accidental deletion or equipment failure; threats are not limited to attacks. NIST: Threat
• Vulnerability: what weakness in a system, process or control could be exploited or triggered? Examples include incorrect permissions, unpatched software or missing necessary review. NIST: Vulnerability
• Risk: how much harm could arise in a particular context? Assessment normally considers both likelihood and impact. NIST: Risk

Distinguish the threat source from the event: a malicious person is a source; unauthorized reading is a possible event.

2. When is this useful?

These concepts support system inventories, patch prioritization, sharing-permission reviews and decisions about which defenses to fund first.

Specify the system boundary, data purpose, normal users and assessment period. The same weakness in public teaching materials and private answers may have different consequences. Risk is not just a count of vulnerabilities, and a scanner's severity rating is not automatically the organization's actual risk.

3. Connecting CIA to the Northstar platform

This is a fictional tabletop scenario. No real platform was operated.

Northstar stores students' private answers. Only each student and the teacher should be able to read them, but the folder is mistakenly set to allow anyone with its link to read it.

• Asset: private answer data.
• Threat event: an unauthorized person obtains the link and reads the answers.
• Vulnerability: sharing permissions exceed the intended scope.
• Potential impact: disclosure harms confidentiality and student privacy.
• Risk assessment: consider how easily the link could spread, who might obtain it, data sensitivity and the effectiveness of existing controls.

Incorrect permissions can be a confirmed vulnerability. Claiming that someone already read the data requires additional evidence such as access records. These are different conclusions.

4. How should controls be selected?

Correct the sharing scope, then use authorized test identities to verify that unauthorized readers are denied while students and teachers can still do necessary work. Reduce unnecessary retained data and inspect appropriate access logs.

Different controls can reduce likelihood or limit harm. Likelihood times impact can support reasoning, but it is not an invariably precise multiplication formula. Explain the scales, evidence and uncertainty used in the assessment.

5. How should evidence be interpreted?

Record separately:

• Observation: which identities do the current permissions allow?
• Inference: what harm could this configuration cause?
• Verification: which accesses succeed or fail at the stated time and under the stated test conditions?

Other risks may remain after correction: data might already have been copied. Risk remaining after controls are implemented is called residual risk. A configuration change does not establish zero risk.

Quick check

Quick check: a private-answer folder mistakenly allows anyone with its link to read it, but no access records from strangers have been found.

Identify one asset, one vulnerability and one possible threat event. Can you already conclude that data was stolen? Why?