This paper presents a framework for security requirements elicitation and analysis. The framework is based on constructing a context for the system, representing security requirements as constraints, and developing satisfaction arguments for the security requirements. The system context is described using a problem-oriented notation, then is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument consists of two parts: a formal argument that the system can meet its security requirements and a structured informal argument supporting the assumptions expressed in the formal argument. The construction of the satisfaction argument may fail, revealing either that the security requirement cannot be satisfied in the context or that the context does not contain sufficient information to develop the argument. In this case, designers and architects are asked to provide additional design information to resolve the problems. We evaluate the framework by applying it to a security requirements analysis within an air traffic control technology evaluation project.

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.

Using an underlying role-based model for the administration of roles has proved itself to be a successful approach. This paper sets out to describe the enterprise role-based access control model (ERBAC) in the context of SAM Jupiter, a commercial enterprise security management software.We provide an overview of the role-based conceptual model underlying SAM Jupiter. Having established this basis, we describe how the model is used to facilitate a role-based administration approach. In particular, we discuss our notion of 'scopes', which describe the objects over which an administrator has authority. The second part provides a case study based on our real-world experiences in the implementation of role-based administrative infrastructures. Finally, a critical evaluation and comparison with current approaches to administrative role-based access control is provided.

Organisational control principles, such as those expressed in the separation of duties, supervision, review and delegation, support the main business goals and activities of an organisation. Some of these principles have previously been described and analysed within the context of role- and policy-based distributed systems, but little has been done with respect to the more general context they are placed in and the analysis of relationships between them. This paper presents a framework in which organisational control principles can be formally expressed and analysed using the Alloy specification language and its constraint analysis tools.

Scope: a variety of things are expressed under the heading of access control: permission assignments, constraints, activations, transition, hierarchies, ect. What things really need to be expressed?Concepts: What modeling concepts are available to express these things? Where are we in understanding the usability of these models?Complexity-flexibility tradeoff: How do we make trade-offs between the flexibility of expression (expressive power) and applying more usable concepts? Can this be measured?Domain specificity: Improving ease of use often involves increasing the level of the specification using domain-specific techniques. What techniques are possible? How can we compare teh effectiveness of these techniques?Composition: How can the modularity of access control policies be leveraged? Is there any modularity?Completeness: How do we integrate access control effectively with support for audit and intrusion detection?

Roles are a powerful and policy neutral concept for facilitating distributed systems management and enforcing access control. Models which are now subject to becoming a standard have been proposed and much work on extensions to these models has been done over the last years as documented in the recent RBAC/SACMAT workshops. When looking at these extensions we can often observe that they concentrate on a particular stage in the life of a role. We investigate how these extensions fit into a more general theoretical framework in order to give practitioners a starting point from which to develop role-based systems. We believe that the life-cycle of a role could be seen as the basis for such a framework and we provide an initial discussion on such a role life-cycle, based on our experiences and observations in enterprise security management. We propose a life-cycle model that is based on an iterative-incremental process similar to those found in the area of software development.

Role-based access control is a powerful and policy-neutral concept for enforcing access control. Many extensions have been proposed, the most significant of which are the decentralised administration of role-based systems and the enforcement of constraints. However, the simultaneous integration of these extensions can cause conflicts in a later system implementation. We demonstrate how we use the Alloy language for the specification of a conflict-free role-based system. This specification provides us at the same time with a suitable basis for further analysis by the Alloy constraint analyser.

Research in the area of role-based access control has made fast progress over the last few years. However, little has been done to identify and describe existing role-based access control systems within large organisations. This paper describes the access control system of a major European Bank. An overview of the systems structure, its administration and existing control principles constraining the administration is given. In addition, we provide an answer to a key question - the ratio of the number of roles to the system user population - which was raised in the recent RBAC2000 Workshop. Having described certain weaknesses of the Banks system, the case study is extended to a comparison between the system and the RBAC96 models. In particular the issues of inheritance and grouping are addressed.

As we know, current hookup or composable properties may impose over-strong security requirements on component systems. To overcome this problem, connectivities of the components have to be considered in order to appropriately handle their composition. Based on such a consideration, in this paper we adopt the concept of rely- and guarantee-conditions to present a composable property of noninterference. We enforce the requirement of noninterference only on some input-output entities of each component with regard to its connectivity, and communication constraints on its others so as to ensure that their entire system can satisfy noninterference. This enables the system and its components to possess different security properties, i.e. the security property of the system can be logically stronger than security properties of its components.>

Distributed system management, involves monitoring the activity of a system, making management decisions and performing control actions to modify the behavior of the system. Most of the research on management has concentrated on management mechanisms related to network management or operating systems. However, in order to automate the management of very large distributed systems, it is necessary to be able to represent and manipulate management policy within the system. These objectives are typically set out in the form of general policies which require detailed interpretation by the system managers. The paper explores the refinement of general high-level policies into a number of more specific policies to form a policy hierarchy in which each policy in the hierarchy represents, to its maker, his plans to meet his objectives and, to its subject, the objectives which he must plan to meet. Management action policies are introduced, and the distinction between imperatival and authority policies is made. The relationship of hierarchies of imperatival policies to responsibility, and to authority policies, is discussed. An outline approach to the provision of automated support for the analysis of policy hierarchies is provided, by means of a more formal definition of policy hierarchy refinement relationships in Prolog.>