Alternative Software Architecture for Personal Electronic Maintenance Aids

Navy SBIR 20.2 - Topic N202-106

Naval Air Systems Command (NAVAIR) - Ms. Donna Attick [email protected]

Opens: June 3, 2020 - Closes: July 2, 2020 (12:00 pm ET)

 

 

N202-106       TITLE: Alternative Software Architecture for Personal Electronic Maintenance Aids

 

RT&L FOCUS AREA(S): General Warfighting Requirements (GWR)

TECHNOLOGY AREA(S): Air Platform, Information Systems

 

OBJECTIVE: Develop a stable operating system architecture based upon open-source software (OSS) that reduces/eliminates dependence on Microsoft Windows. In comparison to Microsoft Windows 10, OSS operating system architecture should require fewer system resources, reduce software licensing and sustainment costs, reduce the overall Department of Defense (DOD) Information Assurance Vulnerability Alert (IAVA) patch cadence, increase performance, and integrate a robust cybersecurity posture requiring less frequent security updates and reduced typical patch file sizes than Microsoft Windows.

 

DESCRIPTION: Currently, Portable Electronic Maintenance Aids (PEMAs) employ the Microsoft Operating System (OS) as the host OS. With the transition to Windows 10, Microsoft has migrated to �Windows as a service�. Windows 10 currently requires 20 gigabytes (GB) for a clean install. In addition to an ever-expanding footprint, the OS requires continual patching, with patch sizes often exceeding 1 GB. Each patch cycle requires a vigorous level of testing to ensure that the applications installed on the PEMA function in accordance with mission requirements. Windows license activation requirements present an additional level of complexity for systems that must function in austere environments that include both network connected and standalone/closed-loop configurations. Microsoft Windows activation requires a Key Management Service for connected systems and a soft token for disconnected systems.�

 

The PEMA environment includes network bandwidth restrictions inherited from the host site networks: Integrated Shipboard Network System (ISNS), Consolidated Afloat Network Enterprise Services (CANES), Navy Marine Corps Intranet (NMCI), OCONUS Navy Enterprise Network (ONE NET), or Marine Corps Enterprise Network (MCEN). A significant portion of the PEMA footprint consists of standalone/closed-loop configured systems that do not connect to enterprise network. For standalone/closed-loop configured systems, the squadron Central Technical Publication Librarian must download patches from an enterprise network connected system and sneaker-net patches to the PEMA via DVD or USB hard drives. Whether patches come directly from a PEMA connected to the host-site enterprise network or sneaker-net via DVD/USB hard drive, the patches are first downloaded from an enterprise network. Occasionally patches are too large to transfer over slow/intermittent network connections and encrypted media has to be mailed to the squadron, where especially in the shipboard environment, network bandwidth is at a premium. A software architecture that results in a reduction in typical OS patch file size and patch frequency is a win for the warfighter.

 

The PEMA Support Equipment environment consists of various Type/Model/Series (T/M/S) specific aircraft and each T/M/S specific aircraft typically includes unique, T/M/S-specific applications. The overarching goal for PEMA is to deliver a single device, to Fleet maintainers, that provide access to technical publications and related Support Equipment applications. Considering the disparate applications required by the various T/M/S aircraft represented within the Support Equipment community, an approach that requires native installation of T/M/S specific application is neither sustainable nor supportable. In order to provide a long-term, supportable and sustainable solution that addresses the Support Equipment fleet maintainer mission on one device, the PEMA architecture must support containerized applications. By employing containerized applications, the process of patching and updating the PEMA underlying software OS architecture is streamlined because patches to the underlying OS do not affect the containerized applications. Employing containerized applications significantly reduces the amount of testing required to ensure T/M/S unique applications function according to mission requirements post patch, as the OS patch does not affect containerized applications.

 

The overarching requirements are to identify and confirm the viability of an OS architecture alternative to Microsoft Windows that:

�       Reduces the frequency and volume (relative to Microsoft Windows 10 OS) of ongoing software vulnerabilities and related requirements for software patch updates as identified and represented by the DoD Information Assurance Vulnerability Management (IAVM) process.

�       Results in a reduction in typical file size requirements for OS patches (relative to Microsoft Windows 10) in order to lower network bandwidth requirements.

�       Natively supports preboot CAC authentication, and full disk data-at-rest encryption including removable media encryption (without the employment of a third party commercial solution). Note: Data-at-rest encryption must meet DoD Risk Management Framework (RMF) [Ref 4] Controls: SC-28.1 Protection Of Information At Rest and applicable DISA Security Technical Implementation Guides (STIGs) [Ref 5] that include Control Correlation Identifier (CCI) 001199; SC-28(1).3 and SC-28(1).4 Cryptographic Protection and applicable DISA STIGs that include CCIs 002475 and 002476.

�       Natively supports two-factor authentication in both network connected and standalone/closed-loop environments. Note: The two factor authentication must meet DoD Risk Management Framework (RMF) [Ref 4] Controls: IA-5(2) PKI-Based Authentication, IA-5(11) Hardware Token-Based Authentication, IA-6 Authenticator Feedback, IA-7 Cryptographic Module Authentication.

�       Delivers OS license activation execution that commonly supports connected and standalone environments or does not require license activation.

�       Demonstrates compliance with DoD Memorandum �Clarifying Guidance Regarding Open Source Software (OSS)�, dated 16 October, 2009 as well as guidelines from Navy DON CIO Memorandum �DEPARTMENT OF THE NAVY OPEN SOURCE SOFTWARE GUIDANCE� (5 JUN 2007).

�       Demonstrates secure file transfer and validation, secure collaboration services, and web browser functionality.�

�       Supports display of PDF documents,

�       Supports live operation in RAM (Secure Live Media),

�       Enables hosting and execution of containerized applications,

�       Supports Squashed File System high speed compression capabilities.

�       Reduces costs related to software licensing relative to the Microsoft Windows Environment.

 

The OSS operating system should function on a ruggedized, clamshell form factor, 2-in-1 touchscreen/ keyboard configuration such as the Panasonic Toughbook currently employed as the PEMA hardware baseline. Ensure that the Open Source operating system architecture supports application containerization technology [Refs 6 and 7]. Provide an analysis of the potential for reducing the supportability and sustainability footprint with regard to patching. In comparison to Windows 10, describe the estimated benefit relative to:

 

1.     Time and effort involved in patching applicable vulnerabilities on a monthly basis.

2.     Typical file size for applicable patches (Identify if there is a patch file size typically smaller for the OSS operating system than Windows 10).

3.     Relative frequency of required patching.

 

The analysis must provide an assessment of the ongoing requirements for patching and updating the system in comparison to the Microsoft Windows 10 environment and contrast the level of effort and risk relative to patching in the Windows environment versus the prototype-operating environment. The analysis must address system performance impacts for live operation in RAM.

 

PHASE I: Design and determine the technical feasibility of developing an OSS architecture OS that meets the guidelines established in References 8 and 9. With regard to supporting containerized applications identify if there is a significant difference in level-of-effort between the OSS operating system architecture and Windows 10. Provide an assessment of the technical feasibility of the OSS operating system architecture to support the capability requirements discussed in the Description section of this topic. Describe expected lifecycle support costs and tasking related to maintaining compliance with DoD and Navy Open Source Software guidelines identified in the Description. The Phase I effort will include prototype plans to be developed under Phase II.

 

PHASE II: Develop and demonstrate a prototype 64-bit software architecture, including boot loader, kernel, and operating system to prove open-source concept meeting all requirements provided in the Description.

 

PHASE III DUAL USE APPLICATIONS: Demonstrate the ability to support containerized applications as discussed in the Description section of this topic. Demonstrate a process for updating a containerized application and the ability to save data from the containerized application to a USB hard drive. Provide design and related support and sustainment documentation. Transition developed technology to the PEMA program of record and field as the core software image which will serve as a potential baseline for all TMS programs to transition unique Windows dependent applications to open-source architectures. Support Risk Reduction Testing, Operational Testing, potential procurement, and pilot fielding to a squadron determined by the PEMA program. Support transition of unique TMS PEMA solutions to operate within this open-source architecture.

 

Technology development would benefit commercial applications supporting austere environments that require maintenance applications hosted on a ruggedized platform. Success would demonstrate how private companies can employ OSS to reduce costs related to software licensing as well as reduce costs related to ongoing requirements to maintain a strong cybersecurity posture throughout the lifecycle of a system by moving from a Microsoft Windows platform to an OSS platform. This same open source approach could be leveraged to meet other peculiar support equipment requirements in commercial and private sector environments such as commercial aircraft maintenance.

 

REFERENCES:

1. Economides, N. and Katsamakas, E. �Linux vs. Windows: A Comparison of Application and Platform Innovation Incentives for Open Source and Proprietary Software Platforms.� The Economics of Open Source Software Development, Elsevier B.V., 2006. http://www.stern.nyu.edu/networks/Linux_vs._Windows.pdf

 

2. Hoepman, J and Jacobs, B. �Software Security Through Open Source.� Institute for Computing and Information Sciences, Radboud University, the Netherlands, April 2005. https://www.cs.ru.nl/~jhh/publications/oss-acm.pdf

 

3. Scarfone, Karen, Jansen, Wayne, and Tracy, Miles. �National Institute of Standards Technology (NIST) Special Publication 800-123, Guide to General Server Security � Recommendations of NIST.� July 2008. http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf

 

4. �DoD Risk Management Framework (RMF) Controls: SC-28.1 Protection Of Information At Rest, IA-5(2) PKI-Based Authentication, IA-5(11) Hardware Token-Based Authentication, IA-6 Authenticator Feedback, IA-7 Cryptographic Module Authentication.� https://nvd.nist.gov/800-53/Rev4/control/IA-5, https://nvd.nist.gov/800-53/Rev4/control/IA-6, https://nvd.nist.gov/800-53/Rev4/control/IA-7, https://nvd.nist.gov/800-53/Rev4/control/IA-SC-28

 

 

5. DISA Security Technical Implementation Guides (STIGs) Control Correlation Identifier (CCIs): 001199, 002475, 002476. https://public.cyber.mil/stigs/

 

6. Chandramouli, Ramaswamy. �National Institute of Standards and Technology (NIST) Interagency Report (IR) NISTIR 8176: Security Assurance Requirements for Linux Application Container Deployments.� https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8176.pdf

 

7. Souppaya, Murugiah, Morello, John and Scarfone, Karen. �NIST Special Publication 800-190 Application Container Security Guide.� https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf

 

8. �DoD Memorandum: Clarifying Guidance Regarding Open Source Software (OSS).� 16 October, 2009. https://dodcio.defense.gov/Portals/0/Documents/FOSS/2009OSS.pdf

 

9. �Navy Memorandum DEPARTMENT OF THE NAVY OPEN SOURCE SOFTWARE GUIDANCE (5 JUN 2007). https://www.doncio.navy.mil/FileHandler.ashx?id=261

 

10. DoD Frequently Asked Question (FAQ) regarding Open Source Software (OSS). https://dodcio.defense.gov/Open-Source-Software-FAQ

 

KEYWORDS: Cyber Security, Windows as a Service, IAVM, Open Source Software, Open Source Architecture, Application Container, OSS, Operating System, OS