SEC-101 Lab 6: Full STRIDE Threat Model with Data Flow Diagram

Week: 3 Graded: Yes Time estimate: 75-90 minutes Tools: OWASP Threat Dragon (browser-based at threatdragon.com, or local Docker/npm install)

Learning objective

Build a complete STRIDE threat model for a student-chosen system: data flow diagram (DFD), trust-boundary map, STRIDE threat enumeration per element, and proposed mitigations. (Bloom's L3: Apply -- produce a threat model artifact; L4: Analyze -- identify which controls are present but not enforced.)

Setup

OWASP Threat Dragon (browser-based)

Go to https://www.threatdragon.com and click "Get Started" or "Demo." The tool runs in your browser; no account is required for basic use. You can export your model as a JSON file and re-import it later.

If the hosted site is unavailable, run Threat Dragon locally:

docker pull owasp/threat-dragon
docker run -p 3000:3000 owasp/threat-dragon
# Then open http://localhost:3000

Review your system description

Bring your Lab 1 system description and your Lab 2 STRIDE sketch. You will formalize them into a Threat Dragon diagram.

Step-by-step instructions

Step 1: Create a new threat model (5 min)

In Threat Dragon, create a new model. Name it SEC-101-Lab6-[Your System Name].

Add a description in the model metadata: the name of the system, what it does, and who its users are (reuse your Lab 1 description).

Step 2: Draw the data flow diagram (20 min)

Data flow diagrams use four element types:

Figure 6.1. A generic four-actor DFD template you can fork for your chosen system. The dashed amber rectangles are trust boundaries; arrows crossing a boundary are the data flows STRIDE asks you to model most carefully (an elevation-of-privilege threat is most plausible where a flow crosses a boundary). The amber-highlighted API service plus its internal RPC inflow are the path the worked example walks. Substitute your own external entities, processes, and stores; keep the zone-and-arrow shape vocabulary intact.

Draw the DFD for your chosen system. You need at minimum:

• At least one external entity (the user or an external service).
• At least two processes (e.g., the frontend app and the backend API, or the browser and the web server).
• At least one data store (e.g., a database or a session store).
• Data flows connecting them.

Add a note to each data flow indicating whether it is authenticated and whether it is encrypted.

Step 3: Mark trust boundaries (10 min)

In Threat Dragon, add Trust Boundary Lines (dashed lines) to your diagram. Mark:

• The boundary between external entities (users, internet) and your processes.
• Any boundary between processes where the trust level changes (user-facing API vs. internal service).
• The boundary between processes and data stores.

Label each boundary: "Internet / Application Boundary," "Authenticated User Boundary," etc.

Step 4: Apply STRIDE to each element and flow (30 min)

For each process, data store, and data flow in your diagram, use Threat Dragon's threat-entry feature to add STRIDE threats. Click on an element, select "Add Threat," and fill in:

• Threat title (short description of the threat)
• STRIDE category (Spoofing, Tampering, etc.)
• Description (what could happen and how)
• Mitigation (what control would prevent or reduce the threat)
• Current status (Mitigated / Not Mitigated / Unknown)

Aim for at least two threats per element. For a minimal DFD with one external entity, two processes, one data store, and four data flows, that is at minimum 16 threats. Prioritize depth over count: two well-documented threats per element is better than six shallow ones.

Step 5: Identify unenforced controls (10 min)

Review your threat list. For each threat you marked as "Mitigated," ask: is the mitigation enforced on every call to every relevant endpoint, or only in some paths?

Mark any mitigations that are present but potentially not enforced with a note: "Control exists; enforcement status uncertain." These are your highest-priority items.

Step 6: Export and submit

Export the threat model as a JSON file (File > Export or Download in Threat Dragon). Submit the JSON file plus a screenshot of the diagram and the threat list. If screenshots are not practical, a plain-text summary of the diagram elements and threats is acceptable.

Deliverable

1. The Threat Dragon JSON export (or a PDF/screenshot of the diagram).
2. A written summary (300-500 words) covering:
   • The system architecture as reflected in the DFD (what did you draw?).
   • The three highest-priority threats you identified and why they are highest-priority.
   • At least one case where a security control exists but you are not certain it is enforced.

Grading rubric

picoCTF connection

Data flow diagrams are a practitioner tool, not an academic exercise. The picoCTF challenges you've been working through are systems too: the challenge server, the player's browser, the flag validation backend. Sketching the trust boundaries of a CTF challenge helps you find the attack surface: where does untrusted input enter the system? What processes execute on the server vs. in your browser? This framing turns a brute-force CTF approach into a structured threat-modeling exercise.

Lab 6 of 9. Next: Lab 7 (OWASP Juice Shop walkthrough capstone, Week 9).