🔄 Topic

Studying how frameworks and controls help organizations reduce risk and how audits turn vague concerns into evidence.

🎯 Goal

Understand how to connect frameworks, controls, CIA impact, OWASP principles, and audit findings to practical security review.

🛠 What I Did

Today I continued Course 2 — Play It Safe: Manage Security Risks and focused on frameworks, controls, the CIA triad, NIST frameworks, OWASP security principles, and security audits.

The key idea was that security should not depend on random effort. Frameworks provide structure. Controls provide protective measures. Audits test whether those measures exist and work.

🔗 Key Cybersecurity Connections

Controls are only useful if they reduce a real risk.

Examples:

MFA reduces risk from stolen passwords.
Least privilege reduces damage from account compromise.
Logging improves investigation and accountability.
Backups reduce ransomware impact.
Input validation reduces web application injection risk.

A security audit is basically an evidence check. It asks whether the expected controls are present, configured correctly, and documented.

🔍 Investigation Questions

  • What framework or control applies to this system?
  • Which part of the CIA triad does the control protect?
  • Is the control preventive, detective, or corrective?
  • What evidence proves the control exists?
  • What evidence proves the control is working?
  • Is the finding about policy, configuration, monitoring, or user behavior?
  • What is the business impact if this control fails?

🚨 Detection Opportunities

Possible detection/control checks:

  • user account without MFA
  • privileged account used outside normal pattern
  • missing logs from critical system
  • firewall rule exposing remote admin service
  • public web input generating server errors
  • backup deletion or backup job failure

Example audit-style note:

control=MFA
system=remote_access_vpn
status=missing_for_3_users
risk=credential_theft_leads_to_remote_access
recommendation=enforce_mfa_for_all_vpn_users

🧭 MITRE ATT&CK Techniques

Possible mappings when behavior is observed:

  • T1078 — Valid Accounts
  • T1098 — Account Manipulation
  • T1190 — Exploit Public-Facing Application
  • T1490 — Inhibit System Recovery
  • T1562 — Impair Defenses

🗺 Visual Investigation Diagram

Framework
    ↓
Control objective
    ↓
System configuration
    ↓
Evidence collected
    ↓
Finding
    ↓
Recommendation

⚠ Challenges

The challenge is that frameworks can become box-ticking. A control checklist is not enough if nobody understands the risk behind each control.

The professional version connects every finding to impact and evidence.

📚 What I Learned

I learned that audits are not just compliance paperwork. A good audit can reveal missing controls before an incident happens.

➡ Next Steps

  • Create a small security audit template
  • Write findings using evidence, risk, and recommendation format
  • Map common controls to CIA impact
  • Review OWASP principles as web security controls

🧠 Reflection

This was useful because it bridges SOC work and GRC-style thinking. Even if I am aiming for technical roles, I need to explain why controls matter.

🧩 Lessons Learned

What worked

Writing controls as risk-reduction mechanisms.

What broke

Thinking of frameworks as only compliance theory.

Why it broke

Frameworks are weak if not tied to actual systems and evidence.

Fix / takeaway

For every control, identify the risk it reduces and the log/configuration that proves it.

📈 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

A control is not a checkbox. It is a risk reduction mechanism.