Improving web application security, part ii

Improving Web Application Security, Part-II – Threat Modeling

KANGKAN GOSWAMI

CORPORATE PRESENTATION

Agenda Steps to decompose an application architecture to discover vulnerabilities

How to identify and document threats that are relevant to the application

Slide 2


Threat Modeling Principles The Process

•Identify assets.

•Create an architecture overview.

•Decompose the application.

•Identify the threats.

•Document the threats.

•Rate the threats.

Slide 3


The Process Identify assets.

Create an architecture overview.

Decompose the application.

Identify the threats.

Document the threats.

Rate the threats.

Slide 4


The Output

Slide 5


Threat Modeling ProcessStep 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.

Slide 6


Threat Modeling ProcessStep 2. Create an Architecture Overview

Identify what the application does.

Create an architecture diagram.

Identify the technologies.

Slide 7


Threat Modeling ProcessStep 3. Decompose the Application

Identify trust boundaries.

Identify data flow.

Identify entry points.

Identify privileged code.

Document the security profile.

Slide 8


Threat Modeling ProcessStep 4. Identify the Threats

Identify network threats.

Identity host threats.

Identify application threats.

Slide 9


Threat Modeling ProcessStep 5. Document the Threats

Documenting the threats

Document target

Document Risk

Document Attack Technique

Document Countermeasure

Slide 10


Threat Modeling ProcessStep 6. Rate the Threats

Estimate the Probability

Estimate Damage Potential

Estimate Risk ()

Scale them – HIGH, MEDIUM, LOW

Prioritize – DREAD Model

Recalculate Risk Rating

Slide 11


Creating Architecture Overview Identify what the application does.


Identify the technologies.

Slide 12


Creating Architecture OverviewIdentify 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.

Slide 13


Creating Architecture OverviewCreate 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

Slide 14


Creating architecture diagram

Slide 15


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


Creating Architecture OverviewIdentify 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.

Slide 16


Identify the technologiesDocument the technologies using a tableTechnology/Platform Implementation DetailsMicrosoft SQL Server on MicrosoftWindows 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.

Slide 17


Decomposing the Application Identify trust boundaries.

Identify data flow.

Identify entry points.

Identify privileged code.

Document the security profile.

Slide 18


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.

Slide 19


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.

Slide 20


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.

Slide 21


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.

Slide 22


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.

Slide 23


Document the security profileCategory 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….

Slide 24


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

Slide 25


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.

Slide 26


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.

Slide 27


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.

Slide 28


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.

Slide 29


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.

Slide 30


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.

Slide 31


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

Slide 32


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.

Slide 33


Rate the Threats - DREAD RatingAt 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?

Slide 34


Rate the Threats - DREAD

Slide 35


Rate the Threats

Slide 36

Update the documented Threat List with RISK RATING


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.

Slide 37


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.

Slide 38


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.

Slide 39


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.

Slide 40


Request

Please read the book…..https://msdn.microsoft.com/en-us/library/ff649874.aspx

Slide 41


Open House

Questions and possible answers

Slide 42


Thanks a lot…

Slide 43

Software

Improving web application security, part ii