Threat modeling is catching on. Increasingly organizations are realizing that securing DevOps projects as early as possible – preferably during the initial white boarding – not only reduces risk, it makes good business sense. For some time now agile DevOps workflows have included static and dynamic scans, issue tracking, and other tools to help ensure coding is secure. More recently organizations have been looking for ways to “left-shift,” automate, and more fully integrate security into existing DevOps workflows – hence the rise of Rugged DevOps and DevSecOps. Yet nothing is as efficient or as effective for securing the development lifecycle as threat modeling with architecturally-based process flow diagrams.
Traditional threat modeling relies on data flow diagrams (DFD) to generate a list of potential threats. However, most DFD-based threat modeling methodologies can – at best – only enumerate potential threats “categorically,” and then, only if an where the threat model indicates a data flow. One of the drawbacks of such methods is that potential threats to the modern organizational cyber environment do not neatly fall into an arbitrary classification scheme, nor are all threats caused by data flows. For example, consider the APT threat actor utilizing spear phishing, insider threats caused by disgruntled or compromised employees, and CVEs caused by insecure coding.
Moreover, traditional DFD-based threat modeling is inextricably related to its system engineering roots from the 1970s. Engineering provides two highly useful purposes: (1) figure out how to make things work, and (2) find a solution when things are not working. Understandably, then, early attempts at threat modeling turned to the field of engineering to find a solution to the problem of threat actors getting in the system. The downside, though, is that engineering is significantly biased toward the users’ legitimate perspective. DFD-based threat modeling, therefore, looks at threats and vulnerabilities from security’s perspective – as problems to be solved. Adopting engineering-based approaches to threat modeling, however, keeps security in the dark about how threat actors think and approach the cyber system.
Architecturally-Based Process Flow Diagrams Provide Needed Understanding
All threat modeling exists to enumerate potential threats. However, without understanding the organization’s threat actors, the enumerated list is meaningless. Threats are only a priority if there exists some agent or agency willing and able to utilize them. Flat tires on your car, for example, are a potential threat to a commuter’s timely arrival at the office – but only if you’re driving your car. If you walk to work, the potential threat of flat tires can never be realized.
Whereas DFDs fundamentally look at the system from the perspective of the defenders, architecturally-based process flow diagrams (PFD) look at the system from the adversary’s perspective. Granted, PFDs will not make potential threats looks like opportunities to be explored and exploited – the way attackers see them. However, attackers do not approach the system upon which they’re doing recon from a “problems to be solved” or a “get it working” perspective. They approach your system architecturally – from a flow and function perspective.
Looking at an application or your entire cyber system with architecturally-based process flow diagrams is similar to looking at a building blueprint to determine where and how a thief or other attacker might strike – very useful for setting up a home security system. In the latter case, we assume the building structure will function equally well for the thief as it does for the legitimate occupants – the engineering is all good. However, what we need to know is how the attacker will get in, move through, and exit the structure with our valuables. That way we can determine the best way to set up our security system to stop the intrusion, or at least catch the criminal after the incident.
PFDs allow defenders to approach their systems from the same vantage point as attackers – architecturally – thereby providing exceptionally useful insight from which the organization can understand its unique attacker population.
Click here to schedule a live demo and learn about the benefits of ThreatModeler’s patent-pending, architecturally-based process flow diagrams.