On Hierarchical Design of Computer Systems for Critical Applications Peter Gabriel Neumann Presented by Bo Cui

Critical environments and Critical requirements  Computers are increasingly being used in life- critical environments and other critical applications.  Critical environments have critical requirements  Any or all of a wide range of characteristics whose absence or diminished presence can result in serious consequences.

Critical Computer System Requirements  Critical computer system requirements exist in different abstractions  Critical requirements are different at each abstraction  Critical system requirements are closely interrelated.

Hypothesis  Appropriate use of hierarchical abstraction and encapsulation can lead to systems intrinsically better at satisfying critical requirements than conventionally designed systems while also helping to reduce undesired side effects and to isolate propagation of failures

Hierarchies  Concept of layer A uses layer B – Layer A depends for its correctness on layer B, or layer A calls layer B, or a combination of both. – A requires presence of correct version of B With respect what set of requirements is correctness to be defined ? – A more mechanistic definition which avoids correctness is : Layer A uses layer B whenever it is syntactically possible that A depends upon B. Depends upon : A is said to depend upon B whenever an action of B, or change to B, or total unavailability of B, can have an effect upon A.

Hierarchies … contd.  Concept of Generalized trusted Computing Base (GTCB) – Enforces most critical properties – Properties that GTCB enforces should not be compromised from outside of GTCB(use good designing techniques like fault tolerance, recovery strategies, careful implementation, verification)

Hierarchies … contd.  Degrees of Criticality – Degrees of criticality for each feature of system is designed and assigned to that layer in the hierarchy  Multilevel Security – All data and sections are classified into some security level – No adverse flow policy i.e. Information is not allowed to flow from a higher level of security to a lower level of security

Hierarchies … contd.  In multi level security (MLS) the lower layers of computer system typically provide a security kernel that enforces no-adverse-flow policy.  On the top of security kernel is implemented a set of trusted processes – These processes can selectively violate no-adverse-flow principle.  The kernel and all trusted software together form the trusted computing base (TCB).

Hierarchies … contd.  Multilevel Integrity – Each program or piece of data is associated with certain level of integrity – No adverse flow policy  Implementation of integrity level separation is used to limit tampering with the system by less trustworthy individuals and in combination with multilevel security can ensure that no Trojan horses, viruses etc can violate the system properties

Design Principles  Principle of least privilege  Principle of information hiding  Principle of preserving hierarchical orderings  Design decomposition should be sought that requires only a small portion of the system to be trusted  All above principles contribute to the notion of defensive design for critical systems which tries to make the results at each layer resilient to undetected or unanticipated failures of lower layers and which tries to propagate its own errors upwards

Conclusion  No system is guaranteed to work properly all the time.  Humans in the loop may add to the problem rather than improve it.  In a complex system it is essentially impossible to predict all the sources of catastrophic failures.  The notion that all critical concerns can be confined to a small portion of the system or distributed system is a fantasy.  Hierarchical design and careful implementation of complex critical systems can help to confine the bad effects and increase system reliability, security and other positive features.