Tm7-Threat-Model

# Microsoft Threat Modeling Tool (.tm7) Generator

You generate **valid `.tm7` files** for the Microsoft Threat Modeling Tool (v7.3+). A `.tm7`

file is **not** generic XML — it is a **WCF `DataContractSerializer`** document with an exact

namespace and element structure. If the structure is wrong, the tool refuses to open the file

with:

> "File is not an actual threat model or the threat model may be corrupted."

Your job is to translate a described system (components, data stores, external actors, data

flows, trust boundaries) into a diagram plus STRIDE threats, serialized in the exact `.tm7`

format described below.

Workflow

When asked to produce a `.tm7` file:

1. **Model the system.** Identify the elements:

- **Processes** (web apps, services, functions) → `StencilEllipse`, `GE.P`

- **Data stores** (databases, caches, queues, blobs) → `StencilParallelLines`, `GE.DS`

- **External interactors** (users, browsers, third-party systems) → `StencilRectangle`, `GE.EI`

- **Trust boundaries** → `BorderBoundary`, `GE.TB`

- **Data flows** connecting the above → `Connector`, `GE.DF`

2. **Assign a unique lowercase UUID** (e.g. `148ade68-5c80-40f3-8e1f-4e2cabdb5991`) to every

stencil and every flow. Never use human-readable ids like `users-browser`.

3. **Lay out coordinates** (`Left`/`Top`/`Width`/`Height`) so stencils don't overlap.

4. **Generate STRIDE threats** per interaction and place them in `<ThreatInstances>`.

5. **Serialize** using the structure in this guide, mirroring `assets/example-minimal.tm7`.

6. **Validate** against the "Common Mistakes" checklist before returning the file.

7. **Write the file with no XML declaration and no pretty-print indentation** (a single

continuous XML stream is what the serializer emits).

Always open [`assets/example-minimal.tm7`](./assets/example-minimal.tm7) first and adapt it — reuse its exact

serialization skeleton and only change stencil types, names, coordinates, flows, and threats.

CRITICAL: Serialization format

TM7 files use **WCF `DataContractSerializer` XML**, not standard XML.

The file MUST start with this exact root element — **no `<?xml?>` declaration**:

<ThreatModel xmlns="http://schemas.datacontract.org/2004/07/ThreatModeling.Model" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

**NEVER use:**

- `<?xml version="1.0" encoding="utf-8"?>` — causes deserialization failure.

- `xmlns:xsi` / `xmlns:xsd` — these are standard XML namespaces, not DataContract namespaces.

- Invented elements such as `<SecurityGaps>` or `<Mitigations>` — they do not exist in the

TM7 schema.

> **Note:** `<MetaInformation>` (with children like `<Owner>`, `<Contributors>`,

> `<Reviewer>`, `<Assumptions>`, `<ExternalDependencies>`, `<HighLevelSystemDescription>`,

> `<ThreatModelName>`), `<Notes>`, and `<KnowledgeBase>` **are** part of the real schema and

> are emitted by the tool — keep them (see the structure below and `assets/example-minimal.tm7`).

> Just don't invent elements that the tool never produces.

Required namespace prefixes

| Prefix | URI | Used for |

|--------|-----|----------|

| (default) | `http://schemas.datacontract.org/2004/07/ThreatModeling.Model` | Root `ThreatModel` |

| `xmlns:i` | `http://www.w3.org/2001/XMLSchema-instance` | Type attributes |

| `xmlns:z` | `http://schemas.microsoft.com/2003/10/Serialization/` | Reference ids (`z:Id`) |

| `xmlns:a` | `http://schemas.microsoft.com/2003/10/Serialization/Arrays` | Arrays / collections |

| `xmlns:b` | `http://schemas.datacontract.org/2004/07/ThreatModeling.KnowledgeBase` | Stencil properties |

| `xmlns:c` | `http://www.w3.org/2001/XMLSchema` | Primitive type values |

File structure (correct order)

A full tool export contains, in this order: `DrawingSurfaceList`, `MetaInformation`, `Notes`,

`ThreatInstances`, `ThreatMetaData` (often empty/self-closing), then the large generic

`KnowledgeBase` as a **top-level sibling** (not nested inside `ThreatMetaData`), and finally

`Profile`.