Using abuse frames to bound the scope of security problems

Journal of Lightwave Technology

We are developing an approach using Jackson's Problem Frames to analyse security problems in order to determine security vulnerabilities. We introduce the notion of an anti-requirement as the requirement of a malicious user that can subvert an existing requirement. We incorporate anti-requirements into so-called abuse frames to represent the notion of a security threat imposed by malicious users in a particular problem context. We suggest how abuse frames can provide a means for bounding the scope of security problems in order to analyse security threats and derive security requirements.

ETAPS-04, 2003

Abstract. In this paper, we present an approach using problem frames to analyse security problems in order to determine security threats and vulnerabilities. We use problem frames to capture and bound the base system that is to be protected. We consider threats to this base problem frame from the point of view of the attacker. For each class of threats, their successful realisation is regarded as the anti-requirement in an abuse frame. Antirequirements are quantified existentially: that is, the attacker succeeds by realising the ...

Emerging Trends in Information and …, 2006

We present a method for security engineering, which is based on two special kinds of problem frames that serve to structure, characterize, analyze, and finally solve software development problems in the area of software and system security. Both kinds of problem frames constitute patterns for representing security problems, variants of which occur frequently in practice. We present security problem frames, which are instantiated in the initial step of our method. They explicitly distinguish security problems from their solutions. To prepare the solution of the security problems in the next step, we employ concretized security problem frames capturing known approaches to achieve security. Finally, the last step of our method results in a specification of the system to be implemented given by concrete security mechanisms and instantiated generic sequence diagrams. We illustrate our approach by the example of a secure remote display system.

1999

The relationships between the work products of a security engineering process can be hard to understand, even for persons with a strong technical background but little knowledge of security engineering. Market forces are driving software practitioners who are not security specialists to develop software that requires security features. When these practitioners develop software solutions without appropriate security-specific processes and models, they sometimes fail to produce effective solutions. We have adapted a proven object oriented modeling technique, use cases, to capture and analyze security requirements in a simple way. We call the adaptation an abuse case model. Its relationship to other security engineering work products is relatively simple, from a user perspective

IFIP International Federation for Information Processing, 2006

An important aspect of security requirements is the understanding and listing of the possible threats to the system. Only then can we decide what specific defense mechanisms to use. We show here an approach to list all threats by considering each action in each use case and analyzing how it can be subverted by an internal or external attacker. From this list we can deduce what policies are necessary to prevent or mitigate the threats. These policies can then be used as guidelines for design. The proposed method can include formal design notations for validation and verification.

2004

We grow increasingly dependent on the appropriate operation of computer-based systems. One aspect of such systems is security. As systems become more complex current means of analysis will probably prove ineffective. In the safety domain a variety of analysis techniques has emerged over many years. These have proved surprisingly effective. Since the safety and security domains share many similarities, various authors have suggested that safety techniques might usefully find application in security. This report takes one such technique, HAZOPs, and applies it to one widely used informal design component – UML’s use cases.

2008

In previous work we introduced an approach for finding security requirements based on misuse activities (actions). This method starts from the activity diagram of a use case (or a sequence of use cases). Each activity is analyzed to see how it could be subverted to produce a misuse of information. This analysis results in a set of threats. We then consider which policies can stop or mitigate these threats. We now extend that approach to consider in the analysis the type of misuse (confidentiality, integrity ...) that can happen in each activity, the role of the attacker, and the context for the threat. This extended analysis results in a finer and more systematic way to find threats and we can identify now more threats. We also improve the way to find the policies to control these threats and we consider how to map the corresponding policies to security patterns. The information in each pattern helps in the selection of an optimal (or good) set of policies. Our extended approach can be conveniently incorporated in a methodology to build secure systems.

IEEE Software, 2003

Proceedings of the 3rd …, 2004

2004

Abstract Unlike typical functional requirements, security requirements can potentially be highly reusable, especially if specified as instances of reusable templates. In this column, I will discuss the concepts underlying security engineering including its quality subfactors. I will then address the issue of security requirements and how they differ from the architectural mechanisms that will fulfill them.