In part one we covered the three layers of network architecture — conceptual, logical, and physical. Working through those gives you a clear picture of what the network contains, what it does, and what depends on what. That foundation is what makes the next step possible: identifying who or what might threaten it, and why.
Security controls don’t exist in a vacuum. A firewall rule, an ACL, an access policy — each one is a response to a specific threat. If you’re deploying controls without first asking what you’re defending against and who might be attacking, you’re guessing. Threat identification turns that guesswork into a reasoned approach.
Mapping Data Flow
Before identifying threats, it helps to have a visual representation of how data moves through the environment. A Data Flow Diagram — DFD — does exactly that. It shows the external entities interacting with your systems, the processes handling data, the data stores holding it, and the flows connecting them. Critically, it also shows trust boundaries — the lines separating what you control from what you don’t.
In this diagram a user sends an HTTPS request to a web application. The application reads and writes to a database and file storage. The trust boundary — the dashed red line — separates the internal systems from the outside world. The user sits outside it. Everything inside is assumed to be under organizational control.
That boundary is where the interesting questions start. What crosses it? In what direction? Who initiates the connection? What happens if something on the outside sends malformed input? What if something on the inside is compromised and tries to exfiltrate data outward? The DFD makes those questions concrete rather than abstract.
From a control perspective, the trust boundary is where you’d start thinking about firewalls, ACLs, and input validation — controls at the perimeter between trusted and untrusted. But the internal flows matter too. The web application talking to the database is an internal flow, and if an attacker gains access to the application tier, unrestricted database access becomes a problem. Defense doesn’t stop at the perimeter.
Threat Agents
A threat agent is anyone or anything capable of exploiting a vulnerability. The tendency is to think of this as external hackers — and they’re certainly on the list — but the full picture is broader and in many cases the more dangerous threats come from inside the organization.
External Attackers
Opportunistic or targeted. Motivated by financial gain, espionage, or disruption. Usually the first threat that comes to mind but not always the most likely.
Malicious Insiders
Employees with legitimate access who misuse it intentionally. Harder to detect because their activity looks normal. Often motivated by financial incentive or grievance.
Negligent Insiders
Employees who don’t intend harm but create risk through poor practices — weak passwords, mishandling sensitive data, falling for phishing. Statistically the most common source of incidents.
Former Employees
Accounts not deprovisioned, credentials still valid, institutional knowledge of systems and processes. Access that persists after separation is a direct threat.
Executives & Privileged Users
Often have broad access and are frequently targeted by social engineering. Privilege without commensurate security controls is a significant risk surface.
Visitors & Contractors
Physical access to facilities, temporary network access, potentially unknown security posture. Third-party risk extends to anyone with a foot in the door.
Competitors
Motivated by corporate espionage — intellectual property, customer data, strategic plans. May operate through direct attack or through compromising a third party with access.
Nation-State Actors
Highly resourced, persistent, and patient. Relevant for critical infrastructure, government, and organizations with valuable intellectual property.
The point of this list isn’t to be exhaustive but to force the question: which of these are realistic threats to this specific environment? A small business isn’t a likely nation-state target. A healthcare organization absolutely needs to account for insider threats given the value of patient data. Context determines which threat agents deserve the most attention.
Once you know who the realistic threat agents are, control selection becomes logical rather than arbitrary. Defending against negligent insiders means security awareness training, MFA, and DLP. Defending against external attackers means perimeter controls, patching, and monitoring. Different threats call for different responses, and trying to address all of them equally leads to oversights and bloated security budgets.
In regulated environments many of these controls aren’t optional. Frameworks like HIPAA, PCI DSS, and NIST prescribe specific requirements based on the type of data handled and the threat landscape. That’s not a reason to skip threat identification. Compliance tells you the minimum. Threat modeling tells you if the minimum is enough.
Threat Identification in the Cloud
Cloud environments introduce a specific challenge: reduced visibility. On-premises, you own and operate every layer of the stack. In the cloud, the provider manages the physical infrastructure, the hypervisor, and in some cases the operating system and runtime. That’s the shared responsibility model — the provider secures the infrastructure, you secure everything you deploy on top of it.
What that means in practice is that traditional network visibility tools don’t apply the same way. You don’t see the physical network. You may not have full visibility into traffic between services unless you explicitly configure it. The boundary between your environment and others on the same infrastructure is managed by the provider, not by you.
This is where a DFD becomes even more valuable. Mapping data flows in a cloud environment forces you to identify what you actually control versus what the provider manages — and where your responsibility begins. That boundary is where your security posture needs to be strongest.
The controls shift but the principles don’t. In a cloud environment, hardening looks like:
- Network segmentation — VPCs, subnets, and routing rules that enforce separation between tiers the same way VLANs and ACLs do on-premises
- Perimeter controls — security groups, network firewalls, and WAFs controlling what traffic reaches your resources
- Identity and access management — least-privilege policies, role-based access, MFA enforcement, and regular access reviews. In the cloud, IAM is the perimeter
- Data protection — encryption at rest and in transit, DLP controls, and careful management of what data leaves your environment and where it goes
- Visibility — flow logs, audit trails, and monitoring to compensate for the physical visibility you’ve given up
Regulatory requirements follow you into the cloud. HIPAA, PCI DSS, and similar frameworks don’t have a cloud exemption — if your data is subject to those requirements on-premises, it’s subject to them in the cloud too. The shared responsibility model doesn’t transfer your compliance obligations to the provider.
One of the most common mistakes in cloud adoption is assuming that because the provider is handling infrastructure security, the organization’s security posture is improved. It may be — but only for the layers the provider manages. The layers you’re responsible for still need the same rigor, and in some cases more, because the attack surface is now internet-accessible by default.
Understanding your threat agents and mapping your data flows gives you the foundation for control selection that’s grounded in actual risk rather than convention. The next step is translating that into a security architecture — where controls go, what they protect, and how they layer.
