Threat modeling (STRIDE, DREAD) in Cybersecurity - Time & Space Complexity
When we analyze threat modeling methods like STRIDE and DREAD, we want to understand how the effort to identify and assess threats grows as the system size or complexity increases.
We ask: How does the work needed change when there are more components or potential threats?
Analyze the time complexity of this simplified threat modeling process.
# For each system component
for component in system_components:
# For each STRIDE threat category
for threat in STRIDE_categories:
# Assess threat impact using DREAD
score = assess_dread(component, threat)
record_score(component, threat, score)
This code checks every component against each STRIDE threat and scores it using DREAD.
Look at what repeats in this process:
- Primary operation: Checking each component against each STRIDE threat category.
- How many times: Number of components times number of STRIDE categories.
As the number of components grows, the total checks grow too.
| Input Size (components) | Approx. Operations (components x 6 STRIDE threats) |
|---|---|
| 10 | 60 |
| 100 | 600 |
| 1000 | 6000 |
Pattern observation: The work grows directly with the number of components; doubling components doubles the work.
Time Complexity: O(n)
This means the time needed grows in a straight line with the number of system components.
[X] Wrong: "Adding more threat categories will make the time grow exponentially."
[OK] Correct: The number of threat categories is fixed and small (like 6 in STRIDE), so it acts like a constant multiplier, not causing exponential growth.
Understanding how threat modeling scales helps you explain how security analysis fits into project timelines and resource planning.
"What if we added a new scoring method that requires checking each threat twice? How would the time complexity change?"