differences between Threat Analysis and Threat Modeling

[paco at cigital.com (Paco Hope)]

On 2/14/07 4:11 PM, "Jason Grembi" <jgrembi at gmail.com> wrote:
>  
> Threat Analysis ? is more informal way of 'eyeballing' system architecture and
> application design.
> Threat Modeling [Microsoft SDL] ? more formal, every requirement is modeled
> and scrutinized.

This is not how I would define the two terms. The outcome is totally
different from the two processes. "Modeling" means "to create a model."
Although some would argue that it implies analyzing the model, I would say
that the two are separable and not necessarily the same. That is, I can
create a model without analyzing it, and I can analyze threats without
modeling them. If you agree with that, then the words "informal" and
"formal" (from your starting definitions above) devolve into "without a
model" and "with a model," but I don't think that's a good definition for
"formality." You can be very formal without using a model, per se.

Threat modeling is creating a threat model. The model encompasses entities
that are important, such as components, interfaces, communications channels,
systems, and (of course) threats. What goes into the model and how it is
arranged is a function of the project being modelled. The model needs to
indicate how the threats interact with the other entities in the model.
Again, this can be at any level of specificity that makes sense in context.
Finally, I don't think "requirements" are modeled in a threat model (as
stated above), but rather the components of the system, whatever they may
be.

Threat analysis is the process of determining the threats to a system, what
they can do, and how they can do it. If you make a model first, that's
probably really helpful. We always do. The outcome of the analysis, however,
is some description of the threat situation. I'm being intentionally general
here. You might be performing threat analysis to simply enumerate threats
(how many are there?). You might be doing threat analysis for common attack
patterns that can be leveraged by multiple threats. You might be analyzing
threats to determine the effectiveness of a specific mitigation (e.g., "by
addressing this attack pattern, we mitigate the risk posed by these threats
on these components...") Presumably, though, your analysis seeks to answer
one or more questions. A model does not answer question as much as it
facilitiates the organized asking of questions.

You mention Microsoft's SDL. As recently as last November, Microsoft offered
the following pithy (but not particularly actionable) advice on "STRIDE,"
their threat modeling method:
http://msdn.microsoft.com/msdnmag/issues/06/11/ThreatModeling/default.aspx
> To follow STRIDE, you decompose your system into relevant components, analyze
> each component for susceptibility to the threats, and mitigate the threats.
They go on to say, just a sentence later:
> If you do this<break your system down into components and mitigate all the
> threats to each component<you can argue that the system is secure.

I suppose if that were possible (mitigating all the threats to each
component), you could be pretty proud of yourself. I don't know if I'd go
proclaiming that the system "is secure." That smacks of "security as a
destination" rather than "security as a journey."

True security is risk based, doing the right amount to get you to a
tolerable amount of known risk. Threat modeling and threat analysis are two
useful exercises in that process.

Paco
-- 
Paco Hope, CISSP
Technical Manager, Cigital, Inc
http://www.cigital.com/ ? +1.703.585.7868
Software Confidence. Achieved.



----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20070222/4e429e5f/attachment.html