🔄 Topic

Using cybersecurity history, common attacks, attacker motivation, and security domains as a map for real-world defensive work.

🎯 Goal

Connect broad attack categories to business impact and understand why security domains help analysts classify incidents.

🛠 What I Did

Today I continued Course 1 — Foundations of Cybersecurity and focused on how cybersecurity evolved as computers, networks, and the internet became part of business operations.

The course material covered past and present attacks, common attack types, attacker motivation, and the CISSP security domains.

Rather than memorizing historical examples as trivia, I focused on the recurring patterns: attackers steal credentials, exploit exposed systems, trick users, disrupt availability, abuse trust, and target valuable data.

🔗 Key Cybersecurity Connections

A SOC analyst needs to explain why an alert matters. Naming an attack is not enough.

Example:

Alert: many failed VPN logins
Weak explanation: brute force attack
Stronger explanation: repeated failed VPN logins may indicate credential attack activity against remote access. If successful, valid account access could allow internal access without malware.

This connects technical evidence to business risk.

The security domains also help organize alerts. A suspicious login is identity. A malicious process is endpoint. A blocked exploit attempt may be network or application security. A suspicious storage access event may involve cloud or data security.

🔍 Investigation Questions

  • What asset or account was affected?
  • Which security domain does the alert belong to?
  • Was confidentiality, integrity, or availability affected?
  • Was the activity caused by a user, attacker, misconfiguration, or outage?
  • Which control should have reduced the risk?
  • Which team owns the affected asset?
  • What evidence proves impact rather than only suspicion?

🚨 Detection Opportunities

Detection ideas by impact:

  • confidentiality: unusual access to sensitive files or databases
  • integrity: unexpected modification of critical files or configurations
  • availability: traffic floods, service crashes, or repeated connection failures
  • identity: failed logins followed by success
  • endpoint: unusual parent-child process chains

Example:

user=j.smith
failed_logins=28
success_after_failures=true
source_country=rare
affected_service=VPN
risk=possible_valid_account_access

🧭 MITRE ATT&CK Techniques

Possible mappings depending on confirmed behavior:

  • T1110 — Brute Force
  • T1078 — Valid Accounts
  • T1190 — Exploit Public-Facing Application
  • T1486 — Data Encrypted for Impact
  • T1498 — Network Denial of Service

🗺 Visual Investigation Diagram

Security event
    ↓
Attack pattern
    ↓
Affected asset
    ↓
Security domain
    ↓
CIA impact
    ↓
Business impact

⚠ Challenges

The difficult part is not learning the words. The difficult part is avoiding shallow labels.

If I write only ‘DDoS’ or ‘ransomware’, I have not explained the operational impact. A professional note should explain what was affected, what evidence exists, and why the organization should care.

📚 What I Learned

I learned to treat attack history as a pattern library. The names change, tools evolve, but many attacker objectives repeat: access, persistence, theft, disruption, and extortion.

➡ Next Steps

  • Create an attack table with columns for evidence, affected asset, CIA impact, and likely controls
  • Map common alerts to security domains
  • Practice writing business-impact statements
  • Avoid using attack labels without evidence

🧠 Reflection

This helped me connect broad foundation material to the kind of writing expected from analysts. A good analyst does not just identify the alert. They explain what it means.

🧩 Lessons Learned

What worked

Grouping attacks by business impact.

What broke

Attack names alone are too shallow.

Why it broke

A label does not explain affected assets, controls, or urgency.

Fix / takeaway

Write every incident in terms of evidence, impact, and response priority.

📈 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

Attack history is useful when it becomes a pattern library, not trivia.