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 threat in any one instance. For a threat to be realised, its abuse frame must be composed with the base problem frame in the sense that the asset attacked in the abuse frame must overlap, or be identified with, a domain of the base problem frame. We explain the process of composition and some of its variations. We illustrate and assess our approach using a case study of a medical information system, and suggest how abuse frames can provide a means for bounding the scope of and reasoning about security problems in order to analyse security threats and identify vulnerabilities. We conclude with an agenda for future work.

Abstract. Misuse cases are a useful technique for eliciting and modelling security requirements and threats. In addition they may be very useful in a risk analysis process, particularly as part of the system development process. The original misuse case notation adds inverted use cases to model threats and inverted actors to represent attackers. However, an attack is usually performed by exploiting a vulnerability in a system and it would be useful to be able to represent vulnerable functions in a model. In addition, it should be possible to discern between insiders and outside attackers in a model, as they have very different abilities and potential for attacking a system. This paper therefore proposes an extended misuse case notation that includes the ability to represent vulnerabilities and the insider threat, and discusses the use of this extended notation in the system development and risk analysis processes. 1

Abstract. In this paper we outline a new process model for security engineering. This process model extends object oriented, use case driven software development by the systematic treatment of security related issues. We introduce the notion of security aspects describing security relevant requirements and measures at a certain level of abstraction. We define a micro-process for security analysis supporting the systematic development of secure components within iterative systems development. 1

Logic will get you from A to B. Imagination will take you everywhere.

Printed by NTNU TrykkLogic will get you from A to B. Imagination will take you everywhere. Access control is a key feature of healthcare information systems. Access control is about enforcing rules to ensure that only authorized users get access to resources in a system. In healthcare systems this means protecting patient privacy. However, the top priority is always to provide the best possible care for a patient. This depends on the clinicians having access to the information they need to make the best, most informed, care decisions. Care processes are often unpredictable and hard to map to strict access control rules. As a result, in emergency or otherwise unexpected situations, clinicians need to be able to bypass access control. In a crisis, availability of information takes precedence over privacy concerns. This duality of concerns is what makes access control in healthcare systems so challenging and interesting as a research subject. To create access control models for healthcare we need to understand how healthcare works. Before creating a model we need to understand the requirements the

development

Detecting known security vulnerabilities from within design and development tools FP7-ICT-2007 215995 D1.2 Initial SHIELDS approach guide

A reoccurring problem in software engineering constitutes ensuring sufficient completeness of requirements specifications with economically justifiable efforts. Formulating precise quality requirements and especially security requirements is elaborate as they depend on many stakeholders and technological aspects that are often unclear in early project phases. Threats that may have a severe impact on the software product are sometimes not even known. One approach to tackle this situation is reusing quality requirements, because they are to a high degree similar in different software products. The effect can be higher quality while at the same time saving time and budget. Quality models are a way to explicitly specify quality. Based on activity-based quality models an approach for specifying reusable quality requirements in early project phases is proposed that also allows a direct derivation of suitable quality requirements for new projects. The applicability of this approach and the resulting reuse potential is investigated in a case study, which concentrates on the security requirements of six industrial projects.

Printed by NTNU TrykkLogic will get you from A to B. Imagination will take you everywhere. Access control is a key feature of healthcare information systems. Access control is about enforcing rules to ensure that only authorized users get access to resources in a system. In healthcare systems this means protecting patient privacy. However, the top priority is always to provide the best possible care for a patient. This depends on the clinicians having access to the information they need to make the best, most informed, care decisions. Care processes are often unpredictable and hard to map to strict access control rules. As a result, in emergency or otherwise unexpected situations, clinicians need to be able to bypass access control. In a crisis, availability of information takes precedence over privacy concerns. This duality of concerns is what makes access control in healthcare systems so challenging and interesting as a research subject. To create access control models for healthcare we need to understand how healthcare works. Before creating a model we need to understand the requirements the

Abstract not found