🔄 Topic

Understanding how data moves through an enterprise network from user action to application response.

🎯 Goal

Build a visual and practical mental model of the major components inside an enterprise network.

🛠 What I Did

Today I focused on the bigger picture of enterprise network architecture.

After studying protocols, firewalls, VPNs, proxy servers, NAT, DNS, and security zones, I wanted to understand how everything connects.

The question was:

When a user types something into a laptop and gets a response back, what does the data actually pass through?

A simplified flow looks like this:

user
    ↓
laptop or workstation
    ↓
local network
    ↓
switch
    ↓
router or firewall
    ↓
DNS resolution
    ↓
proxy or secure web gateway
    ↓
internet or cloud service
    ↓
application server
    ↓
database or backend service
    ↓
response returns to user

In a real enterprise, this can also include:

  • identity provider
  • VPN concentrator
  • endpoint protection
  • EDR
  • SIEM
  • IDS or IPS
  • load balancer
  • web application firewall
  • cloud services
  • logging pipeline
  • data loss prevention
  • email security gateway
  • backup systems
  • privileged access management

🔗 Key Cybersecurity Connections

This matters because attackers can target any part of the path.

A SOC analyst needs to understand where evidence may exist.

For example:

  • endpoint logs show process execution
  • DNS logs show domain lookups
  • proxy logs show web requests
  • firewall logs show allowed or blocked connections
  • VPN logs show remote access
  • identity logs show authentication
  • server logs show application behavior
  • cloud logs show API activity
  • SIEM correlates events from multiple sources

If I do not understand the architecture, I may not know where to look.

A user may report:

The application is slow.

The issue could be:

  • endpoint problem
  • DNS problem
  • proxy issue
  • firewall block
  • application server failure
  • database latency
  • authentication failure
  • network congestion
  • attack traffic

Architecture gives investigation structure.

🔍 Investigation Questions

  • Where does the data start?
  • Which device generated the request?
  • Was DNS resolution successful?
  • Did the request pass through a proxy?
  • Did the firewall allow or block it?
  • Was authentication required?
  • Which application server received the request?
  • Did the backend or database respond?
  • Where are logs collected?
  • Which security tools inspected the traffic?
  • At which layer did the failure or suspicious behavior occur?

🚨 Detection Opportunities

Possible detection ideas:

  • endpoint process makes unusual outbound connection
  • DNS query to suspicious domain
  • proxy request to blocked category
  • firewall denies unexpected traffic
  • VPN login from unusual location
  • identity provider flags risky login
  • web application firewall detects attack payload
  • database receives unusual query volume
  • cloud API call from rare user or region
  • SIEM correlates endpoint and network alerts

Example investigation chain:

user opens attachment
    ↓
endpoint spawns PowerShell
    ↓
DNS lookup for rare domain
    ↓
HTTPS request through proxy
    ↓
firewall allows outbound traffic
    ↓
EDR alerts on suspicious command line

No single log tells the full story.

The investigation comes from connecting them.

🧭 MITRE ATT&CK Techniques

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

🗺 Visual Investigation Diagram

User / Endpoint
    ↓
Switch / Local Network
    ↓
DNS
    ↓
Firewall / Proxy
    ↓
Internet / Cloud
    ↓
Application Server
    ↓
Database / Backend
    ↓
Logs collected into SIEM

⚠ Challenges

The main challenge was that enterprise networks are not simple.

A home network may have only a router, a few devices, and an internet connection.

An enterprise network has many control points and monitoring layers.

Another challenge is that data can take different paths depending on the service.

For example:

  • internal application
  • SaaS application
  • VPN access
  • cloud workload
  • email delivery
  • remote desktop session

Each path creates different evidence.

📚 What I Learned

I learned that network architecture is an investigation map.

If I understand the path, I can decide which logs matter.

If I do not understand the path, I may waste time checking the wrong system.

This is why diagrams are useful for SOC work.

They turn invisible traffic into something I can reason about.

➡ Next Steps

  • Draw a simplified enterprise network diagram
  • Label where logs are generated
  • Label where attacks can happen
  • Connect each device or service to a SOC data source
  • Study how SIEM tools collect logs from different systems
  • Build a simple “data journey” diagram for my portfolio

🧠 Reflection

This helped me connect many separate concepts.

Protocols, DNS, firewalls, proxies, VPNs, and logs are not isolated topics.

They are parts of one system.

Understanding the system makes investigation easier.

🧩 Lessons Learned

What worked

Thinking about the journey of data from user action to response.

What broke

Seeing network tools as separate boxes instead of connected systems.

Why it broke

I was learning components before understanding the full flow.

Fix / takeaway

Always ask where the data starts, where it ends, and what controls inspect it along the way.

📈 Skill Progression Context

This builds the architecture awareness required for SOC analysis.

A SOC analyst needs to know where telemetry comes from and how different systems fit together.

Without that, alerts become isolated facts instead of part of an investigation.

😄 TL;DR

The internet is not magic.

It is a long chain of devices saying:

“You may pass.”