Threat modeling is catching on. Increasingly, organizations are coming to the realization that securing DevOps projects as early as possible – preferably during the initial whiteboard planning and design stages – 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 DevSecOps. Yet nothing is as efficient or as effective for securing the software development lifecycle – and more recently, the cloud development lifecycle (CDLC) – as threat modeling with architecturally-based process flow diagrams.
What is a Process Flow Diagram?
A process flow diagram is a flowchart that helps to describe the general flow of a business process. By extension, a network diagram describes the various components of IT network architecture. Within a process flow diagram, different shapes represent the assortment of components that may exist within an IT ecosystem. Connectors help to clearly describe the flow of data. Flowchart software helps to take ad hoc diagramming and streamline it, so that process flowcharts are uniform and consistent.
ThreatModeler, for example, utilizes process flow diagramming to clearly visualize and describe an IT infrastructure’s attack surface. Process flow diagrams serve as a canvas to describe an organization’s security posture as it pertains to security threats and vulnerabilities, and the security requirements needed to mitigate risk.
Process Flow vs. Data 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 and 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 advanced persistent threat (APT) actor utilizing spear phishing, insider threats caused by disgruntled or compromised employees, and common vulnerabilities and exposures (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:
- Figure out how to make things work
- Find a solution when things are not working.
Early threat modeling methodologies 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 the perspective of security – 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, process flow diagrams will not make potential threats looks like opportunities to be explored and exploited – the way hackers see them.
However, attackers such as cybercriminals 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.
Process Flow Diagram Examples
The following is an example of an AWS Microservices Architecture, as created within the ThreatModeler platform. Notice that each of the components are clearly labeled with their own icons. Notice also the information flow from components that are grouped to other component groups. ThreatModeler makes flow charting easier by enabling users to automatically build out threat models based on existing Templates, or through its searchable component Library.
As part of the user interface, the corresponding Threats summary lists out the security threats, rates the risk level and provides an overview in the Description box to help DevOps teams to understand the risk involved.
The Tasks list allows security teams to understand exactly what needs to get done in order to mitigate risk. Process flow diagrams and the corresponding lists and narratives that describe the information therein clearly provide security teams with the ability to identify, prioritize and mitigate threats.
Process Flow Diagrams and Threat Modeling
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.
Automated threat modeling software using process flow diagrams 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.
ThreatModeler Takes the Guesswork Out of Creating Process Flow Diagrams
ThreatModeler endeavors to deliver a platform that enables automation, collaboration and integration with services that make the process efficient. ThreatModeler helps to shave off time-cost and efforts by enabling basic users to create a threat model in just under an hour. ThreatModeler integrates with cloud service providers, such as AWS, to ensure security and policy compliance requirements are met.
Another integration, with Jira, enables DevOps teams to effectively assign Threat issues to the right personnel to mitigate them. Its handy approval and reporting function also ensures that Threat issues are properly reviewed by security leadership to validate that security controls are set. Learn about the benefits of ThreatModeler’s patent-pending, architecturally-based process flow diagrams, book a demo to speak to a ThreatModeler expert today.
