How to do Threat Modeling

Firstly, answer four questions

1. What are we working on?

• draw first picture on whiteboard
• collaborate with stake holders on the whiteboard.

2. What can go wrong?

• use STRIDE as a guid.
  Spoofing
  Tampering
  Repudiation
  Information disclosure
  Denial of service
  Elevation of privilege

• draw trust boundary on the whiteboard, and focus our analysis of what can go wrong near or inside this boundary.

• look for each STRIDE threat across each part of the diagram, or each part of the diagram that’s inside relevant trust boundaries.

3. What are we going to do about it?

• Track them.
  note them with stickers: how they are found (STRIDE), how they might work.
  transfer them to bug tracking system, e.g., JIRA
• test to see if it’s a real issue, and document that you did that.
• priorities fix them

4. Did we do a good job?

To reflect on

• Is the work done?
  Are there clear answers to question 1, 2 and 3?
• is there a record of a specific instance of a threat against each element in the diagram?
  defining the bad thing that can happen with more specificity: what and where it could happen. Vague about who and why.

STRIDE

Sproofing

authentication

• captcha
• delay login attempts by a minute or exponential backoff.
• MFA(multi factor authentication): Google Authenticator.
• etc.

Tampering

unauthorized modification.

• For local files, configure operating system permissions.
• In the cloud, make use of the permissions the system provides
• And for network systems, use cryptographic integrity protection like what’s included in TLS.

Repudiating

• Logs: who did what and when?
• Complaint management: Customer sends a complaint and gets a tracking number back. We kick off an investigation gathering, correlating and analyzing the logs and may need to get some additional information from the customer. With all the information in hand a decision can be made and communicated back to the customer.

Information disclosure

• Secrets needs to be kept a secret relative to different audiences.
• On the network, the best confidentiality comes via cryptography.
• Within a system, it can be easier to use permissions.
• Sometimes the mere occurrence of communication (the metadata of communication), not the content of communication, can be interesting to some people.

Denial of Service

• There are DoS attacks against processors, networks, and storage, event against batteries and your wallet.
• Symmetric DoS attack: attacker and defender spend roughly the same amount of resources.
• Asymmetric DoS attack: chew up way more of the defender’s resources than the attacker’s.
• The simplest way to defend against DoS attacks is with an abundance of resources that are hard for attackers to exhaust, but expensive
• Defending against distributed attacks is something best done at the network or cloud provider layers.
• Defending against clever attacks requires that you profile your applications and know how they’re going to behave.

Elevation of privilege

• Reducing the set of restrictions applied to you.
• admin control panel
• how unprivileged input is parsed
• confusion about the difference between code and data (SQL injection attack, cross-site scripting attack, from Userland to Root)
• protect against confusion in their environment, state, argument parsing or anyplace else it might take input.

總結

以上是生活随笔為你收集整理的How to do Threat Modeling的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。