Part 2 of the study with the accompanying book: https://msdn.microsoft.com/en-us/library/ff649874.aspx
This is a n architectural study for making application software resilient to security threat.
2. Agenda
Steps to decompose an application architecture to discover vulnerabilities
How to identify and document threats that are relevant to the application
CORPORATE PRESENTATION
Slide 2
3. Threat Modeling Principles
The Process
•Identify assets.
•Create an architecture overview.
•Decompose the application.
•Identify the threats.
•Document the threats.
•Rate the threats.
CORPORATE PRESENTATION
Slide 3
4. The Process
Identify assets.
Create an architecture overview.
Decompose the application.
Identify the threats.
Document the threats.
Rate the threats.
CORPORATE PRESENTATION
Slide 4
6. Threat Modeling Process
Step 1. Identify Assets
Identify the assets that we need to protect.
This could range from confidential data, such as customer or orders database, the Web pages or Web site
availability.
CORPORATE PRESENTATION
Slide 6
7. Threat Modeling Process
Step 2. Create an Architecture Overview
Identify what the application does.
Create an architecture diagram.
Identify the technologies.
CORPORATE PRESENTATION
Slide 7
8. Threat Modeling Process
Step 3. Decompose the Application
Identify trust boundaries.
Identify data flow.
Identify entry points.
Identify privileged code.
Document the security profile.
CORPORATE PRESENTATION
Slide 8
10. Threat Modeling Process
Step 5. Document the Threats
Documenting the threats
Document target
Document Risk
Document Attack Technique
Document Countermeasure
CORPORATE PRESENTATION Slide 10
11. Threat Modeling Process
Step 6. Rate the Threats
Estimate the Probability
Estimate Damage Potential
Estimate Risk ()
Scale them – HIGH, MEDIUM, LOW
Prioritize – DREAD Model
Recalculate Risk Rating
CORPORATE PRESENTATION Slide 11
12. Creating Architecture Overview
Identify what the application does.
Create an architecture diagram.
Identify the technologies.
CORPORATE PRESENTATION Slide 12
13. Creating Architecture Overview
Identify what the application does.
Identify what the application does and how it uses and accesses assets.
Document use cases to help the team understand how the application is supposed to be used.
This also helps to work out how it can be misused.
CORPORATE PRESENTATION Slide 13
14. Creating Architecture Overview
Create an architecture diagram.
Create a high-level architecture diagram
It should describe the composition and structure of the application
It should include its subsystems as well as its physical deployment characteristics
CORPORATE PRESENTATION Slide 14
15. Creating architecture diagram
CORPORATE PRESENTATION Slide 15
Create an architecture diagram.
Start with a rough diagram that
conveys the composition and
structure of the application and its
subsystems together with its
deployment characteristics.
Evolve the diagram by adding details
about the trust boundaries,
authentication, and authorization
mechanisms
16. Creating Architecture Overview
Identify the technologies.
Identify the distinct technologies that are used to implement the solution.
This helps to focus on technology-specific threats later in the process.
It also helps to determine the correct and most appropriate mitigation techniques.
CORPORATE PRESENTATION Slide 16
17. Identify the technologies
Document the technologies using a table
Technology/Platform Implementation Details
Microsoft SQL Server on Microsoft
Windows Advanced Server 2000
Includes logins, database users, user defined
database roles,
tables, stored procedures, views, constraints,
and triggers
Microsoft .NET Framework Secure Used for Forms authentication.
Sockets Layer (SSL) Used to encrypt HTTP traffic.
CORPORATE PRESENTATION Slide 17
18. Decomposing the Application
Identify trust boundaries.
Identify data flow.
Identify entry points.
Identify privileged code.
Document the security profile.
CORPORATE PRESENTATION Slide 18
19. Identify trust boundaries
Identify the trust boundaries that surround each of the tangible assets of the application.
For each subsystem, consider how the data flows and input can be authenticated and authorized.
Also consider how the calling code can be authenticated and authorized.
Start by analyzing trust boundaries from a code perspective.
Also consider server trust relationships.
CORPORATE PRESENTATION Slide 19
20. Identify data flow
Start at the highest level and then iteratively decompose the application by analyzing the data flow
between individual subsystems.
Data flow across trust boundaries is particularly important.
Data from outside of its own trust boundary should be assumed to be malicious and perform thorough
validation of the data.
Data flow diagrams (DFDs) and sequence diagrams can help with the formal decomposition of a system.
CORPORATE PRESENTATION Slide 20
21. Identify entry points
The entry points of the application also serve as entry points for attacks.
Determine the types of gatekeepers that provide authorization and the degree of validation.
Logical entry points include UI (Web pages), service interfaces (Web services), serviced components, and
.NET Remoting components and message queues (asynchronous entry point).
Physical or platform entry points include ports and sockets.
CORPORATE PRESENTATION Slide 21
22. Identify privileged code
Privileged code accesses specific types of secure resources (DNS servers, directory services) and performs
other privileged operations.
Privileged code must be granted the appropriate code access security permissions.
CORPORATE PRESENTATION Slide 22
23. Document the security profile
Identify the approaches used for input validation, authentication, authorization, configuration
management, and the remaining areas where applications are most susceptible.
Consider the next table as a sample.
CORPORATE PRESENTATION Slide 23
24. Document the security profile
Category Considerations
Input validation Is all input data validated?
Could an attacker inject commands or malicious data into the application?
Is data validated as it is passed between separate trust boundaries (by the recipient
entry point)?
Can data in the database be trusted?
Authentication Are credentials secured if they are passed over the network?
Are strong account policies used?
Are strong passwords enforced?
Are you using certificates?
Are password verifiers (using one-way hashes) used for user passwords?
Refer the book for the rest….
CORPORATE PRESENTATION Slide 24
25. Identify the Threats
Use STRIDE to identify threats.
◦ Refer the STRIDE Model
Use categorized threat lists.
◦ Start with a laundry list of common threats grouped by network, host, and application categories.
◦ Apply the threat list to the application architecture and any vulnerabilities
CORPORATE PRESENTATION Slide 25
26. Identify Network Threats
Look for existence of security mechanisms that rely on the IP address of the sender. (IP spoofing is easy)
Possibility of passing session identifiers or cookies over unencrypted network channels. (Session hijacking)
Possibility of passing clear text credentials or other sensitive data over unencrypted communication
channels. (Eavesdropping)
You must also ensure that your network is not vulnerable to threats arising from insecure device and
server configuration.
CORPORATE PRESENTATION Slide 26
27. Identify Host Threats
Un-patched servers can be exploited by viruses, Trojan horses, worms, and IIS attacks.
Using nonessential ports, protocols, and services increase the attack profile and enable attackers to
gather information about and exploit the environment.
Unauthenticated anonymous access.
Weak passwords and account policies that lead to password cracking, identity spoofing, and denial of
service attacks if accounts can be locked out deliberately.
CORPORATE PRESENTATION Slide 27
28. Identify Application Threats
Poor input validation leads to cross-site scripting (XSS), SQL injection, and buffer overflow attacks.
Passing credentials or authentication cookies over unencrypted network links can lead to credential
capture or session hijacking.
Weak password and account policies can lead to unauthorized access.
Failing to secure the configuration management aspects of your application, including administration
interfaces.
CORPORATE PRESENTATION Slide 28
29. Identify Application Threats
Storing configuration secrets, such as connection strings and service account credentials, in clear text.
Using over-privileged process and service accounts.
Using insecure data access coding techniques, which can increase the threat posed by SQL injection.
Using weak or custom encryption and failing to adequately secure encryption keys.
CORPORATE PRESENTATION Slide 29
30. Identify Application Threats
Relying on the integrity of parameters that are passed from the Web browser, for example, form fields,
query strings, cookie data, and HTTP headers.
Using insecure exception handling, which can lead to denial of service attacks and the disclosure of
system-level details that are useful to an attacker.
Doing inadequate auditing and logging, which can lead to repudiation threats.
CORPORATE PRESENTATION Slide 30
31. Identify the Threats
Using Attack Trees and Attack Patterns
◦ An attack tree is a way of collecting and documenting the potential attacks on the system in a structured and
hierarchical manner.
◦ By creating attack trees, we create a reusable representation of security issues that helps focus efforts.
◦ Create test plans to validate security design.
◦ Attack patterns are a formalized approach to capturing attack information in the enterprise.
CORPORATE PRESENTATION Slide 31
32. Identify the Threats
Document the Threats
◦ Use a template that shows several threat attributes similar to the one below.
◦ The threat description and threat target are essential attributes.
◦ The risk rating is used in the final stage of the threat modeling process while prioritizing the identified
threat list.
Threat Description Attacker obtains authentication credentials by monitoring
the network
Threat target Web application user authentication process
Risk
Attack techniques Use of network monitoring software
Countermeasures Use SSL to provide encrypted channel
CORPORATE PRESENTATION Slide 32
33. Rate the Threats
Risk = Probability * Damage Potential
◦ For example, if Probability=10 and Damage Potential=1, then Risk = 10 * 1 = 10.
◦ If Probability=1 and Damage Potential=10, then Risk = 1 * 10 = 10.
Use simple HIGH, MEDIUM and LOW ratings to prioritize risk.
CORPORATE PRESENTATION Slide 33
34. Rate the Threats - DREAD Rating
At Microsoft, the DREAD model is used to help calculate risk.
Damage potential: How great is the damage if the vulnerability is exploited?
Reproducibility: Ease of reproducing the attack?
Exploitability: How easy is it to launch an attack?
Affected users: Percentage of affected users
Discoverability: How easy is it to find the vulnerability?
CORPORATE PRESENTATION Slide 34
37. What is next?
The threat model can be used by the following groups of people:
Designers can use it to make secure design choices about technologies and
functionality.
Developers who write code can use it to mitigate risks.
Testers can write test cases to test if the application is vulnerable to the
threats identified by the analysis.
CORPORATE PRESENTATION Slide 37
38. Generating Work Item Report
Create a formalized work item report that can include additional attributes,
such as a Bug ID
Tie the threat in with the bug tracking system.
Use its reporting facilities to generate the report.
Make sure to include the original threat number to tie it back to the threat
model document.
Organize the threats by network, host, and application categories.
Within each category, present the threats in prioritized order.
CORPORATE PRESENTATION Slide 38
39. Summary
While we can mitigate the risk of an attack, we do not mitigate or eliminate
the actual threat.
Threats still exist regardless of the security actions and the
countermeasures we take/apply.
The reality is that we acknowledge the presence of threats and manage the
risks.
Threat modeling can help us manage and communicate security risks across
the team.
CORPORATE PRESENTATION Slide 39
40. Summary
Treat modeling is an iterative process.
The threat model should be a dynamic item that changes over time to cater
to new types of threats and attacks as they are discovered.
It should also be capable of adapting to follow the natural evolution of the
application as it is enhanced and modified to accommodate changing
business requirements.
CORPORATE PRESENTATION Slide 40