John E. Dobson

The change and evolution of requirements as a challenge to the practice of software engineering

The difficulty of handling changing requirements within traditional development processes is described. The origins of changing user and organizational requirements are discussed and different types are classified. The author identifies a number of ways in which different approaches to design may help to deal with change as well as mechanisms which should underpin effective communication between users and designers.<<ETX>>

Building Reliable Secure Computing Systems Out Of Unreliable Insecure Components

Parallels are drawn between the problems and techniques associated with achieving high reliability, and those associated with the provision of security, in distributed computing systems. Some limitations of the concept of a Trusted Computing Base are discussed, end an alternative approach to thedesign of highly secure computing systems is put forward,based on fault tolerance concepts and techniques.

Towards Operational Measures of Computer Security: Concepts

Ideally, a measure of the security of a system should capture quantitatively the intuitive notion of `the ability of the system to resist attack’. That is, it should be operational,reflecting the degree to which the system can be expected to remain free of security breaches under particular conditions of operation (including attack). Instead, current security levels at best merely reflect the extensiveness of safeguards introduced during the design and development of a system. Whilst we might expect a system developed to a higher level than another to exhibit ‘more secure behaviour’ in operation, this cannot be guaranteed; more particularly, we cannot infer what the actual security behaviour will be from knowledge of such a level. In the paper we discuss similarities between reliability and security with the intention of working towards measures of ‘operational security’ similar to those that we have for reliability of systems. Very informally, these measures could involve expressions such as the rate of occurrence of security breaches (cf rate of occurrence of failures in reliability), or the probability that a specified ‘mission’ can be accomplished without a security breach (cf reliability function). This new approach is based on the analogy between system failure and security breach. A number of other analogies to support this view are introduced. We examine this duality critically, and have identified a number of important open questions that need to be answered before this quantitative approach can be taken further. The work described here is therefore somewhat tentative, and one of our major intentions is to invite discussion about the plausibility and feasibility of this new approach.

How responsibility modelling leads to security requirements

When a technical system is placed in a social context organisational requirements arise in addition to the functional requirements on the system. Security is a good example of such an organisational requirement. A means of identifying these organisational requirements is needed and also a way of specifying them that is meaningful both to users and systems designers. This paper proposes that the concept of responsibility fills both these needs. Responsibilities embody requirements in that the responsibility holder needs to do things, needs to know things and needs to record things for subsequent audit. These needs form the basis of a ‘need-to-know’ security policy. Furthermore a model of responsibilities describes the context within the organisational structure in which the requirements, including those related to security, arise.

A framework for expressing models of security policy

The authors first describe some issues that arise from the interplay between the security requirements for an integrated project support environment (IPSE) for the development of a trusted system, and the security requirements of the trusted system itself. All of these issues derive from security policy and the modeling of security policy. A framework is then presented which allows security policies to be expressed in the context of the enterprise whose needs the trusted system is intended to serve. Finally some possible applications of the framework are used to indicate how security policies affect design decision-making, security policy conflict detection, and security risk evaluation.<<ETX>>

ORDIT: a new methodology to assist in the process of eliciting and modelling organizational requirements

Requirements engineering from an organisational perspective needs to be viewed as social engineering, Thus in this paper a modelling language will be presented, which is visual in nature, and with which we assert that it is possible to diagrammatically represent and reason about the impact that an information technology system may have on an organisation, and thus derive organisational requirements.

Organisational requirements definition for information technology systems

We describe a model of the requirements determination process based on four concurrent subprocesses which we term scoping, modelling, requirements and options. The main features of each of these subprocesses are described and we propose that the concept of responsibility is a boundary object which links them all. We also argue that analysing an organisation in terms of responsibilities leads to requirements definition in a more natural manner than basing the organisational analysis on activities.<<ETX>>

Business and Market Models of Brokerage in Network -Based Commerce

Enterprise models, based on the responsibilities and relationships underlying market activities, are used to provide a framework for representing and analysing the activity of brokerage in network-based commerce. Examples of models are presented that represent new configurations of systems, services and processes. Three distinct phases of brokerage are recognised: rendezvous, transaction and post-sales. The security requirements for transactions in broking are so much greater than those for information provision over the Internet that separate business cases can be made for each.

The ORDIT approach to requirements identification

The authors describe the ORDIT approach to requirements identification and expression within the context of organization change. ORDIT focuses on the representation of organizational requirements in the design of socio-technical systems which are intended to emphasize the relationships between organizational structure and information technology (IT) systems. The five main components of the ORDIT methodology are discussed, with a focus on the process model and the enterprise model. A process model is a model of the process of eliciting and modeling requirements. One of the main characteristics of the ORDIT process model is the way it has separated these two functions and has shown the relation between them. The ORDIT project has devised an enterprise modeling language to represent the structure of the organization to serve two related but distinct purposes: to determine the requirements owners and their positions and roles within the organization; and to determine the users and their roles and responsibilities within the organization.<<ETX>>

New security paradigms: what other concepts do we need as well?

Conventional approaches to computer securit,y lia.ve concentrated on defining securit.y in t,erms of a.ccess t,o resources implemented by locally imposed and ma,naged constraints on simple access modes (e.g., read and write) to system resources (e.g., files a.nd direct,ories). It is now becoming accept,ed t,hat. tellis view of security is inadequa.te for ma.na.giug securit,y in a federation of administrative domains where local policies may conflict with global object,ives and some negot,iation is required to adjust multiple loca.1 policies in order to prevent loca.1 policy conflicts from hindering the achievement of a globa. policy. This new securit.y requirement demands not so much new implementation technology as new concepts t,o be elabora.ted. We shall argue that issues of security policy need to be derived from understanding the wa.y that responsihility and a.uthority work in an ent,erprise, a.nd that t,he conventiona. appr0a.A of giving priorit.y t.0 modelling resource protection in terms of subjects, objects aud rules, formalising these in a. ‘securit.y policy’ and espetting the result automa.tically t.0 achieve orga.nisational security objectives, is to misrllltlerst,antl any legitimate local agency the seci1rit.y syst.em may ha.ve as a global agency. 1 A Perspective on Computer Security Modelling 1.1 Old Security Paradigms There have been a number of import.a.nt. and influential milestones in the development. of secure syst,ems ‘The use of the word ‘paradigm’ (as a noun) in t.he t.it.le is the only such use in this paper. Our unrlerstandiilgof the nse of the word in a philosophical cont,ext leads ns t.o prefer the phrase ‘conceptual model’ (e.g., of securit.y) inskad. 01993 ACM O-89791-635-2