Abstract not found

Security in computer systems is important so as to ensure reliable operation and to protect the integrity of stored information. Faults in the implementation of critical components can be exploited to breach security and penetrate a system. These faults must be identified, detected, and corrected to ensure reliability and safeguard against denial of service, unauthorized modification of data, or disclosure of information. We define a classification of security faults in the Unix operating system. We state the criteria used to categorize the faults and present examples of the different fault types. We present the design and implementation details of a prototype database to store vulnerability information collected from different sources. The data is organized according to our fault categories. The information in the database can be applied in static audit analysis of systems, intrusion detection, and fault detection. We also identify and describe software testing methods that should be effective in detecting different faults in our classification scheme.

ix 0.1 An Overview of Software Testing Methods # # # # # # # # # # # # # # # 2 0.2 Provable Security and Formal Methods # # # # # # # # # # # # # # # # # 9 0.3 Security Testing # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 10 0.4 Applications of Fault Categories # # # # # # # # # # # # # # # # # # # # # 11 0.5 Organization of the Thesis # # # # # # # # # # # # # # # # # # # # # # # # 12 1. RELATED WORK # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 14 1.1 Protection Analysis Project # # # # # # # # # # # # # # # # # # # # # # # 14 1.2 RISOS Project # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 19 1.3 Flaw Hypothesis Methodology # # # # # # # # # # # # # # # # # # # # # # 21 1.4 Case Study# Penetration Analysis of the Michigan Terminal System # 23 1.5 Software Fault Studies # # # # # # # # # # # # # # # # # # # # # # # # # # 25 1.5.1 Fault Categories # # # # # # # # # # # # # # # # # # # # # # # # # # 27 1.6 Errors of T E X # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 31 1.7 A Taxonomy of Computer Program Security Flaws # # # # # # # # # # 32 1.8 Comparison of Security Fault Classi#cation Schemes # # # # # # # # # # 33 2. A TAXONOMY OF SECURITY FAULTS IN THE UNIX OPERATING SYSTEM # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 35 2.1 A Taxonomy of Security Faults # # # # # # # # # # # # # # # # # # # # # 36 2.2 Con#guration Errors # # # # # # # # # # # # # # # # # # # # # # # # # # # 40 2.2.1 Examples # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 40 2.3 Synchronization Errors # # # # # # # # # # # # # # # # # # # # # # # # # # 41 2.3.1 Example # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 41...

Understanding the impact of software changes has been a challenge since software systems were first developed. With the increasing size and complexity of systems, this problem has become more difficult. There are many ways to identify the impact of changes on the system from the plethora of software artifacts produced during development and maintenance. We present the analysis of the software development process using change and defect history data. Specifically, we address the problem of small changes. The studies revealed that (1) there is less than 4 percent probability that a one-line change will introduce an error in the code; (2) nearly 10 percent of all changes made during the maintenance of the software under consideration were one-line changes; (3 the phenomena of change differs for additions, deletions and modifications as well as for the number of lines affected. 1.

Understanding the impact of software changes has been a challenge since software systems were first developed. With the increasing size and complexity of systems, this problem has become more difficult. There are many ways to identify change impact from the plethora of software artifacts produced during development and maintenance. We present the analysis of the software development process using change and defect history data. Specifically, we address the problem of small changes. The studies revealed that (1) there is less than 4 percent probability that a one-line change will introduce an error in the code; (2) nearly 10 percent of all changes made during the maintenance of the software under consideration were one-line changes; (3 the phenomena of change differs for additions, deletions and modifications as well as for the number of lines affected. 1.

We present a novel scheme for categorizing coding faults. Our grammar based scheme uses the notion of syntactic transformers and is automatable. The classification that results from our scheme can be used by researchers investigating the effectiveness of software testing techniques. In these respects our scheme is significantly different from several proposed in the past by other researchers. We have used it to categorize the ten year log of errors of T E X reported by Knuth. For each fault classified, we also provide, wherever possible, the precise substring that constitutes the fault. The entire error log and the associated program is in public domain and hence our categorization can be verified. We also provide a fault classification algorithm that uses a top-down strategy to find the differences between two parse trees, annotated with syntactic transformers, to classify various faults. We claim that such an algorithm can be integrated within a software development envir...

Abstract not found

Many studies have been performed on the subject of software reliability, but few explicitly consider the impact of software testing on the reliability process. This paper presents two important issues on software reliability modeling and software reliability economics: testing effort and efficiency. First, we will discuss on how to extend the logistic testing-effort function into a general form. The generalized logistic testing-effort function has the advantage of relating the work profile more directly to the natural flow of software development. Therefore, it can be used to describe the actual consumption of resources during software development process and get a conspicuous improvement in modeling testing-effort expenditures. Furthermore, we will incorporate the generalized logistic testing-effort function into software

Abstract. While it is clear that there are many sources of variation from one development context to another, it is not clear a priori what specific variables will influence the effectiveness of a process in a given context. For this reason, we argue that knowledge about software process must be built from families of studies, in which related studies are run within similar contexts as well as very different ones. Previous papers have discussed how to design related studies so as to document as precisely as possible the values of likely context variables and be able to compare with those observed in new studies. While such a planned approach is important, we argue that an opportunistic approach is also practical. The approach would combine results from multiple individual studies after the fact, enabling recommendations to be made about process effectiveness in context. In this paper, we describe two processes with which we have been working to build empirical knowledge about software development processes: One is a manual and informal approach, which relies on identifying common beliefs or

Many engineering fields have recognized the need to analyze past mistakes and failures in the hope of learning from them. In computer science this realization has resulted in the development of software testing techniques that attempt to detect known problems from software systems and in improved compilers and development tools. However, there exists a series of software failures where detailed analysis is rarely published, mainly for fear that the information could be used against active systems. These software failures, commonly referred to as computer vulnerabilities, have special properties that set them apart from traditional software failures. Detailed analysis of the factors that contribute to the existence of these vulnerabilities is mostly limited to cryptic articles posted to hacker newsgroups or web sites. There are a few notable exceptions, and this report attempts to add to these with a detailed analysis of four common computer vulnerabilities. The analysis of each vulnera...