Week Introduction
Cybersecurity is risk management under uncertainty. You cannot eliminate all threats or patch all vulnerabilities. The professional skill is prioritizing what matters most — balancing likelihood, impact, and available resources.
This week integrates concepts from Weeks 1-4 into a unified risk framework. You will learn to distinguish threats from vulnerabilities, calculate risk, and make defensible prioritization decisions.
Learning Outcomes (Week 5 Focus)
By the end of this week, you should be able to:
- LO1 - Foundational Concepts: Define and distinguish threats, vulnerabilities, and risks using precise terminology
- LO4 - Risk Reasoning: Apply risk thinking to prioritize security decisions based on likelihood, impact, and exposure
- LO8 - Integration: Connect technical vulnerabilities to business risk (synthesis across weeks)
Lesson 5.1 · Threats: Sources of Potential Harm
Definition: A threat is any circumstance or event with the potential to cause harm to a system, organization, or individual. Threats represent what could happen, not what has happened.
Threat categories (by source):
-
Adversarial threats: Intentional actors with malicious intent
Examples: Nation-state hackers, cybercriminals, hacktivists, malicious insiders
Characteristics: Strategic, adaptive, motivated by specific goals (money, espionage, disruption) -
Accidental threats: Human error without malicious intent
Examples: Employee misconfigures cloud storage, admin deletes production database
Characteristics: Common, often preventable with training and controls -
Environmental threats: Natural events or infrastructure failures
Examples: Power outages, floods, fires, hardware failures
Characteristics: Unpredictable timing, require business continuity planning -
Structural threats: Inherent system design flaws
Examples: Software bugs, protocol weaknesses, architectural assumptions
Characteristics: Exist regardless of attacker presence, discovered over time
Threats exist independently of vulnerabilities. A nation-state hacking group (threat) exists whether your systems are vulnerable or not. Risk emerges when threat meets vulnerability.
Threat modeling questions:
- Who or what could cause harm? (Threat actor identification)
- What are they capable of? (Technical skill, resources, access)
- What motivates them? (Financial gain, espionage, ideology, accident)
- How likely are they to target this system? (Attractiveness, exposure)
Lesson 5.2 · Vulnerabilities: Exploitable Weaknesses
Definition: A vulnerability is a weakness in a system that could be exploited to cause harm. Vulnerabilities represent how harm could occur.
Vulnerability categories (by type):
-
Technical vulnerabilities: Flaws in software, hardware, or protocols
Examples: Buffer overflows, SQL injection, unpatched systems, weak encryption
Common Weakness Enumeration (CWE): Standardized list of software vulnerability types -
Configuration vulnerabilities: Insecure system settings
Examples: Default passwords, open ports, excessive permissions, missing encryption
Note: Often easier to exploit than code-level bugs (no 0-day needed) -
Operational vulnerabilities: Process and procedure weaknesses
Examples: No patch management, weak access reviews, missing monitoring, poor incident response
Impact: Enable attacks to persist undetected -
Human vulnerabilities: Social engineering susceptibility
Examples: Phishing success, credential reuse, insider threats (intentional or accidental)
Reality: Humans are often the weakest link in technical systems
Critical distinction: Vulnerability ≠ Risk
A vulnerability in isolation is just a weakness. It becomes a risk only when:
- A credible threat could exploit it (threat + vulnerability)
- Exploitation would cause meaningful harm (impact)
- The system is accessible to the threat (exposure)
Example: A web server has an unpatched critical vulnerability (CVE). Risk depends on:
- Is it internet-facing? (Exposure — high if public, low if internal-only)
- Is there a public exploit? (Threat capability — high if weaponized)
- What data does it protect? (Impact — high if customer PII, low if test environment)
Defender takeaway: Prioritize vulnerabilities based on exploitability, exposure, and impact — not just severity score. A "critical" CVE in an offline system may be lower priority than a "medium" CVE in an internet-facing payment processor.
Lesson 5.3 · Risk: The Intersection of Threat, Vulnerability, and Impact
Definition: Risk is the potential for loss or harm when a threat exploits a vulnerability. It is calculated as a function of likelihood and impact.
Risk formula (conceptual):
Risk = Likelihood × Impact
Where:
-
Likelihood: Probability that threat will exploit vulnerability
Factors: Threat capability, vulnerability exploitability, exposure, existing controls -
Impact: Magnitude of harm if exploitation succeeds
Factors: Asset value, business criticality, data sensitivity, regulatory consequences
Risk matrix (qualitative approach):
Example risk scenarios:
Example risk scenarios:
- Critical Risk: Internet-facing payment server with known RCE exploit (high likelihood) + stores credit card data (high impact) = Patch immediately
- Medium Risk: Internal dev server with XSS vulnerability (medium likelihood — requires authenticated insider) + contains test data only (low impact) = Schedule fix, not emergency
- Low Risk: Air-gapped system with buffer overflow (zero likelihood — no network access) + non-critical data (low impact) = Defer until next maintenance window
Key insight: Risk is contextual
The same vulnerability has different risk levels in different contexts. A SQL injection flaw is:
- Critical risk in production customer database
- Medium risk in internal employee directory
- Low risk in isolated test environment with no real data
Lesson 5.4 · Vulnerability Prioritization: Risk-Based Approach
Reality check: Organizations have thousands of known vulnerabilities. Attempting to fix them all wastes resources and delays fixing what actually matters.
Common mistake: CVSS score-based prioritization
Many organizations patch "critical" CVEs (CVSS 9.0+) first, regardless of context. This ignores exposure and impact:
- CVSS 9.8 in offline backup system = Low actual risk
- CVSS 6.5 in internet-facing authentication = High actual risk
Better approach: Risk-based prioritization
Prioritize based on the intersection of:
-
Exploitability:
- Is exploit code publicly available? (Weaponized CVEs are highest priority)
- Is it being actively exploited in the wild? (Threat intelligence feeds)
- How difficult is exploitation? (Authentication required? Physical access needed?)
-
Exposure:
- Is the vulnerable system internet-facing? (External > Internal)
- Who can reach it? (Anyone > Authenticated users > Admins only)
- Is it segmented from critical assets? (Blast radius analysis)
-
Impact:
- What data is at risk? (Customer PII > Employee data > Test data)
- What business function depends on it? (Revenue-generating > Support systems)
- Are there regulatory consequences? (HIPAA, PCI-DSS, GDPR fines)
Prioritization tiers:
- Tier 1 (Patch immediately): Internet-facing + weaponized exploit + high-value data
- Tier 2 (Patch this sprint): Internal systems + known exploit + medium impact
- Tier 3 (Schedule for next quarter): Low exposure + theoretical vulnerability + low impact
- Tier 4 (Accept risk): Air-gapped + no exploit + negligible impact
Real-world example: Equifax breach (2017)
Equifax had a known Apache Struts vulnerability (CVE-2017-5638) for months. It should have been Tier 1 priority:
- ✅ Internet-facing web application (maximum exposure)
- ✅ Public exploit code available within days (weaponized)
- ✅ Protected access to 143 million consumer records (catastrophic impact)
Failure to prioritize correctly = $700M+ in costs, reputational destruction, CEO resignation.