Link to Youtube video: https://youtu.be/OJMqMWnxlT8 You can contact me at abhimanyu.bhogwan@gmail.com My linkdin id : https://www.linkedin.com/in/abhimanyu-bhogwan-cissp-ctprp-98978437/ Threat Modeling(system+ enterprise) What is Threat Modeling? Why do we need Threat Modeling? 6 Most Common Threat Modeling Misconceptions Threat Modelling Overview 6 important components of a DevSecOps approach DevSecOps Security Best Practices Threat Modeling Approaches Threat Modeling Methodologies for IT Purposes STRIDE Threat Modelling Detailed Flow System Characterization Create an Architecture Overview Decomposing your Application Decomposing DFD’s and Threat-Element Relationship Identify possible attack scenarios mapped to S.T.R.I.D.E. model Identifying Security Controls Identify possible threats Report to Developers and Security team DREAD Scoring My Opinion on implementing Threat Modeling at enterprise level

1. Threat Modeling
(System + Enterprise)

2. • ABHIMANYU BHOGWAN
• CISSP ,CTPRP , ISO27001 LA,ITILv3
• SKILLS
• Risk Management, Cyber Security, Governance, and Compliance Management Life
Cycle
• Threat Modeling
• DevSecOps and Security Champion Program
• Third Party Risk and Internal Risk Assessment
• Best practices and laws relating to data privacy and protection
• GRC tools, IAM, SIEM, intrusion detection and prevention
• systems, and data diodes. NIST SP 800-53/82, NERC CIP, NEI 08-09, ISA 99, NIST CSF and
C2M2
• SOC 1,2,3 , ISO series standards, PCI-DSS , SOX , COBIT,ITGC, HIPAA , GLBA , GDPR, IT
ACT 2000, Data Privacy Bill , RBI guidelines
• Strong verbal and written communication skills
• Strong existing relationships within the Cybersecurity and IT executive ranks
• Engineering analyses, assessments, audits or penetration testing reports. Write
technical and business reports

4. What is 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?”.

5. Why do we need Threat Modeling?
• You prevent security flaws when there is time to fix them: in the design phase. But there are
many more reasons to start with threat modeling today, such as:
• You select a mitigation strategy and techniques based on identified, documented and rated
threats.
• You identify and address the greatest risks.
• You are able to prioritize development efforts within a project team based on risk weighting.
• You increase risk awareness and understanding.
• You use mechanisms for reaching consensus and better trade-off decisions.
• You also make use of threat modeling to communicate results.
• You benefit from cost justification and support for needed controls.
• You use artifacts to document due diligence for each software project.

6. 6 Most Common Threat Modeling
Misconceptions
• We already conduct penetration tests and code reviews. We’re covered.
• Implementation bugs and architectural flaws are different
• We already deployed our system. There’s no reason to conduct a threat model.
• You have no information about your production security posture.
• You have no information about deployed defenses and attack surfaces.
• Future deployments can’t defend against existing limitations and vulnerabilities.
• Future deployment can’t take advantage of existing defenses.
• We carried out a threat model when the software was built. There’s no reason to do it again.
• It is important to know if anything changed in the system since the last threat model.
• We’ve considered threat modeling and feel that it is way too complicated.
• If you break up the tasks into the five workable steps, performing a threat model on a simple web application, and
even a complex system architecture, becomes systematic.
• The key is to start off with the basics. Create threat models for simple web applications. Once you’re comfortable
with this process, move to more complex systems such as mobile platforms, embedded software, and cloud based
technologies
• We don’t have software security experts, so we can’t do threat modeling.
• We’re threat modeling at all the right times, so we don’t need additional security activities.
• While threat modeling identifies weaknesses, it doesn’t evaluate exploitability.
• Thus, the weaknesses found through threat modeling may or may not be actual vulnerabilities. Subsequent activities
such as penetration testing and code reviews can evaluate this exploitability of the weaknesses found during threat
modeling.

7. Threat Modelling Overview
7

8. Example Scenario

9. Term Definition Example
Threat agent an individual or group that can manifest a threat. It is
fundamental to identify who would want to exploit
the assets of a company, and how they might use
them against the company
Attacker
Attack Any kind of malicious activity that attempts to collect,
disrupt, deny, degrade, or destroy information system
resources or the information itself
Denial of Service
Attack vector is a path or means by which a hacker (or cracker) can
gain access to a computer or network server in order
to deliver a payload or malicious outcome.
Email
Vulnerability Weakness in an information system, system security
procedures, internal controls, or implementation that
could be exploited or triggered by a threat source.
Adobe Reader DC Classic (v15.006.30119)
Exploit a piece of software, a chunk of data, or a sequence of
commands that takes advantage of a bug or
vulnerability in order to cause unintended or
unanticipated behaviour to occur
Malicious PDF containing executable code that
exploits CVE-2016-1009
Attack surface
area
is the sum of the all vulnerabilities where an attacker
can try malicious activity
All instances of the vulnerable version of Adobe Reader DC
Classic (v15.006.30119)

10. Threat Modeling Approaches:
• Asset Centric
• Involve identifying the assets of an organization entrusted to a system or software data processed
by the software.
• Data assets are usually classified according to data sensitivity and their intrinsic value to a
potential attacker, in order to prioritize risk levels
• Attacker Centric
• require profiling an attacker’s characteristics, skill-set, and motivation to exploit vulnerabilities.
• The profiles are then used to develop an understanding of potential attackers who would be most
likely to execute specific types of exploits.
• Based on the understanding of potential attackers, organizations can implement an appropriate
mitigation strategy.
• Software Centric
• This approach involves the design of the system and can be illustrated using software architecture
diagrams such as data flow diagrams (DFD), use case diagrams, or component diagrams
• This method is commonly used to analyze networks and systems and has been adopted as the de-
facto standard among manual approaches to software threat modeling
• Hybrid Approach
• It involves using all the best practices of above 3 approaches.
• We will be using this approach in understanding threat modeling.

11. Threat Modeling Methodologies for IT Purposes
• STRIDE methodology
• The STRIDE approach to threat modeling was introduced in 1999 at Microsoft, providing a mnemonic for developers to
find 'threats to our products'. STRIDE, Patterns and Practices, and Asset/entry point were amongst the threat modeling
approaches developed and published by Microsoft.
• P.A.S.T.A.
• 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.
• Trike
• The focus of the Trike methodology is using threat models as a risk-management tool. Within this framework, threat
models are used to satisfy the security auditing process. Threat models are based on a “requirements model.”
• The requirements model establishes the stakeholder-defined “acceptable” level of risk assigned to each asset class.
Analysis of the requirements model yields a threat model from which threats are enumerated and assigned risk values. .
• VAST
• VAST is an acronym for Visual, Agile, and Simple Threat modeling.
• The underlying principle of this methodology is the necessity of scaling the threat modeling process across the
infrastructure and entire SDLC, and integrating it seamlessly into an Agile software development methodology.

13. Threat Modelling Detailed Flow

14. 14
System
Characterization
Threat Modelling Process
Flow
Create an
Architecture
Overview
Decomposing your Application
Identifying Security
Controls
Identify possible
threats
Report to
Developers and
Security team
Decomposing DFD’s and
Threat-Element
Relationship
Identify possible attack
scenarios mapped to
S.T.R.I.D.E. model

15. System
Characterization
• Define asset category, asset purpose.
• System Interfaces
• Data type, description, classification, etc.
• Users
• Network Diagrams
• Logical Architecture Diagram
• Create a model of
soPware/system/technology
• Decompose the application
• Design data flows, Trust boundaries, Swim
Lanes and State Models.

16. Create an Architecture Overview
1
Draw the end-to-end
deployment scenario
•End to end deployment
topology
•Logical layers
•Key components
•Key services
•Communications
ports/protocols
•Identities
•External dependencies
2
Identify roles
•Identify your application's
roles: that is, identify who
can do what within your
application. What can your
users do? What higher-
privileged groups of users do
you have?
3
Identify key usage
scenarios.
•Identify the dominant
application functionality and
usage, and capture the
Create, Read, Update, and
Delete aspects
4
Identify technologies
•Operating systems
•Web server software
•Database server software
•Technologies used in the
presentation, business, and
data access layers
•Development languages
5
Identify application
security mechanisms
•Input and data validation
Authentication
•Authorization
Configuration management
•Sensitive data
Session management
•Cryptography
Parameter manipulation
•Exception management
Auditing and logging

17. Decomposing your Application
• Identify trust boundaries
• Trust boundaries indicate where trust levels change. You can think of trust from the perspective of confidentiality and integrity
• Start by identifying your outer system boundaries
• Identify access control points or the key places where access requires additional privileges or role membership
• Identify trust boundaries from a data flow perspective
• Knowing which entry points exist between trust boundaries allows you to focus your threat identification on these key entry points.
• Identify data flows
• Trace your application's data input through the application from entry to exit
• Pay particular attention to data flow across trust boundaries and how that data is validated at the trust boundary entry point
• Pay close attention to sensitive data items and how these flow through your system, where they are passed over a network, and
where they are persisted
• Identify entry points
• The entry points of your application also serve as entry points for attacks
• Consider the trust levels required to access an entry point and the type of functionality exposed by the entry point
• focus your attention on entry points that expose privileged functionality, such as administration interfaces.
• Identify exit points
• Identify the points where your application sends data to the client or to external systems
• Prioritize the exit points where your application writes data that includes client input or includes data from untrusted sources, such
as shared databases

18. Decomposing methods
Whiteboard
Diagrams
Brainstorming
Structured
(“formal”)
diagrams
Data Flow
Diagrams
Swim Lanes
State
Machines

19. Decomposing DFD’s and Threat-Element Relationship
 Once we have DFDs in place , we further
simplify them into tabular form.
 The Data Flow Diagram is broadly divided
into four elements.
 Then the STRIDE model is applied to Data
Flow Diagram and efficient threat-
element relationship is established.
Elements
External Entity
Process
Data Storage
Data Flow
Element Type Threat Types
S T R I D E
External Entity X X
Process X X X X X X
Database X X X X
Data Flow X X X

20. Identify possible attack
scenarios mapped to
S.T.R.I.D.E. model

21. Threat Agents Possible Attacks Attack Surfaces
Spoofing
Local Machine
Network
Spoofing a: Process | Filename
Spoofing a: Machine | Role | Person
Identify possible
attack scenarios
Spoofing
Tampering
Repudiation
Information
Disclosure
Denial Of
Service
Mapping attacks
to S.T.R.I.D.E
Software
Hardware
Communications
Supply Chain
Social Engineering
Identify Scope of Attack
Tampering
File
Memory
Modifying a: Server | File | Redirects
Modifying a: Code | Data
Network Modifying a: Redirects the flow of data | Data
flowing over networkRepudiation
Repudiation
Attack of Logs
Repudiating an action
Modifies data flowing over the network
Information Disclosure
Processes
Data Stores
Extracts user data | Extracts Machine Secrets
Permission | Security | Network | Misc.
Denial of Service
Against a: Process | Data Store | Data Flow
Data Flow Network | Metadata
Elevation of Privilege
EoP against process via corruption
EoP via: misused authorization checks | buggy authorization checks
EoP via Data tampering
Elevation of
Privilege

22. Mapping from Attack Patterns To Risk Items.
Attack
Patterns
STRIDE
Attack
Vectors
Exploits
Threat
Category
Security
weakness

23. Mapping Screenshots

24. 24NCR Confidential - Internal Use Only
After we have threat-element relationship, we can relate them to the defined Categories and Sub-Categories. This is
done as follows:
Categories Sub
Categories
External Entity Data Flow Database Process
Spoofing Local Machine
Network
Spoofing a: Process |
Filename
Spoofing a: Machine |
Role | Person
• IP Spoofing
• Session Hijacking
• Offline password
attacks
• Man in the middle
attack - XSS
NA NA • DNS Spoofing
• ARP poisoning
• URL spoofing
• Content spoofing
• MITM
Tampering File
Memory
Network
Modifying a: Server |
File | Redirects
Modifying a: Code |
Data
NA • Sniffing attack
• Replay Attack
• MITM
• SQL injection • Protocol
Manipulation
• Communication
Channel
Manipulation
Repudiation Repudiation
Attack of Logs
Repudiating an action
Modifies data flowing
over the network
Modifies data flowing
over the network
• Repudiation Attack
• Log Injection
• Web parameter
tampering by MITM
NA • Log file manipulation via
SQL injection
• Privilege Abuse
• Configuration/Enviro
nment Manipulation
Information
Disclosure
Processes
Data Stores
Data Flow
Extracts user data |
Extracts Machine
Secrets
Permission | Security |
Network | Misc
Network | Metadata
NA • Side channel Analysis
• Sniffing
• SQL Injection • Fault Injection
• Interception
Denial of
Service
Process
Data Stores
Data Flow
NA NA • Flooding
• Forced Deadlock
• Obstruction
• Buffer Manipulation
• Empty DB tried to be read
or full DB tried to be
written
• Forced browsing
• Resource consumption
attacks
• DOS attack
• XSS, a link may redirect to
another one leading DOS
for actual link
Elevation of
Privileges
EoP via: Process Corruption | Misused
Authorization Checks | Data Tampering
NA NA NA XSS

25. Identifying Security Controls
• We can identify all respective security controls
in place or missing using various methods like
Risk Assessments , Vulnerability assessments,
internal control testing etc.
• Once we have the list of security controls
missing we can get all relevant possible
threats and depending on the priority and
criticality of threats , take action accordingly.

26. • We will identify following parameters :
• Threat agents
• Attack surface elements
• Possible attack scenarios
• Vulnerabilities
• Exploits
• Attack vectors
• Business Impact
• Existing Controls
• We will use this data as an input for issue management, internal risk assessments and vendor risk
management to identify potential risks.
• We will be using DREAD methodology for defining threat severity and rank potential threats accordingly.
• Risks can be analyzed and scored using risk Scoring Methodology like FAIR.

27. Threat
Rating using
DREAD
27
DREAD is a framework that can be used to evaluate and
triage various threats by rating them on an ordinal scale.
The framework is broken into five main categories: Damage,
Reproducibility, Exploitability, Affected Users, and
Discoverability.
It takes into account the following items:
• Damage potential (How much are the assets affected?)
• Reproducibility (How easily the attack can be
reproduced?)
• Exploitability (How easily the attack can be launched?)
• Affected users (What’s the number of affected users?)
• Discoverability (How easily the attack can be found?)

28. Threat Ranking using DREAD Methodology
DREAD Average Ranking
Damage Potential – If a threat exploit
occurs, evaluate the damage caused
1= Nothing
2= Individual user data compromised
3=Complete system or data destruction/Just
a web browser is enough
Exploitability – What is needed to exploit
this threat?
1 = Advanced programming & networking
knowledge
2 = Malware exists on the Net, or any tolls
available
3 = Just a web browser is enough
Reproducibility – How easy is it to reproduce the threat
exploit?
1 = Very hard or impossible even for administrators/DBAs
2 = One or two steps required, may need an authorized user
3= Possible by an unauthorized user
Affected Users – How many users are affected?
1 = None
2 = Some users, but not all
3 = All users
Discoverability – How easy is it to discover the threat
1 = Very hard or impossible; needs source code or admin
access
2 = Can figure it out by guessing or monitoring network
traces
3 = Information is visible in the web browser or address bar
or in the form or as a hidden variable

29. Finally use the formula:
Average Threat Ranking = (D + R + E + A + D)
The Threat Rating will
be assessed as
High/Medium/Low
according to the score:
If Score is from 5-8 =
Low
If score is between 9-
12 = Medium
If score is between 13-
15 = High

30. My Opinion
on
implementing
Threat
Modeling at
enterprise
level
The threat model portfolio has to expand to include all DevOps
projects, deployed applications, on-premises, and cloud-based
environments, mobile, IoT systems, computing endpoints, and
other cyber-physical systems.
Map your Attack patterns with Threat Categories and
weaknesses across different platforms using Mappings with
CWE, CVSS or generic process based weaknesses. Once its done
, aggregate all respective data at a centralized platform.
All assessments, audits, testing at every level in organization
can be mapped with Threat modeling and It will help to
provide an overall security posture.
You can create dashboard/reports as per Org function or team
and see what is the threat posture in that organization function
wise. You can easily segregate threats in terms of severity and
prioritize which threats need to be be fixed on priority.

31. THANK YOU