Air force 14. 1 Small Business Innovation Research (sbir) Proposal Submission Instructions

• A software solution that addresses, at a tactical level, prioritization of transactions, transaction definition changes, and corrective actions based on changing mission needs.

• Account for structured and unstructured data.

• Support scalable "product configuration" options and incremental fielding based on customized sizing, throughput, partitioning, reliability, data model inputs and options.

• Address the operational challenges of data synchronization, sequencing, drill downs, periodicity and timeliness.

• Address merging standards and best practices related to data collection and profiling methodologies, data mining, data categorization, data correlation, and data error resolution, to include reporting, measurement, and threshold monitoring.

• Extend emergent technologies that support features such as rule-based engines; data Extract, Transform and Load (ETL) principles; data hub/master data management; segregation of duties; workflow and notification management. • Integrate with existing "help desk" structures, command specific escalation and release management activities, Business Intelligence (BI) infrastructure and Root Cause Analysis tools, and applicable Information Assurance and Certification/Accreditation laws, rules, and regulations.

• Address data problem identification, analysis/corrective actions and the use of predictive analysis to uncover and mitigate data anomalies.

• Propose extensible best-of-breed standards, topologies, and architectures to fulfill and field the recommended solution Air Force wide.

PHASE I: Submit a proof-of-concept architecture with concept paper, technology design, software prototype, and Phase II build plan. Include solution scenarios, realistic data sets, and technical issues/risks. Prototype software demonstrates use of configurable business rules/innovative data quality-related algorithms.

PHASE II: Mature the prototype, incorporate operational (transaction level) layered services, integrate Master Data Management, extend predictive analysis, and demonstrate full solution capabilities using multidimensional data and complex business scenarios. Deliver revisions to the conceptual framework, technology design, and technical issues. Deliver solution-based training, maintenance materials and an implementation plan based on operational data migration recommendations and considerations.

PHASE III DUAL USE APPLICATIONS: Extend and transition prototype to operational use across the Logistics Enterprise domain.

REFERENCES:

1. Quality Assessment of Trustworthiness of AFMC Acquisition Data, Karhoff, Herman L., Mitre Corp., Sep 2007 (available through DTIC).
2. Handling Exception in Service Oriented Architecture, Zaina, Luciana A M, et.al.
3. Phoenix Prime: Universal Information Management Services for all Domains, Fact Sheet, Air Force Research Laboratory, uploaded in SITIS 12/20/13.
4. USAF MRO Step 1 (PRM) Summary, uploaded in SITIS 1/10/14.
5. USAF PBES Capabilities, uploaded in SITIS 1/10/14.
6. USAF PLMi Step 1 (PRM) Summary, uploaded in SITIS 1/10/14.
KEYWORDS: exception handling, error correction, Service Oriented Architectures, Transaction Data Management, Quality of Service, SOA
AF141-037 TITLE: Laser for Airborne Communications (LAC)
KEY TECHNOLOGY AREA(S): Battlespace Environments
The 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. Kristina Croake, kristina.croake@us.af.mil.

OBJECTIVE: Free Space Optical (FSO) based communication system supporting very high bandwidth communications for the airborne and surface layers. Threshold: reliable long-distance communication among moving platforms in wide variety of weather conditions.

DESCRIPTION: The purpose of this topic is to explore innovative free space optical (FSO) based hardware and software approaches and implementations leading to improved theater level communications for increased warfighter situation awareness (SA) and mission assurance.
The battlefield/theater environment will require both air-to-air communication and air-to-surface (fixed and mobile) communication. Aerial platforms will include: airborne reconnaissance, command and control (C2) assets, UAV ranging in size and altitude from Global Hawk to Shadow, and airships. Threshold required surface platforms include fixed base installations, stationary military vehicles, and slow-moving or static dismounts.
An early system performance goal is for communication to moving ground vehicles, then moving to air-ground and air-air combinations. Threshold performance is for single link capability between platforms. Goal performance is for platforms to have the capability to communicate with multiple platforms, as required, to execute multiple mission scenarios and satisfy the desire to provide seamless, integrated net-centric capabilities to the forward edge of the battlespace. Crosslink ranges between aerial platforms should extend to greater than 200 km. Down/Up link range from aerial to ground assets should be capable of ranges greater than 50 km. The data capacity for aerial-to-aerial crosslinks and aerial-to-ground downlinks should be at least 10 Gb/s with a goal of 40 Gb/s. The data capacity surface to aerial vehicle uplinks should be at least 10 Gb/s. The systems should support at least 1 GigE data inputs with a goal of additionally supporting 10 GigE. Ability to handle additional inputs such as digital data from RF links greater than 200 Mb/s RF is a plus.
The system should provide very high reliability in all weather conditions, although certain threshold throughput limitations may be reduced in defined difficult weather states. This is anticipated to include a hybrid FSO/RF approach for optical links impaired by very high atmospheric attenuation. Other approaches, such as adaptive optics, will be considered. Reduced data throughput is acceptable in these cases. The FSO system should incorporate techniques to allow high data throughput even in times of high atmospheric turbulence. The system designs must meet eye safety regulations for commercial aviation altitudes and below.
The systems must provide means for point-to-point (1:1) and multicast (1:many) communications, to include multiple moving platforms operating in expected conditions (i.e., planned flight conditions, not to include emergency turning, climb/descent, or severe evasive actions).
The systems must be SWaP compatible with their respective aerial platform or ground asset. Finally, low unit production cost, system reliability and mission assurance will be key requirements.

PHASE I: Demonstrate gigabyte transfer and bi-directional gigabyte IP communications over a distance of at least 2 miles, with one platform in motion (roll NLT 15, pitch NLT 5, yaw NLT 3 degrees, elevation NLT 20', lateral motion NLT 15'). Detailed concept design to meet above performance. Address communication with LEO and GEO satellites from aerial and surface nodes. Provide Phase II design.

PHASE II: Complete critical design of the Phase II lab prototype hardware including any additional required supporting MS&A. A network model and baseline network performance model will be provided during Phase II. All proposed programs must include at least Phase II hardware for one air-to-air scenario and one air to ground scenario. Fabricate the lab prototype to show level of performance achieved compared to stated government goals including SWaP, reliability and portability, expected to be at TRL 5.

PHASE III DUAL USE APPLICATIONS: TRL-8. Initial field testing using captive-carry hardware integrated onto commercial aircraft or comparable equipment for dynamic airborne evaluations. Following successful initial field testing, initial end item platforms will be identified and the FSO products be ruggedized for field operations.

REFERENCES:

1. Schug, T.; Dee, C.; Harshman, N.; Merrell, R., "Air Force aerial layer networking transformation initiatives," MILITARY COMMUNICATIONS CONFERENCE, 2011 - MILCOM 2011, pp. 1974, 1978, 7-10 Nov. 2011.

AF141-038 TITLE: Layered Virtualization Detection of Malicious Software Behavior (“Inception”)

OBJECTIVE: Create an appliance which uses one or more layers of Type 2 (software) virtualization within a Type 1 (‘bare metal’) Hypervisor infrastructure which uses introspection to foil virtualization-aware malware escape attempts.

DESCRIPTION: Modern malware (viruses, Trojans, etc.) will attempt to adapt to the environment they are executed in. For instance, many versions of modern malware are able to determine if they are being run within a virtualized machine due to measurable differences in performance, configuration and/or behavior between virtualized and physical platforms. This is commonly done for several different malicious purposes, such as attempting to deceive potential investigation attempts, or in order to escape from within a virtualized system to affect the underlying code, among other possibilities. In the second case, attempted escape from virtualization is an obvious risk to the provider of the virtualization, as well as any other virtualized systems being provided on the same hardware.
In order to add additional defensive capabilities to improve attempts to close every potential gap in virtualization’s emulation of normal operational environments, the creation of multiple-layer virtualization with awareness of what happens in which layer of the virtualization is desired.
In this architecture, malicious content would be allowed to attempt to escape from within one layer of virtualization, yet leave the host system unaffected. Specifically, if any behaviors beyond those few needed to operate the Type 2 virtualization are detected in this (or potentially other layers of virtualization beyond the initial), it can fairly be assumed that there is malicious behavior happening which should be stopped and/or investigated, in accordance to the risk acceptance of the organization providing the virtualization.

PHASE I: Build a Type-1 hypervisor with introspection containing a Type-2 hypervisor with introspection. Show a proof of concept indicating the Type-1 hypervisor stopping functioning if any unexpected behaviors occur outside the Type-2 hypervisor.

PHASE II: Further harden and instrument the infrastructure developed in Phase I. Develop performance metrics for a single Type-2 hypervisor, multiple Type-2s running in parallel, and multiple layers of nested Type-2s. Test the prototype against appropriate "jailbreak" exploits and malware to determine its actual properties.

PHASE III DUAL USE APPLICATIONS: Commercialize the product and provide it for sale or via open source license to DoD, IC and commercial purchasers. Additional business opportunities in training, subject matter expertise, etc., also exist.

REFERENCES:

1. http://www.schneier.com/blog/archives/2012/06/the_failure_of_3.html.

2. http://en.wikipedia.org/wiki/Virtualization.

3. http://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-os-different-from.html (Note that this is not advocating Qubes OS, but provides one expert’s views on some of the risks in various virtualization products available today).

AF141-039 TITLE: Process Level Virtualization for System Assurance

OBJECTIVE: Assure the proper handling of information from cradle to grave by leveraging process level virtualization throughout the information life cycle. This should also reduce malware propagation and improve access control, among other useful features.

DESCRIPTION: Process level virtualization (such as Bromium’s “micro virtualization,” FreeBSD “Jails” or Qubes OS’ “AppVM,” among others) creates a virtual sandbox around chosen processes which prevent them from communicating with other processes other than in explicitly defined ways. This capability is potentially very useful for protecting the confidentiality and integrity of various of these processes and the information within them. Extended to an information work flow, these capabilities could support the assurance of information from cradle to grave.
Thus the challenge is to ensure protected data and information is made available to all relevant users via an assured process level virtualization capability. However, given the DoD CIO’s call that all future conflicts will be coalition conflicts, this capability must be able to interoperate with other solutions, regardless if they use these process level virtualization defenses or not.
Another aspect of the challenge is to make these capabilities mesh across multiple systems in information flows, some of which are subject to rapid change with little warning.

PHASE I: Identify and demonstrate proof-of-concept capability to appropriately separate processes across a notional or representational information life cycle across two or more computers. Show how the prototype protects the information and information flow from failure and/or compromise of various components in the flow.

PHASE II: Extend the Phase I proof of concept to realistic (10-1,000) node scales, address unanticipated users, changing information life cycle processes and dealing with systems which do not provide the same level(s) of process level virtualization defenses but are required as part of the work flow.

PHASE III DUAL USE APPLICATIONS: Work with DoD systems of record and commercial systems to improve the state of the practice to a realistic security model more resilient against propagation of exploits. May also be useful as a moderate- to high-assurance single system capability.

REFERENCES:

1. http://www.cs.manchester.ac.uk/ugt/2012/COMP25212/Virtualization%201.ppt (PowerPoint file, “System and Process Virtualization”).

6. http://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-os-different-from.html.

AF141-040 TITLE: Establishing and Maintaining Mission Application Trust in a Shared Cloud

OBJECTIVE: Develop the methods, techniques, and protocols to establish and maintain mission application trust, and the resulting mission application security, in a shared cloud infrastructure.

PHASE I: Identify the typical application components in mission applications that are required to establish trust in a shared cloud infrastructure. Provide techniques to verify and maintain the trust of each individual application component in the overall system.

PHASE II: Develop a method to establish, verify, and maintain trust between the components outlined in Phase I to allow for trusted communication between components. Once trust is established between two devices, a trusted communication method must be demonstrated. A prototype of this system must demonstrate protection within a cloud infrastructure containing compromised systems with intimate knowledge of the protocol established.

PHASE III DUAL USE APPLICATIONS: Utilize the developed technologies to automate the process of assuring the trust across a large cloud infrastructure for a given mission application. This technology would also directly benefit industries where trust and privacy are essential to business.

REFERENCES:

1. “End to End Trust: Creating a Safer, More Trusted Internet.” www.microsoft.com/mscorp/twc/endtoendtrust/.

AF141-041 TITLE: Granular Compute Cloud Architecture

OBJECTIVE: Develop a general purpose compute cloud architecture that allows more granular and flexible allocation of cloud computing resources for secure cloud-based mission application development.

DESCRIPTION: All traditional virtualization technologies predate the cloud era, and have been designed to be backward compatible with existing systems at the binary level, thus making it easy to run any pre-cloud developed applications in the cloud. This approach has worked well, since the primary use of the cloud today is the outsourcing of traditional enterprise applications by cloud infrastructure providers that then supply these same applications back to customers as a service.
However, for new applications designed specifically for a cloud, these traditional virtualization platforms bring a lot of extraneous overhead. The traditional VM abstraction is at too low a level for a generic compute cloud and as a result requires a full-blown operating system in each VM instance. When looking at a cloud as a general computing resource where a new mission application can be developed to securely run, this requirement limits the flexibility of the mission application architecture. Also, it dramatically increases the cloud resources needed by the mission application in terms of memory and computational power, and increases the management requirements of the overall system.
Most multi-tasking operating systems limit the effects that one process can have upon other process in the system. Various system resources are protected and when a process ends (cleanly or otherwise) the resources held is reclaimed by the system. This process isolation model has made application development easier and safer, and has allowed an almost infinite number of applications to be independently developed for popular operating systems like Linux and Microsoft Windows. Unfortunately, most operating systems did not go far enough in preventing malicious applications from breaking process boundaries.
The Air Force needs a cloud infrastructure that allocates resources on a per process basis, as opposed to the current per operating systems basis. This would result in significant savings, since the operating system need not be duplicated for every virtualized application instance. Such a system must maintain a level of secure isolation that is similar to the isolation between operating system instances in the cloud today.
The goal of this effort is to provide the Air Force with a more granular cloud architecture which allows new mission applications the ability to be deployed utilizing drastically less computing resources, less management burden, and maintain a high level of security. Techniques must be provided to securely isolate application components allow them to be easily deployed within the cloud infrastructure. This secure isolation must be lightweight, operating systems agnostic, and impose a minimal computational resource cost as compared to traditional virtualization, yet provide comparable protections. Methods and protocols must be provided to allow flexible secure communications amongst the deployed application components.