Threat Modeling Your System
Threat modeling in Devici is an iterative process focused on understanding how your system behaves and how that behavior maps to potential threats.
This section explains how to represent your system in a way that allows Devici to identify meaningful threats, while keeping models focused, accurate, and easy to evolve over time.
Start with how the system actually works
The most effective threat models reflect reality.
When modeling your system, focus on:
- How users and systems interact
- How data moves through the system
- Where trust assumptions change
- Which components you own versus depend on
Avoid modeling aspirational designs or future-state architectures unless they are already influencing current decisions.
Model behavior, not implementation detail
Devici is designed to capture system behavior, not code-level detail.
You do not need to model:
- Internal classes or functions
- Line-by-line logic
- Low-level infrastructure unless it affects trust or data handling
Instead, model components at a level where:
- Data enters or leaves the system
- Authorization or authentication decisions are made
- Sensitive data is processed or stored
- External systems are involved
If a detail does not affect security behavior, it usually does not belong in the threat model.
Elements represent system components
Elements are the building blocks of a threat model and represent logical responsibility boundaries.
Use elements to represent:
- Services and applications
- APIs and background processes
- Data stores
- External systems or users
Choose the element type that best reflects how the component behaves, rather than how it is implemented.
Avoid splitting elements too aggressively. Fewer, well-defined elements are easier to understand and review than many small ones.
Data flows show how information moves
Data flows connect elements and describe how information is exchanged.
When adding data flows:
- Show the direction of communication
- Label flows to describe the type of data being transferred
- Include flows that cross trust boundaries
Data flows are often where threats emerge, especially when sensitive data or external actors are involved. You can start with broad flows and refine them later if a specific interaction requires deeper analysis.
Trust boundaries define changes in trust
Trust boundaries indicate where trust levels change within a system.
Common examples include:
- Transitions between internal and external networks
- Boundaries between services owned by different teams
- Interfaces between cloud and on-premise systems
Placing trust boundaries helps Devici identify threats related to exposure, isolation, and privilege assumptions.
Keep scope under control
Not every component needs to be in scope for every threat model.
Use scope to:
- Focus on the system or change under review
- Reduce noise during early modeling
- Exclude components owned by other teams
Out-of-scope elements can still appear on the canvas for context, but should be clearly marked to avoid confusion.
Let threats guide refinement
Once your model is in place, Devici identifies threats based on system behavior and applied attributes.
Use identified threats as feedback:
- Missing threats often indicate missing elements, flows, or trust boundaries
- Unexpected threats may signal unclear trust assumptions
- Too many threats can indicate over-modeling
Threat modeling works best when the model and the threats inform each other.
Iterate as the system evolves
Threat models should evolve alongside the system.
Update the model when:
- New components are introduced
- Data flows change
- Trust assumptions shift
- New integrations are added
Small, frequent updates are more effective than infrequent, large revisions.
What’s next
Now that you understand how to represent your system, the next step is learning how Devici uses attributes to describe behavior and determine which threats apply.