On 2/14/07 4:11 PM, "Jason Grembi" <[EMAIL PROTECTED]> 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. ----------------------------------------------------------------------------
_______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
