🔄 Topic

Consolidating network protocol knowledge into a practical SOC investigation mindset.

🎯 Goal

Move beyond memorizing protocols and ports, and start thinking about how network activity becomes evidence during security investigations.

🛠 What I Did

Today I used the recent Google Cybersecurity Certificate material as a consolidation day.

Instead of adding more protocol names, I focused on how to think like an analyst when looking at network activity.

The key shift was:

protocol knowledge
    ↓
traffic interpretation
    ↓
investigation questions
    ↓
detection logic
    ↓
incident explanation

A port number is useful, but it is not enough.

For example:

TCP 22 = SSH

That tells me the service.

It does not tell me whether the activity is normal, suspicious, malicious, authorized, or accidental.

A stronger investigation needs context:

  • source IP
  • destination IP
  • protocol
  • port
  • user
  • hostname
  • time
  • action
  • frequency
  • success or failure
  • what happened before
  • what happened after

🔗 Key Cybersecurity Connections

SOC analysts do not just identify protocols.

They interpret behavior.

Example:

One SSH login from an admin workstation during business hours
    ↓
probably normal

500 failed SSH logins from one external IP in 10 minutes
    ↓
possible brute force

DNS queries to a normal business domain
    ↓
probably normal

long random-looking DNS queries every 30 seconds to a rare domain
    ↓
possible malware beaconing or DNS tunneling

HTTPS traffic to a known SaaS service
    ↓
probably normal

HTTPS traffic from PowerShell to a rare external IP after a suspicious document opened
    ↓
possible payload download or command-and-control

The protocol is the starting point.

The behavior is the evidence.

🔍 Investigation Questions

  • What is the protocol?
  • What is the port?
  • Is the port expected for this service?
  • Is this protocol normal for this host?
  • Is the source expected?
  • Is the destination expected?
  • Is the timing normal?
  • Is the volume normal?
  • Is this a single event or a pattern?
  • Was authentication involved?
  • Did the connection succeed or fail?
  • What process generated the traffic?
  • Did any endpoint alert happen near the same time?

🚨 Detection Opportunities

Possible detection ideas:

  • many failed connections to the same service
  • rare protocol use from a workstation
  • internal host connecting to many destinations
  • unusual outbound traffic after suspicious process execution
  • DNS queries with abnormal length or randomness
  • repeated traffic at fixed intervals
  • cleartext protocols used where encryption is expected
  • administrative protocols used by non-admin systems
  • traffic to newly observed external infrastructure

Example detection pattern:

host=WORKSTATION-12
process=powershell.exe
destination_port=443
destination_seen_first_time=true
parent_process=winword.exe
suspicion=suspicious_outbound_connection

Even though the port is 443, the context makes it suspicious.

🧭 MITRE ATT&CK Techniques

  • T1046 — Network Service Discovery
  • T1071 — Application Layer Protocol
  • T1021 — Remote Services
  • T1105 — Ingress Tool Transfer
  • T1041 — Exfiltration Over C2 Channel

🗺 Visual Investigation Diagram

Raw network event
    ↓
Identify protocol and port
    ↓
Add source and destination context
    ↓
Check frequency and timing
    ↓
Correlate with endpoint or identity logs
    ↓
Decide if behavior is normal or suspicious

⚠ Challenges

The main challenge was avoiding shallow memorization.

Knowing that DNS uses port 53 is useful.

But in a SOC, the more important skill is recognizing suspicious DNS behavior.

Another challenge is remembering that ports can mislead.

Attackers often use common ports such as 80 and 443 because those ports blend into normal web traffic.

So the port alone cannot be trusted as the full explanation.

📚 What I Learned

I learned that protocol knowledge becomes valuable only when connected to behavior.

A protocol tells me what kind of communication may be happening.

Logs tell me who, where, when, and how often.

Correlation tells me whether the event matters.

This is the difference between course memorization and operational investigation.

➡ Next Steps

  • Turn protocol notes into investigation questions
  • Build fake log examples for SSH, DNS, HTTP, and VPN
  • Practice identifying suspicious patterns from normal-looking ports
  • Learn how proxy, firewall, and DNS logs complement each other
  • Continue building SOC-style notes instead of simple flashcards

🧠 Reflection

This was a useful bridge day.

I can feel the learning moving from “what is this protocol?” toward “what does this activity mean?”

That is the direction I need for SOC work.

🧩 Lessons Learned

What worked

Reframing ports and protocols as evidence.

What broke

Thinking memorization alone was enough.

Why it broke

SOC work requires context, patterns, and correlation.

Fix / takeaway

For every network event, ask:

Is this expected behavior for this source, destination, user, and time?

📈 Skill Progression Context

This supports the transition from beginner networking knowledge to practical SOC triage.

A job-ready analyst needs to read traffic fields and explain what they suggest in real operational language.

😄 TL;DR

A port tells you what door was used.

SOC analysis asks who used it, why, and whether they should have.