Targeted Automatic Integer Overflow Discovery Using Goal-Directed Conditional Branch Enforcement

We present a new technique and system, DIODE, for auto- matically generating inputs that trigger overflows at memory allocation sites. DIODE is designed to identify relevant sanity checks that inputs must satisfy to trigger overflows at target memory allocation sites, then generate inputs that satisfy these sanity checks to successfully trigger the overflow. DIODE works with off-the-shelf, production x86 binaries. Our results show that, for our benchmark set of applications, and for every target memory allocation site exercised by our seed inputs (which the applications process correctly with no overflows), either 1) DIODE is able to generate an input that triggers an overflow at that site or 2) there is no input that would trigger an overflow for the observed target expression at that site.United States. Defense Advanced Research Projects Agency (Grant FA8650-11-C-7192

Workshop on COTS integration and evaluation

In any component-based software engineering effort, the issues of locating, evaluating and determining compatibility between components are highly important. Also, the knowledge gained during integration is not easily managed or shared. The goal of the STEP2002 Workshop on COTS integration and evaluation was to continue the effort to define a reference architecture for a system to codify component integration knowledge. The system can then evaluate ensembles of components against a manifest of desired components and interactions, and rank these ensembles based upon ease of integration.</p

FOR THE COMMANDER

This report was prepared for th

Secure Design Patterns

The cost of fixing system vulnerabilities and the risk associated with vulnerabilities after system deployment are high for both developers and end users. While there are a number of best practices available to address the issue of software security vulnerabilities, these practices are often difficult to reuse due to the implementation-specific nature of the best practices. In addition, greater understanding of the root causes of security flaws has led to a greater appreciation of the importance of taking security into account in all phases in the software development life cycle, not just in the implementation and deployment phases. This report describes a set of secure design patterns, which are descriptions or templates describing a general solution to a security problem that can be applied in many different situations. Rather than focus on the implementation of specific security mechanisms, the secure design patterns detailed in this report are meant to eliminate the accidental insertion of vulnerabilities into code or to mitigate the consequences of vulnerabilities. The patterns were derived by generalizing existing best security design practices and by extending existing design patterns with security-specific functionality. They are categorized according to their level of abstraction: architecture, design, or implementation

An Enterprise Information System Data Architecture Guide

Data architecture defines how data is stored, managed, and used in a system. It establishes common guidelines for data operations that make it possible to predict, model, gauge, and control the flow of data in the system. This is even more important when system components are developed by or acquired from different contractors or vendors. This report describes a sample data architecture in terms of a collection of generic architectural patterns that both define and constrain how data is managed in a system that uses the Java2 Enterprise Edition (J2EE) platform and the Open Applications Group Integration Specification (OAGIS). Each of these data architectural patterns illustrates a common data operation and how it is implemented in a system