What it means
A threat is a possible cause of harm, not necessarily an attacker. Malicious activity, human error, equipment failure, and environmental events can all threaten a service or its information. It helps to distinguish a threat source from a threat event: a criminal group is a source, while using stolen credentials to read records is an event.
A useful threat description connects that possible event to an asset and a consequence. Avoid stopping at labels such as “insider” or “ransomware.” Ask what could actually happen in this environment, which conditions make it plausible, and what evidence supports spending attention on it.
The idea at a glance / Foundations
Several possible causes. One service.
A threat can come from malicious action, human error, or the environment. Name the source, event, and possible loss instead of treating every threat as an attacker.
Fictional ParcelDesk dispatch planning. These are three separate possible scenarios, not an incident history. The dispatch service depends on its route data, configuration, and building power.
READ THE PICTURE
Read the distinction and scope
An intruder could delete routes using stolen admin access. An operator could publish a bad configuration. A power failure could stop the service if its alternate supply fails. Different causes can threaten the same delivery-coordination task.
Keep in mindNo scenario is shown as having occurred. Their relevance, likelihood, operating safeguards, and real consequences need local evidence; this picture supplies no priority ranking.
Read the complete example
- Read the distinction and scope. An intruder could delete routes using stolen admin access. An operator could publish a bad configuration. A power failure could stop the service if its alternate supply fails. Different causes can threaten the same delivery-coordination task. ParcelDesk is a fictional service used by dispatchers to coordinate deliveries from current route plans. The three cards are alternative possible threat scenarios, not stages in one incident and not events asserted to have occurred. In the malicious scenario, an intruder who has obtained valid route-administration access deliberately deletes the active route plan; dispatchers could lose the information needed to coordinate deliveries. Obtaining that access and the permission to delete are explicit prerequisites, not consequences established by the word intruder. In the accidental scenario, an operator with configuration authority publishes a configuration the service cannot use, interrupting planning. A software/configuration validation failure and lack of a working rollback are assumptions that would need checking. In the environmental scenario, loss of building power interrupts the service under the assumption that no working alternate supply keeps it running. Building power is a dependency; a failed primary supply need not cause a service loss when a tested alternative operates. Each scenario names a possible source or cause, event, and service consequence. A threat description differs from a weakness that enables it and from evidence of a completed incident. This comparison does not measure frequency, establish that these are ParcelDesk’s most important threats, or assess its actual safeguards.
No scenario is shown as having occurred. Their relevance, likelihood, operating safeguards, and real consequences need local evidence; this picture supplies no priority ranking.
Diagram references: NIST SP 800-30 Rev. 1 - threat sources and events
AN ILLUSTRATIVE SCENARIO
A council records office
A council stores important case records in a building with a history of basement flooding. The potential flood is a threat even though no malicious actor is involved. A separate threat scenario involves someone using a stolen staff account to download those records. The office assesses both scenarios, recognizing that physical storage choices and account permissions create different weaknesses. A single anti-malware product would not address both paths to harm.
Put it to work
- Identify the assets and service outcomes that matter, then consider malicious, accidental, technical, and environmental sources of disruption or misuse.
- Write plausible threat events with a clear action and consequence, using relevant local evidence and trustworthy external information.
- Connect each event to the conditions and weaknesses it could use, then assess likelihood, impact, and suitable safeguards with the asset owner.
How to check your work
Review a threat statement with someone who operates the service. They should understand the event, recognize the affected asset and consequence, and identify the evidence and assumptions behind its inclusion.
Connect the ideas
- Vulnerability
A weakness in a system, process, or person that makes a loss easier to cause.
- Exploit
A method or code that uses a vulnerability to cause an unauthorized effect.
- Risk
The potential for harm, assessed using what could happen, how likely it is, its impact, and what remains uncertain.
- Likelihood
How plausible it is that a threat will cause a loss in this environment, given exposure and evidence.