Page 322 - Software and Systems Requirements Engineering in Practice

284 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

11.2 Threat Modeling
Threat modeling differs from hazard analysis in where in the life cycle
it occurs. While hazard analysis tends to occur after a significant part
of the high-level requirements analysis effort has been completed,
threat modeling usually occurs in parallel with initial elicitation and
analysis. Although there are many different approaches to modeling
threats, the use of scenarios is very common. It is, therefore, a simple
matter to extend MDRE techniques to support threat modeling. Just
as hazard analysis requires experienced hazard analysts, threat
modeling is best accomplished by experienced security analysts. The
role of the requirements engineer is to merge the threat modeling
processes into the larger requirements elicitation and analysis effort
so that there are no discontinuities between analysis and threat
models; e.g., full traceability and metrics are in place. Of course, the
easier it is for nonexperts to understand the models, the easier it will
be to conduct reviews with stakeholders.
Basic Terminology
There are just a few basic terms the requirements engineer needs to
know about threat modeling:
• Asset An item that needs to be protected or secured. It can
be because of the potential for financial (e.g., bank account
information) or personal (e.g., medical information) loss.
• Threat The type of attack (e.g., service denial) that may
cause a potential risk of lost, destroyed, or stolen assets.
• Treatment A modification to a system that will help prevent
or mitigate the effect of an attack.

Example Scenarios Where Threat Modeling Would Have Helped
“One case involved child-support payments in California, where one
of the flaws in the application was updating the wrong father’s records.
Due to this flaw, some fathers who paid child support were not getting
the payments recorded, while some other, unrelated father was falsely
credited with payment. There were even a few arrests made due to this
defect.”
“Another case involved a financial application where a defect caused
the plaintiff to have to restate prior year earnings. This caused a disruption
of bank credit. Another interesting aspect of this case is that the defendant
made 4 unsuccessful attempts to fix the defect. Each attempt not only left
the defect in the software, but accidentally injected new defects as well!
The defect was finally fixed on the 5th attempt, about 10 months after it
had been reported. The point is that software can cause business damage
as well as harm in a physical sense.”—Capers Jones