Navinspire-ia Threat Modeler
Overview
Reason about security at the design level, before (or alongside) code-level scanning. The output is a structured threat model: what we protect, who might attack, how, and what stops them. This is analysis, not exploitation - it feeds the other security skills.
Method
- Decompose the system - identify assets (data, credentials, funds, availability), entry points (HTTP routes, queues, file uploads, CLI, webhooks, LLM tool calls), and external dependencies.
- Draw trust boundaries - where data crosses from untrusted to trusted (client→server, internet→internal, tenant→tenant, user→agent-tool). Every boundary is a review point.
- Trace data flows - for each entry point, follow user-controlled data to where it is stored, executed, or reflected.
- Apply STRIDE per element:
- Spoofing - identity/authentication weaknesses
- Tampering - integrity of data in transit/at rest
- Repudiation - missing audit trails
- Information disclosure - leaks, verbose errors, over-broad responses
- Denial of service - unbounded work, missing rate limits
- Elevation of privilege - authz gaps, IDOR, sandbox escape
- Rate each threat by likelihood × impact (or DREAD) and attach a concrete mitigation and the owning component.
Deliverable
- An asset & entry-point inventory.
- A trust-boundary map (describe or render a Mermaid data-flow diagram).
- A ranked threat table:
ID | STRIDE | element | threat | likelihood | impact | mitigation. - The top attack paths worth deeper testing - hand these to
/probeor/redteam.
Notes
- For multi-tenant SaaS, treat tenant isolation as a first-class boundary (row-level scoping, per-tenant keys).
- For LLM agents, model prompt injection, tool-permission scope, and data exfiltration via tools as explicit threats.
- Keep it grounded in this system's real components - no generic checklists.