Page 324 - Software and Systems Requirements Engineering in Practice

286 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

Threat Modeling Metrics
Threat modeling metrics may be simple or complex, depending on
the methodology used to perform the security analysis. Simple
metrics are relatively easy to add to an MDRE model; for example,
percent of use cases or features that may be associated with unwanted
incidents. If this number is large, it might be indicative of a system
that is inherently unsafe and needs a redesign.

11.3 Summary
In this chapter, we have shown the relationships of hazard analysis
and threat modeling to requirements engineering processes. Hazard
analyses take place late in the requirements analysis phase, while
threat modeling should occur at an earlier point in the life cycle.
It is important to use an integrated approach to requirements
engineering, hazard analysis, and threat modeling. If a seamless set
of processes and artifacts are not in place, traces may break, or, even
worse, not get created. When that happens, there is the potential for
catastrophic consequences to customers, users, vendors, or owners of
a product or system.

11.4 Discussion Questions

1. Give some examples of systems where inadequate hazard
analysis can lead to potential loss of life or personal injury.
2. What types of additional tooling are necessary for threat
modeling?
3. What is the difference between a hazard and a threat?

References
Burns, S., “Threat Modeling: A Process to Ensure Application Security,” SANS
Institute, January 5, 2005.
Ingalsbe, J., Kunimatsu, L., Mead, N., and Baeten, T., “Threat Modeling: Diving into
the Deep End,” IEEE Software, Vol. 25, No. 1, January/February 2008.
Swiderski, F. and Snyder, W., Threat Modeling, Microsoft Press, June 2004.