Victoria Stavridou

An Architecture for an Adaptive Intrusion-Tolerant Server

We describe a general architecture for intrusion-tolerant enterprise systems and the implementation of an intrusion-tolerant Web server as a specific instance. The architecture comprises functionally redundant COTS servers running on diverse operating systems and platforms, hardened intrusion-tolerance proxies that mediate client requests and verify the behavior of servers and other proxies, and monitoring and alert management components based on the EMERALD intrusion-detection framework. Integrity and availability are maintained by dynamically adapting the system configuration in response to intrusions or other faults. The dynamic configuration specifies the servers assigned to each client request, the agreement protocol used to validate server replies, and the resources spent on monitoring and detection. Alerts trigger increasingly strict regimes to ensure continued service, with graceful degradation of performance, even if some servers or proxies are compromised or faulty. The system returns to less stringent regimes as threats diminish. Servers and proxies can be isolated, repaired, and reinserted without interrupting service.

Integration in software intensive systems

Abstract This article is concerned with systems integration and its impact on software intensive projects. It contains a review and a taxonomy of integration concepts as applied to software intensive systems. We identify pertinent technical integration issues and review and classify integration models, strategies, mechanisms and architectures. We argue that integration is part of the design activity and propose existing best integration practice for project management and engineering of large software intensive systems.This article is concerned with systems integration and its impact on software intensive projects. It contains a review and a taxonomy of integration concepts as applied to software intensive systems. We identify pertinent technical integration issues and review and classify integration models, strategies, mechanisms and architectures. We argue that integration is part of the design activity and propose existing best integration practice for project management and engineering of large software intensive systems.

Provably dependable software architectures

Dependable architectures demonstrably possess properties such as safety, security, and fault tolerance. We are interested in developing methods allowing formal demonstrations through proof that an architecture does indeed possess the desired dependability properties. We focus on architecture hierarchies as a means of enabling such demonstrations. We pose a challenge problem for dependable software architectures and we propose a research agenda for solving it. 1 What are dependable software architectures? Software architectures describing software products that are used to implement critical functions must be trustworthy. Dependability is the property of a computing system which allows reliance to be justi ably placed on the service it delivers. The service delivered by a system is its behavior as it is perceived by its users. Dependability is a qualitative judgment about a system. The software architecture community has made great strides toward characterizing and capturing system descriptions appropriately and toward providing linguistic support for de ning families of software products, but current ADLs and their associated methodologies do not adequately address dependability. When software products are deployed in a high-integrity system, their dependability pro le is key to the survivability of the system. It is desirable to have developers of critical systems also bene t from software architecture technology. For example, an autopilot software producer would like to be able to derive, from a single abstract speci cation of a dependable software architecture, implementations for a number of aircraft variants. The derivation process would be supported by tools for applying dependability-preserving transformations that make abstract speci cations more concrete. So, these implementations would be known to share dependability attributes as well as functionality. Such dependability-preserving transformations are key not only for e ective and timely resource development, but also for assurance and certi cation. Enriching software architecture descriptions by including dependability attributes will enable and facilitate the reuse of not only software components but certi cation data as well. In critical systems, the cost of assurance and certi cation is comparable with the development cost. Dependable architectures demonstrably possess properties such as safety, security, and fault tolerance. It is our objective to produce methods allowing formal demonstrations through proof that an architecture does indeed possess the speci ed dependability properties. One important limitation on the utility of applying typical formal methods to reasoning about architectures is the purely informal connection between the mathematical models that are analyzed and the system being modeled. If formal analysis of a model reveals the presence of a aw, it is generally easy to determine whether that aw is present in the implemented system. But it is highly desirable to use formal methods to establish that the software is free of certain types of aws, such as failing to meet safety, security, or fault tolerance objectives. Security properties typically state that certain sorts of error cannot occur. For example, a security property might state that certain sorts of communication within the system | such as ow of restricted information to a component without adequate clearances | cannot occur. Tools supporting various formal methods can be used to prove that any correct implementation of the abstract mathematical model has these properties. However, there is no guarantee that the actual software correctly implements the model. The problem of gaining con dence in the correctness of the implementation is especially acute in the case of dynamic, dependable architectures, where exhaustive testing of architectural con gurations is frequently prohibitively expensive, when not theoretically infeasible. 2 IMA: a challenge problem for dependable software ar-

Intrusion-tolerant group management in Enclaves

Groupware applications require secure communication and group-management services. Participants in such applications may have divergent interests and may not fully trust each other. The services provided must then be designed to tolerate possibly misbehaving participants. Enclaves is a software framework for building such group applications. We discuss how the protocols used by Enclaves can be modified to guarantee proper service in the presence of nontrustworthy group members. We show how the improved protocol was formally specified and proven correct.

A model of noninterference for integrating mixed-criticality software components

The paper examines the problem of safely integrating independent software components of different criticality levels in a single system. We examine the risks of interference between independent components which share common hardware resources. We propose a definition of safe integration in which only a limited form of interference is tolerated, namely a bounded performance degradation. We show how the definition can be applied to systems modeled as input-output automata, and we compare our model to other notions of noninterference and related concepts.

Protocol codesign

This afternoon Im going to talk to you about some work that were doing on protocol design. This is actually Hassen Saidis work; he spoke a little about this at the workshop here a couple of years ago and since then theres been quite a bit of progress. n nThere are many challenges in the design of protocols; both the ones that we have today, and the ones that we need to evolve in the future. The conversation here this morning clearly identified those challenges, so I dont think I will preach here. But protocols are changing, and theyre changing form in a couple of ways. Theyre changing by moving from the traditional place where one would do a protocol – from the network layer into the application layer – because the applications themselves are changing. Also our expectations of the technology that we develop for security applications has changed. For example, now we talk about intrusion tolerance; its not enough to build something that is secure, I also want to build it in such a way that even if attackers succeed in penetrating it it will still provide some level of service. In that one might see the influence of fault tolerance: todays applications not only have traditional security requirements, but also things that have not traditionally been thought of as properties security protocols would implement. Nonetheless, now that were putting them together the protocols have got to do both jobs. n nNew applications need new protocols and sometimes that happens, but sometimes known protocols get re-engineered (sometimes well, mostly badly), and what tends to happen is that unless one is very, very careful and thoughtful and systematic about the way that protocols are re-engineered or composed, you may end up actually making things worse. Rushby has a good example about putting together two protocols, a fault tolerant protocol and a security protocol, and ending up with something that is neither secure nor fault tolerant. Weve been driven not just by changes in the application, but also by this variety of properties that they have to implement, so we need to understand the interactions of the properties, and the subtleties that those interactions entail, and the impact that those subtleties have on the final product: by and large this is a darn hard thing to do.

Specifying in OBJ, Verifying in REVE and Some Ideas about Time

It is widely recognised that formal specification and verification plays an important role in the design and construction of both software and hardware systems. In this paper we investigate the applicability of the OBJ specification language and the REVE theorem prover, both of which have been traditionally used in connection with software development, as tools for the specification and verification of digital systems. We therefore identify the aspects of these systems which are relevant to hardware development. In particular, we are concerned with optimising proofs in REVE and specifying behaviour of circuits through time.

Dependability then and now: commentary on Donald MacKenzie, "a view from the Sonnenbichl"

Donald MacKenzie has written an insightful account of the evolution of the term “dependability” and its relationship with the efforts of the software engineering community to produce reliable software artifacts. All I need to do here is underline some of his findings and supply some examples of such efforts that I have encountered in my work as a practitioner of software engineering so far. I will also comment on the still evolving nature of dependability and hazard some predictions about the challenges that future dependability procurement will entail given the rapidly changing computing infrastructure of our time.

Safety related standards: a tutorial

The objective of this tutorial is to introduce current and emerging standards that address computer system and software safety. We consider relevant available standards and identify their strengths and weaknesses, we explore how to evaluate standards and we consider their application in practice. We address in depth IEC 61508 and Def Stan 00-56, two important standards. In addition, we will discuss current safety standards activity within the IEEE Software Engineering Standards Committee and we will touch upon the thorny issue of introducing standards into an organization. The tutorial will be practical and will address the application - not just the theory of safety standards. The tutorial is aimed at managers, project managers, safety engineers and software engineers with system or safety responsibility during the lifecycle of safety critical systems.