Hi there.

Welcome to the August edition of Threat Modeling Insider in 2022. We hope you enjoyed the summer and are ready to model again!

For this edition, we selected a variety of threat modeling content for you. From PASTA to SDWAN and everything in between.

Our complete TMI Line-up:

• Interview. “Threat Modeling can be considered as fun as cooking a good PASTA meal.” – Risk-Centric Threat Modeling, an interview with Marco Mirko Morana, Executive Director and Head of Security Architecture at JP Morgan Chase Co.
• Curated content: A mapping of STRIDE with OWASP ASVS, drafted by Miguel Llamazares.
• Curated content: A publicly available threat model on SD WAN, published by Tim (Wadhwa-) Brown.
• Toreon Blog Post: Examining attack trees and tooling, how do they compare?
• Toreon Tip: A tool to support threat modeling in a DevSecOps environment: Threagile, created by Christian Schneider.
• An overview of our next trainings.

Risk Centric Threat Modeling, an interview with Marco Mirko Morana, Executive Director and Head of Security Architecture at JP Morgan Chase Co.Seth Carmody

Note: The interview was quite long. We will publish the second part in our next edition. Stay tuned! 

Disclaimer: The views put forth in the article herein are the personal views of Marco Morana based upon his professional experience and do not necessarily reflect the views of the employer (JP Morgan Chase). The references in this article are to sources available in the public domain and are provided solely as informational references, without endorsement by the author. 

Can you describe your background and how you got into IT-security?  

My career focus has been application security, security engineering and more recently cloud security and security architecture. In the last 15 years I have been employed at financial institutions where I had the opportunity in different capacities, as sole contributor as well as manager, to influence the adoption of security in the SDLC practice, including threat modeling/architecture risk analysis and development of secure code training for developers. In the last two years my focus as head of security architecture has been to establish a security architecture practice embedded in the engineering organization including manage a team of security architects (including cloud security architects) and internal security instructors. s medical device cybersecurity policies.

You wrote a book about threat modeling covering a methodology called PASTA. What is the key take-away for readers?  

PASTA is an acronym that stands for Process for Attack simulation and Threat analysis. PASTA is a risk-centric methodology published in 2015, that myself and Tony UcedaVelez with whom I collaborated through OWASP. The book was endorsed by the former (2011-2003) cyber-security czar of the white house in USA, Richard Clarke, and he wrote the introduction. Today, PASTA is an industry recognized risk-centric threat modeling methodology. The PASTA methodology is also taught at US universities, for example the Threat Modeling and Intel graduate course at the NSA accredited National University and covers the methodology in depth with some examples.

When Tony and I started working on PASTA in 2012, we wanted to document a comprehensive threat modeling risk-centric process for modeling and analyzing threats and identify design flaws that can be mitigated by recommendations of countermeasures based upon risks. Tony and I are both cyber-security risks management geeks. We believe that risk considerations should be at the core of a threat modeling methodology. For example, we included traditional risk analysis techniques such as BIA (Business Impact Analysis) to determine impact of a realization of a threat to the application assets that include both data and application functionalities.

Besides the importance to focus on risk management when modeling threats, another take away of the book on PASTA is adopting an attacker mindset. To secure an application from cyber-attacks, it is not enough to follow security by design. That is the traditional approach to design applications based on information security risks that consists of applying controls to protect confidentiality, integrity and availability of data based upon classification. There is a need to design applications for cyber-attack resilience that is capable to withstand targeted attacks and even compromise. The need of the cyber-attack resilience for applications is something that emerged in the last 10-15 years. In the banking industry, it started with the emergence of banking trojans that were designed to target banking applications with malware. These malwares are specifically designed to bypass controls, such as Multi-Factor Authentication, for the authentication and the authorization of payments such as wire transfers. Cyber-attack resiliency is a property that is achieved by considering that controls can fail when attacked, for example when an attack chain of events progresses, but it is detected and the impact such as data exfiltration is still being prevented.

I believe cyber-attack resiliency for applications is more complex today as we have to deal with malware threat scenarios that include ransomware and malwares that can perform later attacks to compromise data. For security architects, it is important that cyber-attack resilience is among the security architecture principles, my suggested list includes the following security architecture principles: 

1. design for defense in depth (multiple controls at different tiers),  
2. designing for 0-trust (as trust no inputs) (trust boundaries are passed only if we can validate, authenticate, and authorize traffic),  
3. enforce least privileges (roles as permissions), 
4. design with adequate strength for authentication and encryption,  
5. protect confidential data in storage and in transit,  
6. limit the attack surface, 
7. apply security by defaults, 
8. the design is as secure as the weakest link  
9. design for open security vetted model avoiding complexity in the security mechanism and last not the least 
10. design for cyber-resilience to attacks 

Can you explain how PASTA is different from other threat modeling methodologies?  

In general, the differentiator of PASTA versus other threat modeling methodologies is that it is risk based, but also SDLC-based. PASTA considers the business context and the business impact, simulates the attacks of threats that are relevant for the application asset being targeted to, leverages other Security in the SDLC processes for security (such as static code scanning, vulnerability management and risk management) and collaborates with the stakeholders in security and risk as well as the business.

If we consider threat modeling not just a methodology, but also a risk framework, then there at least 12 available methods to execute threat modeling today. These  include risk management methodologies such as Octave, methods such as attack trees and even CVSS risk scoring for vulnerabilities. We did not document PASTA just to add another methodology, even if it is risk-centric, but as a methodology that is comprehensive in the consideration of cyber-attack risks. In doing this we did not redefine what a threat, an attack and a risk is. Instead, we leveraged NIST standard definitions for risk management terminologies. Making sure we use terminologies for risk management that are used in the industry and standardized is important to avoid misclassifications for example when we confuse threats with attacks.

According to the NIST taxonomy, a threat is an adverse condition that can be exploited by a threat agent, human or not, to cause an impact to an application. The impact of an attack might vary depending on what the threat agent motives are and its capabilities to compromise the asset confidentiality, integrity, and availability. All threat modeling methodologies have a generic goal. That is modeling threats to identify countermeasures to mitigate these threats based upon risk. Since we wrote the methodology based on experience executing it; we made sure that besides a risk-centric approach, we defined the technical and business scope as the context for which the threats need to be evaluated.

The modeling of the threats includes potential attacks. Attack methods used by an attacker or attackers is not something abstracted from the scope of the application and the risks to the architecture of which threat modeling or analysis is part of it. Traditionally, threat modeling methodologies in the industry adopted frameworks for which threats and controls could be identified (e.g., STRIDE). A  software developer can use these threats to analyze controls to mitigate threats during the SDLC. Some methodologies have both an application and operational focus (e.g., VAST), while some are geared as risk management and analysis (e.g., OCTAVE), which can help organizations to derive a risk mitigation strategy.

The PASTA threat modeling methodology incorporates a focus that is both risk- and attacker-centric. It is attack-centric because it incorporates an output attacker-centric perspective on potential threats with a risk and impact analysis. It is risk-centric, because in the consideration of the risk that a threat is exploiting a weakness (e.g., a gap in the controls of a vulnerability causing an impact), it focuses not just on the technical impact but also on the impact to the business, so that the threat can be prioritized as minimization of that impact. The main difference with other methodologies, such as STRIDE, is that PASTA considers threats in the business and technical context for the application and the assets to protect considers both business and data assets that can be potentially targeted. Comparing with STRIDE, PASTA is not just a categorization of threats and association of risks for these threats. It considers the business and technical context, it considers the relevant threats, it simulates the attacks of threats that are relevant for the application asset being targeted, and it leverages other processes for security that seek to find vulnerabilities such as static code scanning, vulnerability management, risk management and maps threats and attacks to these vulnerable assets.

PASTA Threat Modeling does not just aim to be used by software developers, it is aimed for collaboration with the application stakeholders in cyber-security, including both risk managers as well as the business managers. This is a departure from a software-centric model because it involves business and risk management in the evaluation of the risk and the strategy to mitigate them is a business decision. In the book, we documented the methodology and provided examples on how this can be executed. In a nutshell, PASTA has seven stages, and each stage has activities that allow to incorporate threat modeling as part of the SDLC-process by collaboration among software engineers, architects, business managers, engineering managers and the security teams.

One colorful note is the chosen name of PASTA, Tony and I chose that food name metaphorically in an attempt to make threat modeling a fun methodology to apply. Threat Modeling can be considered as fun as cooking a good PASTA meal. Tony has done a video on YouTube where he dresses as cook and explains the 7 stages of PASTA as cooking with pasta. In general, I use metaphors in trainings to make difficult concepts simple. Besides threat modeling I have done presentations titled for example “why making good security products is like making good wine”. The attendees got to taste wine while I was giving the presentation and it was great to improve participation and engagement. As a fun side note, I personally do not think Tony and I can ever compete with Stanley Tucci’s cooking classes, such as “Searching for Italy”, but we might at least have some success to make PASTA Threat modeling a fun methodology to learn when attending our presentations and watching the videos. 

What are, according to you, the top 3 benefits of threat modeling for an organization and the systems they are building?  

It is important when we discuss the benefits of threat modeling, that we answer the question who (i.e., which roles) benefits from adopting it. In my view, the beneficiaries of adopting risk-centric threat modeling are all stakeholders that include business, technology/engineering, and security/risk. The benefits need to be articulated based upon different point of views. From the business point of view, it is cost effective, since threat modeling follows a proactive approach toward risk mitigation and can help business to deliver products that are designed and built for security. This approach is less costly for application business owners than bolting on security controls when vulnerabilities are identified either by security testing or because there is an attacker exploiting them.
Some studies show that security by bolting on is much more expensive than security by building by design in of a factor of hundred to thousand times. From the architects’ point of view, threat modeling helps to make sure that the design of the application follows secure by design principles that include attack resilience and adoption of countermeasures for threats that are decided during the design phase. From the security teams’, managers’, CISOs’ and risk managers’ point of view, threat modeling allows to drive security throughout the SDLC.

Today, Threat Modeling is positioned as part of SecDevOps during design, pre-build, testing, delivery, and prod operations. Even more ahead of the design phase, during early requirements definition phase, threat modeling is to elicit security requirements that can be later validated when the application is build and tested. Threat modeling as a methodology complements security assessments including security testing following white and black box testing techniques and SAST, DAST, RASP tools, for example attack driven tests can help security testers to identify additional design flaws and vulnerabilities in the applications 

What trends did you see in threat modeling over the last couple of years?   

One trend I observed is toward trying to incorporate threat modeling as part of SecDevOps. For example, the deployment of threat modeling tools integrated with other security tools, such as tools for security testing and for security issue management (e.g. JIRA). In the security tooling space, there is a trend to automate security testing, such as automatically triggering vulnerability code scanning at every static build of the code. Unfortunately, in the case of many threat modeling tools available today, threat modeling is at best still semi or partially automated as execution process and automation is not achieved at the same extent of SAST, DAST or RASP. For example, I have seen threat modeling tools (e.g., Avocado Reveal) to extract automatically component level diagrams from deployed applications upon which threat models can be applied and that automatically trigger the analysis of threats during the design, geared towards automatically applying the threat libraries to the assets to which these threats can be exposed to and dynamically generating a set of security requirements for mitigating these threats including tools that suggest developers secure code snippets to follow for the implementation of security controls (i.e., authentication, authorization, data protection, input validation, audit and logging).

A good result of the trends is the adoption of threat modeling as a methodology that is executed consistently with adoption across the organization increases over time. The maturity of threat modeling methodology adoption can probably be assessed by the adoption in the industries. Today there are methodologies such as the Open software security maturity assessment (OWASP SAMM) and Build in Security Maturity Model (BISMM). It is important to compare each company among peers in the industry for the same activities that are threat modeling related, including architecture analysis. The last time I saw BSIMM reports (about 2, 3 years ago). Based on these, I reckoned that threat modeling was more mature in the financial industry sector versus other industry sectors.  

What can we do as a community to improve the threat modeling practice in the next coming years?  

There have been some improvements in the threat modeling best practices and the tools that support these. Originally, when I started working on OWASP threat modeling methodology about 10 years ago, there were no free open-source OWASP threat modeling tools available, but today we have OWASP, that published a free OWASP Dragon Threat Modeling. As a methodology, PASTA can be executed with tools like ThreatModeler and IriusRisk. In general, PASTA as a risk-centric process for threat modeling is well suited to be executed by any kind of threat modeling tool that includes both commercial vendors as well as open-source. In the future, it would be nice to see threat modeling tools integrated as part of the secure code delivery pipelines ahead of security testing tools (SAST, DAST, IAST), leveraging issue management like JIRA as well. Perhaps via the tool improvement space, such as the community project OWASP?

It will also be nice to see threat modeling tools specific for cloud deployments with the capability to extract architecture diagrams and data flow diagrams from deployed cloud components, including containers and workloads running on these and then leverage these automatically generated diagrams to feed into threat modeling tools to customize the threat models and update them as these change. To my knowledge, there are some RASP tools today that can extract DFDs directly from the deployed architecture and the components at the server level as well as at the processes running on the server. These real-time DFDs can be the basis to apply threat models using threat modeling tools. RASP also can take these threats that are modeled to apply rules to block or detect attack vectors. 

Stay tuned for part two of this interview, which will be available in the next Threat Modeling Insider!

STRIDE to ASVS mapping

SD WAN Threat Model

A lot of threat modelers make use of attack trees. In this article we dive into two attack tree tools, compare them, and see if they’re worth using. We would like to know the value of using specialized software, how time can be saved and what other benefits could be gotten from the use of these specialized tools.  You can read all about it here.

The tool Threagile, created by Christian Schneider, enables teams to execute Agile Threat Modeling as seamless as possible, even highly-integrated into DevSecOps. Have a look on the official page. It gives you a bunch of information on the tool and how to get started.

We aim to make this a community-driven newsletter and welcome your input or feedback. If you have content or pointers for the next edition, please share them with us.

Kind regards,
Sebastien Deleersnyder
CTO, Toreon