Late-stage Software Customization and Complexity Reduction S&T for Legacy Naval Systems

Description

The Office of Naval Research (ONR) is interested in receiving proposals addressing the fundamental problem of modern systems and software insecurity. The main focus for this solicitation is late-stage software customization/specialization and complexity reduction science and technology (S&T) projects which offer potential for advancement and improvement of security and efficiency of Navy and Marine Corps systems and software. A brief description of the science and technology thrusts, Technical Areas (TA) 1 through 5), that ONR is pursuing is provided below. TA1: Functionality identification and reduction Subcategories: Apps (including web), OS, Hypervisor, Communications Protocols One focus area of transformation and customization is that of feature or functionality reduction. Modern commercial software is notoriously bloated due to the one-size-fits-all methodology commonly practiced by many development and deployment efforts. This practice eases the burden on developers that intend to sell and deploy code to a large and diverse user base, but has a detrimental impact on performance and security. Many features built into a software program may not be needed by the average user, but are often included with no way for those users to disable or remove those features. Between the additional code (which may contain its own bugs and vulnerabilities) and the potentially undesirable functionality, extraneous features unnecessarily hamper performance while broadening a software product’s attack surface. Extraneous features that broaden attack surfaces are not restricted to just software. Protocols used for communication across the stack also suffer bloat from a variety of sources such as support for legacy features or rarely used (and unnecessary) functionality. In networking environments that are tightly controlled by a single entity (e.g., a connection to back-end database), it would be desirable to automatically customize or subset the protocols to allow only necessary functionality. Subsetting protocols may require automated transformation and rewriting of protocol implementations as well as methods to automate analysis and determination of required functionality. Even for some general-purpose communications, restriction of supported features is desirable in such that it reduces attack surface without introducing additional security issues (proposed techniques must address this analysis). This BAA seeks efforts to reverse the trend toward one-size-fits-all software and protocols by enabling and empowering end users to selectively remove features they do not use or want. Examples of software features to be removed could include elements of the user interface, or something that could potentially compromise privacy such as a callback or diagnostic reporting functions. Examples of protocol features could include support for legacy functionality or a feature that is made unnecessary by a feature in another layer. Some features may manifest themselves through externally visible interfaces (e.g., a system call) while others may be internal and thus more difficult to identify and trace back to specific regions of code. We make no assumption that developers have tagged their software to identify features, so identification of features (units of functionality) and their corresponding code is a key challenge that must be addressed. Due to the goal of reducing attack surface, preference will be given to approaches that operate statically to remove the feature in question and transform the software or protocol implementation so that it is permanently removed. Dynamic approaches can be used to supplement, but must not be employed alone due to the lesser benefit to attack surface reduction. Proposals must discuss what to do when an attempt is made to access a feature that has been removed. Feature reduction is of interest across application software, middleware APIs, operating systems, hypervisors, and communications protocols. TA2: De-bloat/de-layer Even without removing any required functionality, software can be transformed so that it is more efficient. Extensive use of layers upon layers of abstractions, indirections, and other software development practices meant to increase productivity have the side effect of causing a great deal of bloat in modern software. While modularization and use of shared libraries improve software reuse, they often come precompiled without source code and their clients are not known a priori so they must be kept general-purpose. The result is that very little of the code in a function or library is actually executed when loaded and executed, often wasting memory bandwidth and making code reuse attacks much easier. By reducing indirections, layers of abstraction, and bloat within a program and across all of the libraries and APIs invoked during runtime, a non-trivial amount of software execution efficiency can be reclaimed while simultaneously reducing complexity and attack surface. While striving to improve software efficiency, it is important to retain the positive effects of current software engineering practices, e.g., software reuse. Thus, it is highly desirable to have an enhanced software architecture, development methodology, and deployment strategy that improve software efficiency while preserving the productivity benefits of current practices. Improving the actual software efficiency of the final executable while maintaining the productivity benefits of software reuse and layering at the development stage is an important goal to be addressed in this BAA. The leanest and most efficient program customizations are likely achievable at late-stage, i.e., during installation or just-in-time for execution, when all of the platform and execution environment parameters are known. As a result, binary code understanding and transformation is a critical challenge for this topic. When undertaken statically, specialization and transformation of programs and all the libraries that program utilizes must reduce testing complexity, improve test coverage, and improve the overall robustness and efficiency of the final product. Proposals must be directed toward research and development of automated and transparent debloating and delayering tools to be run at installation time or perform just-in-time transformations. TA3: Addition of security constructs Another aspect of late-stage software customization is the capability to retrofit pre-existing executable code with security constructs to improve the safety and security of that software. The software transformations performed with tools developed in TA1 and TA2 will significantly reduce the size and complexity of an executable. These transformations present an opportunity for a more complete examination for security defects and software hardening across the resulting executable chain. TA3 performers will develop automated transformation tools for security-hardening of executables and executable chains. It is important that proposed tools developed within TA3 target software executables as opposed to source code and that they be completely automated and transparent to end users. This focus on executables is necessary for practical deployment purposes. Late stage security retrofitting tools can efficiently and effectively harden software executables and reintegrate security constructs that may have been accidently trimmed by TA1 and TA2 tools. TA4: Verification and Validation The steps taken by TA1 and TA2 tools to simplify and compact software executables and TA3 tools to harden and apply security constructs represent an aggressive set of transformations. After applying these sets of install-time transformations to software executables, we need to ensure that the resulting software functions as expected (functional verification). Functional verification and validation will be required to ensure that the results of the executable transformations of TA1, TA2 and TA3 are proper and satisfy requirements. This is especially important given that the application of TA1 (functionality customization and specialization) tools may render some of the tests in the original test suite invalid. Any invalidated tests need to be automatically identified and either modified, replaced, or removed. ONR is interested in research and development for tools that automatically assemble a verification and validation test suite for the transformed code. The tools could use the original test suite, original code, and the transformed code as input to automatically produce the new test suite. Beyond software testing, formal methods can be used to provide the highest level of assurance for certain important properties of software. However, formal methods generally suffer from key limitations that limit its practical, widespread use. One major drawback is the need for a manually generated formal model of the code. The scalability of the mathematical tools used to evaluate the model, e.g., SMT solvers, theorem provers, etc., is also an issue. As previously noted, however, the resulting software of the TA1, TA2, and TA3 transformations will have been significantly reduced in both size and complexity. ONR is interested in S&T approaches that explore whether the reduced size and complexity alleviates scalability problems with formal methods and allows for automated lifting or extraction of the formal model needed for evaluation. A bottom-up approach to formal methods analysis, made possible by complexity reduction efforts, would make comprehensive (all layers) formal verification of complex software become practical for widespread use. Proposals addressing this topic shall be capable of extracting formal specification from executables, since the application of late-stage program transformation tools in other technical areas makes manual formal modelling impractical. TA5: Supportive and complementary approaches ONR is interested in research and development approaches that are comp

Agency Contact

More from Office of Naval Research