Contact Us
  • This field is for validation purposes and should be left unchanged.

System Architecture Recovery and Analysis (SARA)

TECHNOLOGY AREA(S): Information SystemThe technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), 22 CFR Parts 120-130, which controls the export and import of defense-related material and services, including export of sensitive technical data, or the Export Administration Regulation (EAR), 15 CFR Parts 730-774, which controls dual use items. Offerors must disclose any proposed use of foreign nationals (FNs), their country(ies) of origin, the type of visa or work permit possessed, and the statement of work (SOW) tasks intended for accomplishment by the FN(s) in accordance with section 5.4.c.(8) of the solicitation and within the AF Component-specific instructions. Offerors are advised foreign nationals proposed to perform on this topic may be restricted due to the technical data under US Export Control Laws. Please direct questions to the AF SBIR/STTR Contracting Officer, Ms. Gail Nyikon, gail.nyikon@us.af.mil. OBJECTIVE: Develop innovative methods, tools and techniques to recover the implemented software architecture of a cyber-physical system in the absence of source code or other program information. DESCRIPTION: The understanding of the architectural design of a system (such as a nuclear reactor safety system or vehicle operations system) is crucial in assessing the system?s security posture and robustness. Even if the original design of a software architecture is known, the implemented architecture may vary due to implementation choices related to performance, efficiency, language constructs, patching, etc. While reverse engineering and binary analysis tools for desktop applications have been developed for some time, tools for embedded applications (e.g., supervisory control and data acquisition (SCADA) systems, industrial control systems (ICS), embedded systems, etc.) are either immature or non-existent. In addition, vulnerability analysis at a software design and source code level cannot uncover all susceptibilities because additional software (e.g., library routines, firmware, etc.) are integrated into the architecture and are potential malware sources.In order to truly understand weaknesses, a mechanism is needed that can extract the ?as-built? architecture from the machine code and achieve a high level of confidence that the recovered architecture representation is accurate. This mechanism should: (1) Identify critical security points in the architecture, (2) discover the functionality of individual system components and (3) enable cyber security engineers to scrutinize critical access points and potential susceptibilities in the system. This technology could be used by systems engineers either to analyze ?black box? architectures where the design is unknown, or to verify that a software system has been implemented and performs as designed which, in turn, would make it possible to discover when a system has been compromised and does not function as intended.A focus on real-time embedded systems and real-time operating systems is highly desirable. A solution that runs on Linux or Windows in a desktop environment and can accept binaries from a variety of operating systems (Linux, Windows, VxWorks, Integrity, LynxOS, etc.) and architectures (ARM, x86, PowerPC, etc.) is more relevant than a solution that is OS and/or architecture specific. PHASE I: Describe & design creative methods/techniques/tools for recovering and reconstructing architecture of an implemented software system, accurately modeling and displaying the architecture, and assessing its security posture. The result should use common modeling standards (SysML, UML, etc.) where possible. PHASE II: Develop, implement and validate a prototype tool that utilizes the methods/techniques from Phase I. The prototype(s) should be sufficiently functional to evaluate the effectiveness of the approach on a representative realworld software system. Models produced by the tool should highlight potential cyber access points and weaknesses or susceptibilities in the system. Initial compatibility with a variety of processing architectures is desirable, but the solution may initially focus on one. PHASE III DUAL USE APPLICATIONS: The ability to accurately model and validate an implemented system architecture for verification and assessment will be an invaluable tool for ensuring the safety and security of DoD systems with additional uses in security and safety sensitive industries such as commercial and civil aviation. KEYWORDS: system, architecture, recovery, analysis, embedded, systems, software, binary, assessment, vulnerability, cyber, security, reverse, engineering, design POINT OF CONTACT: Joshua McCamey, Phone: 937-528-8152, Email: Joshua.McCamey@us.af.mil

  • Agency: Office of the Secretary of Defense,Department of Defense,Department of Defense
  • Program: SBIR
  • Phase: Phase I
  • Release Date: August 27, 2015
  • Open Date: September 28, 2015
  • Close Date: October 28, 2015
  • URL: https://sbir.defensebusiness.org/topics
Contact Us
  • This field is for validation purposes and should be left unchanged.