The document discusses application threat modeling for a college library website. It describes decomposing the application into external dependencies, entry points, assets, and trust levels. It then covers determining and ranking threats using STRIDE and ASF categorizations. The document outlines identifying security controls and countermeasures to address vulnerabilities. It provides steps for threat analysis and defining mitigation strategies.

1. Web Application Security (PHP)
Zakieh Alizadeh
zakiehalizadeh@gmail.com
APA Laboratory – Ferdowsi University of Mashhad

2. Session 2
Application Threat Modeling

3. Application Threat Modeling
 Scenario : “Producing Thread Model For The College Library Website”
 Table of Content
 Introduction
 Decompose The Application
o External Dependencies
o Entry Points
o Assets
o Trust Levels
 Determine And Rank Threats
o o Threat Categorization
o o Introducing STRIDE And ASF
 Security Controls
 Countermeasure Identification
 Mitigation Strategies

4. Application Threat Modeling
Decompose The Application
Determine And Rank Threats
Security Controls
 Countermeasure Identification
 Mitigation Strategies

5. Application Threat Modeling
Introduction
 Threat modeling is an approach for analyzing the security of an
application.
 It is a structured approach that enables you to identify, quantify, and
address the security risks associated with an application
 Threat modeling is not an approach to reviewing code, but it does
complement the security code review process.
 The inclusion of threat modeling in the SDLC can help to ensure that
applications are being developed with security built-in from the very
beginning.

6. Application Threat Modeling
Why Use Threat Modeling?
 Shape your application design to meet your security objectives.
 Help make trade-offs during key engineering decisions.(in different
conditions)
 Reduce risk of security issues arising during development and operations.

7. Application Threat Modeling
Terminology
 Threat.
o A threat is an undesired event. A potential occurrence, often best
described as an effect that might damage or compromise an asset or
objective. It may or may not be malicious in nature.
 Vulnerability
o A vulnerability is a weakness in some aspect or feature of a system
that makes an exploit possible. Vulnerabilities can exist at the network,
host, or application levels

8. Application Threat Modeling
Terminology
 Attack (or exploit).
o An attack is an action taken that utilizes one or more vulnerabilities to
realize a threat.
 Countermeasure.
o Countermeasures address vulnerabilities to reduce the probability of
attacks or the impacts of threats. They do not directly address threats;
instead, they address the factors that define the threats.

9. Application Threat Modeling
Terminology
 Authentication
 Authorization
 Confidentiality
 Integrity
 Availability

10. Application Threat Modeling
Approaches to threat modeling
 Attacker-centric
 Software-centric
 Asset-centric

11. Application Threat Modeling
Approaches to threat modeling
 Attacker-centric
o Attacker-centric threat modeling starts with an attacker, and evaluates
their goals, and how they might achieve them. Attacker's motivations
are often considered, for example:
Attacker-centric:
"The attacker wants login illegal”
Simple Thread modelling:
Identify thered  guest password
Countermeasure Identification.
Mitigation Strategies  allow 4 time
enter incorrect password, then block
user

12. Application Threat Modeling
 Approaches to threat modeling
 Software-centric
o threat modeling (also called 'system-centric,' 'design-centric,' or 'architecture-centric')
starts from the design of the system, and attempts to step through a model of the
system, looking for types of attacks against each element of the model.
Attacker-centric:
"The attacker wants login illegal”
Simple Thread modelling:
Identify thered  guest password
Countermeasure Identification.
Mitigation Strategies  allow 4 time
enter incorrect password, then block
user

13. Application Threat Modeling
Approaches to threat modeling
 Asset-centric
o threat modeling involves starting from assets entrusted to a system,
such as a collection of sensitive personal information.
Asset:
“User Personall data”
Simple Thread modelling:
Identify thered  Acceess data via SQL Injection
Countermeasure Identification.
Mitigation Strategies
1. Secure DataBase
2. Data Validation Strategies

14. Application Threat Modeling
Threat Modeling Perspective
 Threat modeling has changed in recent times (around 2004) to take on a
more defensive perspective rather than an adversarial perspective. The
problem with an adversarial perspective is that it is reactive.
o defensive perspective
o adversarial perspective

15. Application Threat Modeling
adversarial perspectiev
 examine software applications, trying to find holes in it they might be
exploited. Techniques :
o penetration testing (white box and black box)
o and code review.
 Disadvantages:
o use them once the software has been written.
o defensive mechanisms patched in later
o security bugs vs functionality bugs. Since code around security usually
touches every portion of the application, the 'ripple effect' makes the
cost exponentially more expensive than functionality bugs.

16. Application Threat Modeling
defensive perspective
 This means that threats are examined and countermeasures, or security
services, are identified at the design state of the application before any
code is written. This way the defensive mechanisms are built into the
code as it is written rather than patched in later.
 Disadvantages:
o all threats can not be identified unless the code is trivially simple and
often threat modeling on a defender's perspective will cause the
development team to falsely believe that the code is secure.

17. Application Threat Modeling
defensive perspective
 Thread Modeling can be perform erly:

18. Application Threat Modeling
defensive perspective
 Thread Modeling can also be perform later:

19. Application Threat Modeling
Steps
 Decompose The Application
o External Dependencies
o Entry Points
o Assets
o Trust Levels
 Determine And Rank Threats
o Security Controls
 Countermeasure Identification
 Mitigation Strategies

20. Application Threat Modeling
Decompose The Application
 External Dependencies
o External dependencies are items external to the code of the application
that may pose a threat to the application. These items are typically still
within the control of the organization, but possibly not within the control
of the development team. Such as Server, database server,…
 Entry Points
o Entry points define the interfaces through which potential attackers can
interact with the application or supply it with data. such as forms,Ports

21. Application Threat Modeling
Decompose The Application
 Assets
o The system must have something that the attacker is interested in;
these items/areas of interest are defined as assets. Such as user
personal data, company's reputation
 Trust Levels
o Trust levels represent the access rights that the application will grant to
external entities.

22. Application Threat Modeling
Decompose The “College Library Website”
 Model Information: documented as

23. Application Threat Modeling
 Decompose The “College Library Website”
 External Dependencies: documented as
o ID
o description

24. Application Threat Modeling
Decompose The “College Library Website”
 Entry Points: documented as
o ID
o Name
o Description
o Trust Levels

25. Application Threat Modeling
Decompose The “College Library Website”

26. Application Threat Modeling
Decompose The “College Library Website”
 Assets : documented as
o ID
o Name
o Description
o Trust Levels

27. Application Threat Modeling
Decompose The “College Library Website”
 Assets

28. Application Threat Modeling
 Decompose The “College Library Website”
 Assets

29. Application Threat Modeling
 Decompose The “College Library Website”
 Assets

30. Application Threat Modeling
 Decompose The “College Library Website”
 Trust Levels

31. Application Threat Modeling
Determine and Rank
 Threat Categorization
 The first step in the determination of threats is adopting a threat
categorization. A threat categorization provides a set of threat categories
with corresponding examples :
o STRIDE :adversarial perspectiev
o Application Security Frame (ASF ): defensive perspective

32. Application Threat Modeling
 Determine and Rank Threats of
STRIDE ::adversarial perspectiev
Spoofing Tampering Repudition Information
disclosure
Elevation of
privilage
Denial
of service
ASF :: defensive perspective
Data
Protection in
Storage and
Transit
Exception
Management
Data
Validation
Configuration
Management
Authorization Authenticatio
n
Auditing &
Logging

33. Application Threat Modeling
 Determine and Rank Threats

34. Application Threat Modeling
Security Controls
 the review team should try to identify the set of controls that could
prevent these threat agents from causing those impacts. primary focus of
the code review :
o be to ensure that these security controls are in place,
o that these security controls work properly
o that these security controls are correctly invoked in all the necessary
places.
This is main goal of this
class

35. Application Threat Modeling
Security Controls
 Authentication
 Authorization
 Cookie Management
 Data/Input Validation
 Error Handling/Information leakage:
 Logging/Auditing:
 Secure Code Environment:
 Session Management:

36. Application Threat Modeling
Threat Analysis
 Threat analysis as such is the identification of the threats to the application,
and involves the analysis of each aspect of the application functionality .

37. Application Threat Modeling
 Countermeasure Identification
 The purpose of the countermeasure identification is to determine if there
is some kind of protective measure (e.g. security control, policy
measures) in place that can prevent each threat previosly identified via
threat analysis from being realized.
 Vulnerabilities are then those threats that have no countermeasures.
Since each of these threats has been categorized either with STRIDE or
ASF, it is possible to find appropriate countermeasures in the application
within the given category.

38. Application Threat Modeling
 Countermeasure Identification
 Some STRIDE Mitigation Techniques

39. Application Threat Modeling
Mitigation Strategies
 Do nothing: for example, hoping for the best
 Inform about the risk: for example, warning user population about the risk
 Mitigate the risk: for example, by putting countermeasures in place
 Accept the risk: for example, after evaluating the impact of the exploitation
 Transfer the risk: for example, through contractual agreements and insurance
 Terminate the risk: for example, shutdown, turn-off, unplug or decommission
the asset

40. Application Threat Modeling