Information Security Threats and Risks
This domain tests whether you can separate three words candidates habitually blur - threat, vulnerability and risk - and whether you can choose a proportionate risk treatment. Expect scenario questions about malware, social engineering and insider behaviour, plus one simple risk calculation.
The vocabulary
- Threat: a potential cause of an unwanted incident - a person, group or natural event.
- Vulnerability: a weakness in an asset, control, process or design that a threat can exploit.
- Risk: the combination of likelihood and impact of a threat exploiting a vulnerability against an asset. No asset, or no vulnerability, means no risk.
- Qualitative risk uses a matrix (high/medium/low); quantitative risk uses money: SLE = asset value × exposure factor, ALE = SLE × annualised rate of occurrence.
Threat landscape
- Malware families: virus (needs a host and a user), worm (self-propagating over networks), trojan (disguised), ransomware (encrypts and extorts), spyware and keyloggers, rootkits, logic bombs, botnets.
- Social engineering attacks people, so technical controls alone fail: phishing, spear phishing, whaling (senior targets), vishing (voice), smishing (SMS), pretexting, baiting, tailgating.
- Insider threat may be malicious or accidental; accidental misconfiguration and misdirected email cause more incidents than nation-state attacks.
- Environmental and technical causes - fire, flood, power loss, hardware failure, software bugs - belong in the same risk register.
Risk treatment and appetite
- Four options per ISO/IEC 27005: reduce (controls), transfer (insurance, outsourcing - shared, not removed), avoid (stop the activity), accept (documented and signed by the risk owner).
- Residual risk always remains after treatment and must be formally accepted by management.
- Risk appetite is how much risk the organisation chooses to take; risk tolerance is the acceptable variation around it.
Worked example
An order database worth 500,000 has a 40% exposure factor per incident and the event is expected twice every four years. SLE = 200,000; ALE = 0.5 × 200,000 = 100,000. A monitoring control costs 30,000 a year and halves the occurrence rate, giving a new ALE of 50,000 - a 50,000 saving for 30,000 spend, so it is cost-effective. At 80,000 a year, transfer or accept would be the rational answer.
Traps that cost marks
- Calling a vulnerability a risk (an unpatched server is a vulnerability, not a risk).
- Implying transfer removes risk entirely; accountability stays with the organisation.
- Choosing the strongest control instead of the one whose cost sits below the loss it prevents.
- Assuming insider incidents are rare or always malicious.