Robin C. Laney

Security Requirements Engineering: A Framework for Representation and Analysis

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.

Relating software requirements and architectures using problem frames

Problem frames provide a means of analyzing and decomposing problems. They emphasise the world outside of the computer, helping the developer to focus on the problem domain, instead of drifting into inventing solutions. However, even modestly complex problems can force us into detailed consideration of the architecture of the solution. This is counter to the intention of the problem frames approach, which is to delay consideration of the solution space until a good understanding of the problem is gained. We therefore extend problem frames, allowing architectural structures, services and artifacts to be considered as part of the problem domain. Through a case study, we show how this extension enhances the applicability of problem frames in permitting an architecture-based approach to software development. We conclude that, through our extension, the applicability of problem frames is extended to include domains with existing architectural support.

A framework for security requirements engineering

This paper presents a framework for security requirements elicitation and analysis, based upon the construction of a context for the system and satisfaction arguments for the security of the system. One starts with enumeration of security goals based on assets in the system. These goals are used to derive security requirements in the form of constraints. The system context is described using a problem-centered notation, then this context is validated against the security requirements through construction of a satisfaction argument. The satisfaction argument is in 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.

Deriving security requirements from crosscutting threat descriptions

It is generally accepted that early determination of the stakeholder requirements assists in the development of systems that better meet the needs of those stakeholders. General security requirements frustrate this goal because it is difficult to determine how they affect the functional requirements of the system.This paper illustrates how representing threats as crosscutting concerns aids in determining the effect of security requirements on the functional requirements. Assets (objects that have value in a system) are first enumerated, and then threats on these assets are listed. The points where assets and functional requirements join are examined to expose vulnerabilities to the threats. Security requirements, represented as constraints, are added to the functional requirements to reduce the scope of the vulnerabilities. These requirements are used during the analysis and specification process, thereby incorporating security concerns into the functional requirements of the system.

Composing requirements using problem frames

Problem frames are a systematic approach to the decomposition of problems that allows us to relate requirements, domain properties, and machine specifications. Having decomposed a problem, one approach to solving it is through a process of composing solutions to sub-problems. In This work, we contribute to supporting such a process by providing a way to compose multiple problem frames. We develop a systematic approach to composing inconsistent requirements. We introduce composition frames, a requirements construct that models relevant aspects of composition and thus deals with unwanted effects, such as interference of overlapping reactions to events. Throughout the paper, we use a simple case study to illustrate and validate our ideas.

The effect of trust assumptions on the elaboration of security requirements

Assumptions are frequently made during requirements analysis of a system-to-be about the trustworthiness of its various components (including human components). These trust assumptions can affect the scope of the analysis, derivation of security requirements, and in some cases, how functionality is realized. This work presents trust assumptions in the context of analysis of security requirements. A running example shows how trust assumptions can be used by a requirements engineer to help define and limit the scope of analysis and to document the decisions made during the process. The paper concludes with a case study examining the impact of trust assumptions on software that uses the secure electronic transaction (SET) specification.

Let's jam the reactable: Peer learning during musical improvisation with a tabletop tangible interface

There has been little research on how interactions with tabletop and Tangible User Interfaces (TUIs) by groups of users change over time. In this article, we investigate the challenges and opportunities of a tabletop tangible interface based on constructive building blocks. We describe a long-term lab study of groups of expert musicians improvising with the Reactable, a commercial tabletop TUI for music performance. We examine interaction, focusing on interface, tangible, musical, and social phenomena. Our findings reveal a practice-based learning between peers in situated contexts, and new forms of participation, all of which is facilitated by the Reactables tangible interface, if compared to traditional musical ensembles. We summarise our findings as a set of design considerations and conclude that construction processes on interactive tabletops support learning by doing and peer learning, which can inform constructivist approaches to learning with technology.

Problem Frames: A Case for Coordination

We show how principles of separation of Coordination from Computation can be used to endow the Problem Frames approach to problem analysis with representation schemes. These representation schemes facilitate the way evolution of requirements or of the application domain can be reflected in the decomposition structure, making it easier to change.

Picking Battles: The Impact of Trust Assumptions on the Elaboration of Security Requirements

This position paper describes work on trust assumptions in the context of security requirements. We show how trust assumptions can affect the scope of the analysis, derivation of security requirements, and in some cases how functionality is realized. An example shows how trust assumptions are used by a requirements engineer to help define and limit the scope of analysis and to document the decisions made during the process.

Modelling the similarity of pitch collections with expectation tensors

Models of the perceived distance between pairs of pitch collections are a core component of broader models of music cognition. Numerous distance measures have been proposed, including voice-leading, psychoacoustic, and pitch and interval class distances; but, so far, there has been no attempt to bind these different measures into a single mathematical or conceptual framework or to incorporate the uncertain or probabilistic nature of pitch perception. This paper embeds pitch collections in expectation tensors and shows how metrics between such tensors can model their perceived dissimilarity. Expectation tensors indicate the expected number of tones, ordered pairs of tones, ordered triples of tones, etc., that are heard as having any given pitch, dyad of pitches, triad of pitches, etc. The pitches can be either absolute or relative (in which case the tensors are invariant with respect to transposition). Examples are given to show how the metrics accord with musical intuition.