Secure Scroll

In Part 2, we drew the diagram and generated a report. Now, we are staring at a list of 40+ potential threats. In this guide, we learn how to filter the noise, prioritize the real risks, and turn a scary report into a to-do list.

Welcome back to our Threat Modeling series!

In our previous article, we experienced the “magic” of the Microsoft Threat Modeling Tool. We drew a simple Online Store, clicked “Analyze,” and were immediately presented with a long list of potential security flaws

If you are like most beginners, you probably felt a moment of panic. “My simple app has 45 security holes? How is that possible?”

Here is the secret: It doesn’t.

The tool is a robot. It prioritizes quantity over quality. It’s your job as the human analyst to filter through that list, throw out the trash, and focus on the gold. Today, we are going to learn how to “Triage” your threat model.

Step 1: The Analysis View

First, let’s get oriented. After you click the Analyze button (the magnifying glass icon), your view changes. You are no longer drawing; you are reviewing.

At the bottom of your screen, you will see the Threat List. This is your workspace for today.

Step 2: Spotting “False Positives” (The Cleanup)

A “False Positive” is when the tool flags a threat that doesn’t actually exist in your specific context.

• Example: The tool might warn you about “Weak Authentication” on the connection between your Web App and your internal Database.
• Context: But wait! You are using a Cloud Provider’s “Managed Identity” system. There are no passwords to steal.

How to handle this:

1. Click on the threat in the list.
2. Look at the Threat Properties panel (usually on the right).
3. Find the Status dropdown menu.
4. Change it from “Not Started” to “Not Applicable” or “Justified.”
5. Critical Step: In the “Justification” box, write why. (e.g., “We are using Azure Managed Identity, so no credentials are passed over the wire.”)

Step 3: Mitigating Real Threats (The Fix)

Now that we’ve cleared the noise, let’s look at a real threat.

Let’s say you find a Tampering threat labeled: “SQL Injection risk on the Data Flow to Orders DB.” This is real. If you don’t fix it, hackers can steal your data.

How to handle this:

1. Analyze: How do we fix SQL injection? The industry standard is using “Parameterized Queries.”
2. Document: In the Threat Properties panel, look for the text box labeled “Mitigations”.
3. Write: Type your plan here. “We will use PreparedStatement objects in Java/C# to ensure user input is never treated as code.”
4. Update Status: Change the Status dropdown to “Mitigated”.

⚠️ The “Map vs. Territory” Rule: Writing “Mitigated” in this tool does not magically fix your code! It creates a “Ticket” or a “Requirement” for your developers. You still have to go into your IDE and actually write the secure code.

Step 4: Prioritization (Risk Rating)

You can’t fix everything today. Some threats are “The house is on fire,” and others are ” The window is squeaky.”

In Article 1, we discussed Risk = Likelihood x Impact. The tool allows you to assign this priority.

In the Threat Properties panel, look for the Priority dropdown.

• High: Do this before you launch. (e.g., SQL Injection, No Encryption).
• Medium: Do this soon. (e.g., Weak Password Policy).
• Low: Do this when you have time. (e.g., Obscure error messages).

Use this field to help your manager or team understand what needs to happen now.

Step 5: The Final Report

You have filtered the false positives, documented the fixes, and set the priorities. Now you need to show your work to your boss or client.

1. Go to the Reports menu at the top.
2. Select “Create Full Report” (or “Generate Report”).
3. Save the file as an HTML file.

Open that HTML file in your browser. You will see a beautiful, professional dashboard showing charts of your threats, followed by the detailed list of mitigations you just wrote. This is your “Deliverable.”

Conclusion: From Design to Reality

Congratulations! You have successfully completed a Threat Model.

1. You understood the Concepts.
2. You Drew the architecture.
3. You Analyzed the flaws.
4. You Planned the fixes.

But wait… Even the best blueprints can’t stop a determined thief if they find a window you forgot to lock. We have secured the design, but how do we catch a hacker who is trying to break in right now?

In the next article, we are going to pivot from Defense to Offense. We will take the map we just built and use it to start Threat Hunting.

Get ready to go hunting.