– Part 2
In Part 1, we installed the tool and laid the foundation. Now, it’s time to build. In this guide, we will draw our first architecture diagram and let the tool automatically hunt for design flaws.
Welcome back! In our previous article, we walked through the installation of the Microsoft Threat Modeling Tool and discussed why “blueprinting” your security is so important before you build. We left off with a blank canvas and a scenario: building a simple Online Store.
Today, we turn that blank canvas into a security roadmap. We will draw the system, connect the components, and generate a threat report.
Don’t worry if you aren’t a graphic artist—this tool is “drag-and-drop” simple. Let’s build.
Step 1: Understanding Your Toolbox (The Stencils)
When you open your new model, look at the Stencils panel on the right side of the screen. This isn’t just a collection of clip art; every shape here has specific security meanings attached to it (metadata) that the tool uses to find flaws.
While there are many categories, you will mostly use these three core types for a basic model:
- Interactors (The “Who”): These represent things outside your control that interact with your system.
- Example: Humans (Users, Admins) or External Systems (Third-party APIs).
- Processes (The “Logic”): These are the applications or services you are building.
- Example: Web Application, Web Service, or a Lambda function.
- Data Stores (The “Memory”): This is where your information lives.
- Example: SQL Database, Cloud Storage, or a local File System.
Step 2: Drawing the “Online Store”
Let’s map out our simple e-commerce scenario. We need a Customer, a Web Website, and a Database to store orders.
1. Add the Customer: Go to the “Generic Interactors” section in the right panel. Drag and drop the “Human User” onto the main white canvas.
- Tip: Double-click the text under the icon to rename it to “Customer.”
2. Add the Website: Go to the “Generic Process” section. Drag and drop the “Web Application” onto the center of the canvas.
- Tip: Rename this “Online Store Front.”
3. Add the Database: Go to the “Generic Data Store” section. Drag and drop the “SQL Database” to the right side.
- Tip: Rename this “Orders DB.”
You should now have three icons sitting separately on your screen.
Step 3: Connecting the Dots (Data Flows)
A system does nothing until data moves. In threat modeling, the lines (Data Flows) are often where the most dangerous attacks happen (like “Man-in-the-Middle” attacks where someone intercepts the data).
1. Customer to Website:
- Select the “Generic Data Flow” (the arrow) from the stencils panel.
- Click on the “Customer” and drag the line to connect it to the “Online Store Front.”
- Crucial Step: Click on the line itself that you just drew to select it. In the Properties panel (usually at the bottom left of the screen), look for the “Protocol” setting. Change it to HTTPS.
⚠️ Important Reality Check (Map vs. Territory): Changing this setting in the tool to “HTTPS” does not actually encrypt your real-world website. It simply tells the Threat Modeling Tool: “Assume I am going to use HTTPS here, and analyze the design based on that assumption.” You must still manually configure SSL/TLS certificates on your actual server when you build it!
2. Website to Database:
- Draw another Data Flow arrow from the “Online Store Front” to the “Orders DB.”
- You can leave the protocol as default for now, as this traffic is usually internal to your network.
Step 4: The Magic Moment (Generating the Report)
This is why we use this tool. You don’t need to brainstorm every possible hack yourself; the tool knows the STRIDE methodology. It looks at your diagram, sees a “Web App” talking to a “SQL Database,” and immediately knows what usually goes wrong in that scenario.
To generate the report:
- Look at the toolbar at the top of the screen.
- Find the icon that looks like a Magnifying Glass over a Document (In older versions, this might be a button labeled “Analysis View”).
- Click it. The tool will process your diagram and create a list of threats in a panel at the bottom of the screen.
Note on Tool Limitations: This tool analyzes your design, not your actual code. It acts as an architect reviewing blueprints, not a spellchecker reviewing text. It cannot see if you used a weak password or wrote a buggy line of python; it only points out logical flaws in the architecture.
Step 5: Reading Your First Threat Report
Suddenly, the bottom of your screen is filled with a list of potential threats.
Don’t panic!
You might see 30 or 40 threats listed for this simple diagram. This is normal. The tool is automated and generates potential threats based on patterns. Many of these might not apply to your specific situation (these are called “False Positives”).
You will see entries like this:
- ID: 1
- Category: SQL Injection (Tampering)
- Description: Risk of an attacker modifying the SQL query to access unauthorized data.
- Interaction: Online Store Front -> Orders DB.
The tool is essentially saying: “Hey, I see you are talking to a database. Did you remember to sanitize your inputs? If not, someone could delete your data.”
What Comes Next?
Congratulations! You have just created your first professional Threat Model. You have a visual map of your software and a list of potential security holes.
But now you have a report full of scary warnings. How do we know which ones matter? And more importantly, how do we fix them?
In the next article, “Taming the Beast,” we will learn how to read this report like a pro, filter out the noise, and prioritize the critical fixes that will actually keep your users safe.
Stay tuned!
Disclaimer
This article is for educational purposes only. The tools and techniques discussed are intended to help developers and security professionals secure their own systems. The author assumes no liability for the security of your actual applications based on the use of this tool. Always perform due diligence and consult with security experts when handling sensitive data.
Secure Scroll 
Leave a comment