🔄 Topic

Practicing how to turn technical network evidence into a clear incident summary.

🎯 Goal

Learn how to explain a technical issue using evidence, not guesses.

🛠 What I Did

Today I focused on the reporting side of SOC work.

After studying protocols, network paths, attack surfaces, and security roles, I wanted to connect that knowledge to incident writing.

A SOC analyst does not only investigate.

They also need to explain.

A weak incident summary sounds like this:

The website was broken.

A stronger incident summary sounds like this:

The client attempted to query the DNS server over UDP port 53 but received an ICMP port unreachable response, suggesting the DNS service or path to the DNS service was unavailable.

The second version is better because it includes:

  • source behavior
  • protocol
  • port
  • response
  • likely failure point
  • evidence-based reasoning

This is the difference between opinion and analysis.

🔗 Key Cybersecurity Connections

Incident reports matter because other people depend on them.

A good report helps:

  • IT teams fix the issue
  • managers understand impact
  • incident responders reconstruct timelines
  • security teams improve detections
  • auditors review what happened
  • future analysts learn from the case

Bad reports create confusion.

They may be too vague, too emotional, or too certain without evidence.

A SOC analyst needs to write with precision.

Useful structure:

What happened?
When did it happen?
Who or what was affected?
What evidence supports the conclusion?
What is the likely cause?
What actions were taken?
What should happen next?

🔍 Investigation Questions

  • What was the user-facing symptom?
  • What was the first observable technical failure?
  • Which protocol was involved?
  • Which source and destination were involved?
  • What did the response show?
  • Was the event isolated or widespread?
  • What logs support the conclusion?
  • What is known?
  • What is still unknown?
  • What is the most likely cause?
  • What should be checked next?

🚨 Detection Opportunities

Possible detection and reporting improvements:

  • alert on repeated protocol failures
  • track DNS query failures
  • monitor ICMP unreachable responses
  • alert on service ports becoming unreachable
  • detect repeated failed connections to critical infrastructure
  • correlate user reports with network telemetry
  • build dashboards for DNS, VPN, proxy, and firewall errors
  • create templates for common incident summaries

Example evidence statement:

observed_protocol=UDP
destination_port=53
response=ICMP_port_unreachable
likely_failure=DNS_service_or_path_unavailable

This gives the report a clear technical basis.

🧭 MITRE ATT&CK Techniques

No MITRE ATT&CK technique should be forced unless malicious behavior is confirmed.

This is important.

Not every incident is an attack.

Some incidents are outages, misconfigurations, or service failures.

If malicious activity is later confirmed, possible areas may include:

  • T1498 — Network Denial of Service
  • T1499 — Endpoint Denial of Service
  • T1071 — Application Layer Protocol

But evidence must come first.

🗺 Visual Investigation Diagram

User symptom
    ↓
Technical evidence
    ↓
Protocol and port identified
    ↓
Response or error reviewed
    ↓
Likely cause written
    ↓
Next action recommended

⚠ Challenges

The main challenge is avoiding assumptions.

A user report is not the same as root cause.

For example:

I cannot access the website

could mean:

  • DNS failed
  • web server is down
  • firewall blocked traffic
  • proxy issue
  • certificate issue
  • local device problem
  • routing issue
  • application error

The analyst must follow the evidence.

Another challenge is not overusing attack labels.

If the evidence only shows a service failure, calling it an attack is sloppy.

📚 What I Learned

I learned that good incident writing is a security skill.

It forces clear thinking.

If I cannot explain the evidence, I probably do not fully understand the incident.

Strong reports avoid vague language and separate:

  • facts
  • assumptions
  • likely causes
  • unknowns
  • recommended actions

➡ Next Steps

  • Practice writing short incident summaries
  • Use protocol evidence in explanations
  • Separate symptoms from root cause
  • Avoid forcing MITRE mappings without evidence
  • Build a reusable incident report template
  • Apply this to the DNS and ICMP traffic activity

🧠 Reflection

This was a practical preparation day.

The technical knowledge matters, but being able to communicate it matters too.

SOC work is not only finding evidence.

It is explaining evidence clearly enough that someone can act on it.

🧩 Lessons Learned

What worked

Turning technical observations into structured incident language.

What broke

Trying to jump from symptom directly to conclusion.

Why it broke

Symptoms do not prove root cause.

Fix / takeaway

Write from evidence:

observed traffic → interpreted meaning → likely cause → next step

📈 Skill Progression Context

This supports SOC employability because analysts need to document investigations clearly.

Good writing improves triage, escalation, handoffs, and portfolio quality.

😄 TL;DR

Logs tell you what happened.

A good analyst explains why it matters without making stuff up.