Steps for Business Analyst To Gather Security Requirements from Misuse Cases
In this write-up, I will talk about misuse cases and steps to identify security requirements. Ivar Jacobson while working on large telecommunication systems introduced use cases. According to him use cases describe system's desired behavior in the form of a story ('Scenario')from the point view of a user or interfacing system('Actor') and supported by subsidiary scenarios in the form of alternatives and exceptions[Jacabson 1992]. On the other hand misuse cases are the inverse of use cases. The concept was coined in 1990s by Guttorm Sindre of the Norwegian University of Science and Technology, and Andreas L. Opdahl of the University of Bergen, Norway. The basic concept is describing the steps of performing a malicious act against a system, just as you would describe an act that the system is supposed to perform in a use case. So, use cases models the behavior expected from the system and misuse cases models the behavior not expected from the system.
Download the paper from below link.
| Attachment | Size |
|---|---|
| Misuse case.pdf | 493.84 KB |
Re:But what is a misuse case
Hi Leslie,
Thanks for opening up the discussion. The thief is never been an appropriate actor for a car system. He is a misuser considered over here to make your system more secure from threats like car stealing. Now as far as the question of stopping is considered I think it is more like when do you stop gathering your requirements.Are all the requirements gathered? Are requirements complete? These questions can never be answered correctly. It is more about the mutual consensus of the stakeholders and the experts. Like you correctly pointed out that the security experts should be introduced in the early phases especially when you are gathering use cases and mis usecases. Here if the customers or the security experts or even the developers to some extent agree that all the negative scenarios and the misuse case are identified and are appropriate for the system in question they can stop. Again it is an iterative process. You keep on refining them.
I will explain in more detail the car system example in the paper. The expected behaviour of the car system is that the driver(actor) "Drive the car". This is the use case for the system. Now let us say, one of the security expert pitch in to say that the car can be stolen by the thief(threat). We need to detail it as the sytem should stop such act. It is modelled with required details in "Steal the car" misuse case with the negative actor as "Thief". Now how can it be mitigated? A new use case " Lock the car" is introduced which stops the thief to steal the car. Based on the misuse case what can be the derived security requirements " The auto lock after few minutes" or "the car with central locking system which raises alarm whenever required."
As far as exceptional flows are concerned, they are more like for handling the "errors" of the system. An "error" is not necessary a "threat".
I hope I answered your questions to some extent atleast. Kindly keep posting for more discussions.