🔄 Topic

Beginning Course 2 by separating threats, vulnerabilities, and risks, then connecting them to structured risk management.

🎯 Goal

Learn to write about security problems precisely instead of mixing up basic risk terms.

🛠 What I Did

Today I started Course 2 — Play It Safe: Manage Security Risks.

The material focused on security domains, threats, risks, vulnerabilities, business impact, and the NIST Risk Management Framework.

The most important correction is simple but critical:

Threat = something that can cause harm
Vulnerability = weakness that can be exploited
Risk = likelihood and impact if the threat exploits the weakness

This distinction matters in professional writing.

🔗 Key Cybersecurity Connections

A SOC analyst needs precise language.

Weak statement:

The risk is a hacker.

Better statement:

The threat is external credential attack activity. The vulnerability is weak remote-access authentication. The risk is unauthorized VPN access leading to internal network exposure.

This is much clearer for escalation because it separates actor, weakness, and business concern.

🔍 Investigation Questions

  • What is the threat?
  • What vulnerability or weakness makes the threat realistic?
  • What asset is exposed?
  • What is the likely impact?
  • What existing control should reduce the risk?
  • Is the control missing, weak, bypassed, or misconfigured?
  • What evidence confirms the risk is active rather than theoretical?

🚨 Detection Opportunities

Detection examples:

  • repeated failed logins against VPN
  • successful login after many failures
  • administrative login from rare source IP
  • exposed service discovered by external scanner
  • vulnerable software version on internet-facing host

Example:

threat=credential_attack
vulnerability=no_mfa_on_vpn
evidence=failed_logins_followed_by_success
risk=unauthorized_remote_access

🧭 MITRE ATT&CK Techniques

Possible mappings:

  • T1110 — Brute Force
  • T1110.003 — Password Spraying
  • T1078 — Valid Accounts
  • T1046 — Network Service Discovery
  • T1190 — Exploit Public-Facing Application

🗺 Visual Investigation Diagram

Threat
    ↓
Vulnerability
    ↓
Asset exposure
    ↓
Risk
    ↓
Control
    ↓
Evidence

⚠ Challenges

The challenge is that beginners often use threat, vulnerability, and risk interchangeably. That creates sloppy reports.

In real security work, imprecise wording can cause bad prioritization.

📚 What I Learned

I learned that risk language is not bureaucratic fluff. It is how analysts explain why an event matters and what should be fixed.

➡ Next Steps

  • Build a threat-vulnerability-risk table
  • Apply this structure to phishing, VPN brute force, exposed RDP, and weak passwords
  • Practice writing findings in precise risk language
  • Connect risks to controls and evidence

🧠 Reflection

This is the kind of foundational writing skill that makes reports more professional. It also helps avoid overreacting to harmless events or underreacting to meaningful ones.

🧩 Lessons Learned

What worked

Separating threat, vulnerability, and risk.

What broke

Using one security word to mean everything.

Why it broke

Sloppy terms hide the actual weakness and impact.

Fix / takeaway

Write findings as: threat + vulnerability + asset + impact + evidence.

📈 Skill Progression Context

This supports my SOC analyst and detection engineering progression because it turns course material into investigation habits: identifying assets, reading evidence, asking better questions, and explaining security risk clearly.

Instead of treating the certificate as passive study, I am using each topic to build practical analyst thinking that can later become lab notes, detections, diagrams, or portfolio writeups.

😄 TL;DR

Threat is the danger. Vulnerability is the weakness. Risk is what happens if they meet.