Misuse case

Use cases specify required behaviour of software and other products under development, and are essentially structured stories or scenarios detailing the normal behavior and usage of the software. A Misuse Case on the other hand highlights something that should not happen (i.e. a Negative Scenario) and the threats hence identified, help in defining new requirements, which are expressed as new Use Cases. This modeling tool has several strengths: • It allows the provision of equal weightage to functional and non-functional requirements (e.g. security requirements, platform requirements, etc.), which may not be possible with other tools. • It emphasizes security from the beginning of the design process and helps to avoid hasty design decisions. • It is a tool for improving communication between developers and stakeholders and is valuable in ensuring that both agree on critical system solutions and Trade-off analysis. • Creating misuse cases often triggers a chain reaction which eases the identification of functional and non-functional requirements. The discovery of a misuse case will often lead to the creation of a new use case that acts as a counter measure. This in turn might be the subject of a new misuse case. • Compared to other tools, It relates better to use cases and UML and eases the seamless employment of the model. Its biggest weakness is its simplicity. It needs to be combined with more powerful tools to establish an adequate plan for the execution of a project. One other weakness is its lack of structure and semantics. From use to misuse case In an industry it is important to describe a system's behavior when it responds to a request that originates from outside : the use cases have become popular for requirements The level of abstraction of a use case model makes it an appropriate starting point for design activities, thanks to the use of UML use case diagrams and the end user's or domain expert's language. But for software security analyses, the developers should pay attention to negative scenarios and understand them. That is why, in the 1990s, the concept of "inverse of a use case" was born in Norway. The contrast between the misuse case and the use case is the goal: the misuse case describes potential system behaviors that a system's stakeholders consider unacceptable or, as Guttorm Sindre and Andreas L. Opdahl said, "a function that the system should not allow". Another description of the difference is by that defines a use case as a completed sequence of actions which gives increased value to the user, one could define a misuse case as a completed sequence of actions which results in loss for the organization or some specific stakeholder. Between the "good" and the "bad" case the language to represent the scenario is common: the use case diagrams are formally included in two modeling languages defined by the OMG: the Unified Modeling Language (UML) and the Systems Modeling Language (SysML), and this use of drawing the agents and misuse cases of the scenario explicitly helps focus attention on it. Area of use Misuse case are most commonly used in the field of security. With the ever-growing importance of IT system, it has become vital for every company to develop capability to protect its data. Hence, for example a misuse case might be used to define what a hacker would want to do with the system and define his or her requirements. A developer or designer can then define the requirements of the user and the hacker in the same UML diagram which in turn helps identify the security risks of the system. ==Basic concepts==

A misuse case diagram is created together with a corresponding use case diagram. The model introduces 2 new important entities (in addition to those from the traditional use case model, use case and actor: • Misuse case : A sequence of actions that can be performed by any person or entity in order to harm the system. • Misuser : The actor that initiates the misuse case. This can either be done intentionally or inadvertently. Diagrams The misuse case model makes use of those relation types found in the use case model; include, extend, generalize and association. In addition, it introduces two new relations to be used in the diagram: ;mitigates: A use case can mitigate the chance that a misuse case will complete successfully. ;threatens: A misuse case can threaten a use case, e.g. by exploiting it or hinder it from achieving its goals. These new concepts together with the existing ones from use case give the following meta model, which is also found as fig. 2 in Sindre and Opdahl (2004). Descriptions There are two different ways of describing a misuse case textual; one is embedded in a use case description template - where an extra description field called Threats can be added. This is the field where misuse case steps (and alternate steps) can be filled in. This is referred to as the lightweight mode of describing a misuse case. The other way of describing a misuse case, is by using a separate template for this purpose only. It is suggested to inherit some of the field from use case description (Name, Summary, Author and Date). It also adapts the fields Basic path and Alternative path, where they now describe the paths of the misuse cases instead of the use cases. In addition to there, it is proposed to use several other fields too: • Misuse case name • Summary • Author • Date • Basic path • Alternative paths • Mitigation points • Extension points • Triggers • Preconditions • Assumptions • Mitigation guarantee • Related business rules • Potential misuser profile • Stakeholders and threats • Terminology and explanations • Scope • Abstraction level • Precision level As one might understand, the list above is too comprehensive to be completely filled out every time. Not all the fields are required to be filled in at the beginning, and it should thus be viewed as a living document. There has also been some debating whether to start with diagrams or to start with descriptions. The recommendation given by Sindre and Opdahl on that matter is that it should be done as with use cases. Sindre and Opdahl proposes the following 5 steps for using misuse cases to identify security requirements: • Identify critical assets in the system • Define security goals for each assets • Identify threats to each of these security goals, by identifying the stakeholders that may want to cause harm to the system • Identify and analyze risks for the threats, using techniques like Risk Assessment • Define security requirements for the risks. It is suggested to use a repository of reusable misuse cases as a support in this 5-step process. ==Research==

Current field of research Current research on misuse cases are primarily focused on the security improvements they can bring to a project, software projects in particular. Ways to increase the widespread adoption of the practice of misuse case development during earlier phases of application development are being considered: the sooner a flaw is found, the easier it is to find a patch and the lower the impact is on the final cost of the project. Other research focuses on improving the misuse case to achieve its final goal: for "there is a lack on the application process, and the results are too general and can cause a under-definition or misinterpretation of their concepts". They suggest furthermore "to see the misuse case in the light of a reference model for information system security risk management (ISSRM)" to obtain a security risk management process. Future improvement The misuse cases are well known by the population of researchers. The body of research on the subject demonstrate the knowledge, but beyond the academic world, the misuse case has not been broadly adopted. As Sindre and Opdahl (the parents of the misuse case concept) suggest: "Another important goal for further work is to facilitate broader industrial adoption of misuse cases". wrote "While this approach can help in a high level elicitation of security requirements, it does not show how to associate the misuse cases to legitimate behavior and concrete assets; therefore, it is not clear what misuse case should be considered, nor in what context". These criticisms might be addressed with the suggestions and improvements presented in the precedent section. Standardization of the misuse case as part of the UML notation might allow it to become a mandatory part of project development. "It might be useful to create a specific notation for security functionality, or countermeasures that have been added to mitigate vulnerabilities and threats." == See also ==