Network Diagrams & Data Flows — Interpret basic network diagrams and data flows

Long before the term "cybersecurity" entered the lexicon, engineers needed systematic ways to represent the interconnection of computing devices and the movement of information between them. The earliest computer networks of the 1960s were small enough that an engineer could hold the entire topology in mind, but as the ARPANET expanded and organizations deployed their own local area networks, informal sketches gave way to formalized network diagrams — standardized visual representations of nodes, links, and the protocols binding them together. In parallel, software engineers developed data flow diagrams (DFDs) as a structured analysis technique for understanding how information enters, is processed by, and exits a system. Together, these two diagram families form the visual backbone of network security analysis, enabling practitioners to identify trust boundaries, single points of failure, and potential attack surfaces long before a single packet is sniffed.

The central question these diagrams address is deceptively simple: What talks to what, over which path, carrying which data, and who can observe or modify that data in transit? Answering this question visually rather than textually enables faster pattern recognition, more effective communication among multidisciplinary teams, and — critically for security — the identification of trust boundary crossings where threats concentrate.

Before diving into specific diagram types, it is essential to internalize several foundational ideas that govern how network professionals and security analysts create and interpret these visual artifacts. A diagram is only as useful as the conventions it obeys; ambiguity in notation leads directly to ambiguity in security analysis.

The diagram above follows a layered layout convention widely used in security architecture reviews. Traffic originating from the Internet must pass through Firewall 1 before reaching any DMZ service. If a DMZ server needs to query the internal database, that request must traverse Firewall 2 — which enforces a far more restrictive policy (e.g., only TCP 3306 from the web server's IP to the database). Notice that the directed arrows make it immediately clear which direction initiation of connections is allowed; an analyst can spot, at a glance, that the database should never initiate outbound connections to the Internet.

Reading a topology diagram for security purposes involves scanning every edge and asking: Is this connection necessary? Is the data encrypted in transit? Could an attacker who compromises one node use this link to pivot laterally? These questions are far easier to answer visually than by combing through router ACLs or firewall rule tables.

While a network topology diagram answers "what physical or logical connections exist," a data flow diagram (DFD) answers "what data moves where, processed by whom, and stored how." DFDs use a deliberately minimal set of four symbol types, making them straightforward to draw and to analyze for threat modeling. The notation most commonly used in security contexts derives from the Yourdon–DeMarco convention, though the Gane–Sarson variant (rectangles with rounded corners for processes) is also common.

The Four DFD Elements

Decomposition Levels

DFDs are hierarchical. A Level 0 (context) diagram depicts the entire system as a single process, surrounded by external entities and the data flows connecting them. This provides the highest-level view, ideal for executive briefings and initial threat modeling. A Level 1 diagram decomposes that single process into its major sub-processes and internal data stores, revealing how data is routed internally. Further decomposition into Level 2 and beyond is performed selectively, typically only for high-risk sub-processes. The rule of thumb in security analysis is to decompose until every trust boundary crossing is visible and every process handling sensitive data is explicitly represented.

Examining this DFD from a security perspective reveals several critical analysis points. First, the "credentials" flow from User to P1 crosses the trust boundary — this flow must use TLS encryption (HTTPS) to prevent eavesdropping. Second, P1's lookup to D1 (User DB) should use parameterized queries to prevent SQL injection. Third, the session token stored in D2 is a high-value target; if an attacker gains access to the Session Store, they can hijack any active session. Fourth, P3's audit log provides a detective control — but only if the log itself is tamper-resistant and stored with appropriate access controls. Each of these observations emerges naturally from reading the diagram's flows and boundary crossings.

Reading Strategy for DFDs

1. Enumerate all external entities — these are the entry and exit points of the system and the primary sources of untrusted input.
2. Trace each data flow — follow every arrow from source to destination. Ask: What type of data does this carry? Is it sensitive (PII, credentials, tokens)?
3. Identify trust boundary crossings — every arrow that crosses a dashed boundary is a candidate for authentication, authorization, encryption, and input validation.
4. Examine data stores — for each store, determine what data it holds, who can read from it, who can write to it, and whether the data is encrypted at rest.
5. Apply threat categories — use a framework like STRIDE to systematically assess each element and flow for relevant threats.

Consider the Level 1 DFD from Section 5. A security analyst is asked to enumerate threats for the login subsystem using the STRIDE framework. Below is a systematic walkthrough of how to interpret the diagram and produce actionable security findings.

No single diagram type provides a complete security picture. Understanding the strengths and limitations of network topology diagrams versus data flow diagrams — and when to use each — is essential for effective security analysis.

The network diagrams and DFDs covered in this lesson form the input artifacts for more sophisticated security methodologies. Understanding these diagrams is a prerequisite for advanced frameworks used in industry and research.

The shift toward Zero Trust Architecture is particularly noteworthy because it fundamentally challenges the perimeter-based trust model depicted in traditional three-zone topology diagrams. In a zero-trust paradigm, every data flow — whether it crosses a traditional trust boundary or not — is treated as potentially hostile. This means the DFD becomes even more critical, since the analyst must annotate every flow with its authentication mechanism, encryption status, and authorization policy, not just those at the perimeter. Future coursework in this area will build directly on the diagramming skills developed in this lesson.