Summary form only given. Software security has come a long way in the last few years, but we've really only just begun. I will present a detailed approach to getting past theory and putting software security into practice. The three pillars of software security are applied risk management, software security best practices (which I call touchpoints), and knowledge. By describing a manageably small set of touchpoints based around the software artifacts that you already produce, I avoid religious warfare over process and get on with the business of software security. That means you can adopt the touchpoints without radically changing the way you work. The touchpoints I will describe include: code review using static analysis tools; architectural risk analysis; penetration testing; security testing; abuse case development; and security requirements. Like the yin and the yang, software security requires a careful balance-attack and defense, exploiting and designing, breaking and building-bound into a coherent package. Create your own Security Development Lifecycle by enhancing your existing software development lifecycle with the touchpoints

Software security has blossomed nicely in the last few years with the appearance of new textbooks, new courses, and a government mandate, yet there are many people still to be educated. Savvy security people from the operations side tend to decry the cluelessness of software developers, putting the blame for our current software problems squarely on the shoulders of the "builders." However, builders cannot rightly be blamed for their lack of security knowledge, because security is only rarely a part of any standard curriculum. Getting the security message to developers, architects and other builders is an essential aspect of addressing the software security problem. Awareness training for software professionals is one way to do this. Integrating security thinking into the academic curriculum is another.

The growing number of instances of breaches in information security in the last few years has created a compelling case for efforts towards secure electronic systems. Embedded systems, which will be ubiquitously used to capture, store, manipulate, and access data of a sensitive nature, pose several unique and interesting security challenges. Security has been the subject of intensive research in the areas of cryptography, computing, and networking. However, despite these efforts, security is often mis-construed by designers as the hardware or software implementation of specific cryptographic algorithms and security protocols. In reality, it is an entirely new metric that designers should consider throughout the design process, along with other metrics such as cost, performance, and power..This paper is intended to introduce embedded system designers and design tool developers to the challenges involved in designing secure embedded systems. We attempt to provide a unified and holistic view of embedded system security by first analyzing the typical functional security requirements for embedded systems from an end-user perspective. We then identify the implied challenges for embedded system architects, as well as hardware and software designers (e.g., tamper-resistant embedded system design, processing requirements for security, impact of security on battery life for battery-powered systems, etc.). We also survey solution techniques to address these challenges, drawing from both current practice and emerging research, and identify open research problems that will require innovations in embedded system architecture and design methodologies.

We describe ITS4 , a tool for statically scanning C and C++ source code for security vulnerabilities. Compared to other approaches, our scanning technique stakes out a new middle ground between accuracy and efficiency. This method is efficient enough to offer real-time feedback to developers during coding while producing few false negatives. Unlike other techniques, our method is also simple enough to scan C++ code despite the complexities inherent in the language. Using ITS4 , we found new remotely exploitable vulnerabilities in a widely distributed software package as well as in a major piece of e-commerce software.We also describe functionality in more recent tools modeled after ITS4 , and discuss algorithms that could easily be used to augment these kinds of tools. Particularly, we describe a solution we have prototyped that allows for more rigorous analysis of C and C++ source code, without failing to analyze parts of the program due to preprocessor conditionals.

This paper discusses the use of genetic algorithms (GAs) for automatic software test data generation. This research extends previous work on dynamic test data generation where the problem of test data generation is reduced to one of minimizing a function. In our work, the function is minimized by using one of two genetic algorithms in place of the local minimization techniques used in earlier research. We describe the implementation of our GA-based system and examine the effectiveness of this approach on a number of programs, one of which is significantly larger than those for which results have previously been reported in the literature. We also examine the effect of program complexity on the test data generation problem by executing our system on a number of synthetic programs that have varying complexities.

We describe ITS4, a tool for statically scanning security-critical C source code for vulnerabilities. Compared to other approaches, our scanning technique stakes out a new middle ground between accuracy and efficiency. This method is efficient enough to offer real-time feedback to developers during coding while producing few false negatives. Unlike other techniques, our method is also simple enough to scan C++ code despite the complexities inherent in the language. Using ITS4 we found new remotely-exploitable vulnerabilities in a widely distributed software package as well as in a major piece of e-commerce software. The ITS4 source distribution is available at http://www.rstcorp.com/its4.

I am using the term openish source as a reaction to the fact that the OSI has hijacked the term open source and the natural definition most people likely intuit does not apply. The term I am using is ridiculous. I chose an intentionally ridiculous term to emphasize the silly nature of common arguments for making open source mean something it does not mean to most people. The openish source community claims that the movement towards providing free, source-code available programs will result in more secure software. This claim appears to be based on several fallacies briefly presented: the Microsoft fallacy; the Java fallacy; and the many-eyeballs fallacy.

We report on GADGET, a new software test generation system that uses combinatorial optimization to obtain condition/decision coverage of C/C++ programs. The GADGET system is fully automatic and supports all C/C++ language constructs. This allows us to generate tests for programs more complex than those previously reported in the literature. We address a number of issues that are encountered when automatically generating tests for complex software systems. These issues have not been discussed in earlier work on test-data generation, which concentrates on small programs (most often single functions) written in restricted programming languages.

The paper presents results from analyzing the vulnerability of security-critical software applications to malicious threats and anomalous events using an automated fault injection analysis approach. The work is based on the well understood premise that a large proportion of security violations result from errors in software source code and configuration. The methodology employs software fault injection to force anomalous program states during the execution of software and observes their corresponding effects on system security. If insecure behaviour is detected, the perturbed location that resulted in the violation is isolated for further analysis and possibly retrofitting with fault tolerant mechanisms.

In software testing, it is often desirable to find test inputs that exercise specific program features. To find these inputs by hand is extremely time-consuming, especially when the software is complex. Therefore, numerous attempts have been made to automate the process. Random test data generation consists of generating test inputs at random, in the hope that they will exercise the desired software features. Often, the desired inputs must satisfy complex constraints, and this makes a random approach seem unlikely to succeed. In contrast, combinatorial optimization techniques, such as those using genetic algorithms, are meant to solve difficult problems involving the simultaneous satisfaction of many constraints. In this paper, we discuss experiments with a test generation problem that is harder than the ones discussed in earlier literature-we use a larger program and more complex test adequacy criteria. We find a widening gap between a technique based on genetic algorithms and those based on random test generation.

This paper describes a system for explaining solutions generated by genetic algorithms (GAs) using tools developed for case-based reasoning (CBR). In addition, this work empirically supports the building block hypothesis (BBH) which states that genetic algorithms work by combining good sub-solutions called building blocks into complete solutions. Since the space of possible building blocks and their combinations is extremely large, solutions found by GAs are often opaque and cannot be easily explained. Ironically, much of the knowledge required to explain such solutions is implicit in the processing done by the GA. Our system extracts and processes historical information from the GA by using knowledge acquisition and analysis tools developed for case-based reasoning. If properly analysed, the resulting knowledge base can be used: to shed light on the nature of the search space; to explain how a solution evolved; to discover its building blocks; and to justify why it works. Such knowledge about the search space can be used to tune the GA in various ways. As well as being a useful explanatory tool for GA researchers, our system serves as an empirical test of the building block hypothesis. The fact that it works so well lends credence to the theory that GAs work by exploiting common genetic building blocks.