Threat Modeling Again, STRIDE per Element

Threat Modeling Again, Threat Modeling PlaySound

Larry Osterman's WebLog — Tue, 11 Sep 2007 19:28:10 GMT

Finally it's time to think about threat modeling the PlaySound API. Let's go back to the DFD that I included

STRIDE chart

The Security Development Lifecycle — Wed, 12 Sep 2007 21:09:16 GMT

Adam Shostack here. I've been meaning to talk more about what I actually do, which is help the teams

Some final thoughts on Threat Modeling...

Larry Osterman's WebLog — Tue, 02 Oct 2007 21:54:44 GMT

I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah,

re: Threat Modeling Again, STRIDE per Element

John Melville — Thu, 11 Oct 2007 08:10:53 GMT

I just noticed that STRIDE perelement is remarkably similar to how physicians solve a (surprisingly) similar problem: reading EKGs.

The trick to successfully reading EKG's is to have a set pattern of things to look for, and then follow the pattern religiously; regardless of whether you are leisurely discussing an EKG in cardiology rounds or madly reviewing one in the middle of an emergency. I saw my intern's repeatedly try to shortcut the process and "Jump to the obvious answer" and miss significant, but nonobvious, abnormalities.

I have a few thoughts based on the analogy between the two processes which I am curious as to how much they apply in software engineering.

1. The first is don't try to streamline the process too much. The lesson I think we have both learned is that the process is the value -- each of the ideas needs to pass through your head sequentially and get accepted or rejected.

2. We are a lot less onerous in our documentation (in this respect) than you describe. I am permitted to simply write "EKG normal" and my collegues will accept that I checked the rate, rhythm, axis, etc because this is how any professional reads an EKG. If they were abnormal, I would have said so.

That allowance gives us speed at the expense of transparency. I can read an entire ekg, which includes checking about 20 different things in 12 different leads in about 1 minute. Discussing (or documenting) those same critera takes 5-10 times as long. I wonder if some of the pushback you describe is against STRIDE by example is against documentation and not the process.

In medicine we have a very personal model of responsibility and liability, where as software engineering is more team oriented. I am not suggesting our documentation requirements would work in software engineering. I mention it merely because I think the similarity and contrast is interesting.

re: Threat Modeling Again, STRIDE per Element

sdl — Fri, 12 Oct 2007 04:10:19 GMT

Hi John,

Interesting questions and analogies--do you have a good intro site I can read up on EKG? Searching there's a lot of expert information out there.

Regarding "EKG normal," you have a different pre-cursor than we do. Not everyone threat modeling has been through years of training in software engineering, and so what's "normal" to one person may not be normal to another. Maybe in a few years we'll be a lot closer to what you descibe.

-- Adam Shostak

re: Threat Modeling Again, STRIDE per Element

John Melville — Fri, 12 Oct 2007 06:13:41 GMT

The classic text that _everybody_ uses to learn EKGs is Dubin's "Rapid Interpretations of EKG's." I found some of the reference sheets from dubin at http://www.emergencyekg.com/Reference_Sheets.pdf. The first page has an abreviated algorithm. Like most internists I have taken a special interest in EKGs, so my algorithm is a little bit longer. This is the one most of the medical students and interns use.

I don't think that software engineering is that much different than medicine with regard to having practitioners at many levels of skill. I often get asked to "look over an ekg" by docs who read fewer than I do. I frequently forward EKGs to the cardiologist I refer to when I have questions. So just like there are run of the mill developers, team security champions, and full time security specialists, we have just as much variation in skill with EKG interpretation as programmers do with software security.

As you mention, we have the advantage that it is very easy for us to agree about what "normal" means. We just do EKGs on 100 consecutive healthy 20 year olds you find on the street. Anything you see in more than 5 of them is normal. (This has actually been done, many times.) I am not sure I know what a "normal" threat model means. I am not sure I even know what a "mitigated" threat model or a "secured" threat model means. It is possible that in 5 years you will be able to tell me.