Ammendment_one-DHS-SBIR-14.2.pdf

Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods:

(a) By completing items 8 and 15, and returning or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment your desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified.

E. IMPORTANT: Contractor is not, is required to sign this document and return copies to the issuing office.

AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT 1. CONTRACT ID CODE

2. AMENDMENT/MODIFICATION NO. 3. EFFECTIVE DATE 4. REQUISITION/PURCHASE REQ. NO. 5. PROJECT NO. (If applicable)

7. ADMINISTERED BY (If other than Item 6) CODE

STANDARD FORM 30 (REV. 10-83)

Prescribed by GSA FAR (48 CFR) 53.243

FACILITY CODE

9A. AMENDMENT OF SOLICITATION

NO.

9B. DATED (SEE ITEM 11)

10A. MODIFICATION OF CONTRACT/ORDER NO.

10B. DATED (SEE ITEM 13)

11. THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS

The above numbered solicitation is amended as set forth in Item 14. The hour and date specified for receipt of Offers is extended, is not extended.

12. ACCOUNTING AND APPROPRIATION DATA (If required) copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted;

13. THIS ITEM ONLY APPLIES TO MODIFICATION OF CONTRACTS/ORDERS.

IT MODIFIES THE CONTRACT/ORDER NO. AS DESCRIBED IN ITEM 14.

CHECK ONE A. THIS CHANGE ORDER IS ISSUED PURSUANT TO: (Specify authority) THE CHANGES SET FORTH IN ITEM 14 ARE MADE IN THE CONTRACT ORDER NO.

IN ITEM 10A.

B. THE ABOVE NUMBERED CONTRACT/ORDER IS MODIFIED TO REFLECT THE ADMINISTRATIVE CHANGES (such as changes in paying office, appropriation date, etc.) SET FORTH IN ITEM 14, PURSUANT TO THE AUTHORITY OF FAR 43.103(b).

C. THIS SUPPLEMENTAL AGREEMENT IS ENTERED INTO PURSUANT TO AUTHORITY OF:

D. OTHER (Specify type of modification and authority)

Except as provided herein, all terms and conditions of the document referenced in Item 9A or 10A, as heretofore changed, remains unchanged and in full force and effect.

15C. DATE SIGNED

15A. NAME AND TITLE OF SIGNER (Type or print)

16C. DATE SIGNED

16A. NAME AND TITLE OF CONTRACTING OFFICER (Type or print)

14. DESCRIPTION OF AMENDMENT/MODIFICATION (Organized by UCF section headings, including solicitation/contract subject matter where feasible.)

PAGE OF PAGES

6. ISSUED BY CODE

8. NAME AND ADDRESS OF CONTRACTOR (No., street, county, State and ZIP Code) (X)

CODE

15B. CONTRACTOR/OFFEROR

(Signature of person authorized to sign)

16B. UNITED STATES OF AMERICA

(Signature of Contracting Officer)

NSN 7540-01-152-8070

Previous edition unusable

A00001

DHS/OPO/DNDO

N/A

The purpose of this amendment is to make revisions to DHS SBIR topic number H-SB014.2-002 to differentiate it from DARPA topic number SB131-003 entitled “Automatic Detection and Patching of Vulnerabilities in Embedded Systems”, which was included in the DoD 2013.1 SBIR Solicitation that closed for Phase I proposal submission on January 16, 2013. Notice to potential offerors: the SBIR Policy Directive, dated August 6, 2012, states the following “While it is permissible with proposal notification to submit identical proposals or proposals containing a significant amount of essentially equivalent work for consideration under numerous Federal program solicitations, it is unlawful to enter into funding agreements requiring essentially equivalent work. In accordance with block 11 of this form, Offerors will provide a signed copy of this amendment with their proposal acknowledging they received this amendment and took it into account when submitting their proposal.

U.S. Dept. of Homeland Security Office of Procurment Operatiions Domestic Nuclear Detect. Office 245 Murray Lane, SW #0115 Washington DC 20528-0115

HSHQDC-14-R-00035

DHS SBIR 14.2

1 4

05/01/2014

04/17/2014

Digitally signed by DAVID J VILLALOBOS Date: 2014.05.01 00:09:48 -04'00'

05/01/2014

David.Villalobos Typewritten Text David J. Villalobos, Contracting Officer

David.Villalobos Typewritten Text

SBIR TOPIC NUMBER: H-SB014.2-002

TITLE: Automatic Detection and Patching of Vulnerabilities in Embedded Systems

TECHNOLOGY AREAS: Resilient Systems, Embedded System Security

OBJECTIVE: Develop innovative techniques to rapidly and automatically detect and automatically patch vulnerabilities in complex networked, embedded systems while offline.

This offline analysis and data-mining of features of large firmware image populations enables identification of vulnerabilities in the firmware of embedded devices, to support risk assessment and mitigation actions of complex software systems found throughout national critical infrastructures and systems.

DESCRIPTION: Embedded systems form a ubiquitous, networked, computing substrate that underlies much of modern technological society. Embedded systems are considered to be networked even if the network connection is intermittent or occasional. Examples include supervisory control and data acquisition (SCADA) systems, medical devices, computer peripherals, communication devices, and vehicles, and the many consumer devices that make up the “Internet of Things”. A report in January of 2014 by Proofpoint[1] indicated that about 25% of a spamming botnet was from the Internet of Things, including at least one refrigerator.

Networking these embedded systems enables remote retrieval of diagnostic information, permits software updates, and provides access to innovative features, but it also introduces vulnerabilities to the system via remote attack. As these systems continue to grow more numerous, more complex and more interconnected, so will the need for automatic identification and response to vulnerabilities in these systems, distributed throughout our critical infrastructure networks and systems.

A study by Cui and Stolfo [2] showed that an extensive number of unsecured, embedded, networked devices exist that are trivially vulnerable to exploitation by remote attackers.

Furthermore, a 2012 report by McAfee Labs [3] predicted that in 2012, industrial threats to SCADA systems and industrial controller systems (ICS) will mature and that embedded hardware attacks will widen and deepen. Operational availability has taken precedence over security in this community. This state of SCADA systems was confirmed in the 2013 report by Secunia [4]. The state of the practice of security for traditional IT systems is anti-virus scanning, intrusion detection systems, and a patching infrastructure. This approach does not work well for embedded systems for a variety of reasons, including its focus on known vulnerabilities and the fact that security code can itself introduce new vulnerabilities. Embedded systems impose additional difficulties, such as strict resource constraints, hard real-time performance requirements, reliability over long periods of time, and the need for extensive verification and validation before patches can be installed [5].

Embedded system research has lagged behind general IT security research [6]. Some progress has been made in the last few years, but at best we have only kept up with the problem, the net outcome is essentially unchanged. DHS seeks to develop novel technology for automatically detecting and automatically patching vulnerabilities in networked, embedded systems. The technology should represent practical and effective techniques that can be applied to a wide-range of embedded system platforms that will increasingly be employed across the various infrastructure sectors. In addition, the techniques should be versatile such that it can be implemented on systems externally networked by various mechanisms, including, Bluetooth, Wi-Fi, radios, etc. This technology will lead to more resilient and secure embedded systems used in critical infrastructure, medical, transportation and other sectors. Manual techniques for detecting and patching vulnerabilities are not within the scope of this topic and should not be submitted for consideration.

This SBIR effort is focused on the near-term needs of critical infrastructure systems and components, which is different than the focus of related work at DARPA (longer term and higher risk), NSF (foundational research that will support future improvements), and Military Service R&D organizations (near-term needs of military systems and components).

The offline analysis and data-mining of features of large firmware image populations encourages a hybrid approach for vulnerability identification using host based monitoring capabilities on the device, in conjunction with offline static analysis of code and data. Fuzzing is one approach to incorporate dynamic analysis of embedded systems, and has successfully been used for some device types, such as cell phones, to identify some vulnerabilities that are not detected with static code analysis. The hybrid approach fits the off-line analysis envisioned in this request, rather than pipeline approach concepts needed to repair firmware exploited inside running embedded devices. This hybrid approach (using fuzzing or other appropriate techniques and host based run-time defense) will enable:

1. mitigation or prevention of potential run-time threats;

2. offline modification of firmware to either remove or replace vulnerable code;

3. allowing the embedded device to act as a detector, to alert on successful exploitation of known vulnerabilities; and

4. using host-based capabilities to dynamically react to real-time information generated by a large population of embedded devices acting as sensors.

With the scope, complexity and dynamics of embedded software found throughout our national infrastructures and their various systems, hybrid approaches will be needed to address the vulnerabilities of these kinds of systems.

PHASE I: Develop novel techniques for automatic detection and automatic patching of vulnerabilities in networked, embedded systems that are offline for one or more applications.

Required Phase I deliverable includes monthly progress reports, a final report that details the proposed techniques, the level of vulnerability expected to be achieved by the techniques, the specific systems or types of systems that the technique(s) will benefit, the basic architecture or design to implement the intended approach, and the anticipated amount of software development required.

PHASE II: Demonstrate that the techniques from Phase I can be practically and effectively applied to any general networked, embedded system connected by any external means, such as, Bluetooth, Wi-Fi, radios, etc. These offline devices may only connect intermittently or occasionally. Required Phase II deliverables include all documentation for the developed techniques; full architecture/design supporting the implementation; software or prototype(s) that will be demonstrated on multiple networked, embedded system platforms; monthly reports; and a final report describing the effort, including a description of remaining work to commercialize the prototype.

PHASE III: The technology will be demonstrated through a full-scale pilot in one or more civil/commercial applications, such as SCADA systems, medical devices, computer peripherals, communication devices, and vehicles. Required deliverables include a commercial service, or a technology product that can be commercialized in the private sector. For example, this technology can be integrated into a larger security software product suite (i.e., McAfee, Symantec) and would represent a specialized tool that can be applied specifically on networked, embedded systems that are offline, as opposed to current security tools designed specifically for traditional IT systems.

REFERENCES:

1. Proofpoint, (January 16, 2014) Proofpoint Uncovers Internet of Things (IoT) Cyberattack, Proofpoiont. Retriefed from http://wwwlproofpoint.com/about-up/press-release/011620.php

2. A. Cui and S. Stolfo, “A Quantitative Analysis of the Insecurity of Embedded Network Devices: Results of a Wide-Area Scan”, ACSAC, pages 97-106, 2010.

3. McAfee Labs, 2012 Threats Predictions, http://www.mcafee.com/us/resources/reports/rp-threat-predictions-2012.pdf.

4. Secunia Vulnerability Review March 14, 2013 http://secunia.com/?action=fetch&filename=Secunia_Vulnerability_Review_2013 .pdf

5. C. Ebert and C. Jones, “Embedded Software: Facts, Figures, and Software”, IEEE Computer Society, pages 42-52, April 2009.

6. A. Cui and S. Stolfo, "Defending Legacy Embedded Systems with Software Symbiotes", The 14th International Symposium on Recent Advances in Intrusion Detection (RAID), September 2011.

KEY WORDS: Vulnerabilities of Embedded Systems, Automatic Detection, and Automatic Patching, resilient systems, Internet of Things http://wwwlproofpoint.com/about-up/press-release/011620.php http://wwwlproofpoint.com/about-up/press-release/011620.php http://secunia.com/?action=fetch&filename=Secunia_Vulnerability_Review_2013.pdf http://secunia.com/?action=fetch&filename=Secunia_Vulnerability_Review_2013.pdf