You model because it enables you to find issues in things you haven’t built yet, and because it enables you to catch a problem before it start.
Threat modeling is a process that focuses on four questions:
- What are we working on (what are we building)?
- We use diagram (DFD) to address what are we building.
- We will actually start thinking about what can go wrong here.
- Adding trust boundaries to show who controls what is a simple way to improve the diagram. Good examples of this include the following:
- Network interfaces.
- Different physical computers.
- Organizational boundaries.
- What can go wrong?
- Identify threats: we can use STRIDE.
- Tips for identifying threats:
- Start with external entities. You might start with the web browser, looking for spoofing, then tampering, and so on.
- Never ignore a threat because it’s not what you’re looking for right now.
- Focus on feasible threats.
- What should we do about those things that can go wrong?
- There are four types of action you can take against each threat: mitigate it, eliminate it, transfer it, or accept it.
- Mitigating threats is about doing things to make it harder to take advantage of a threat. Mitigation is generally the easiest and the best for your customers.
- Eliminating threats is almost always achieved by eliminating features 🤔 (nếu không giải quyết được vấn đề thì ta giải quyết thứ tạo ra vấn đề ?)
- Transferring threats is about letting someone or something else handle the risk.
- Accepting the risk is the final approach to addressing threats. And once you’ve accepted the risk, you shouldn’t worry over it.
- For each threat that you address, ensure you’ve built a good test to detect the problem.
- There are four types of action you can take against each threat: mitigate it, eliminate it, transfer it, or accept it.
- Did we do a good job?
- The validation tasks include checking the model, checking that you’ve looked for each threat, and checking your tests. You probably also want to validate the model a second time as you get close to shipping or deploying.
- Checking the model:
- Focus on data flow, not control flow.
- Anytime you need to qualify your answer with “sometimes” or “also,” you should consider adding more detail to break out the various cases.
- Data can’t move itself from one data store to another: show the process that moves it.
- Don’t draw an eye chart (a diagram with so much detail that you need to squint to read the tiny print). One technique is to use a sub diagram that shows the details of one particular area.
- Answer both of these questions:
- Is the model accurate?
- Are the assets and actors accurate?