🔄 Topic

Understanding which cybersecurity roles defend different parts of an enterprise environment.

🎯 Goal

Connect the technical attack surface to real cybersecurity job roles and responsibilities.

🛠 What I Did

Today I looked at cybersecurity from a roles-and-responsibilities perspective.

After mapping enterprise network components and weak points, the next question was:

Who actually defends each part?

Different cybersecurity roles focus on different layers.

Examples:

  • SOC analyst monitors alerts and investigates suspicious activity
  • incident responder contains and investigates confirmed incidents
  • detection engineer builds and tunes detection logic
  • network security engineer manages firewalls, segmentation, IDS, and IPS
  • endpoint security analyst focuses on EDR, malware, and host telemetry
  • identity security engineer focuses on MFA, access, roles, and authentication
  • cloud security engineer protects cloud accounts, workloads, storage, and APIs
  • application security engineer finds and fixes software vulnerabilities
  • GRC analyst focuses on governance, risk, compliance, and policy
  • threat intelligence analyst studies attacker behavior and campaigns
  • red team operator simulates realistic attacks
  • blue team defender detects and responds to attacks

This helped me understand how broad cybersecurity is.

🔗 Key Cybersecurity Connections

This matters because SOC work does not happen in isolation.

A SOC analyst may detect an issue, but other teams may own the fix.

Example:

SOC detects suspicious VPN login
    ↓
identity team reviews account controls
    ↓
network team checks VPN access
    ↓
endpoint team checks the device
    ↓
incident response coordinates containment
    ↓
GRC may document business risk

Good security depends on handoffs.

A weak handoff can delay response.

For example, detecting a vulnerable public application is useful, but someone still needs to patch or mitigate it.

🔍 Investigation Questions

  • Which security domain does this alert belong to?
  • Who owns the affected system?
  • Is this endpoint, network, identity, cloud, application, or data-related?
  • Does the SOC have enough information to triage it?
  • Does this need escalation?
  • Which team can contain the threat?
  • Which team can fix the root cause?
  • Is this a detection problem, control problem, or process problem?
  • Was the alert actionable?
  • Was the handoff clear?

🚨 Detection Opportunities

Detection is not only about technical rules.

It also depends on ownership.

Possible detection-to-role mapping:

  • suspicious PowerShell → endpoint / SOC / detection engineering
  • impossible travel login → identity / SOC
  • public exploit attempt → AppSec / SOC / network security
  • firewall rule change → network security / SOC
  • S3 bucket exposure → cloud security / GRC
  • phishing email → email security / SOC
  • data exfiltration → SOC / data security / incident response
  • ransomware behavior → endpoint / SOC / incident response
  • policy violation → GRC / security operations

Example handoff chain:

alert=suspicious_oauth_consent
triage_owner=SOC
technical_owner=identity_security
response_owner=incident_response
remediation=revoke_app_and_review_permissions

This makes the investigation operational, not theoretical.

🧭 MITRE ATT&CK Techniques

This post is more about defensive organization than a single attacker technique.

Relevant areas may include:

  • T1078 — Valid Accounts
  • T1059 — Command and Scripting Interpreter
  • T1190 — Exploit Public-Facing Application
  • T1041 — Exfiltration Over C2 Channel
  • T1486 — Data Encrypted for Impact

🗺 Visual Investigation Diagram

Alert generated
    ↓
SOC triage
    ↓
Domain owner identified
    ↓
Escalation or containment
    ↓
Root cause fixed
    ↓
Detection improved

⚠ Challenges

The main challenge was realizing that cybersecurity is not one job.

There are many branches.

Another challenge is understanding that SOC analysts need breadth.

They may not be experts in every domain, but they need enough knowledge to understand what they are seeing and who should handle it next.

A SOC analyst who cannot identify the affected domain will struggle to escalate properly.

📚 What I Learned

I learned that roles map to parts of the attack surface.

This gives me a better career mental model.

SOC work sits in the middle of many domains because alerts can come from everywhere:

  • endpoint
  • identity
  • network
  • cloud
  • application
  • email
  • data

That is why SOC analysts need practical fundamentals across many areas.

➡ Next Steps

  • Create a role map for cybersecurity branches
  • Learn common SOC escalation paths
  • Study how detection engineers write rules
  • Compare SOC analyst, detection engineer, and incident responder responsibilities
  • Link each role to logs and tools
  • Use this for career planning and portfolio structure

🧠 Reflection

This helped me understand where I am aiming.

SOC analyst and detection engineering work require broad technical awareness.

I do not need to become expert in every branch immediately.

But I do need to understand how the branches connect.

🧩 Lessons Learned

What worked

Mapping roles to the systems they defend.

What broke

Thinking of cybersecurity as one generic profession.

Why it broke

Different security roles own different risks, tools, and decisions.

Fix / takeaway

Learn SOC deeply, but understand enough of the surrounding domains to investigate and escalate correctly.

📈 Skill Progression Context

This supports career readiness.

Knowing the difference between security roles helps me target learning, build better portfolio projects, and explain my path clearly to recruiters or hiring managers.

😄 TL;DR

Cybersecurity is not one superhero.

It is a team of specialists trying to stop the same fire from different angles.