Protocol Feature Identification and Removal
Navy STTR 2018.A - Topic N18A-T018
ONR - Mr. Steve Sullivan - steven.sullivan@navy.mil
Opens: January 8, 2018 - Closes: February 7, 2018 (8:00 PM ET)

N18A-T018

TITLE: Protocol Feature Identification and Removal

 

TECHNOLOGY AREA(S): Information Systems

ACQUISITION PROGRAM: Total Platform Cyber Protection (TPCP) Innovative Naval Prototype (INP)

OBJECTIVE: The goal of this research effort is to produce algorithms that can identify features in a communications protocol and remove features identified by user selection.  The focus of this thrust area is to develop a capability for modifying standard protocols for reducing and altering the attack surface, and to amplify anomalies.

DESCRIPTION: The Navy extensively leverages and adopts protocols and standards developed for commercial and public sectors.  These standard, feature-rich protocols are often implemented as a one-size-fits-all library and are generally deployed as a whole.  It is extremely rare that an application or even a set of applications within the computing system requires and invokes the entire feature set supported by a standard protocol.  In most deployments, many features are not needed and are never invoked by the application(s).  However, these extraneous, unnecessary features are invoke-able by an external party and represent an attack surface and risks that need not be incurred.  As an illustration, most applications that use the Secure Sockets Layer (SSL) protocol do not require the heartbeat feature.  However, it is a standard feature in a popular one-size-fits-all SSL library.  An implementation bug/flaw for heartbeat opens the door for the heartbleed attack.  All computing systems that used the popular standard SSL library became susceptible to the heartbleed attack, whether or not their applications needed or invoked the heartbeat feature.  Aside from vulnerabilities that were caused by implementation flaws such as heartbeat, which are repairable, vulnerabilities may also be a result of unintended/unanticipated use of a legitimate feature.  This type of vulnerability is a result of a flaw in the protocol design itself and not the implementation.  This type of vulnerability cannot easily be fixed without changes in the essence of the protocol itself.

The Navy would like to acquire the capability for modifying standard protocols it deploys for reducing the attack surface and limiting the risk exposure to only that of the protocol features that are essential to its application(s).  The Navy is soliciting Science and Technology (S&T) projects that lead to the development of protocol customization tools.  The tools will take a list of required features for a particular protocol and either binary or source code of the standard protocol and transform or generate a specialized protocol that only supports the listed features and nothing more.  Along with feature reductions, care needs to be taken to properly respond to an external party invoking the removed features.

In subsetting, the Navy is only interested in supporting protocol features necessary for correct communication of our application(s) and nothing else.  All other protocol features should be removed from the protocol code/library.  The core functionality of the protocol remains intact, and the resulting protocol is still compatible with an external party communicating via the standard protocol.  Currently, solutions for addressing threats against protocols involving Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS) and firewall approaches are not encouraged.  The proposer may assume that the list of required features already exists.  A user interface may also be built on top of the protocol customization tool to help an administrator configure and customize protocols, when the desired-feature-list is unavailable and automated feature list extractor is not practical.  Proposer should not assume that the binary or source code of the standard protocol are annotated or tagged with feature identifying labels.  Proposals that implement a wrapper will be deemed unacceptable.  Proposer must modify the existing protocol and not create their own protocol baseline for editing.

PHASE I: Develop a concept and methodology to associate protocol features to its implementation/code within the protocol software and perform code transformation to remove undesired features and replace them with safe response.  Provide a limited proof-of-concept application to demonstrate the viability of the approach for identifying and trimming protocol features.  Develop a Phase II prototype plan.

PHASE II: Develop the prototype into a fully functioning software toolset for identifying and tagging protocol features, allowing end users to selectively remove unwanted features and their corresponding code.  Demonstrate and evaluate the efficacy of the tools on protocols of varying complexity as selected by the performer, along with demonstration of the continued correct and functional operation of the remaining protocol features.

PHASE III DUAL USE APPLICATIONS: All third-party or commercial software used by the military contains extraneous protocol features that unnecessarily widen a system’s attack surface.  Being able to remove those features without needing the cooperation of the developer would be a great advantage and drastically help improve the security posture of such systems.  As a result, expected transition of these tools could extend to a wide range of government programs interested in improving the security and performance parameters of their software environments.  Enterprise IT Management departments would also welcome the removal of unnecessary protocol features for both security and speed.

REFERENCES:

1. “HbbTV and Security.” http://www.hbbtv.org/wp-content/uploads/2015/09/HbbTv-Security-2015.pdf

2. Fingas, Jon. “Exploit attacks your smart TV through over-the-air signals.” Engadget, 1 April 2017. https://www.engadget.com/2017/04/01/smart-tv-broadcast-security-exploit/

KEYWORDS: Protocol Vulnerability; Software Feature Identification and Removal

** TOPIC NOTICE **

These Navy Topics are part of the overall DoD 2018.A STTR BAA. The DoD issued its 2018.A BAA SBIR pre-release on November 29, 2017, which opens to receive proposals on January 8, 2018, and closes February 7, 2018 at 8:00 PM ET.

Between November 29, 2017 and January 7, 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 January 8, 2018
when DoD begins accepting proposals for this BAA.
However, until January 24, 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 sbir.defensebusiness.org/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/STTR Help Desk at 800-348-0787 or via email at sbirhelp@bytecubed.com