N182-131
|
TITLE: Red Team in a Box for Embedded and Non-IP Devices
|
TECHNOLOGY AREA(S): Air
Platform, Electronics, Ground/Sea Vehicles
ACQUISITION PROGRAM:
Resilient Hull/Infrastructure, Mechanical, Electrical Security (RHIMES) FNC
OBJECTIVE: Develop a tool to
overcome the limitation of human red team resources for conducting
vulnerability assessments on Navy systems, in particular, cyber-physical
systems. In this context, a red team is comprised of a number of human hackers
that attempt to infiltrate a computer system. The aforementioned limitation
stems from the scarcity of these hackers relative to the Navy�s need for vulnerability
testing to develop safeguards. The Navy is soliciting research and development
(R&D) proposals for constructing a �Red Team in a Box� specifically suited
to embedded devices and cyber-physical devices that may not be connected to any
internet protocol (IP) network. This would be a portable appliance that could
connect to various cyber-physical system interfaces and utilize such
connections to assess the device for potential unknown vulnerabilities by
applying software tools developed by a red team. It would be used by non-expert
Sailors or Marines to identify vulnerabilities and generate a report.
DESCRIPTION: The Navy depends
on a vast array of cyber-physical systems to operate safely and to maintain
integrity in the face of an uncertain cyber environment. Many systems operate
in harsh environments at sea, undersea, and in the air. In addition, these
systems are not traditional IP-connected devices and their cyber security
postures are not as well understood. Security of embedded devices is increasingly
important in the commercial sector. Early commercial tools advertise
vulnerability assessment for home networks and Internet of Things (IoT)
devices. Current approaches are limited, however, and rely on a centralized
repository of scanning signatures that must be manually maintained by experts.
Most commercial assessment tools also only inspect devices remotely via an
IP-based interface. While an array of network-based vulnerability scanners
exists for IP-based networks and devices, very few tools exist to audit the
attack surface of many embedded devices. The Navy is concerned about zero-day
attacks on all computing devices, even if they do not maintain connectivity
with an IP-based network.
The Navy desires a tool and method to effectively and efficiently assess the
cyber security posture of such devices where auditing for vulnerabilities from
a centralized point on a network is not possible. Many devices that must be
audited, such as Programmable Logic Controllers (PLCs), microcontrollers, various
engine control units, and navigation systems, either cannot or will not be
connected to a network solely for cyber security auditing purposes. An
assessment tool must therefore be brought to the device itself. The Navy is
looking to develop a man-portable device that a Sailor or Marine could easily
carry along and use, featuring an appropriate set of connectors to interface
with various cyber physical systems. The device must be able to communicate
with a cyber-physical system and analyze using the software loaded on it [Ref
1].
For the purposes of this SBIR topic, assessing a device across an IP-based
network is out of scope. Assessing or auditing traditional Information
Technology (IT) devices such as workstations and servers is also out of scope.
The tool should investigate any available alternative means to interface with
cyber-physical or embedded devices. Some common interfaces include: Universal
Serial Bus (USB), Joint Test Action Group (JTAG) connections, Serial Peripheral
Interface (SPI) bus, universal asynchronous receiver-transmitter (UART) and
other serial ports such as RS-232, or other bus connections such as On-board
Diagnostics (OBD) ports. The class of embedded systems is very broad so
proposers should select a specific subset of systems to target and the
appropriate interfaces based on what is common to that chosen subset.
When assessing a target device, the security auditing methodology must go
beyond traditional signature-based assessments. The goal for this SBIR effort
is to emulate a deeper red team approach in an automated and autonomous manner
[Refs 1-4]. Due to the much larger array of devices and firmware revisions
across embedded devices than IT, it is likely the tool will come across devices
and firmware images that have not been previously seen. Discovered
vulnerabilities can be stored in a repository for easy testing on future
devices, but the tool should be equipped with an array of techniques to perform
a vulnerability assessment without any prior knowledge of the device. Firmware
extraction techniques can be paired with modern program analysis (e.g., static
or dynamic analysis) to reason about the security posture of a device and the
software it runs. Dynamic analysis (e.g., fuzzing) can be done but steps should
be taken so as not to corrupt the actual device undergoing testing [Ref 3].
Reprogramming or injecting new functionality to the device to aid analysis is
within scope but should obey similar rules to not disrupt its original
functions.
After analysis, the tool should provide an intuitive interface to a non-expert,
presenting possible vulnerabilities and ideally potential recommendations for
solutions (remediation). The tool could utilize models of a system and develop
attack graphs. The tool should be capable of interfacing with more than one
type of system.
PHASE I: Develop a
methodology and proof-of-concept tool to execute Red Team in a Box for
non-IP-centric embedded or cyber-physical devices. Select a subset of the class
of embedded devices on which to focus first and include appropriate system
interfaces on the proof-of-concept tool. Provide a limited proof-of-concept
application to demonstrate the viability of the approach, to include automated
firmware extraction and autonomous analysis. The physical size of the proof-of-concept
tool will not be an emphasis at this phase, but a plan should be devised to
miniaturize the device to be portable in Phase II. Develop a Phase II prototype
plan.
PHASE II: Develop the
prototype into a fully functioning handheld appliance capable of interfacing
with multiple types of cyber-physical systems with various types of
connections. Demonstrate that the device can be used by non-experts and is
capable of providing intuitive insights into potential zero-day
vulnerabilities.
PHASE III DUAL USE
APPLICATIONS: Work with the Navy to integrate the tool into current cyber
assessment processes. Many test and evaluation teams require more automated and
more frequent assessment of the cyber security posture of weapons systems and
hull, mechanical, and electrical (HM&E) systems. The Office of Naval
Research (ONR) will facilitate interactions with NAVSEA, NAVAIR, and SPAWAR to
apply the tool to Navy�s cyber-physical systems.
As mentioned in the Description, security of embedded devices is increasingly
important in the commercial sector and current methods to provide security have
limitations. The market opportunity for a tool with the capabilities described
in this SBIR topic is large. It could be applied to various classes of IoT
devices such as home automation or wearables, automobiles, industrial
controllers, or power plants.
REFERENCES:
1. Palavicini Jr, G., et al.
"Towards Firmware Analysis of Industrial Internet of Things (IIoT)."
2017. https://www.researchgate.net/publication/316867708_Towards_Firmware_Analysis_of_Industrial_Internet_of_Things_IIoT_-_Applying_Symbolic_Analysis_to_IIoT_Firmware_Vetting
2. Stephens, N., et al.
"Driller: Augmenting Fuzzing Through Selective Symbolic Execution."
NDSS 2016. http://cs.ucsb.edu/~chris/research/doc/ndss16_driller.pdf
3. Chen, D., et al.
"Towards Automated Dynamic Analysis for Linux-based Embedded
Firmware." NDSS 2016. https://www.dcddcc.com/docs/2016_paper_firmadyne.pdf
4. Shoshitaishvili, Y., et
al. "Firmalice-Automatic Detection of Authentication Bypass
Vulnerabilities in Binary Firmware." NDSS 2015. http://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2017/09/11_1_2.pdf
KEYWORDS: Cyber;
Vulnerability Assessment; Automation; Red Teaming; Embedded Devices;
Cyber-physical; Static Analysis; Dynamic Analysis; Fuzzing; Attack Graph;
Heuristic
** TOPIC NOTICE **
These Navy Topics are part of the overall DoD 2018.2 SBIR BAA. The DoD issued its 2018.2 BAA SBIR pre-release on April 20, 2018, which opens to receive proposals on May 22, 2018, and closes June 20, 2018 at 8:00 PM ET.
Between April 20, 2018 and May 21, 2018 you may talk directly with the Topic Authors (TPOC) to ask technical questions about the topics. During these dates, their contact information is listed above. For reasons of competitive fairness, direct communication between proposers and topic authors is not allowed starting May 22, 2018 when DoD begins accepting proposals for this BAA.
However, until June 6, 2018, proposers may still submit written questions about solicitation topics through the DoD's SBIR/STTR Interactive Topic Information System (SITIS), in which the questioner and respondent remain anonymous and all questions and answers are posted electronically for general viewing until the solicitation closes. All proposers are advised to monitor SITIS during the Open BAA period for questions and answers and other significant information relevant to their SBIR/STTR topics of interest.
Topics Search Engine: Visit the DoD Topic Search Tool at www.defensesbirsttr.mil/topics/ to find topics by keyword across all DoD Components participating in this BAA.
Proposal Submission: All SBIR/STTR Proposals must be submitted electronically through the DoD SBIR/STTR Electronic Submission Website, as described in the Proposal Preparation and Submission of Proposal sections of the program Announcement.
Help: If you have general questions about DoD SBIR program, please contact the DoD SBIR Help Desk at 800-348-0787 or via email at [email protected]
|