🔄 Topic

Starting Course 3 by building a practical mental model of network architecture and communication.

🎯 Goal

Understand how devices, networks, cloud systems, and TCP/IP layers fit into security investigations.

🛠 What I Did

Today I started Course 3 — Connect and Protect: Networks and Network Security.

The material covered network architecture, network components, cloud networks, network tools, the TCP/IP model, the OSI model, and how IP addresses support communication.

This is much more operational for SOC work because many alerts contain the same basic fields:

source IP
destination IP
protocol
port
timestamp
action
device or host

🔗 Key Cybersecurity Connections

Networking is the map that helps an analyst know where to look.

If I see this:

src_ip=10.0.1.25
dst_ip=8.8.8.8
protocol=UDP
dst_port=53

I should recognize likely DNS activity.

If I see:

src_ip=10.0.1.25
dst_ip=203.0.113.10
protocol=TCP
dst_port=443

I should recognize likely HTTPS traffic.

Without network fundamentals, firewall logs, DNS logs, proxy logs, and packet captures look like random numbers.

🔍 Investigation Questions

  • Where does the traffic start?
  • Where is it going?
  • Is the destination internal, external, private, public, or cloud-hosted?
  • Which protocol and port are involved?
  • Which network device would log this traffic?
  • Is this normal for the source host?
  • Did the traffic pass through firewall, proxy, VPN, or cloud controls?

🚨 Detection Opportunities

Detection opportunities:

  • workstation connecting to unusual external IP
  • internal host scanning many destinations
  • unexpected protocol on unusual port
  • DNS query followed by outbound HTTPS to rare domain
  • cloud workload communicating with unknown external host

Example:

host=workstation-22
src_ip=10.0.10.22
dst_ip=198.51.100.77
dst_port=4444
protocol=TCP
baseline=rare_destination
triage=review_process_and_dns_history

🧭 MITRE ATT&CK Techniques

Possible mappings:

  • T1046 — Network Service Discovery
  • T1071 — Application Layer Protocol
  • T1105 — Ingress Tool Transfer
  • T1021 — Remote Services

🗺 Visual Investigation Diagram

Endpoint
    ↓
Local network
    ↓
Switch / router
    ↓
Firewall / proxy
    ↓
Internet or cloud
    ↓
Application / service

⚠ Challenges

The challenge is not memorizing models as diagrams only. TCP/IP and OSI become useful when I can use them to locate evidence.

A failure at DNS is different from a failure at HTTP. A blocked firewall connection is different from an application error.

📚 What I Learned

I learned that network architecture gives structure to investigation. It tells me where data should travel and which devices may have logged it.

➡ Next Steps

  • Draw a simple enterprise network diagram
  • Label where DNS, firewall, proxy, VPN, and cloud logs appear
  • Practice reading source/destination/protocol/port fields
  • Connect each TCP/IP layer to evidence examples

🧠 Reflection

This is one of the areas where the certificate connects strongly with real SOC work. Network evidence appears everywhere.

🧩 Lessons Learned

What worked

Reading traffic fields as evidence.

What broke

Model diagrams are useless if I cannot connect them to logs.

Why it broke

SOC investigations need observable data, not abstract layers only.

Fix / takeaway

For each network layer, identify what log or packet evidence it can produce.

📈 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

Networking is the map. Logs are the footprints.