Thursday, March 31, 2022

MVP vs POC vs prototype

  •  Proof of Concept (POC)


Approach: Is the idea feasible? 


Implementation: Developing a POC is the quickest and most accurate way to validate or invalidate assumptions about your target users and app concept. 



Mobile App Prototype


Approach: How will this product function? 


Implementation: Mobile app prototyping is a form of user research to validate the strategic design direction of a product. A prototype is a preliminary visualization of a working product. Prototypes build an understanding of the mobile app’s look and feel, which helps test how customers use and react to the overall user experience (UX) design. Using a prototype for usability testing gives you enough time to make changes to critical design issues before the product reaches development and it’s too late (and too expensive) to make major changes to the UX. 



Minimum Viable Product (MVP)


Approach: What are the product’s core functionalities and value proposition? 


Implementation: A mobile app MVP is a minimal and usable form of your complete product to release and test in the app market. The MVP development method allows your team to learn how the product’s target users experience and respond to the app’s core business purpose. Using the insight and learnings from real users, you can allocate your time, effort and budget to areas that best satisfy your overall business objectives. Building an MVP is an iterative process designed to identify user pain points and determine the proper functionality to address those needs over time.


What is a POC? 

A POC will provide a definitive “yes” or “no” answer; either the concept is viable or it’s not.

The POC approach to product validation is about demonstrating functionality and verifying whether a particular idea is feasible for development.

Even if a POC proves that the concept won’t work, it’s possible to find other solutions from the same starting point. 


What is a Mobile App Prototype? 

While a POC shows a product concept can be done, a mobile app prototype shows how it will be done.

The purpose of a prototype is to communicate a product’s design and navigation flow to maximize the efficiency of development. Prototyping is a valuable exercise which results in visualization of how the app will function by demonstrating user flows and depicting a working design and layout. Naturally, there will be errors in a prototype, but discovering these errors during the early stages of a project is one of the purposes of a prototype. 


What is a Minimum Viable Product?

Prototypes often influence an MVP and the two work together to create a successful end product.

An MVP is a minimal form of your complete product that is tested in the market.

This approach to development allows you to learn how your users will react to your product before you waste a lot of money and resources building something no one wants or needs.

While prototypes solve problems during the early stages of development, an MVP’s iterative process is designed to identify users’ pain points when the product is actually tested in the market. 

The risk of developing more (or less) than you need is why validating your product assumptions with an MVP is so important. 

Starting with a core feature, learning how users react to that feature and building in accordance with user feedback is essential for determining the appropriate amount of functionality your product needs to acquire and retain users. Over time, the learnings that come from an MVP define your product roadmap and guide the evolution of your app. 


An MVP is a version of a product that includes only the features it needs to be marketable. With the MVP process, you can verify the following: 


    Product viability 

    Product assumptions 

    Usability 

    Market demand 


MVPs provide immediate value while minimizing development costs.

Ultimately, an MVP allows you to build a product with minimal features and iteratively build it out to create a better, more polished product while leveraging user intelligence to make the best decisions possible. With every release version, the product evolves to maximize ROI and move towards a fully mature application. 



https://clearbridgemobile.com/beginners-guide-poc-vs-mvp-vs-prototype/











  • What is the Difference Between MVP vs POC vs Prototype and why does it matter?


Factor:Role 


POC

Is this concept even feasible? The POC can be used to validate assumptions about the idea.

Prototype:

How will the product or solution actually function?

MVP:

What is the value proposition of the product and how will it function?



Factor:Development


POC

Demonstrates that a solution could be built

Prototype:

Shows how the solution will be built and how it will work.

MVP:

Is a built version of the product that tests the market for it.


Factor:Audiences


POC

Tends to be rather small and used internally to showcase an idea.

Prototype:

Usually used internally to see how the development work will be carried out.

MVP:

Is used externally to gauge market interest and see how it could be improved.


Factor:Issues


Prototype:

Deals with issues at the early stage of development.

MVP:

Takes an iterative approach to development looking at issues the client has with the product when it is in the market.


Factor: Function


POC

Does not function as a fully working product.

Helps to understand whether it is feasible to go ahead with the product.

Prototype:

Does not function as a fully working product.

Helps to see how the product will look and how it will feel for the user.

MVP:

Functions fully as a working product using the basic but most essential functionality.

Helps to see how the product will be used.


Factor: Feedback


POC

Does not provide an opportunity for feedback from actual or possible customers. Might sometimes be used with investors to attract funding.

Prototype:

Can allow the firm to get feedback from a few possible customers.

MVP:

Allows the firm to gather feedback from a lot of customers, potentially.


Factor: Customer growth


POC

Does not grow the customer base.

Prototype:

Does not grow the customer base.

MVP:

Grows the customer base at the same time as iterative development is taking place.


Factor: Revenues


POC

Will not bring in revenues from customers.

Prototype:

Will not bring in revenues from customers.

MVP:

Can bring in revenues from customers.


https://enkonix.com/blog/mvp-vs-poc-vs-prototype/

Tuesday, March 1, 2022

Cyber Threat Modelling

 

  • Definition of threat modeling

Threat modeling is a structured process with these objectives: identify security requirements, pinpoint security threats and potential vulnerabilities, quantify threat and vulnerability criticality, and prioritize remediation methods. Threat modeling methods create these artifacts:

    An abstraction of the system
    Profiles of potential attackers, including their goals and methods
    A catalog of threats that could arise

How does threat modeling work?
Threat modeling works by identifying the types of threat agents that cause harm to an application or computer system.
Typically, organizations conduct threat modeling during the design stage (but it can occur at other stages) of a new application to help developers find vulnerabilities and become aware of the security implications of their design, code, and configuration decisions. Generally, developers perform threat modeling in four steps:

    Diagram. What are we building?
    Identify threats. What could go wrong?
    Mitigate. What are we doing to defend against threats?
    Validate. Have we acted on each of the previous steps?


Advantages of threat modeling

When performed correctly, threat modeling can provide a clear line of sight across a software project, helping to justify security efforts. The threat modeling process helps an organization document knowable security threats to an application and make rational decisions about how to address them


Overall, a well-documented threat model provides assurances that are useful in explaining and defending the security posture of an application or computer system

    Detect problems early in the software development life cycle (SDLC)—even before coding begins.
    Spot design flaws that traditional testing methods and code reviews may overlook.
    Evaluate new forms of attack that you might not otherwise consider.
    Maximize testing budgets by helping target testing and code review.
    Identify security requirements.
    Remediate problems before software release and prevent costly recoding post-deployment.
    Think about threats beyond standard attacks to the security issues unique to your application.
    Keep frameworks ahead of the internal and external attackers relevant to your applications.
    Highlight assets, threat agents, and controls to deduce components that attackers will target.
    Model the location of threat agents, motivations, skills, and capabilities to locate potential attackers in relation to the system architecture.

Misconceptions of threat modeling
Penetration testing and code reviews can’t substitute for threat modeling.
There’s a good reason to conduct a threat model after deployment.

Best practices of threat modeling
1. Define the scope and depth of analysis
Determine the scope with stakeholders, then break down the depth of analysis for individual development teams so they can threat model the software.
2. Gain a visual understanding of what you’re threat modeling. 
Identify software assets, security controls, and threat agents and diagram their locations to create a security model of the system 
3. Model the attack possibilities
Identify software assets, security controls, and threat agents and diagram their locations to create a security model of the system
4. Identify threats. 
To produce a list of potential attacks, ask questions such as the following:
                    Are there paths where a threat agent can reach an asset without going through a control?
                    Could a threat agent defeat this security control?
                    What must a threat agent do to defeat this control?
5. Create a traceability matrix of missing or weak security controls
Consider the threat agents and follow their control paths. If you reach the software asset without going through a security control, that’s a potential attack. If you go through a control, consider whether it would halt a threat agent or whether the agent would have methods to bypass it.

the Synopsys high-level approach to threat modeling adheres to the following steps:

    Model the system.
    Conduct a threat analysis.
    Prioritize the threats.


Model the system

System modeling consists of two parts:

    Creating a component diagram with a control flow graph (which shows all possible execution paths in a program)
    Identifying assets, security controls, trust zones, and threat agents

Conduct a threat analysis 

Checklist-based approaches. Many threat modeling approaches involve a checklist or a template. For example, STRIDE recommends you consider six types of threats—spoofing, tampering, repudiation, information disclosure, denial of service, and escalation of privilege
Non-checklist-based approaches. These approaches generally use creative methods (e.g., brainstorming) to identify attacks.


https://www.synopsys.com/glossary/what-is-threat-modeling.html
  • Threat Modeling
Threat modeling is a core element of the Microsoft Security Development Lifecycle (SDL). It’s an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application's design, meet your company's security objectives, and reduce risk.

There are five major threat modeling steps:
 Defining security requirements.
 Creating an application diagram.
 Identifying threats.
 Mitigating threats.
 Validating that threats have been mitigated.

https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling
  •  A threat model is essentially a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through security glasses.
 Threat modeling enables informed decision-making about application security risk. 
 In addition to producing a model, typical threat modeling efforts also produce a prioritized list of security improvements to the concept, requirements, design, or implementation.
 
 Objectives of Threat Modeling

Threat modeling is a family of activities for improving security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. A threat is a potential or actual undesirable event that may be malicious (such as DoS attack) or incidental (failure of a Storage Device). Threat modeling is a planned activity for identifying and assessing application threats and vulnerabilities.

Threat Modeling - Generic Steps
Following is a four question framework that helps understand threat modeling:

    What are we working on?
    What can go wrong?
    What are we going to do about it?
    Did we do a good job?

The basic threat modeling process consists of the following generic steps. The process of exploring the search space is iterative and constantly refined based on what you have done so far. So, for example, starting with all possible vulnerabilities is usually pointless, as most of them are not attackable by the threat agents, protected by a safeguard, or do not lead to a consequence. Therefore, it’s generally best to start with the factors that make a lot of difference.

Assessment Scope - The first step is always to understand what’s on the line. Identifying tangible assets, like databases of information or sensitive files is usually easy
Identify Threat Agents and Possible Attacks - A key part of the threat model is a characterization of the different groups of people who might be able to attack your application.
Understand Existing Countermeasures - The model must include the existing countermeasures
Identify Exploitable Vulnerabilities - Once you have an understanding of the security in the application, you can then analyze for new vulnerabilities.
Prioritized Identified Risks - Prioritization is everything in threat modeling, as there are always lots of risks that simply don’t rate any attention. For each threat, you estimate a number of likelihood and impact factors to determine an overall risk or severity level
Identify Countermeasures to Reduce Threat - The last step is to identify countermeasures to reduce the risk to acceptable levels.

Benefits
The threat model allows security decisions to be made rationally, with all the information on the table
The threat modeling process naturally produces an assurance argument that can be used to explain and defend the security of an application. An assurance argument starts with a few high level claims, and justifies them with either subclaims or evidence

https://owasp.org/www-community/Threat_Modeling
  • Threat modeling is a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified, enumerated, and mitigations can be prioritized. The purpose of threat modeling is to provide defenders with a systematic analysis of what controls or defenses need to be included, given the nature of the system, the probable attacker's profile, the most likely attack vectors, and the assets most desired by an attacker. Threat modeling answers questions like “Where am I most vulnerable to attack?”, “What are the most relevant threats?”, and “What do I need to do to safeguard against these threats?”.
https://en.wikipedia.org/wiki/Threat_model
  • Application Threat Modeling
Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, distributed systems, things in the Internet of things, business processes, etc. 

Most of the time, a threat model includes:

    A description / design / model of what you’re worried about
    A list of assumptions that can be checked or challenged in the future as the threat landscape changes
    A list of potential threats to the system
    A list of actions to be taken for each threat
    A way of validating the model and threats, and verification of success of actions taken

The inclusion of threat modeling in the SDLC can help

    Build a secure design
    Efficient investment of resources; appropriately prioritize security, development, and other tasks
    Bring Security and Development together to collaborate on a shared understanding, informing development of the system
    Identify threats and compliance requirements, and evaluate their risk
    Define and build required controls.
    Balance risks, controls, and usability
    Identify where building a control is unnecessary, based on acceptable risk
    Document threats and mitigation
    Ensure business requirements (or goals) are adequately protected in the face of a malicious actor, accidents, or other causes of impact
    Identification of security test cases / security test scenarios to test the security requirements


4 Questions
Most threat model methodologies answer one or more of the following questions in the technical steps which they follow:

What are we building?
As a starting point you need to define the scope of the Threat Model. To do that you need to understand the application you are building, examples of helpful techniques are:

    Architecture diagrams
    Dataflow transitions
    Data classifications
    You will also need to gather people from different roles with sufficient technical and risk awareness to agree on the framework to be used during the Threat modeling exercise

What can go wrong?
This is a “research” activity in which you want to find the main threats that apply to your application
There are many ways to approach the question, including brainstorming or using a structure to help think it through. Structures that can help include STRIDE, Kill Chains, CAPEC and others.

What are we going to do about that?

Did we do a good enough job?
Finally, carry out a retrospective activity over the work you have done to check quality, feasibility, progress, and/or planning

Process

The technical steps in threat modeling involve answering questions:

    What are we working on - What can go wrong - What will we do with the findings
    Did we do a good job? The work to answer these questions is embedded in some sort of process, ranging from incredibly informal Kanban with Post-its on the wall to strictly structured waterfalls
https://owasp.org/www-community/Application_Threat_Modeling

  • What Is Threat Modeling?
Threat modeling is the process of using hypothetical scenarios, system diagrams, and testing to help secure systems and data. By identifying vulnerabilities, helping with risk assessment, and suggesting corrective action, threat modeling helps improve cybersecurity and trust in key business systems.

What are the benefits of threat modeling?

Provide an enhanced view of systems. The steps involved in threat modeling--creating data flow diagrams (DFDs) and graphical representations of attack paths, as well as prioritizing assets and risks--help IT teams gain a deeper understanding of network security and architecture.

Help enable better collaboration on security. Proper threat modeling requires input from many stakeholders. Participating in the process can help instill cybersecurity consciousness as a core competency for all participants.

Facilitate risk prioritization. Businesses can use the threat data provided by modeling to make decisions about which security risks to prioritize--a helpful process for understanding where to allocate people and budget resources.

Does threat modeling require special software?
While basic threat modeling can be performed in a brainstorming session, larger enterprises with more potential vulnerabilities can use software and hardware tools to improve the security of complex systems with multiple points of entry

What is involved in the threat modeling process?

Identify assets. An asset could be account data, intellectual property, or simply the reliable functioning of a system.

Diagram the system. DFDs provide a high-level, asset-centric view of systems and the data flows of attacks. An attack tree, or graphic representation of an attack path, illustrates the possible origins and paths of attacks.

Analyze threats. Use threat modeling methods to further analyze specific threat types, identify potential threats, map data flows, and quantify risk.

Perform risk management and prioritization. Many threat modeling tools produce threat scores and data for calculating risk. Stakeholder input is essential to this step.

Identify fixes. Once you identify the areas, assets, or threats that matter most to the organization, the next steps may be apparent. Changing firewall, encryption, or multi-factor authentication settings are examples of steps to address a threat.

How do I measure the effectiveness of threat modeling?

Common Vulnerability Scoring System (CVSS). CVSS produces standardized scores for application vulnerabilities, IT systems and elements, and IoT devices; the scores can be calculated with a free online tool. For additional perspective, scores can be compared against a database of existing scores crowdsourced from similar enterprises.

Penetration testing. Sometimes referred to as "ethical hacking," penetration testing is the process of staging dummy attacks on a system to measure its strengths and weaknesses.

Is threat modeling available as a service?
Threat modeling as a service (TMaaS) can allow an organization to focus on remediation and high-level network architecture decisions, while leaving necessary data-crunching to TMaaS providers. TMaaS also can perform continuous threat modeling, automatically running testing anytime a system is updated, expanded, or changed. TMaaS solutions incorporate threat intelligence--such as data about threats and attacks crowdsourced from organizations worldwide--that can inform threat hypotheses for networks and improve network security.

Threat modeling methods and tools

CIA method
For example, there may be sensitive customer information (confidentiality), company operational or proprietary data (integrity), or reliability of a service such as a web portal (availability).

Attack trees
Attack trees are a graphic representation of systems and possible vulnerabilities. The trunk of the attack tree is the asset, while entry points and threats are branches or root

STRIDE
one of the oldest and most widely used frameworks for threat modeling. STRIDE is a free tool that will produce DFDs and analyze threats.

PASTA
PASTA (process for attack simulation and threat analysis) is a framework designed to elevate threat modeling to the strategic level, with input from all stakeholders, not just IT or security teams. PASTA is a seven-step process that begins with defining objectives and scope. It includes vulnerability checks, weakness analysis, and attack modeling, and ends with risk and impact analysis expressed through scoring

Trike
An open-source tool available as a spreadsheet template or stand-alone program, Trike consists of a matrix combining assets, actors, actions, and rules. When parameters and data are entered in this matrix, the program produces a score-based analysis of risks and probabilities.

VAST
VAST (visual, agile, and simple threat) modeling consists of methods and processes that can be easily scaled and adapted to any scope or part of an organization. The results produce benchmarks that can be used to make reliable comparisons and measurements of effective risk across a whole organization.

Persona non grata
This method is similar to criminal profiling in law enforcement. To anticipate attacks in more detail, brainstorming exercises are performed to create a detailed picture of a hypothetical attacker, including their psychology, motivations, goals, and capabilities.

LINDDUN

The LINDDUN framework focuses on analysis of privacy threats, based on the categories that form its acronym: linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness, and non-compliance. It uses threat trees to help users choose the relevant privacy controls to apply.
https://www.cisco.com/c/en/us/products/security/what-is-threat-modeling.html
  • Threat Modeling: 12 Available Methods

STRIDE and Associated Derivations
Invented in 1999 and adopted by Microsoft in 2002, STRIDE is currently the most mature threat-modeling method.

PASTA
The Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric threat-modeling framework developed in 2012.

LINDDUN
LINDDUN (linkabilityidentifiability, nonrepudiation, detectability, disclosure of information, unawareness, noncompliance) focuses on privacy concerns and can be used for data security.

CVSS
The Common Vulnerability Scoring System (CVSS) captures the principal characteristics of a vulnerability and produces a numerical severity score

Attack Trees
Using attack trees to model threats is one of the oldest and most widely applied techniques on cyber-only systems, cyber-physical systems, and purely physical systems. Attack trees were initially applied as a stand-alone method and has since been combined with other methods and frameworks.

Persona non Grata
Persona non Grata (PnG) focuses on the motivations and skills of human attackers

Security Cards
Security Cards identify unusual and complex attacks. They are not a formal method but, rather, a kind of brainstorming technique.

hTMM
The Hybrid Threat Modeling Method (hTMM) was developed by the SEI in 2018. It consists of a combination of SQUARE (Security Quality Requirements Engineering Method), Security Cards, and PnG activities.

Quantitative Threat Modeling Method
This hybrid method consists of attack trees, STRIDE, and CVSS methods applied in synergy.

Trike
Trike was created as a security audit framework that uses threat modeling as a technique. It looks at threat modeling from a risk-management and defensive perspective.

VAST Modeling
The Visual, Agile, and Simple Threat (VAST) Modeling method is based on ThreatModeler, an automated threat-modeling platform.

OCTAVE
The Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) method is a risk-based strategic assessment and planning method for cybersecurity.

https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html
  • STRIDE, VAST, TRIKE, & MORE: WHICH THREAT MODELING METHODOLOGY IS RIGHT FOR YOUR ORGANIZATION?

OCTAVE (Practice Focused)
Though OCTAVE threat modeling provides a robust, asset-centric view, and organizational risk awareness, the documentation can become voluminous. OCTAVE lacks scalability – as technological systems add users, applications, and functionality, a manual process can quickly become unmanageable.
This method is most useful when creating a risk-aware corporate culture. The method is highly customizable to an organization’s specific security objectives and risk environment.

Trike Threat Modeling (Acceptable Risk Focused)
The foundation of the Trike threat modeling methodology is a “requirements model.” The requirements model ensures the assigned level of risk for each asset is “acceptable” to the various stakeholders.
However, because Trike threat modeling requires a person to hold a view of the entire system to conduct an attack surface analysis, it can be challenging to scale to larger systems.

P.A.S.T.A. Threat Modeling (Attacker Focused)
The output provides threat management, enumeration, and scoring.
The PASTA threat modeling methodology combines an attacker-centric perspective on potential threats with risk and impact analysis. 
The outputs are asset-centric.
PASTA threat modeling works best for organizations that wish to align threat modeling with strategic objectives because it incorporates business impact analysis as an integral part of the process and expands cybersecurity responsibilities beyond the IT department.
This alignment can sometimes be a weakness of the PASTA threat modeling methodologies. Depending on the technological literacy of key stakeholders throughout the organization, adopting the PASTA methodology can require many additional hours of training and education.

STRIDE Threat Modeling (Developer Focused)
The primary focus of that directive is to help ensure that Microsoft’s Windows software developers think about security during the design phase.
The STRIDE threat modeling goal is to get an application to meet the security properties of Confidentiality, Integrity, and Availability (CIA), along with Authorization, Authentication, and Non-Repudiation.
Once the security subject matter experts construct the data flow diagram-based threat model, system engineers or other subject matter experts check the application against the STRIDE threat model classification scheme.

VAST Threat Modeling (Enterprise Focused)
The founding principle is that, in order to be effective, threat modeling must scale across the infrastructure and entire DevOps portfolio, integrate seamlessly into an Agile environment and provide actionable, accurate, and consistent outputs for developers, security teams, and senior executives alike.
A fundamental difference of the VAST threat modeling methodology‍ is its practical approach. 
Recognizing the security concerns of development teams are distinct from those of an infrastructure team, this methodology calls for two types of threat models.


VAST: Application Threat Models
Application threat models for development teams are created with process flow diagrams (PFD). Process flow diagrams map the features and communications of an application in much the same way as developers and architects think about the application during an SDLC design session.

VAST: Operational Threat Models
Operational threat models are designed for the infrastructure teams
Though more similar to traditional DFDs than application threat models, the data flow information is presented from an attacker – not a data packet – perspective. 
By relying on PFDs rather than DFDs, VAST threat models do not require extensive systems expertise.

The most significant difference of the VAST threat modeling methodology, however, is its ability to allow organizations to scale across thousands of threat models
The pillars of a scalable threat modeling practice – automation, integration, and collaboration – are foundational to VAST threat modeling.
 As the organization matures and new threats arise, these pillars help to develop a sustainable self-service threat modeling practice driven by the DevOps teams rather than the security team

https://threatmodeler.com/threat-modeling-methodologies-overview-for-your-business/
  • Threat Modeling Methodologies

When performing threat modeling, there are multiple methodologies you can use. The right model for your needs depends on what types of threats you are trying to model and for what purpose.

STRIDE threat modeling
STRIDE is a threat model, created by Microsoft engineers, which is meant to guide the discovery of threats in a system

STRIDE is an acronym for the types of threats it covers, which are:

    Spoofing—a user or program pretends to be another
    Tampering—attackers modify components or code
    Repudiation—threat events are not logged or monitored
    Information disclosure—data is leaked or expose
    Denial of service (DoS)—services or components are overloaded with traffic to prevent legitimate use
    Privilege escalation—attackers grant themselves additional privileges to gain greater control over a system


Process for Attack Simulation and Threat Analysis (PASTA)
PASTA is an attacker-centric methodology with seven steps

The steps of a PASTA threat model are:

    Define business objectives
    Define the technical scope of assets and components
    Application decomposition and identify application controls
    Threat analysis based on threat intelligence
    Vulnerability detection
    Attack enumeration and modeling
    Risk analysis and development of countermeasures

Common Vulnerability Scoring System (CVSS)
CVSS is a standardized threat scoring system used for known vulnerabilities.

This system is designed to help security teams access threats, identify impacts, and identify existing countermeasures. It also helps security professionals assess and apply threat intelligence developed by others in a reliable way.

CVSS accounts for the inherent properties of a threat and the impacts of the risk factor due to time since the vulnerability was first discovered. It also includes measures that allow security teams to specifically modify risk scores based on individual system configurations.

Attack trees
Attack trees are charts that display the paths that attacks can take in a system. These charts display attack goals as a root with possible paths as branches.

Security Cards
Security Cards is a methodology based on brainstorming and creative thinking rather than structured threat modeling approaches. It is designed to help security teams account for less common or novel attacks.

The methodology uses a set of 42 cards, which help analysts answer questions about future attacks, such as who might attack, what their motivation could be, which systems they might attack, and how they would implement an attack.

Hybrid Threat Modeling Method (hTMM)
hTMM is a methodology developed by Security Equipment Inc. (SEI) that combines two other methodologies:

    Security Quality Requirements Engineering (SQUARE)—a methodology designed to elicit, categorize and prioritize security requirements.
    Persona non Grata (PnG)—a methodology that focuses on uncovering ways a system can be abused to meet an attacker’s goals.


https://www.exabeam.com/information-security/threat-modeling/
  • STRIDE is a mnemonic for a set of threats – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service (DoS), and Elevation of Privilege as described in the table below.
https://www.eccouncil.org/threat-modeling/

  • Developed by Microsoft, STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) is one of the oldest and most widely used frameworks for threat modeling. STRIDE is a free tool that will produce DFDs and analyze threats
https://www.cisco.com/c/en/us/products/security/what-is-threat-modeling.html#~methods-and-tools
  • STRIDE is a model of threats .It provides a mnemonic for security threats in six categories. (First letters)


The threats are:
    Spoofing
    Tampering
    Repudiation
    Information disclosure (privacy breach or data leak)
    Denial of service
    Elevation of privilege

Each threat is a violation of a desirable property for a system
Spoofing  Authenticity
Tampering  Integrity
Repudiation  Non-repudiability
Information disclosure  Confidentiality
Denial of Service  Availability
Elevation of Privilege  Authorization 

https://en.wikipedia.org/wiki/STRIDE_%28security%29



  • The Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric threat modeling methodology that provides a step-by-step process to inject risk analysis and context into an organization’s overall security strategy from the beginning. PASTA encourages collaboration across all stakeholders, creating an environment focused on security

PASTA allows for collaboration between developer and business stakeholders to truly understand your application’s inherent risk, its likelihood of attack, and the business impact if there was a compromise

Benefits of PASTA Threat Modeling:
Contextualized approach that always ties back to business context
Simulates and tests the viability of evidence-based threats
Takes the perspective of an attacker
Leverages existing processes from within the organization
Collaborative process that can quickly scale up or down

Stage One: Define the Objectives

Governance and Compliance To Include in Your Threat Model:
External Framework – CoBit, ISO, NIST, SANS, CAG, CIS
Internal Standards – Crypto, Authentication, .NET security, JAVA security
External Regulations – PCI-DSS, NERC CIP, FIPS 140-2, FedRAMP
Internal Process/Artifacts – Risk Assessments, Vulnerability Assessments, SAST/DAST report

Stage Two: Define the Technical Scope
Stage two of PASTA is to understand your attack surface by defining your technical scope: know what you are protecting.
Attack Surface Component Examples:
API endpoints
Web application
Network infrastructure
OS Settings
DNS server
Certificate server
Mobile client
3rd party SW/Library
Data storage device
Application Framework
Kubernetes configuration
Docker configuration
Service configuration


Stage Three: Decompose the Application
Stage three goes further by creating context around how everything communicates, how it all comes together.
Data flow diagrams alone are not threat modeling. A data flow diagram shows the flow of data between callers across trust boundaries, but it has no depiction of threats. It doesn’t illustrate to a developer or to an engineer what they should be worried about, it provides a map for analysis.

Stage Four: Analyze the Threats
The main output for stage four is to understand what the application does and what sort of threats are affecting your defined attack surface.

Dos:

Make your own threat intel utilizing internal/external researchers or internal logs
Know where your threat sources come from, it’s relevant, and cross validated

Don’ts:

Use one source of threat intel data
Use your competitors threat intelligence as a basis for industry related threats
Let the threat analysis reveal assets you didn’t consider in stages 2 and 3 (this means you did those steps wrong”

Stage Five: Vulnerability Analysis
Stage five correlates the application’s vulnerabilities to the application’s assets
The key differentiator with PASTA is focusing on risks that will have the most impact to the business

Stage Six: Attack Analysis
The key objective for stage six of PASTA, is to prove that the things we found vulnerable in stage five, are actually viable.
Using attack trees allows you to map known vulnerabilities to a node on the attack tree to determine it’s likelihood.
The parent node of your attack tree is typically your threat objective.

Stage Seven: Risk and Impact Analysis
PASTA threat modeling is about reducing risks.
The end goal for stage seven, is to build countermeasures that mitigate the threats that are important.

https://versprite.com/blog/what-is-pasta-threat-modeling/
  • The Process for Attack Simulation and Threat Analysis (PASTA) is a seven-step, risk-centric methodology


It provides a seven-step process for aligning business objectives and technical requirements, taking into account compliance issues and business analysis. The intent of the method is to provide a dynamic threat identification, enumeration, and scoring process. Once the threat model is completed security subject matter experts develop a detailed analysis of the identified threats. Finally, appropriate security controls can be enumerated. This methodology is intended to provide an attacker-centric view of the application and infrastructure from which defenders can develop an asset-centric mitigation strategy.
https://en.wikipedia.org/wiki/Threat_model
  1. TRIKE is an open-source threat modeling methodology that is used when security auditing from a risk management perspective. TRIKE threat modeling is a fusion of two models namely – Requirement Model and Implementations Model. The requirement model is the base of TRIKE modeling that explains the security characteristics of an IT system and assigns acceptable levels of risk to each asset. This model also enables coordination among different security teams and stakeholders by providing a conceptual framework. After this comes the implementation model. In this model, a Data Flow Diagram (DFD) is created to illustrate the flow of data and the user performed actions within a system. In this model, threats are analyzed to enumerate and assign a risk value. Based on this, security controls or preventive measures defined to address the threats as per the priority and assigned risks.
https://www.eccouncil.org/threat-modeling/

  • Trike is an open source threat modeling methodology and tool. The project began in 2006 as an attempt to improve the efficiency and effectiveness of existing threat modeling methodologies, and is being actively used and developed.
http://www.octotrike.org/#:~:text=Trike%20is%20an%20open%20source,being%20actively%20used%20and%20developed.




  • VAST
The Visual, Agile and Simple Threat (VAST) methodology[12], is based on ThreatModeler, a commercial automated threat-modeling platform. VAST requires creating two types of models: application threat models and operational threat models. Application threat models use process-flow diagrams, representing the architectural point of view. Operational threat models are created from an attacker point of view based on DFDs. This approach allows for the integration of VAST into the organization's development and DevOps lifecycles
https://en.wikipedia.org/wiki/Threat_model





  • OCTAVE
OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is an approach to identify, assess, and manage risks to IT assets. This process identifies the critical components of information security and the threats that could affect their confidentiality, integrity, and availability. This helps them understand what information is at risk and design a protection strategy to reduce or eliminate the risks to IT assets.

https://www.eccouncil.org/threat-modeling/




  • DREAD
DREAD methodology is used to assess, analyze, and find the probability of risk by rating the threats as described in the image below.
https://www.eccouncil.org/threat-modeling/

















  • Persona non grata
This method is similar to criminal profiling in law enforcement. To anticipate attacks in more detail, brainstorming exercises are performed to create a detailed picture of a hypothetical attacker, including their psychology, motivations, goals, and capabilities.
https://www.cisco.com/c/en/us/products/security/what-is-threat-modeling.html#~methods-and-tools
  • Attack trees are conceptual diagrams showing how an asset, or target, might be attacked. Attack trees have been used in a variety of applications. In the field of information technology, they have been used to describe threats on computer systems and possible attacks to realize those threats.
https://en.wikipedia.org/wiki/Attack_tree
  • GDPR enforces the implementation of Privacy-by-Design and Privacy-by-Default paradigms to be embedded within the software development lifecycle. But how should you execute a thorough privacy assessment of your software system?

LINDDUN is a privacy threat modeling methodology that supports analysts in systematically eliciting and mitigating privacy threats in software architectures.
LINDDUN provides support to guide you through the threat modeling process in a structured way.
In addition, LINDDUN provides privacy knowledge support to enable also non-privacy experts to reason about privacy
https://www.linddun.org/
  • VAST
VAST (Visual, Agile, and Simple Threat) methodology is based on automated threat modeling that covers the software development life cycle across the organization with proper integration with tools and collaboration with all key stakeholders like developers, architects, security professionals, and leaders across the organization.
https://www.eccouncil.org/threat-modeling/