Reference no: EM13907184

The Thread Risk Analysis and Modeling Process

1. Assemble the threat-modeling team.
2. Decompose the application.
3. Determine the threats to the system
4. Rank the threats risk by decreasing risk.
5. Choose how to respond to the threats
6. Choose techniques to mitigate the threats
7. Choose the appropriate technologies for the identified techniques. A. Assemble the threat risk modeling team (less than 10)
Security person

Members of design, development, testing, documentation, sales teams;

Communicate the goal of the meetings: to find threats, not to fix them

The iterative process should not take for ever

Decompose the application

Create high level diagrams of system components

Iteratively decompose the previous diagram layer, making sure all important elements are captured (remember the threat tree example)

C. Determine the threats and countermeasures for system components

Determine the Threat Risks

Rank the threats risk by decreasing risk.

Choose how to respond to the threats

Choose techniques to mitigate the threats

Choose the appropriate technologies for the identified techniques.

B. Decompose the application. Create high level diagrams of system components

1. Use DFDs(Data Flow Diagrams)[1]
https://www.slideshare.net/starbuck3000/threat-modeling-web-applications
Slides 53- include DFD demos
Not easy (Developers, other stakeholders)

2. Use the Thread Risk Analysis and Modeling Tool from Microsoft (TRAM)

Wizard based
Makes easier for developers to build the Thread Risk Model
Ensures detailed information is retained
Helps with Knowledge sharing between projects
Evaluates the application vulnerabilities to create a prioritized set of countermeasures to measure and contain the risks.

B.2. Create high level diagrams of system components (continued)

The list of components and their interactions help suggest the threat trees

Define User Roles such as Administrator, User, Web Designer, Auditor

Define Data Groups: Define the logical data groups in your application based on the functionality in the application; for example Payroll Data, Authentication Data, Web Pages, Web Service Code

Define Data Access Control: List what a user can do in the application: create, read, update, and/or delete (CRUD) within that group and add conditions, if any

Define Components, Service Roles, and Identities and Select Component Relevancies:

B.2. Create high level diagrams of system components (continued)

The list of components and their interactions help suggest the threat trees
For technologies not listed in the attack library, import the attack library: Tools -> Attack Library -> Import.

Generate/Create Use Cases: Menu item: Tools -> Generate Use Cases. The cases are based on the information from the previous steps.

Define CALLS: Detail each use case with its appropriate call structure: data sent/data received and authorization entries. You can copy/paste or drag/drop calls from one use case to another. Check each use case by looking at Call, Data and Trust flow Visualizations

) Determining Threats Risks and Countermeasures

Generate and Evaluate Threats: Tools -> Generate Threats, click "OK" to generate threats. Then evaluate each threat risk by selecting appropriate risk factors and risk response.

Use DREAD for evaluation.

Refresh Countermeasures: Tools -> Refresh Countermeasures, will identify countermeasures for each threat.

Analyze the Threat Trees

Customize Metadata: Tools -> Options -> metadata Editor

Download and install the TAM tool. Perform Threat Risk Modeling of the Payroll Application[1] using TAM. Submit 10 slides different than the slides given here as sample.

Provide at last 6 Analytics, Visualization or Reports Results including customization and additional configuration screens.
Check slides 4 for TAM tool and instruction

SwSecurity Design Best Practices

Addressing STRIDE concerns

Spoofing(Impersonation) vs Authentication

Spoofing(Impersonation) vs Authentication
Attacker steals or guesses another user's credentials
Attacker changes Session Cookie's content to make it appear as coming from another user or another server

Spoofing Countermeasures

Implement strong authentication
Use Operating system frameworks
(e.g.) Kerberos
Use Encrypted Session cookies
Use Digital Signatures

Weaknesses(Spoofing)

Using unencrypted credentials
Storing credentials in cookies/ parameters
Self-designed/unproven authentication methods
Authentication to the wrong trust domain

Tampering vs information integrity
WebSite Defacement
Changing data in transit

Tampering Countermeasures

Use operating system security to lock down files, directories, other resources
Validate and Sanitize input data
Encrypt/sign data in transit (SSL/ IPSec)

Weaknesses(Tampering)

Using data sources without validation
Running with escalated privileges
Unencrypted Sensitive data
Missing Input Validation

SwSecurity Design Best Practices

Attachment:- HomeWorkSecurity.rar