Malicious attacks on systems are a threat to business, government, and defense. Many attacks exploit system behavior unknown to the developers who created it. In today’s state of art, software engineers have no practical means to determine how a sizable program will behave in all circumstances of use. This sobering reality lies at the heart of many problems in security and survivability. If full behavior is unknown, so too are embedded errors, vulnerabilities, and malicious code. This paper describes function-theoretic foundations for automated calculation of full program behavior. These foundations treat program control structures as mathematical functions or relations. The function, or behavior, of control structures can be abstracted in a stepwise process into procedurefree expressions that specify their net functional effects. Problems of computability and complexities of language semantics appear to have engineering solutions. Automated behavior calculation will add rigor to security and survivability engineering. 1. Understanding Program Behavior Traditional engineering disciplines depend on rigorous methods to evaluate the expressions (equations, for example) that represent and manipulate their subject matter. Yet the discipline of software engineering has no practical means to fully evaluate the expressions it produces. In this case, the expressions are computer programs, and evaluation means understanding their full behavior, right or wrong, intended or malicious. Short of substantial time and effort, no software engineer can say for sure what a sizable program does in all circumstances of use. Yet modern society is dependent on the correct functioning of countless large-scale systems composed of programs whose full behavior and security properties are

We describe a relational method for specifying features and detecting feature interactions. The method allows for an independent specification of system features, and for a detection of interaction between features. 1 Introduction Feature Interaction refers to a situation where the activation of two functions produces an unpredictable behaviour, that fails to satisfy one of the functions or both of them. This phenomenon occurs in complex software systems that offer a wide range of welldefined functions, and is prevalent in systems that provide telecommunications services; such systems may provide several hundred distinct functions, hence have the potential to create feature interactions on a massive scale. The first observation that one may make in regards to feature interaction is that it is typically a property of the specifications of the functions that make up the system, rather than their implementation; consequently, it should be detected and dealt with at the requirements speci...

Technology on Next-Generation

We describe a relational method for specifying features and detecting feature interactions. The method allows for an independent specification of system features, and for a detection of interaction between features. The method is based on the lattice of relational specifications: the system specification is given as the conjunction (lattice operator meet) of the features; a feature interaction is detected when the meet of the features does not exist. Examples of detection are given using logic programming. 1 Introduction Over the past years, the problem of feature interaction has drawn considerable interest in the research community [5, 4, 9]. A feature is a collection of functionalities that are added incrementally in a software system. A feature interaction occurs whenever their specifications contradict each other by producing conditions that no behavior can satisfy. This problem is especially acute in telecommunication systems [5], where the number of features is impressive: some ...

Introduction Graphs and graphic notations play a prominent role in the representation and analysis of software specifications and software designs: From data flow diagrams, to entity-relation diagrams, to modular structure diagrams, to Petri Nets, the range of application of graphs is very wide, as it varies with how nodes and arrows are interpreted, and how they are annotated. The purpose of this section is to give a characterization of state transition diagrams; our characterization attempts to be specific enough to exclude all other graphic notations, yet general enough to include all the notations that are typically considered as such diagrams. Basically, a state transition diagram is a graph whose nodes represent states of a system and whose arrows represent transitions between states. The literature about state transition diagrams is abundant. We have chosen to restrict our presentation to the initial models of state transition diagrams, and to present some of their succ

Abstract not found