Techy News Blog » The Trouble with Threat Modeling

Techy News Blog » The Trouble with Threat Modeling — Wed, 26 Sep 2007 22:36:59 GMT

PingBack from http://www.artofbam.com/wordpress/?p=3149

Update on the Threat Modeling Process

Michael Howard's Web Log — Fri, 12 Oct 2007 23:06:56 GMT

At Microsoft, we have been using various forms of threat modeling for years now, and we're always learning

Threat modeling matures - another look inside Microsoft's processes

greg hughes - dot net — Tue, 16 Oct 2007 19:08:04 GMT

Threat modeling matures - another look inside Microsoft's processes

greg hughes - dot net — Tue, 16 Oct 2007 19:08:49 GMT

understanding Threat Modeling

Jim Yuill — Thu, 03 Jul 2008 00:18:33 GMT

I found Threat Modeling (TM) to be puzzling and confusing at first. What helped in understanding TM was realizing that it is built for some specific conditions at MS. I'm posting an explanation, should it be of help, and also, to get feedback. I’m investigating SDL and TM for use in an open-source system being developed at North Carolina State University.

TM focuses on finding security problems in an existing system, or perhaps in a new system whose design has largely been worked-out. In the MS books on SDL and TM, it seems TM is the central component in the SDL. For instance, TM is the largest section in the SDL book, and there is an entire TM book. However, it seems security design should be a more central and prominent component of an SDL than TM. Ideally, security should be correctly put in the system when it is designed. TM is largely a form of testing, used to find security problems in the design. SDL does have a security-design step. It is SDL’s third step, and TM is the fourth. I found it puzzling and confusing for TM to have such a central role in security development, and that it is given more attention than security design.

Another thing that was confusing about TM is the way it overlaps with SDL’s security-design step: the security-design step involves TM activities, and TM involves security-design activities. For instance, during the security-design step, attacks should be considered. However, considering attacks is what the TM process does. Further, the TM process involves "mitigation of threats". However, this mitigation of threats is really security design. I found it puzzling and confusing for TM and security-design activities to be mixed between the two steps. Why not have a single security-design step, and it would compose a design based on assets to be protected, system vulnerabilities, potential attacks (e.g., STRIDE), and available defensive countermeasures (e.g., that provide CIA)?

What helped in making sense of SDL’s security-design and TM was considering MS’s environment. This explanation is speculative, but it seems plausible:

1) In general, MS’s developers are not security experts. Apparently, during the system design stage, MS developers do the best job they can on security design. Having a separate TM stage provides a way for the security department’s experts to review the security design and find problems. If MS had a single security-design step, then all the system designers would need to have security expertise, and this is not feasible.

In general, it’s not practical to expect that most developers be security experts. Security engineering is a unique skill, just as technical writing is a unique skill. It’s well known that programmers typically dislike technical writing and many lack writing aptitude or skill. Similarly, security engineering requires a certain savvy, and not all developers have aptitude for security engineering. Further, acquiring security skills takes time and experience.

2) SDL grew out of MS’s efforts to reduce the high incidence of security bugs in its products. TM is largely a form of testing, used to find security problems in the design. SDL’s focus on TM may have been motivated by MS’s goal of dramatically reducing security bugs in the short term.

Another reason for separate security-design and TM steps could be complexity. Security design is complex, and although it involves consideration of attacks, it could be helpful to have an additional step that focuses exclusively on attacks.

In summary, I found it puzzling and confusing for TM to be the central step in SDL. Also, it was puzzling why SDL’s security-design and TM steps overlapped. It would seem best to have a single security-design step and for it to be central in the SDL. I found SDL and TM made much more sense when we considered them in the context of Microsoft’s development and security teams and Microsoft’s security objectives.

Jim Yuill