Threat Model Your Strategic Planning

alikl — Wed, 23 May 2007 15:59:00 GMT

I am not marketing guy, nor strategic one – I really do not know why I started to read this post - Why strategic planning fails - may be because my RSS reading technique ( How to Use Outlook 2007 RSS To Effectively Aggregate And Distill Information )...(read more)

Late Threat Modeling

alikl — Wed, 09 May 2007 22:35:12 GMT

I always suggest conducting Threat Modeling even in advanced dev cycle stages, although it might seem absurd – why would one model threats for something that already has been completed? I often start working with projects that have advanced into their dev cycle, say started to write code, in stabilizing stage, or even in deployment phase.

Threat Modeling takes me step back from code to design and even higher to the architecture. Code may be written perfectly, but no perfect code can save bad design or bad architecture from security breach.

How I Explain Threat Modeling to Customers post can give more answers to the question why. I love the idea of incremental rendering for example. I also loved the comment from Scott Barber who cited somebody else:

"All models are wrong. Some models are useful." -- George Box, Industrial Statistician

So conducting late Threat Modeling can be useful in revealing bad design and architecture decisions and changes that took place during the dev lifecycle.

Late Threat Modeling is useful to understand what risks one accepts deploying the application. Some would prefer not even know that, some would like just to know, but my favorite is to know and act applying Security Engineering.

Enjoy your late or on time Threat Modeling

Threat Modeling Big Chunks

alikl — Fri, 27 Apr 2007 21:34:41 GMT

When three years ago I started to practice Threat Modeling I thought it is most boring part of security (which itself is not the most fascinating thing to most of people). I hated it since it seemed too boring - interview folks, read tones of specs, and write documents. Come on! I am .Net code guy! But fortunately to me I was motivated by good reasons to keep doing it - one cannot build good design from security perspective unless security is considered through out the design process itself. That is essentially the one and single reason to do Threat Modeling.

Now what approach to take? How actually to conduct Threat Modeling? Here came the confusion...

These are some really good sources of knowledge I tried to adopt:

Michael Howard's and David LeBlanc's book Writing Secure Code has the whole chapter on this.
Frank Swidersky's book Threat Modeling that totally dedicated to the subject.
JD Meier from patterns&practices has detailed walkthrough in Improving Web Application Security: Threats and Countermeasures
And then came out updated whole guidance form JD, totally dedicated to Threat Modeling Web Applications
Also I found very cool walktrhough here - Guerrilla Threat Modelling (or 'Threat Modeling' if you're American)
Our team, ACE (Application Consulting & Engineering) has very cool tool that supports the process - Microsoft Threat Analysis & Modeling (free download here) loaded with goodies.
There is more...

Seems like we are really crazy about the topic, lets do some search, hmm indeed we really like it:

So which one is the best?

Depends on who you are. Are you developer, architect, IT guy, security auditor, security consultant, doing line of business app, ISV guy, what is your budget, what is your dev culture? There are lot more attributes.

So while I cannot map each each and every attribute to the above Threat Modeling techniques (which have a lots in common anyway), I found the big chunks of the process while conducting Threat Modeling that work for me and my customers. It is also very aligned to Security Language That Every One Understands

Here are my big chunks:

Understand the business. Find some role that understands the business and can explain the biz processes and the valuable stuff from biz perspective. Usually it is mid range managers with the customer. This big chunk helps generating Threats and Objectives (which I use in the last big chunk).
Understand application architecture and design. It is totally technical information. Find app architect and dev lead to understand how the dev solution supports/implements the biz processes explained in first big chunk. The outcome of this big chunk is static view of the solution, data flows, and major usage scenarios (not use cases!).
Go home and analyze. Try to find gaps between the two big chunks above, i.e. how biz valuable stuff gets unwanted impact by technical implementation of the solution. This big chunk generates Vulnerabilities that the solution must [based on severity] fix.
Go back to customer and show the analysis. This step must get senior management involved. I usually do not talk security stuff during this big chunk rather present to senior management threats [generated during first big chunk] that are not countered or poorly countered by the solution [vulnerabilities identified during second big chunk]. If I succeed to present it right then senior management directs development team to fix most severe threats. How? According to the fix I provide along with the vulnerability found.

It is not my invention rather what I absorbed from the resources above and adjusted to my needs.

Today I just love Threat Modeling and the above approach works for me - I am still got paid for this :)

Enjoy.

Alik Levin's : Threat Modeling

Threat Model Your Strategic Planning

Late Threat Modeling

Threat Modeling Big Chunks