Threat models are a very good way to make implicit security threats and mechanisms, into explicit threats and mechanisms, so that you can write requirements, build, and test that they do the job you intend. As a starting point, I like to use a modified version of STRIDE, which among other things cleanly maps threat to mechanism. This way when starting a new project, for example with SOA Web services, you can identify where the standards will help you.
| Threat | Mechanism | Example Standard |
| Spoofing | Authentication | WS-Security |
| Tampering | Digital Signature, Hash | WS-Security + XML Signature |
| Dispute | Audit Logging | None |
| Information Disclosure | Encryption | WS-Security + XML Encryption |
| Denial of Service | Availability Services | None |
| Elevation of Privilege | Authorization | None |
Threat models are misunderstood, they are not about modeling threats. As defensive programmers, we have little to no control over threats, our job is to find and fix vulnerabilities. So why bother with threats and threat modeling at all then? It turns out that vulnerabilities are basically passive weaknesses, and the threat is the catalyst that exercises the vulnerability so that we can 1) identify it and 2) deal with it.
So the end result of threat modeling is not a list of threats, but rather a list of countermeasures. And not just a generic list either. The active ingredient (threat) gives us a way to locate where the countermeasure can/should live in the architecture.
Further, if we are comparing approaches early in architecture/design phases of building software, the threat model is a structured back of the cocktail napkin way to compare/contrast approaches. For example if we are looking to build out a set of Web services and are choosing between SOA style (WS-*) and REST style, we may want to look at the readily available implemented standards that each software security stack supports
| Threat | Mechanism | Example SOA Standard | Example REST Standard |
| Spoofing | Authentication | WS-Security | XML Signature (response only) |
| Tampering | Digital Signature, Hash | WS-Security + XML Signature | XML Signature (response only) |
| Dispute | Audit Logging | None | None |
| Information Disclosure | Encryption | WS-Security + XML Encryption | XML Encryption (response only) |
| Denial of Service | Availability Services | None | None |
| Elevation of Privilege | Authorization | None | None |
Threat modeling gives a concrete structure to a fairly abstract subject like analyzing software security capabilities in services, but as you see its not about the threats its about the security architecture elements. This is just an illustrative example not a complete threat model, but it does give an effective, context-sensitive way to look at tradeoffs in security architecture. In this example, SOA/WS-* has potentially more coverage the security mechanisms work on both the request and response side. In the next series of posts, we’ll look slicing and dicing the threat model a layer deeper and how we can use it secure our services.
本文还暂无回复