What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Threat modeling helps a team identify plausible threats, make assumptions and response choices visible, and decide what risks remain within a defined system boundary. It does not implement protections or guarantee that a system is secure. Here, SAL means NIST’s Security Assurance Levels: a vector for describing security requirements, not a threat-modeling method.
What does SAL mean?
In this context, SAL is NIST’s term for Security Assurance Levels. James D. Gilsinn and Ragnar Schierholz introduced the vector approach in a 2010 paper to describe the protection factor required for a system. It is a way to express security requirements, not the name of a proprietary threat-modeling framework.
The vector matters because security requirements can be difficult to compress into one score. As the authors put it, “The increased complexity of security systems makes compressing the protection factor down to a single number much more difficult.” The paper’s publication metadata includes industrial automation and control systems among its keywords. Read the NIST paper.
What does threat modeling defend against?
Threat modeling is a structured analysis of what is being built, who or what may be affected, what could go wrong, and how the team will respond. It helps make important threats, assumptions, affected stakeholders, and residual risks visible while requirements and design can still be changed. The model should show enough of the system, actors, data flows, and trust boundaries to support those decisions; teams can revise it as the design evolves.
#1 Best Overall
The analysis can address malicious threats as well as incidental ones. It can also surface privacy and socio-technical harms that affect people, not just technical assets. A threat model is useful when it helps a team choose requirements, controls, or other responses—not simply when it produces a diagram. The W3C Threat Modeling Guide and OWASP’s threat-modeling guidance describe this broader purpose.
Questions that make threats concrete
STRIDE-style prompts can help teams examine specific failure modes. For example: Could an attacker change authentication data? Could user profile data be disclosed? Could access to a profile database be denied? Microsoft presents these as analysis prompts; asking them does not establish that a product is protected. See Microsoft’s threat descriptions.
What does threat modeling not do?
It does not guarantee security
A model records analysis and decisions. Controls still have to be implemented and evaluated, and attacks may still succeed. Treating completion of a model as proof of security confuses planning with the work needed to make and verify protections.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →It does not have to enumerate every imaginable threat
An exhaustive list can be harder to write, review, and maintain. The W3C guide says, “A threat model does not need to be exhaustive to be useful.” The practical goal is to capture enough of the important threats for the current stage and decision.
It does not automatically cover everything outside its scope
Implementation, deployment, dependencies, and wider ecosystem behavior can introduce risks that a model of a specification or design does not directly control. State the system boundary, assumptions, ownership, and remaining threats so that uncovered risks are not mistaken for resolved ones.
It is not itself risk scoring or risk management
A threat model can inform a separate risk assessment and management decision. Scoring is optional; use it when it helps the decision rather than assuming that every model needs a numerical score.
Rank #4
It does not replace code review
Threat modeling and security code review examine different things. OWASP’s historical process guidance describes threat modeling as complementary to code review, not a substitute for it. See OWASP’s historical process page.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →How to use threat modeling in practice
OWASP organizes the work around four questions. The answers should be specific enough to guide design, implementation, or a risk decision.
- What are we working on? Define the system boundary, purpose, key components, actors, data flows, and trust boundaries. Record assumptions that affect the analysis.
- What can go wrong? Use a suitable technique to identify plausible security threats and harms to affected stakeholders. Focus on the threats relevant to the current design and decision.
- What are we going to do about it? Choose a response, such as a design change or mitigation, or explicitly accept and assign ownership of a residual risk.
- Did we do a good job? Check whether the model is adequate for the current stage, whether important assumptions and threats are visible, and whether the chosen responses have owners.
Start early enough for findings to influence requirements and design, then revisit the model when features, incidents, architecture, or infrastructure change. The process and cadence are described in OWASP’s threat-modeling guidance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to compare SAL and a threat model
They answer different questions: SAL describes security requirements using a vector, while a threat model structures analysis of threats and responses within a system boundary. When comparing SAL with a threat model—or comparing two threat-modeling approaches—check the same dimensions rather than reducing either to a single score.
| Comparison axis | What to examine |
|---|---|
| System boundary and scope | Which system, components, actors, and dependencies are included? |
| Threats, harms, or assurance dimensions | Which security concerns, stakeholder harms, or requirement dimensions are considered? |
| Assumptions and ownership | Which conditions are assumed, and who is responsible for addressing each risk? |
| Responses and mitigations | What design changes, controls, or other responses are selected? |
| Residual risk | What remains unresolved or outside the analysis? |
| Use in a separate decision | How does the result inform risk assessment, requirements, or management? |
For SAL, keep the vector approach intact: it describes security requirements across dimensions rather than supplying one universal security score. For a threat model, judge whether the analysis supports the decision at hand, not whether it claims to list every possible threat.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
