From misuse cases to mal-activity diagrams: bridging the gap between functional security analysis and design

Nowadays, it is impossible to ignore the implementation of security features in information systems since they manage important assets that are critical for the business processes of organizations. In this aspect, there have been several researches for introducing the security analysis in different stages of software development life cycle. Among those solutions, one of the most interesting one is the usage of misuse cases. Misuse cases, which are extensions of the well-known use cases, were created for defining security requirements. A misuse case can be considered as the inverse of a use case and it defines functions that the system should not allow. Even though, misuse cases are very useful for eliciting security requirements, they do not provide a mechanism to prioritize such requirements. Therefore, they do not address the problem of optimal risk management. Software engineers often have to work within a given set of budget constraints that may impede them from implementing all possible countermeasures. Thus, the software engineer needs to find a way to prioritize the security requirements to decide which requirements will be developed. Motivated by the mentioned limitation of misuse cases, the presented paper proposes an enhanced misuse case model which incorporates a method for prioritization of security requirements.

Negative scenarios have long been applied in e.g. military and commercial operations planning. The negative form of the use case is the 'misuse case'. Experience has been gained in applying misuse cases to analyse requirement/design option trade-offs in a railway case study. In a trade-off workshop, a diagram is constructed showing use cases for goals held by system designers, and misuse cases for goals of hostile agents. Relationships between these goals are elicited and documented on the diagram. Experience in a railway trade-off study led to the devising of a set of relationships suited to trade-off analysis: 'threatens', 'mitigates', 'aggravates', and 'conflicts with', as well as the more general 'includes'. The result is a graphic that makes clear to nontechnical stakeholders how their requirements may conflict in the design domain. This contributed to the success of the trade-off workshop. The approach taken for the railway workshop is simple. It could be applied in other domains, and with other participative methods.

Software applications are essential for managing daily life activities, including social interactions and business transactions, that significantly increase the need for security in sharing sensitive information. Misuse case modeling is used for identifying and analyzing security requirements in software applications. However, security threats and their corresponding mitigations are inherently cross-cutting concerns. These concerns are scattered and tangled within multiple functional requirements and cannot be modularized using traditional object-oriented techniques. The realization of misuse cases causes crosscutting threats and corresponding mitigations to be scattered and tangled across use cases, resulting in ambiguity, incomplete understanding, and insufficient analysis of security requirements. This study proposes a misuse case modelling method called Aspect-oriented Formalized Misuse Case (AFMUC). It specifies crosscutting security threats separately as an aspect misuse case and integrates them with use cases using an aspect-oriented approach. AFMUC provides structured guidelines and restriction rules for modeling crosscutting security threats and corresponding mitigations using aspect-oriented constructs such as Pointcut, Joinpoint Advice, and Introduction. The aspect threat model is then woven into the base use case model. Similarly, an aspect mitigation model is proposed to specify crosscutting mitigations following the AFMUC restriction rules. The aspect mitigation model is then woven into the base misuse case model. The proposed approach is applied to a case study and evaluated through a controlled experiment involving twenty-four students with a background in information security. The findings indicate that the AFMUC approach is practical and unambiguous for specifying and analyzing crosscutting security requirements. However, some aspect-oriented modeling constructs and restriction rules have been misapplied by students. This shows that while students favored the AFMUC approach, they may have found it challenging to apply the aspect-oriented constructs and restriction rules due to a limited exposure to aspect-oriented modelling.

Modeling Security and Privacy Requirements: a Use Case-Driven Approach

The software development industry often brings in security at the eleventh hour, right before developers throw the code over the wall - that is, deploy it into production - and asks, "Well, is it secure?" At this point, hilarity - for the objective observers, anyhow - ensues as security personnel work feverishly to shove crypto, firewalls, and all the other mechanisms at their disposal into the most egregious risk areas. To combat this antipattern, the software security discipline has worked to instantiate itself closer to the beginning of the software development life cycle (SDLC). After signing off on a software project, use cases represent the earliest opportunity for involvement. Misuse cases; prescribe one such way for security to involve itself in early brainstorming. That article outlined misuse cases as a way to help analysts characterize what misuses or abuses attackers could promulgate against a system. This article extends this outline to how to create useful misuse cases within the development process

Software security testing is an important technique for discovering software vulnerabilities that violate security requirements. Existing security testing methods, however, seldom generate security tests directly from security requirements specifications. To address this issue, this paper presents an approach for constructing security test models from the artifacts of misuse case modeling (i.e., use/misuse cases and mitigation use cases), which is a popular method for security requirements specification in the software development process. The security test models can then be used to automatically generate security tests, which consist of test inputs (normal behaviors from use cases and attack actions from misuse cases) and test oracles from mitigation use cases. We have applied the approach to two case studies. One case study demonstrates that the proposed approach can build security test models in a structured fashion such that the generated security tests are as effective as reported in the literature. The second case study applies the proposed approach to an ongoing software development project. The security tests have revealed at least 24 vulnerabilities, and are very helpful for the development team to improve the security of the software implementation. This demonstrates that the proposed approach is effective in the software development process.

Towards developing consistent misuse case models

The idea of security aware system development from the start of the engineering process is generally accepted nowadays and is becoming applied in practice. Many recent initiatives support this idea with special focus on security requirements elicitation. However, there are so far no techniques that provide integrated overviews of security threats and system architecture. One way to achieve this is by combining misuse cases with use case maps into misuse case maps (MUCM). This paper presents an experimental evaluation of MUCM diagrams focusing on identification of vulnerabilities and mitigations. The controlled experiment with 33 IT students included a complex hacker intrusion from the literature, illustrated either with MUCM or with alternative diagrams. The results suggest that participants using MUCM found significantly more mitigations than participants using regular misuse cases combined with system architecture diagrams.

As interests in security increases, several software development lifecycle considering security have been proposed. Actual results of applying software development lifecycle considering security reduced threats have been reported. But to apply software development lifecycle considering security, requires expertise and experiences. In this paper a secure software development lifecycle applying integrated secure guide is proposed. Secure Guides such as Misuse Case, Security Patterns and Secure Coding are integrated in the proposed method. And then, by applying integrated Secure Guide in each software development phase, the security becomes available in every phase of software development. Since, proposed secure guide provides more security information than available secure guides, software developer can use more security information while they are developing software. As a result, it is expected that developers could consider security more easily when developing software even though developers lacks expertise in security or experience.

A scientific evaluation of the misuse case diagrams visual syntax

Use case diagrams is a popular early stage modeling notation for functional requirements, and misuse cases have similarly been explored for security and safety threats and requirements implied by these. One key goal of use case diagrams is simplicity, which make it possible to involve many types of stakeholders. Hence one wants to avoid including too much information in these diagrams. One type of information typically not included relates to the usage context, for instance what kind of equipment to be used to perform the use case. However, for multi-channel information systems, this is often highly relevant, and may in some cases make the diagrams clearer to stakeholders rather than more obscure, as long as the information is presented in a visually intuitive manner. This paper proposes some adapted notations to indicate what equipment is applied in use and misuse case diagrams.

While software security has become an expectation, stakeholders often have difficulty expressing such expectations. Elaborate (and expensive) frameworks to identify, analyze, validate and incorporate security requirements for large software systems (and organizations) have been proposed, however, small organizations working within short development lifecycles and minimal resources cannot justify such frameworks and often need a light and practical approach to security requirements engineering that can be easily integrated into their existing development processes. This work presents an approach for eliciting, analyzing, prioritizing and developing security requirements which can be integrated into existing software development lifecycles for small organizations. The approach is based on identifying candidate security goals using part of speech (POS) tagging, categorizing security goals based on canonical security definitions, and understanding the stakeholder goals to develop preliminary security requirements and to prioritize them. It uses a case study to validate the feasibility and effectiveness of the proposed approach.

Security requirements play a vital role in the software development process to gain secured software. The security levels of each software system can be varied depending on multiple factors, such as information processing or storing in the software system, business criticality of the software system, or features and functions of the system. However, the understanding of these factors has not been done early and has little or no involvement from the business users (end-users or system owners), who have the best understanding of how the system should be used in their business and the business impacts. As a result, the system design is done without awareness of these factors. Most of the time designing the system to address security concerns is done late in the development lifecycle, which causes extra money, effort, and time from the development team. In this paper, we propose a framework to help elicit the security requirements from business users based on the survey questions. The framework recommends a set of security requirements and implementation methods that are suitable for the business operations of the system. Two web applications with 12 business users for each application were selected to experiment with the effectiveness of the framework. The framework's suggested results were tested for conformity against a set of security recommendations from four security experts. We found that the security requirements and recommendations from the framework have an average 89% conformity for the WFMS system and a 93% conformity for the ASMS system with the expert recommendations.

From the Publisher: Models in System Design tracks the general trend in electronics in terms of size, complexity and difficulty of maintenance. System design is by nature combined with prototyping, mixed domain design, and verification, and it is no surprise that today's modeling & models are used in various levels of system design and verification. In order to deal with constraints induced by volume and complexity, new methods and techniques have been defined. Models in System Design provides an overview of the latest modeling techniques for use by system designers. Models in System Design will help designers and researchers to understand these latest techniques in system design and as such will be of interest to all involved in embedded system design.

With the introduction of the Industrial/sup IT/ vision at ABB, the coordination of hardware and software development is a crucial aspect that the organization needs to address. Software development and hardware production processes need to be coordinated into one coherent lifecycle model to optimize development. This paper presents some basic concepts in software and hardware development lifecycles and paves the road for a more comprehensive approach for a system development lifecycle.