Military reference books and manuals (2009-2023, Volume 1)

UNCLASSIFIED//FOR OFFICIAL USE ONLY

Annex 1: Air Force Reserve Component Units

960th Cyber Operations Group Units

These locations were selected based on the existence of infrastructure for these part-time

positions and the availability of SCIF space.



960^th Cyber Operations Group (Texas). Mission: C2 of subordinate squadrons. 42

authorized personnel;



860^th Network Operations Squadron (NOS) (Virginia) and 960^th Network Operations

Squadron (Colorado). Mission: Defend Air Force networks and uphold Air Force and

DoD standards to ensure network availability. 62 authorized personnel (860^th NOS); 72

authorized personnel (960^th NOS).



854^th Cyberspace Operations Squadron (Texas). Mission: Full-spectrum cyber

operations and capabilities in support of Air Force and Joint requirements. 101

authorized personnel;



426^th Network Warfare Squadron (Texas). Mission: To produce effects for the Air Force

and CCMDs in, through and from cyberspace by employing synchronized network

defense operations to detect, respond, and prevent network intrusions. 157 authorized

personnel;



960^th Network Warfare Flight (NWF) (Nebraska) and 860th Network Warfare Flight

(Texas). Mission: Provide personnel to monitor Air Force communications computer

systems for adversary value. 35 authorized personnel (960^th NWF); 39 authorized

personnel (860^th NWF)

Air National Guard Units



102^nd Network Warfare Squadron (Rhode Island). Mission: Air Force Computer

Emergency Response Team support and forensics;



229^th Information Operations Squadron (Vermont). Mission: Cyber training for the Air

Force and Army;



166^th Network Warfare Squadron (Delaware) and 175^th Network Warfare Squadron

(Maryland). Mission: Force Application;



273^rd Information Operation Squadron (Texas). Mission: 24^th Air Force support;



262^nd Network Warfare Squadron (Washington). Mission: Interceptor/hunter, Industrial

Control System/Supervisory Control and Data Acquisition missions and AFCYBER

support;



143^rd Information Operations Squadron (Washington) and 261^st Network Warfare

Squadron (California). Mission: Interceptor/hunter missions; and



177^th Information Aggressor Squadron (Kansas). Mission: Red teaming assessments.

UNCLASSIFIED//FOR OFFICIAL USE ONLY

Annex 2: Reserve Component Infrastructure

Army Reserve Components

The USAR is using existing infrastructure to support cyber missions such as: the ARIOC

consisting of 308 personnel, headquartered in Adelphi, Maryland with five battalions distributed

nationwide; the USCYBERCOM-U.S. Army Reserve Element (ARE), which has capacity for 23

personnel located at Fort Meade, Maryland; and the DISA ARE with 111 total personnel (57

personnel at Ft Meade, 18 personnel at Redstone Arsenal, Alabama, 18 personnel at Fort

Carson, Colorado, and 18 personnel at Scott AFB, Missouri). As discussed earlier, the ARNG is

leveraging the following infrastructure to perform cyber missions: the Virginia DPU with its 174

personnel in Manassas, Virginia, the ARNG Title 10 team in Laurel, Maryland with capacity and

connectivity for 43 personnel. This is in addition to forces possessed by each State and territory

such as JFHQ-DOIMs consisting of 1,160 total personnel and State Cyber Network Defense-

Teams with a total strength of 432 personnel. The USAR and ARNG are also assessing their

additional infrastructure assets for future use by the RC’s CMF. The USAR plans to locate their

CPTs within the facilities currently used by the ARIOC. The ARIOC has subordinate

infrastructure located in: Adelphi, Maryland; Pittsburgh, Pennsylvania; Devens, Massachusetts;

Fort Sam Houston, Texas; and Camp Parks, California. Each of these facilities can

accommodate and provide connectivity for 59 personnel. This presents a potential requirement

to increase capacity or connectivity at each location to account for future CPT capacity.

Air Force Reserves

Air Force Reserve cyber personnel work in the same infrastructure space as their active-duty

counterparts greatly reducing, and in many cases eliminating, infrastructure needs.

Navy Reserves

Reserve units work in the CMF leveraging access to command assets whenever possible. For

those personnel and units not collocated with a gaining command, the Navy relies on the JRICs

to provide the necessary infrastructure.

Marine Corps Reserves

The Marine Corps Reserve personnel augment existing forces utilizing existing infrastructure

within those commands.

UNCLASSIFIED//FOR OFFICIAL USE ONLY

Annex 3: Acronym list

AAS - Associate in Applied Science

AC - Active Component

AFCYBER - Air Force Cyber Command

ARCOG - U.S. Army Reserves Army Cyber Operations Group

ARCYBER - Army Cyber Command

ARIOC - Army Reserve Information Operations Command

ARE - Army Reserve Element

ARNG - Army National Guard

ANG - Air National Guard

ASI - Additional Skill Identifier

ASVAB - Armed Services Vocational Aptitude Battery

C2 - Command and Control

C10F - Commander 10^th Fleet

CCMD - Combatant Command

CFCOE - Cyberspace Forces Concept of Operations and Employment

CIMB - Cyber Investment Management Board

CJCS - Chairman of the Joint Chiefs of Staff

CMF - Cyber Mission Force

CMT - Combat Mission Team

CNDSP - Computer Network Defense-Service Provider

CND-T - Computer Network Defense Teams

CNO - Chief of Naval Operations

CoE - Center of Excellence

CoG - Council of Governors

COMINT - Communications Intelligence

C/TAA - Coordinate, Train, Advise, and Assist

CPT - Cyber Protection Team

CS/IA - Cyber Security / Information Assurance

CST - Combat Support Team

CTN - Cryptologic Technician Networks

CVA - Cyber Vulnerability Assessment

CWE - Cyber Warfare Engineer

CyOG - Cyber Operations Group

CyTAC - Cyber Training Advisory Council

DCO - Defensive Cyber Operations

DHS - Department of Homeland Security

DIB - Defense Industrial Base

DISA - Defense Information Systems Agency

DoD - Department of Defense

DoDIN - Department of Defense Information Networks

DoJ - Department of Justice

DSCA - Defense Support of Civil Authorities

DSOC - 2011 Department of Defense Strategy for Operating in Cyberspace

UNCLASSIFIED//FOR OFFICIAL USE ONLY

ECS - Enhanced Cybersecurity Services

FCC/C10F - Fleet Cyber Command/Commander 10^th Fleet

HRC - Human Resources Command

HQ - Headquarters

IASP - Information Assurance Scholarship Program

IC - Intelligence Community

IMA - Individual Mobilization Augmentees

IAS - Information Aggressor Squadron

IDC - Information Dominance Corps

IOS - Information Operations Support

IOSC - Information Operations Support Command

ISR - Intelligence, Surveillance, and Reconnaissance

IT - Information Systems Technician

ITEB - Individual Training Equivalency Board

ITP - Individual Training Pipeline

JCAC - Joint Cyber Analysis Course

JCRE - Joint Cyber Reserve Element

JCT&TS - Joint Cyberspace Training and Certification Standard

JFHQ-C - Joint Force Headquarters-Cyber

JFHQ-DOIM - Joint Force Headquarters-Directorates of Information Management

JIE - Joint Information Environment

JRIC - Joint Reserve Intelligence Centers

KIFC - Kansas Intelligence Fusion Center

KSA - Knowledge, Skills, and Ability

MOS - Military Occupational Specialty

NDAA - National Defense Authorization Act

NG - National Guard

NGB - National Guard Bureau

NICE - National Initiative for Cybersecurity Education Workforce

NMT - National Mission Team

NOS - Network Operations Squadron

NPS - Naval Postgraduate School

NRO - National Reconnaissance Office

NSA - National Security Agency

NST - National Support Team

NVCC ASI - Northern Virginia Community College Advanced Standing Initiative

NWF - Network Warfare Flight

NWS - Network Warfare Squadrons

OPM/NSF - Office of Personnel Management/National Science Foundation

OPNAVO - Office of the Chief of Naval Operations

OSD - Office of the Secretary of Defense

PCA - Principal Cyber Advisor

POM - Program Objective Memorandum

RC - Reserve Component

ROTC - Reserve Officer Training Corps

UNCLASSIFIED//FOR OFFICIAL USE ONLY

Annex 4: Section 933 Reporting Requirement

Reporting Requirement

Section 933 of H.R. 3304, the National Defense Authorization Act for Fiscal Year 2014

(Public Law 113-66)

SEC. 933. MISSION ANALYSIS FOR CYBER OPERATIONS OF DEPARTMENT OF

DEFENSE.

(a) MISSION ANALYSIS REQU IR ED.—Not later than 180 days after the date of the

enactment of this Act, the Secretary of Defense shall conduct a mission analysis of the cyber

operations of the Department of Defense.

(b) ELEMENTS.—The mission analysis under subsection (a) shall include the following:

(1) The concept of operations and concept of employment for cyber operations forces.

(2) An assessment of the manpower needs for cyber operations forces, including

military requirements for both active and reserve components and civilian requirements.

(3) An assessment of the mechanisms for improving recruitment, retention, and

management of cyber operations forces, including through focused recruiting; educational,

training, or certification scholarships; bonuses; or the use of short-term or virtual

deployments without the need for permanent relocation.

(4) A description of the alignment of the organization and reporting chains of the

Department, the military departments, and the combatant commands.

(5) An assessment of the current, as of the date of the analysis, and projected equipping

needs of cyber operations forces.

(6) An analysis of how the Secretary, for purposes of cyber operations, depends upon

organizations outside of the Department, including industry and international partners.

(7) Methods for ensuring resilience, mission assurance, and continuity of operations

for cyber operations.

(8) An evaluation of the potential roles of the reserve components in the concept of

operations and concept of employment for cyber operations forces required under paragraph

(1), including—

(A) in consultation with the Secretaries of the military departments and the

Commander of the United States Cyber Command, an identification of the Department

of Defense cyber mission requirements that could be discharged by members of the

reserve components;

UNCLASSIFIED//FOR OFFICIAL USE ONLY

(B) in consultation with the Secretary of Homeland Security, consideration of

ways to ensure that the Governors of the several States, through the Council of

Governors, as appropriate, have an opportunity to provide the Secretary of Defense and

the Secretary of Homeland Security an independent evaluation of State cyber

capabilities, and State cyber needs that cannot be fulfilled through the private sector;

activities of the reserve components, including—

(i) an identification of current positions in the reserve components serving

Department cyber missions;

(ii) an inventory of the existing cyber skills of reserve component personnel,

including the skills of units and elements of the reserve components that are

transitioning to cyber missions;

(iii) an inventory of the existing infrastructure of the reserve components that

contributes to the cyber missions of the United States Cyber Command, including

the infrastructure available to units and elements of the reserve components that

are transitioning to such missions; and

(iv) an assessment of the manner in which the military departments plan to

use the reserve components to meet total force resource requirements, and the

effect of such plans on the potential ability of members of the reserve components

to support the cyber missions of the United States Cyber Command;

(D) an assessment of whether the National Guard, when activated in a State status

(either State Active Duty or in a duty status under title 32, United States Code) can

operate under unique and useful authorities to support domestic cyber missions and

requirements of the Department or the United States Cyber Command;

(E) an assessment of the appropriateness of hiring on a part-time basis non-dual

status technicians who possess appropriate cyber security expertise for purposes of

assisting the National Guard in protecting critical infrastructure and carrying out cyber

missions;

(F) an assessment of the current and potential ability of the reserve components

to—

(i) attract and retain personnel with substantial, relevant cyber technical

expertise who use those skills in the private sector;

(ii) organize such personnel into units at the State, regional, or national level

under appropriate command and control arrangements for Department cyber

missions;

UNCLASSIFIED//FOR OFFICIAL USE ONLY

(iii) meet and sustain the training standards of the United States Cyber

Command; and

(iv) establish and manage career paths for such personnel;

(G) a determination of how the reserve components could contribute to total force

solutions to cyber operations requirements of the United States Cyber Command; and

(H) development of an estimate of the personnel, infrastructure, and training

required, and the costs that would be incurred, in connection with implementing a

strategy for integrating the reserve components into the total force for support of the

cyber missions of the Department and United States Cyber Command, including by

taking into account the potential savings under the strategy through use of personnel

referred to in subparagraph (C)(i), provided that for specific cyber units that exist or

are transitioning to a cyber mission, the estimate shall examine whether there are

misalignments in existing plans between unit missions and facility readiness to support

such missions.

(1) REDUCTION IN PERSONNEL OF AIR NATIONAL GUARD CYBER

UNITS.—No reduction in personnel of a cyber unit of the Air National Guard of the United

States may be implemented or carried out in fiscal year 2014 before the submittal of the

report required by subsection (d).

(2) REDUCTION IN PERSONNEL AND CAPACITY OF AIR NATIONAL GUARD

RED TEAMS.—No reduction in the personnel or capacity of a Red Team of the Air

National Guard of the United States may be implemented or carried out unless the report

required by subsection (d) includes a certification that the personnel or capacity to be

reduced is directly related to Red Team capabilities that are no longer required.

(d) REPOR T REQUIRED .—Not later than 30 days after the completion of the mission

analysis under subsection (a), the Secretary shall submit to the congressional defense committees

a report containing—

(1) the results of the mission analysis;

(2) recommendations for improving or changing the roles, organization, missions,

concept of operations, or authorities related to the cyber operations of the Department; and

(3) any other matters concerning the mission analysis that the Secretary considers

appropriate.

(e) NATIONAL GUAR D ASSESSMENT.—Not later than 30 days after the date on which the

Secretary submits the report required under subsection (d), the Chief of the National Guard

UNCLASSIFIED//FOR OFFICIAL USE ONLY

HBGary Federal, LLC.

3604 Fair Oaks Blvd. Suite 250, Sac ramento, C A. 95864

Pho ne: (916) 459-4727 Fax: (916) 481-1460

VOLUME I TECHNICAL MANAGEMENT PROPOSAL

Prepared for DARPA

CYBER GENOME PROGRAM

STRATEGIC TECHNOLOGY OFFICE

DARPA-BAA-10-36

March 21, 2010

This proposal includes data that shall not be disclosed outside the Government and shall not be duplicated,

used, or disclosed-in whole or in part-for any purpose other than to evaluate this proposal. If, however, a

contract is awarded to this proposer as a result of, or in connection with, the submission of this data, the

Government shall have the right to duplicate, use, or disclose the data to the extent provided in the

resulting contract. This restriction does not limit the Government's right to use information contained in

this data if it is ob tained from another source without restriction. The data subject to this restriction are

contained in marked sheets.

Table of Contents

Section I. Administrative

A. Proposal Cover Sheet

DARPA-BAA-10-36

Cyber Genome Program

B. Official transmittal letter

Section II. Summary of Proposal

II.A Innovative Claims for the Proposed Research

II.B

Deliverables, Plans, and Capability for technology transition and Commercialization

II.B.1 Deliverables

II.B.2 Plans and Capability to Achieve Commercialization and Technology Transition

II.B.3 Data Rights and Intellectual Property

II.C

Cost, Schedule and Measurable Milestones

II.D

Technical Rationale, Technical Approach, and Constructive Plan

II.D.1 Technical Rationale

II.D.2 Technical Approach and Constructive Plan

II.E

Detailed Management, Staffing, Organization Chart, and Key Personnel:

II.E.1 Management

II.E.2 Teaming and Staffing

II.E.3 Organizational Chart

II.E.4 Key Personnel

II.F

Summary Slides

Section III. Detailed Proposal Information

III.A

Statement of Work (SOW)

III.A.1

Program Management

III.A.2

SOW Tasks

III.B

Description of the Results

III.C

Detailed Technical Rationale

III.D

Detailed Technical Approach

III.D.1 Specimen Collection and Pre-Processing

III.D.2 Specimen Repository

III.D.3 Specimen Analysis and Visualization Interface (SAVI)

III.D.4 Traits Library

III.D.5 Genomes Library

III.D.6 Static Memory Analysis and Runtime Tracing (SMART)

III.D.7 Belief Reasoning and Inference Node (BRaIN)

III.E

Comparison with Other Research

III.F

Previous Accomplishments

III.G

Place of Performance, Facilities, and Locations

III.H

Detailed Support (Including Teaming Agreements)

III.I

Cost, Schedules and Measurable Milestones

III.J

Data Description

Section IV. Additional Information

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - ii

restriction on the title page of this proposal.

Section I. Administrative

Proposal Cover Sheet

Broad Agency

DARPA-BAA-10-36

Announce ment

Cyber Genome Program

Prime Orga nizat ion

HBGary Federal, LLC.

Proposal Title

Cyber Genome Program, Cyber Physiology

□ Large Business

□ Small Disadvantaged

□ Historically-Black Colleges

Type of Business (Check

Business

□ Minority Institut ion (MI)

one)

X Other Small Business

□ Other Educational

□ Government Laboratory

□ Other Nonprofit

or FFRDC

Contractor’s Reference

Number

Contractor and

Government Entity

5U1U6

(CAGE) Code

Dun and Bradstreet

832950831

(DUN) Number

North Ame rican

Industrial Classification

541512

System (NAICS)

Number

Taxpayer Identification

27-1485507

Number (TIN)

Mr. Aaron Barr, CEO, HBGary Federal

Technical Point of

3604 Fair Oaks Blvd B STE 250

Contact

Sacramento, CA 95864

Mr. Ted Vera, President, HBGary Federal

Administrative Point of

3604 Fair Oaks Blvd B STE 250

Contact

Sacramento, CA 95864

Mr. Aaron Barr, CEO, HBGary Federal

Security Point of Contact

3604 Fair Oaks Blvd B STE 250

Sacramento, CA 95864

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - iii

restriction on the title page of this proposal.

Technical POC salutation, last name,

Pikewerks, Other Small

first name, street address, city, state,

Other Team Membe rs (if

SecureDecisions, Other

zip code, telephone, fax (if available),

applicable)

Small

electronic mail (if available), CAGE

Code

Base Effort Cost

Base Effort:

(Phas e 1)

Base Options Cost: (list all)

Option Effort Cost

Option Effort:

Funds Requested From

(Phas e 2)

DARPA

Phase II Options Cost: (list all)

Total Proposed Cost

Total

(Including Options)

Amount of Cost Share

Amount of cost share (if any)

Xcost-plus- fixed-fee

□grant

□cost-contract- no-fee

□agreement

Award Instrument

□cost sharing contract-no fee

□other award instrument:

Requested

□other procurement

__________

contract:______________

Propos ers Cognizant

Name, mailing address, telephone number and Point of Contact of

Government

the Proposers cognizant government administration office (i.e.,

Administration Office

Defense Contract Management Agency (DCMA))

Propos er’s Cogn izant

Defense Contract Audit

Name, mailing address, telephone number, and Point of Contact if

Agency (DCAA) audit

known

Office

Any Forward Pricing Rate Agreement, other such Approved Rate

Other

Information, or such other documentation that may assist in

expediting negotiations (if available)

Date Propos al Prepared

Mar. 29, 2010

Proposal Expiration

July 30, 2010

Date

Location where the proposed work will be performed and dates of

Place(s) and Period(s) of

proposed performance

Performance

□ Technical Area 1 - Cyber Genetics

Technical Area

□ Technical Area 2 - Cyber Anthropology and Sociology

(check one)

X Technica l Area 3 - Cyber Physiology

□ Technical Area 4 - Other

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - iv

restriction on the title page of this proposal.

Official transmittal letter.

HBGary Federal, LLC.

3604 Fair Oaks Blvd. Suite 250, Sac ramento, C A. 95864

Pho ne: (916) 459-4727 Fax: (916) 481-1460

March 29, 2010

Attn: Dr. M ichael VanPutte

Defense Advanced Research Projects Agency

Subject: DARPA Cybe r Genome Program

HBGary Federal is pleased to present this proposal to DARPA in response to DARPA BAA-10-36 Cyber

Genome Program Technical Area III: Cyber Physiology. This proposal assumes a CPFF type contract and is

valid through July 30, 2010.

Cost

Fixed Fee

Total CPFF

Organizational Conflict of Interest

HBGary Federal, LLC. does not provide scientific, engineering and technical assistance (SETA) or similar

support to any DARPA technical office(s) through active contracts or subcontracts. We therefore do not have

any organizational conflicts of interest that require affirmation.

Sincerely yours,

Aaron D. Barr

CEO

HBGary Federal, LLC.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - v

restriction on the title page of this proposal.

Section II. Summary of Proposal

II.A Innovative Claims for the Proposed Research

Our HBGary Federal Team comprises some of the most capable companies and research organizations in the

field of malware analysis and visualization. Together, we offer a revolutionary approach to addressing

Technical Area Three, Cyber Physiology that builds on our depth and breadth of experience. From research to

product to operations, we all are documented leaders in our fields, with demonstrated capabilities to provide

cyber defense and investigatory technologies in support of defense, law enforcement, and intelligence and

counter intelligence

In our proposed Cybe r Physiology system, malware objects are pre-processed to remove obfuscation and anti-

analysis capabilities, then stored in the specimen repository and flagged for execution and analysis. A

combination of memor y and runtime analys is is perfor med using the de velop ed traits and patterns libraries and

data flow tracing used to collect near full execution of all code and low- level data and stored back into the

repository, a physiology profile is developed that mathematically and descriptively represents the malware

aggregate functions, behaviors, and intent. A Physiology Profile report can be generated through our

visualization interface, which shows a variety of graphical representations of the malware object and allows an

analyst to interact with the mode ls to better understand. Once mature data sets exist there will be a capability to

process the low level data outputs from the memory and runtime analysis through a reasoning engine that can

make probability decisions on malware functions and behaviors even for previously undefined traits and

patterns.

Table 1. Innovative Claims for the Proposed Research

Research Area

Innovati ve Clai m

State-of-the-Art

Specimen Collection

The most advanced binary unpacking and

Current de-obfuscation techniques are not

and Pre-Processing

automated de-obfuscation system. Self-evaluation

fully automated, and cannot resolve APIs

metrics will allow it to iteratively detect and

automatically, nor reliably auto-discover the

recover fro m binary unpacking proble ms and

original entry point. They cannot deal with

avoid anti-reverse engineering countermeasures

block encryption or code segmentation.

It will incorporate snapshot-stitching techniques

Current binary unpacking systems are tuned

to deal with multi-stage packers and block

toward static disassembly and analysis.

encryption. We will research and develop

These systems yield a disassembled

automated ways to recognize obfuscated code and

approximation of the binary that does not

identify the obfuscation steps employed to hinder

support logic and data flow extraction

automated analysis, then systematically de-

through the informed execution of malware.

obfuscate to restore the binary to an equivalent but

un-obfuscated form.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - vi

restriction on the title page of this proposal.

Specimen Analysis

Visual representations of ma lwa re, through

A few capabilities that show loop and

and Visualization

analyst views and the Cyber Physiology Profile,

branch and function view of ma lwa re, but

that allow for easy understanding of the malware

they only view, without any functional

behaviors, functions, and intent.

context or purpose.

Traits Library

A comprehensive data set that describes the

Limited capabilities/tools that describe some

discrete functions and behaviors of ma lware

subset of discrete functions and behaviors of

through mathematical representations, rule sets,

ma lware but not in a standardized,

and descriptions.

comprehensive manner that can be

mathe matica lly calculated and automated.

Genomes Library

A library that codifies comple x patterns within

Some theory and research papers exist that

ma lware that indicates aggregate functions and

discuss the potential benefits of codifying

behaviors. This is the heart of what is missing

complex patterns of functions and behaviors

today.

of malware

Static Malware

An integrated and automated approach to

Most capabilities still exist in manual

Analysis and Runtime

capturing nearly 100% of code coverage of an

dissasemblers and interactive debuggers.

Tracing

analyzed malware object using memory and

No e xisting automated capability to

runtime analysis.

combine memory and runtime data for full

code path resolution.

Be lie f Reasoning and

Using reasoning models, deliver a co mp letely

No e xisting capability to define unknown

Inference Net work

automated capability to analyze malware and

characteristics of malware. Research that

discern behaviors and functions for previously

describes the potential benefits of using

unidentified traits and genomes.

mach ine lea rning and reasoning engines for

ma lware analysis.

II.B Deliverables, Plans, and Capability for technology transition and Commercialization

II.B.1 Deliverables

In the course of this Cyber Genome Project the HBGary Federal team will make regularly scheduled deliveries

to the Government including but not limited to the following:

• Monthly reports detailing current research to include

o Written use cases and investigation plans

o Software architectural diagrams and algorithms

o Source code and executable machine code of prototypes developed

• On a less frequent basis and at DARPA’s direction the team will deliver detailed presentations of work

progress and conduct software prototype demonstrations.

• Research Papers for each of the research areas

• Data and Libraries for Traits and Genomes

• Prototypes for malware object pre-processor, visualization interface, memory and runtime tracing, and

reasoning engine

II.B.2 Plans and Capability to Achieve Commercialization and Technology Transition

HBGary and Pikewerks have track records of commercialization success. They have successfully transitioned

their cyber security software products to the operational environment, as evidenced by hundreds of active

customers. These were developed in part via the Small Business Innovative Research program. If awarded the

contract, we anticipate that promising technologies will emerge from our research that will be desired by bo th

Government and private sector organizations. Where appropriate, we will offer the technologies to the

Department of Defense (DoD), the Intelligence Community (IC) and civilian agencies for further development

and transition to ope rations. But we will not rely on the Government for technology transition. We ant icipate

making signi ficant add itional IRAD investment to convert the results of this contract into commercial grade

software.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - vii

restriction on the title page of this proposal.

II.B.3 Data Rights and Intellectual Property

HBGary has developed two patented technologies that it brings to the table for possible use to fulfill this

requirement -- Digital DNA Sequence and Fuzzy Hash Algorithm. We propose these technologies for possible

use to fulfill this requirement; although it is possible these technologies may end up playing no role in

developing the methodology that DARPA seeks. At the very least, the team will leverage the tremendo us

expe rience gained in de veloping these two technologies. If and to the extent that these two technologies

become deliverables in the resulting contract, HBGary will deliver them with Limited Rights.

(See table

below). To the extent that any mod ifications to these two existing, proprietary technologies need to be made,

HBGary will perform such modifications under pre-existing administrative codes billed to HBGary indirect

accounts, and they will not be charged under the contract.

Table 2: Existing Intellectual Property Table

Assertion of Technic al Data Rights in acc or dance wi th DFARS 252.227-7018

Asserted Rights

Basis for Assertion

Na me of Person Asserting Restrictions

Technical Data Computer Software

Category

To be Furnished With Restrictions

Developed at Private

Bob Slapnik, Vice President HBGary,

Dig ital DNA Sequence

Limited Rights

Expense

Inc.

Developed at Private

Bob Slapnik, Vice President HBGary,

Fuzzy Hash Algorithm

Limited Rights

Expense

Inc.

HBGary Digital DNA™

Developed at Private

Bob Slapnik, Vice President HBGary,

Limited Rights

commercial software (1)

Expense

Inc.

Developed at Private

HBGary Responder™ Professional

Bob Slapnik, Vice President HBGary,

Expense and SBIR,

Limited Rights

commercial software (1)

Inc.

non-severable

Developed at Private

HBGary REcon™ commercial

Bob Slapnik, Vice President HBGary,

Expense and SBIR,

Limited Rights

software (1)

Inc.

non-severable

Developed with mixed

Govern ment Pu rpose

Eure ka

SRI

funding

Rights

(1) Data involved in and related to commercial software products listed above will not be delivered nor do they

need to be delivered to fulfill the requirements of this BAA contract, if awarded, but will be discussed in the

proposal.

Digital DNA Sequence

The digital DNA sequencing engine is a system or method to evaluate any data object received via any device,

network or physical memory ba sed upo n a set of rules (“genome”). The inve ntion evaluates the contents of the

digital object and generates a digital DNA sequence, which permits the data object to be classified into an

object type. A trait has a rule, weight, trait-code, and description. A DDNA sequence is formed by at least one

expressed trait with reference to a particular data object that has been evaluated by the DDNA engine.

Typically, a DDNA sequence is formed by a set of expressed traits with reference to a particular data object that

has been evaluated by the DDN A engine. When a rule fires, then that means that the trait code (or trait) for that

rule has been expressed. In an embodiment of the invention, the traits can be concatenated together as a single

digital file (or string) that the user can easily access.

• Patent application number: 12/386,970

• Inventor name(s): Michael Gregor y Hoglund

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - viii

restriction on the title page of this proposal.

• Assigne e names: HBGary, Inc.

• Filing date: April 24, 2009

• Filing da te of any related provisional app lication: not applicable

• Summary of the patent title: Digital DNA Sequence

HBGary's ownership of the invention is indicated in Reel/Frame 023009/0815 in the Assignment Division of

the US Patent and Trademark O ffice.

Fuzzy Hash Algorithm

An embod iment of the invent ion provide s an algorithm that will generate a fuzzy hash value to ide ntify contents

of a data object and to classify a data object. A digital DNA sequencing engine may be used to execute the

fuzzy hash algorithm. A fuzzy hash value is a calculated sequence of bytes (e.g., hexade cimal bytes). A data

stream is data content of a data ob ject. The algorithm will place meta-tags (i.e., metadata tags) in a buffer,

where a meta-tag corresponds to a value in the data stream. The fuzzy hash value can be calculated against

varied data streams and can then be used to determine the percentage of match between those data streams.

• Patent application number: 12/459,203

• Inventor name(s): Michael Gregor y Hoglund

• Assignee names: HBGary, Inc.

• Filing da te: June 26, 2009

• Filing da te of any related provisional application: not applicable

• Summary of the patent title: Fuzzy Hash Algorithm

HBGary's ownership of the invent ion is indicated in Reel/Frame 023441/0496 in the Assignment Division of

the US Patent and Trademark O ffice.

II.C

Cost, Schedule and Measurable Milestones

for the proposed research, including estimates of cost for each task in each year of the effort delineated by

the prime and major subcontractors, total cost and company cost share, if app licable. Note: Measurable

milestones should capture key development points in tas ks and should be clearly a rticulated and

defined in time relative to start of effort. These milestones should enable and support a decision for the

next part of the effort.

Add itional interim non-critical management milestones are also highly encouraged at

a regular interval.

*Recommend metrics that we strive to achieve in phase 1 and phase 2 in order to demonstrate technological

progress. C ite quantitative and q ualitative success criteria that the propo sed technology will achieve by the time

of each phases program metric measurement, as well as explain how the proposed effort will achieve those

criteria.

Table 3. Program Costs by Company and Year

Company

Phase 1a

Phase 1 b

Phase 2a

Phase 2 b

Total

HBGary Federal

$500,000

$2,000,000

HBGary

$300,000

$400,000

$1,500,000

Pikewe rks

$516,168

$532,654

$548,070

$386,862

$1983,753

SRI

$499,997

$499,925

$999,922

Secure Dec isions

$435,937

$465,727

$801,664

General Dyna mics

$176,971

$188,470

$166,180

$170,920

$702,541

Total

$2,429,073.00

$2,586,776.00

$1,614,250.00

$1,457,782.00

$7,987,880.00

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - ix

restriction on the title page of this proposal.

Table 4. Task Costs by Company and Year

Task

Contr actor

Year

Cost

Success Criteria

Task1

SRI

$499,997

developed techniques for automating unpacking, de-obfuscating, and

mitigating anti-analysis techniques achieved through research.

Pikewe rks

$326,083

Working prototypes and techniques for collecting Linux-based malware in

the wild.

$826,080

SRI

499,925

Developed prototypes that successfully unpack/de-obfuscate, and mit igate

anti-analysis techniques on over 50% of malware employing such techniques

Pikewe rks

229,100

Mature and robust capabilities for collecting Linux-based malware

$729,025

Pikewe rks

$119,227

Enhanced collection methods for Linu x-based malware

Pikewe rks

$89505

Enhanced collection methods for Linu x-based malware

Total Task 1

$1,763,837

Task 2

HBGary Federal

$50,000

Developed database architecture with appropriate schema for storing all

related ma lwa re specimen data, includ ing; object, traits, genomes, analysis

and tracing meta-data, and physiology profile

Total Task 2

$50,000

Task 3

Secure Dec isions

$435,937

Proof-of-concept visualizations of ma lwa re behavior, function, and structure

that enhance understanding and identification of malware characteristics

GDAIS

$26,119

Provide re levant use cases that aid in the development of visualizat ions of

ma lware

$462056

Secure Dec isions

$465,727

Enhanced prototype visualizations of ma lware overall behavior and

functions as well as more detailed views of tra its and patterns that enhance

manual analysis and overall understanding of malware behavior, function,

and intent.

GDAIS

$26789

Provide re levant use cases that aid in the development of visualizat ions of

ma lware

492,516

Total Task 3

$954,572

Task 4

HBGary Federal

Proof-of-concept foundational Windows-based genomes library that can be

applied during malware analysis to identify trait patterns unique to malware

HBGary

Support the successful development of ma lware geno mes (comp le x tra it

patterns: sequences, clusters, conditional)

Pikewe rks

$52,346

Proof-of-concept foundational Linu x-based genomes libra ry that can be

applied during malware analysis to identify trait patterns unique to malware

HBGary Federal

HBGary

Pikewe rks

$119,227

HBGary Federal

HBGary

Pikewe rks

Total Task 4

Task 5

HBGary Federal

$350,000

Proof-of-concept foundational traits library that can be applied during

ma lware analysis to identify and qualify tra its that represent discrete

functions and behaviors in malware

HBGary

$250,000

Support the successful development of ma lware tra its

Pikewe rks

$118,369

Proof-of-concept foundational Linu x-based traits library that can be applied

during malware analysis to identify and qualify traits that represent discrete

functions and behaviors in malware

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - x

restriction on the title page of this proposal.

General

$80,366

Support the successful development of ma lware tra its

Dynamics

HBGary Federal

Prototype malware t raits library that successfully identifies malware d iscrete

behaviors and functions based on trait matches.

HBGary

Support the successful development of ma lware tra its

Pikewe rks

$52,346

Prototype malware Linu x-based traits library that successfully identifies

ma lware d iscrete behaviors and functions based on trait matches.

General

$82,428

Support the successful development of ma lware tra its

Dynamics

HBGary Federal

Mature malware traits library to decrease false positives and increase

accuracy of identification of malware discrete behaviors and functions

HBGary

Support the successful development of ma lware tra its

Pikewe rks

$119.227

Mature malware Linux-based traits library to decrease false positives and

increase accuracy of identification of ma lware d iscrete behaviors and

functions

General

$84,795

Support the successful development of ma lware tra its

Dynamics

HBGary Federal

Mature malware traits library to decrease false positives and increase

accuracy of identification of malware discrete behaviors and functions

HBGary

Support the successful development of ma lware tra its

Pikewe rks

$122,804

Mature malware Linux-based traits library to decrease false positives and

increase accuracy of identification of ma lware d iscrete behaviors and

functions

General

$87,235

Support the successful development of ma lware tra its

Dynamics

Total Task 5

Task 6

HBGary

Pikewe rks

$129,224

HBGary

Pikewe rks

$119,227

HBGary

Pikewe rks

$122,804

Task 7

HBGary Federal

II.D

Technical Rationale, Technical Approach, and Constructive Plan

II.D.1

Technical Rationale

While it is a challenging undertaking, we plan to research and develop a fully automated malware analysis

framework that will produce results comparable with the best reverse engineering experts, and complete the

analysis in a fast, scalable system without human interaction. In the completed mature system, the only hum an

involvement will be the consumption of repor ts and visualizations of malware profiles.

Our app roach is a major shift from common binary and malware analysis toda y, requiring manual labor by

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xi

restriction on the title page of this proposal.

highly skilled and well-paid engineers. Results are slow, unpredictable, expensive and don’t scale. Engineers

are required to be proficient with low- level assembly code and operating system internals. Results depend upon

the ir ability to interpret and mode l complex program logic and ever-changing computer states. The mos t

common too ls are disassemblers for static analysis and interactive debuggers for dynamic analys is. The best

engineers have an ad-hoc collection of non-standard homegrown or Internet-collected plug- ins. Complex

malware protection mechanisms, such as packing, obfuscation, encryption and anti-debugging techniques,

present further challenges that slow down and thwart traditional reverse engineering technique.

We start with the realization that malware is just software in binary form without source code. Like any

software, malware must execute to do what it does. To execute it must reside in physical memory (RAM) and

be operated on by the CPU. The CPU has two requirements: 1) the ope rating instructions of the binary must be

in clear text, and 2) the CPU does only one thing at a time. A binary that is packed or encrypted must unpack or

unencrypt itself; otherwise the CPU will not operate on it.

We will solve the prob lems with traditional reverse engi neering by runni ng the binary in a controlled,

instrumented and automated run trace system that will harvest everything the CPU does, one operation at a time

in sequential fashion. All instructions and d ata will be collected and stored in the exactly the same sequence as

the y occur. Replaying the execution will reprod uce the binary’s behaviors, along with contextual infor mation

about interactions with other digital ob jects. Physical memory can be imaged and automatically reconstructed,

revealing all digital objects in memory at that point in time. The binary can be extracted from the memory

image - typically unpacked and unencrypted - and analyzed statically, along with the context ual infor mation

cont ained within the memory image. From the automated run tracing and memory reconstruction we will have

harvested and collected vast amounts of low-leve l da ta abo ut the binary under test.

We make the assumption that there is a finite set of possible functions and behaviors that software and malware

can have, although it can be a large set as software evolves over time. For example, there are only so many

ways to commun icate over the network, to survive reboot or to write to a file. We will create a set of traits and

genomes that predefine observable functions and behaviors of software and malware. Using a set of rules to

operate on the vast low level data collected from the binary run trace and memory reconstruction, the system

will automatically determine which traits and genomes exist in each binary sample. Over time, this approach

will also be able to determine evolutionary changes in the traits and genomes.

Even though the automated analysis has moved from granular technical data to the higher levels of traits and

genomes, this level of information is insufficient to completely describe the functions, be haviors and intent of

the binary sample. The observed traits and genomes will be fed into the Belief Reasoning engine that uses prior

knowledge to make probabilistic decisions about the binary. The user will be presented with visual

representations of malware physiology profiles.

II.D.2 Technical Approach and Constructive Plan

Fig. 1 illustrates our malware analysis framework, which will allow users to quickly comprehend malware

functions, behaviors and intent in a fully automated system. The system will automatically recognize traits

and genomes to classify and categorize binaries and malware. During the initial phase, traits and genomes will

be developed manua lly, b ut ultimately the mature system will create traits and genomes automatically d uring

later phases based on prior knowledge of malware. The mature system will rely on manua l development of

traits and genomes only as an exception. The low- level data generation will occur using a n iterative static

memory and runtime tracing approach. The three data sets - the Malware Specimen Repos itory, Traits and

Genomes Libraries - will be continually updated with data through the analysis process, to include a resulting

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xii

restriction on the title page of this proposal.

malware physiology profile. The physiology profile will contain mathematical and visual representations of the

malware, as well as a human readable summary of the malware's overall and more detailed behaviors, functions,

and p urpo se.

Fig.1: Cyber Physiology Analysis Frame work

Cybe r Physiology Analysis Frame work:

1. Specimen Collection and Pre-Processing - Subscriptions to malware feeds for updated malware objects.

We also propose to research methods for identifying and collecting emergent malware specimens that are

less common than the traditional Window s binary malware. For Pre-processing, we will research automated

and comprehensive methods for static binary preparation, external analysis, and instrumentation, including:

unpacking, de-obfuscating, reconstructing, removing anti-analysis mechanisms, and discovering

environmental triggers. The goal of this phase is to normalize and prepare malware specimens for

automated memory analysis and runtime tracing.

2. Specimens Repo sitory - The central repos itory for specimen objects, as well as analytical information

collected during pre-processing and the analysis process, with all of the memory data related to the

specimen, low- level data collected during runtime tracing, and the final phys iology profiles. The goa l of

this phase is to create a single malware repos itory that contains sufficient data, organized to improve

malware analysis and incident respo nse capabilities as well as integrate easily with malware lineage

capabilities. HBGary brings an existing malware repository, approximately 500GB of unique malware

samples to start the effort. We will conduct research for data format normalization and standardization for

malware analysis results. Information maintained will include: specimen raw files, hard artifacts, associated

traits and genomes, all low level data recorded through static and runt ime analysis, and a full malware

physiology profile.

3. Specimen Analysis & Visualization Interface (SAVI) - Methodology for streamlined analysis to assist in

identifying new traits and genomes, as well as present malware physiology profiles. Research will focus on

visual representations of malware data to aid in analysis and understanding of malware's functions and

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xiii

restriction on the title page of this proposal.

behaviors and purpose. When there are function and be havior traits or genome sequences that are not fully

understood by the automated system, those are flagged in the malware physiology profile stored in the

specimen repository and scheduled for manual analysis.

4. Traits (Gene) Library - A repository of developed trait rules that represent discrete functions, behaviors, and

intent of software. To best understand the aggregate functions, behaviors, and purpose of malware, we

propose to first identify and understand the discrete expressed parts of malware at their lowest level and

build up, q ualifying t hem in a way that can be classified and mathematically calculated.

5. Genomes Library - A repos itory of identified trait patterns and sequences that express an aggr egated

functionality or behavior. These algorithms and patterns will be used to develop the visual and

mathematical graphs that highlight the malware’s overall function, purpose, severity. The sequences,

ordering, and clustering of traits will suppo rt de velop ment of be havior and function cor relation engi nes and

visual representations based on exhibited traits, including external and environmental artifacts, space and

temporal artifact relationships, and sequencing.

6. Static Memory Analysis and Runtime Tracer (SMART) - Uses a combination of static memory analysis and

runt ime tracing techniques to collect and record as much of the malware internals as pos sible, includ ing

exercising as much of the full execution tree as possible. Our research will foc us on full branch execut ion,

as well as automated analysis and tracing. HBGary and Pikewerks have existing semi-automated

technologies that we can leverage for the research and development in this task.

7. Belief Reasoning Analysis and Inference Node (BRAIN) - We should be able to instrument a Belief

Reasoning Engine to automatically identify mutations within the genomes and classify those mutations to

some degree without any manual analysis. Our research will focus on building the malware behavior and

function inference models to do the automated analysis of malware.

II.E

Detailed Management, Staffing, Organization Chart, and Key Personnel:

As a small business, HBGary Federal has a very simple and streamlined approach to program management,

defining a framework for the research and development with well-defined responsibilities and interfaces for

collaboration, and exchange of information. This includes a detailed research and development schedule. The

program quantitative and qualitative success criteria will be included in the schedule, milestones, and

deliverables, with progress updated regularly in weekly management and technical discussions. The Principle

Investigator is responsible for the overall technical direction of the effort and quality of the technical

deliverables, and as such will lead the technical approach, make decisions on redirection based on research

results measured against the quantitative and qualitative success criteria. The Program Manager is responsible

for the cost and schedule of the effort and works closely with the Principle Investigator to ensure the team is

meeting the technical, quantitative and qualitative goals of the effort within the cost and schedule proposed.

Each of the subcontractor provides an individual respo nsible for leading their areas of respo nsibility within the

project (listed b elow as Key Personnel).

II.E.1 Management

HBGary Federal will manage all project deliverables through a ll execution p hases of this contract and will hold

weekly Technical and Management meetings with the research leads (key personnel) or representative of each

the team members to ensure we are managing cost, schedule and milestones in meeting quantitative and

qualitative success criteria.

II.E.2 Teaming and Staffing

HBGary Federal’s teaming strategy focuses on addressing the hard problems associated with automated

analysis of malwares behavior, function, and intent. Our team offers the companies with the most significant

capabilities to research, develop, and deliver tangible, quantitative and qualitative solutions. This requires

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xiv

restriction on the title page of this proposal.

organizations with extens ive expe rience in malware research, b inary instrumentation, c yber security ope rations

and investigations, computer security productizing, malware analysis products and services, visualization, data

management, and Windows and Linux malware analysis. We are very proud of our team, which we believe

offer the greatest depth and breadth of experience in each of these essential areas of focus.

II.E.3 Organizational Chart

Fig 2. Organizational Chart

II.E.4 Key Personnel

Greg Hoglund, Chief Executive Officer

Proposed Role:

Principal Investigator

Company

HBGary Inc.

Proposed Level of Support:

15%

Location:

Sacramento, California

Greg Hoglund is a world renowned cyber security and Windows internals expert. He architected HBGa ry’s co mmerc ial

cyber security software products Digital DNA, Responder and REcon. He pioneered new technologies to automatically

reverse engineer software binaries fro m with in co mputer me mory and technologies to automatically harvest ma lware

behaviors during its execution. Greg has published many significant works in the cyber security field, including:

Rootk its: Subverting the Windows Kernel; Exploiting Soft ware: How to Break Code; E xploiting Online

Games;Hack ing World of Warcraft: An Exercise in Advanced Rootk it Design; VICE - Catch the

Hook ers!;Runtime Dec ompilation; Exploiting Parsing Vulnerabilities;Application Testing Through Fault Injection

Techniques;Kernel Mode Rootk its; Advanc ed Buffer Overflow Techniques; A *REAL* N T Rootk it, patching the NT

Kernel.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xv

restriction on the title page of this proposal.

He created and documented the first Windows kernel rootkit, owns the rootkit foru m (http://www.rootkit.co m) and created

a popular training program “Offensive Aspects of Rootkit Technology.” Greg has mastery in software design and

development, software reverse engineering, network protocols, network programming, and packet parsing. He is fluent and

highly e xperience with developing Windows device drivers, debuggers and disassemblers. Prior to founding HBGa ry,

Greg was founder and CTO o f Cenzic where he developed Ha ilstorm, a software fau lt in jection test tool.

Aaron Barr, Chief Executive Officer

Proposed Role:

Program Manager

Company

HBGary Federal, LLC.

Proposed Level of Support:

20%

Education:

M.S. Computer Science

Location:

Washington, DC

Aaron Barr has seven years of program management experience at increasing levels of responsibility. Most recently he

was responsible for developing and imp le menting Northrop Gru mman ’s Cyber and SIGINT Systems Business Unit

technical strategy and ensuring quality technical execution on programs. He provided input to key targets and technical

approaches to the LRSP a

 A O P of a $700M organization. His responsibilities included managing a $20M R&D

program across Cyber, SIGINT, Airborne, and Special Access Programs.

Aaron was also the Chief Engineer for Northrop Grumman Corporations cyber security Integration Group, developing the

technical cyber security strategy for the company.

Tom O’Connor, Principle Investigator

Proposed Role:

Research Lead

Company

Pikewerks

Proposed Level of Support:

100%

Education:

B.S. Physics & Computer Science

Location:

Washington, DC

Tom O’Connor has over ten years experience in software development on multiple platforms. Tom has contributed to the

development of software security products in both the government funded research and commercial sectors. After

graduating from Willia m & Ma ry in 1997, he jo ined the research team at Cig ital (formerly Reliable Soft ware

Technologies). At Cigital, he focused on developing source-based software security tools for both C and Java. Results of

Tom's research into using fault injection to identify software security flaws were presented at the 1998 IEEE Symposium

on Security & Privacy. Tom was also involved with Cigital's early Java Security efforts, helping to co-author an appendix

on Java code signing for the 1999 McGraw and Felten “Security Java” book. Prior to joining Pikewerks, Tom spent two

years at Cyveillance working on open source intelligence applications. A main focus for Tom at Cyveillance was scanning

the Internet for compromised credit card and social security numbers on web sites, FTP drop sites used by malware, and

IRC channels used for the sale and exchange of stolen credentials. To m also assisted in operating Cyveillance's monthly

web crawl and inde x of over 100 million doma ins, helping to increase automation and predictability.

Tom's skill set includes development on Microsoft Windows and Linux platforms, in multiple languages such as C, C++,

Java, and Python, and for mu ltiple re lational database systems such as Microsoft SQLServer, MySQL, and IBM DB2.

Kenneth Prole, Project Engineer at AVI/Secure Decisions Inc.

Proposed Role:

Research Lead

Co mpany:

AVI-Secure Dec isions

Proposed Level of Support

25%

Ken Pro le is a Pro ject Engineer at the Secure Dec isions Division of Applied Vis ions, Inc. with e xtensive e xperience in

visualizat ion and informat ion assurance applications. He has over twelve years of e xperience developing visualization

solutions for both government and commercial clients. He is currently leading a DARPA funded SBIR project called

MeerCAT, which visualizes wireless transmitters. This project is being transitioned into use by the DoD through DISA

funding and was selected as a DARPA success story. Ken is also leading the visualization develop ment for the DA RPA

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xv i

restriction on the title page of this proposal.

sponsored National Cyber Range program. Prior to leading the these projects, Ken led large scale government research

projects for DA RPA and the Depart ment of Ho meland Security, applying his e xtensive knowledge in security visualizat ion

and information assurance to help protect the Department of Defense from cyber attacks. Mr. Prole holds a Master’s

degree from Long Island University, C.W. Post and a Bachelor’s degree from Marist College, both in Information

Systems. Ken holds a TS c learance and has a Patent Pending for Multilayer Wireless Network Flow Graph.

Coauthored selected Publications include: “Advances in Topological Vu lnerability Analysis,” in Proceedings of the

Cybersecurity Applications & Technology Conference for Homeland Security 2009; “Wireless Cyber Assets

Discovery Visualization,” in VizSec 2008; and, “A Graph-Theoretic Visualizat ion Approach to Network Risk

Analysis,” VizSec 2008.

Phillip Porras, Program Director of Systems Security Research

Proposed Role:

Research Area Lead

Company

SRI International

Proposed Level of Support:

25%

Education:

M.S. Computer Science

Location:

Menlo Park, California

Phillip Porras is a Progra m Director of systems security research in the Computer Science Laboratory at SRI International,

and has been a Principal Investigator for many research projects sponsored by DARPA, DoD, NSF, NSA, and others. He is

currently a Principal Investigator in a multi-organization NSF research project, entitled “Logic and Data Flow Extraction

for Live and Informed Ma lwa re Execution.” He leads a research project studying malware pandemics on next generation

networks for the Office of Naval Research. He is also the Principal Investigator of a large ARO-sponsored research

program entitled Cyber-TA, which is developing new techniques to gather and analyze large-scale ma lware threat

intelligence across the Internet. Phillip’s most recent research prototype technologies include BotHunter

(http://www.bothunter.net), BLA DE (ww.b lade-defender.org), Highly Predictive Blacklists (http://www.cyber-

ta.org/releases/HPB/), and the Eureka malware unpacking system (eureka.cyber-ta.org). He has been an active researcher,

publishing and conducting technology development in intrusion detection, alarm correlation, malware analysis, active

networks, and wireless security. Previously, he was a manager in the Trusted Computer Systems Department of the

Aerospace Corporation, where he was also an experienced trusted product evaluator for NSA (which includes security

testing, risk assessment, and penetration testing of systems and networks). Phillip has participated on numerous program

committees and editorial boards, and on multiple commercial company technical advisory boards. He holds eight U.S.

patents, and has been awarded Best Paper honors in 1995, 1999, and 2008.

Jason Upchurch, Senior Technical Lead for Intrusions Forensics

Proposed Role:

Research Area Lead

Company

GDAIS

Proposed Level of Support:

25%

Education:

B.S. Computer Science, Regis University, 2007

Location:

Centennial, Colorado

Jason Upchurch has extensive experience as a technical manager and subject matter e xpert in ma lwa re analysis and

intrusion forensics. He is currently a senior technical lead for GDA IS Cyber Systems. He is responsible for leading

incident response and forensics relating to computer intrusions and reports to the Director of Cyber Systems. In addition,

he provides mentoring/coaching to other cyber systems personnel, develops automation techniques for digital forensics,

and provides training both internally and externally on Malware Analysis and Large Dataset Forensics. He has presented at

conferences at the national and international level.

Jason was the technical lead and contract manager for both the Defense Computer Forensics Laboratory (DCFL) Intrusion

Section, to include the ma lwa re analysis unit, and the contract personnel in the Nat ional Cyber Investigative Joint Task

Force (NCIJTF) and the Defense Collaborative Investigative Environment (DCISE). He lead the effort for ma lware

analysis development at the DoD Cyber Crime Center and was the center’s first malware analyst. In these roles he was

instrumental in guiding the process for ma lwa re analysis and cyber intelligence within the DoD LE/ CI co mmun ity. Jason

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xv ii

restriction on the title page of this proposal.

Section III. Detailed Proposal Information

III.A Statement of Work (SOW)

The HBGary Federal Team will execute the Statement of Work in accordance with the Work Breakdown

Structure (WBS) de velope d for the DARPA Cyber Genome (DCG) Program, consisting of the following seven

major Tasks: Task 1 - Specimen Feeds and Pre-processor; Task 2 - Specimen Repos itory; Task 3 - Specimen

Analysis & Visualization Interface; Task 4 - Genomes Library; Task 5 - Traits Library; Task 6 - Static Memory

Analysis and Runtime Tracing; Task 7 - Belief Reasoning and Inference Network.

III.A.1 Program Management

The HBGary Federal Team will use suitable program and subcontract management practices to attain the

technical, cost and schedule goals of the DCG program. We conduct internal technical interchange meetings to

facilitate perfor mance on our programs, with quarterly program reviews and a final review with DARPA at the

conclusion of each phase. Q uarterly reviews will be held at different contractor locations, or with DARPA’s

concurrence, at other facilities to pe rmit demonstrations of incremental system capabilities. The HBGary

Federal team will divide the work according to our strongest competencies and adjust work share appropriately

as the research progresses.

Date

Description

Type

Monthly

Financia l Reports

Document

NLT 30 days

Technical and Financial Plan/Report

Document

EOP

NLT EOP

Software Docu mentation (Design, Instructions, Use)

Document

NLT 3 days EOP

Annual Review

Presentation

EOP

Final Report

Document

III.A.2 SOW Tasks

III.A.2.1

Task 1: Specimen Feeds & Pre-Processor: SRI Lead

Team Member SRI shall provide research and development of techniques for unpacking and de-ob fuscating

malware, as well as identification and remediation of malware trigger and anti-analysis techniques. This

includes developing and refining research papers and prototypes for each of these capabilities.

Team Member Pikewerks shall provide research and de velopment of Linux malware capture capabilities

inc luding ne xt generation honeynets, client-side malware, email-borne malware, and malware embedded in p2p

networks. This will include support for the development of novel and scalable automated unpacking/de-

obfuscation techniques for captured malware.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxiii

restriction on the title page of this proposal.

Table 1. Task 1 - Detailed Task Description and Duration

Date

Effort

Performer

Months 1-12

Establish basis of research for automated unpacking/de-obfuscation of ma lwa re.

SRI

Months 1-12

Establish basis of research for identify ing malic ious logic and anti-analysis

SRI

techniques in malware

Months 12-24

Develop a prototype for automated unpacking/de-obfuscation of a subset of

SRI

packing/obfuscation techniques.

Months 12-24

Research methodologies for automated re mediation of malic ious logic and anti-

SRI

analysis techniques.

Months 24-36

Refine techniques and prototype for automated unpacking/de-obfuscation.

SRI

Months 24-36

Develop a prototype of automated remed iation of ma licious logic and anti-ana lysis

SRI

techniques

Months 36-48

Refine automated re med iation of malic ious logic and anti-analysis prototype

SRI

Months 1-6

Establish basis of research, proof of concept and methodologies for acquiring Linu x-

Pikewe rks

based malware with an emphasis on current specimens.

Months 6-12

Develop prototype(s) for acquiring Linu x-based ma lwa re

Pikewe rks

Months 1-12

Provide support in research and development of automated unpacking/de-obfuscation

Pikewe rks

techniques for Linux-based malware

Months 12-24

Provide support in research and development of automated unpacking/de-obfuscation

Pikewe rks

techniques for Linux-based malware

Months 12-24

Mature prototype capabilities to acquire Linux-based malware in the wild.

Pikewe rks

Months 24-36

Maintain acquisition capability of new Linux-based malware through development of

Pikewe rks

new techniques (honeypots, clients, etc).

Months 36-48

Maintain acquisition capability of new Linux-based malware through development of

Pikewe rks

new techniques (honeypots, clients, etc).

Table 2. Task 1 - WBS Milestones, Completion Criteria and Deliverables

Performer

Planned Date

Milestones, Completion Criteria and Deliverables

Month 12

Deliver research paper and proof of concept for automated unpacking/de-obfuscation

SRI

of binaries and code not mapped to process me mory

Month 12

Deliver a research paper on ma licious logic and anti-analysis techniques.

SRI

Month 24

Deliver updated research paper on refined unpacking/de-obfuscation techniques and

SRI

deliver prototype to cover a subset of high priority/high volume packing/obfuscation

technologies.

Month 24

Deliver a proof of concept and research paper on removal of ma lic ious logic and anti-

SRI

analysis techniques

Month 36

Deliver an enhanced prototype for automated de-obfuscation/unpacking of a la rger

SRI

subset of malware packing/obfuscation techniques

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxiv

restriction on the title page of this proposal.

Month 36

Deliver a full-features prototype and demonstration on malic ious logic and anti-

SRI

analysis techniques with updated research paper.

Month 48

Deliver a fully automated prototype for re moval of ma licious logic and anti-analysis

SRI

techniques with updated research paper.

Month 2

Deliver Linu x-based malware feeds or specimens necessary for the project.

Pikewe rks

Month 6

Deliver research paper and proof of concept for methods to acquire current Linu x-

Pikewe rks

based malware specimens (i.e. honeynets, client capture, email, document, or p2p

embedded.

Month 12

Pikewe rks

Month 24

Pikewe rks

Task 1 Dependencies

Task 1 activities are not dependant on other DCG Tasks..

III.A.2.2

Task 2: Specimen Repository: HBGary Federal Lead

HBGary Federal will develop a specimen repos itory, which will be used to store live malware samples and their

associated metadata.

Table 3. Task 2 - Detailed Task Description and Duration

Date

Effort

Performer

Months 1-3

Develop database schema for storing malware samples and their associated metadata.

HBGary Federal

Design architecture to host the Specimen Repository,

Months 3-4

Imple ment Specimen Repository Database and configure architecture.

HBGary Federal

Months 4-12

Refine database schema to incorporate new knowledge gained through research on

HBGary Federal

other DCG tasks.

Table 4. Task 2 - Milestones, Completion Criteria and Deliverables

Performer

Planned Date

Milestones, Completion Criteria and Deliverables

Month 3

Deliver database design document for Specimen Repository.

HBGary Federal

Month 4

Deliver Specimen Repository software architecture.

HBGary Federal

Month 12

Deliver refined Specimen Repository software architecture.

HBGary Federal

Task 2 Dependencies

Task 2 activities are dependant upo n ob taining sample of malware specimens collected d uring Task 1.

III.A.2.3

Task 3: Specimen Analysis & Visualization Interface: AVI/Secure Decisions Lead

Team MemberAVI/Secure Decisions, supported by GDAIS, will develop visual tools to support the visual

representations of malware traits, sequences, and physiology profiles. These will aid analysts in the

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxv

restriction on the title page of this proposal.

identification of new traits, genomes, and aggregate malware types and unique compositions, and assist in the

understanding of malware’s overall function, behavior and intent through these visual cues.

Table 5. Task 3 - Detailed Task Description and Duration

Date

Effort

Performer

Months 1-6

Define visualization require ments for the analysis of malware functionality and

AVI/Secure

behaviors.

Decisions

Months 7-8

Describe and document an architecture that visualizes ma lwa re functionality and

AVI/Secure

behaviors

Decisions

Months 9-12

Develop visualization prototypes to assist in the analysis of ma lwa re functionality

AVI/Secure

and behaviors.

Decisions

Months 12-24

Integrate and demonstrate progressively mo re co mplete visualizat ion prototypes

AVI/Secure

Decisions

Months 19-21

Define require ments for the visualization of aggregate malware functionality and

AVI/Secure

behaviors (fingerprinting and auto-discovery of characteristics through visual cues.

Decisions

Months 22-23

Describe and document an architecture that visualizes aggregate ma lware

AVI/Secure

functionality and behaviors (fingerprinting and auto-discovery of characteristics

Decisions

through visual cues.

Months 1-12

Provide ma lwa re analysis e xpertise and operational re levance to the developed

GD AIS

analysis interfaces and products developed in phase 1a

Months 12-24

Provide ma lwa re analysis e xpertise and operational re levance to the developed

GD AIS

analysis interfaces and products developed in phase 1b

Table 6. Task 3 - Milestones, Completion Criteria and Deliverables

Performer

Planned Date

Milestones, Completion Criteria and Deliverables

Month 6

Deliver research paper on visualizat ion for analysis of ma lwa re behavior and

AVI/Secure

functions.

Decisions

Month 8

Deliver research paper on visualizat ion architecture and proof of concept for malware

AVI/Secure

functions and behaviors.

Decisions

Month 12

Deliver prototype capability for the visualization of ma lware functionality and

AVI/Secure

behaviors

Decisions

Month 24

Deliver enhanced prototype with fully functional capability to visualize ma lwa re

AVI/Secure

functionality and behaviors.

Decisions

Month 21

Deliver a research paper on the visualization of aggregate ma lwa re functionality and

AVI/Secure

behaviors, including the ability to identify and classify malware based on its visual

Decisions

cues.

Month 23

Deliver research paper on visualizat ion architecture and proof of concept of ma lware

AVI/Secure

aggregate functionality and behaviors.

Decisions

Task 3 Dependancies

Task 3 activities are dependant upon the outputs of Tasks 4,5, and 6.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxv i

restriction on the title page of this proposal.

III.A.2.4

Task 4: Genomes Library: HBGary Federal Lead

HBGary Fede ral will provide research and development of complex, clustered, or sequenced functions and

behaviors (genomes) to fully enumerate and qualify overall malware functions, behavior, and intent.

Table 7. Task 4 - Detailed Task Description and Duration

Date

Effor t

Per for mer

Months 12-24

Establish basis of research for identification and mathemat ical representation of

HBGary

Windows-based malware comp le x, c lustered, or sequenced functions (genomes).

Federal

Months 24-36

Research and develop Windows base genome datasets of linear e xecution space.

HBGary

Federal

Months 36-48

Research and develop more sophisticated Windows genome datasets in linear e xecution

HBGary

space.

Federal

Months 12-48

Provide support to Windows based Genome datasets.

HBGary

Months 12-24

Establish basis of research for identification and mathemat ical representation of linu x-

Pikewe rks

based malware complex, clustered, or sequenced functions (genomes).

Months 24-36

Research and develop base genome datasets of linear e xecution space.

Pikewe rks

Months 36-48

Research and develop more sophisticated genome datasets in linear e xecution space.

Pikewe rks

Table 8. Task 4 - Milestones, Completion Criteria and Deliverables

Planned

Per for mer

Milestone

Date

Month 24

Deliver research paper and proof of concept for enumerating higher level co mple x

HBGary

behaviors and functions (genomes) of Windows-based malware, including techniques and

Federal

mathe matica l mode ls used.

Month 36

Deliver W indows genomes library

HBGary

Federal

Month 48

Deliver a more e xtensive Windows genomes library

HBGary

Federal

Month 24

Deliver research paper and proof of concept for enumerating higher level co mple x

Pikewe rks

behaviors and functions (genomes) of linux-based malware, including techniques and

mathe matica l mode ls used.

Month 36

Deliver geno mes lib rary

Pikewe rks

Month 48

Deliver a more e xtensive genomes libra ry

Pikewe rks

Task 4 Dependencies

Task 4 Genome Library activities are dependant upon Task 5 Traits Library and the output of Task 6.

III.A.2.5

Task 5: Traits Library: HBGary Federal Lead

HBGary Fede ral will conduct research and de velop a malware traits library for the purpo ses of identifying and

qualifying malware discrete functions and be haviors that will be used as the building blocks for evaluating

malware function, behavior, and intent. This will include research and development of toolmarks and latent

artifacts within linux executables that can reveal information about the environment when developed and

compiled.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxv ii

restriction on the title page of this proposal.

Table 9. Task 5 - Detailed Task Description and Duration

Date

Effort

Performer

Months 1-12

Establish basis of research for identification and mathematical representation of

HBGary

Windows-based malware behavior and function (traits).

Federal

Months 12-24

Research and develop simple traits datasets of Windows linear execution space.

HBGary

Federal

Months 24-36

Research and develop complex traits datasets of Windows linear execution space.

HBGary

Federal

Months 1-36

Provide support to Windows based Trait development.

HBGary, Inc.

Months 1-12

Establish basis of research for identification and mathematical representation of

Pikewerks

linux-based malware behavior and function (traits).

Months 12-24

Research and develop simple traits datasets of linear execution space.

Pikewerks

Months 24-36

Research and develop complex traits datasets of linear execution space.

Pikewerks

Months 1-48

Provide 400 hours of support to HBGary Federal in the development of malware

GD AIS

traits.

Table 10. Task 5 - Milestones, Completion Criteria and Deliverables

Planned

Performer

Milestones, Completion Criteria and Deliverables

Date

Month 12

Deliver research paper on methodology for Windows-malware function

HBGary

enumeration including mathematical language and models used to qualify traits

Federal

Month 24

Deliver foundational Windows traits library

HBGary

Federal

Month 36

Deliver complex Windows traits library

HBGary

Federal

Month 12

Deliver research paper on methodology for Linux-malware function enumeration

Pikewerks

including mathematical language and models used to qualify traits

Month 24

Deliver foundational traits library

Pikewerks

Month 36

Deliver complex traits library

Pikewerks

Task 5 Dependencies

Task 5 activities are dependant upon Task 6.

III.A.2.6

Task 6: Static Memory Analysis & Runtime Tracing: HBGary Inc. Lead

HBGary will conduct research and develop automated methods to exercising Linux-based malware full

execution paths for the purposes of providing a complete analysis of malware behavior, functionality, and

intent.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxv iii

restriction on the title page of this proposal.

Table 11. Task 6 - Detailed Task Description and Duration

Date

Effort

Performer

Months 12-24

Establish basis of Windows research and methodology for using static and dynamic

HBGary

analysis to discern variables required for greater function tree execution

Months 24-36

Develop a Windows proof-of-concept capability to automatica lly identify and e xe rcise

HBGary

variables to achieve greater branch execution coverage

Months 36-48

Develop an enhanced prototype capability to automatically identify and e xe rcise variab les

HBGary

to achieve greater branch execution coverage

Months 12-24

Establish basis of Linu x research and methodology for using static and dynamic ana lysis

Pikewe rks

to discern variables required for greater function tree execution

Months 24-36

Develop a Linu x proof-of-concept capability to automatica lly identify and e xe rcise

Pikewe rks

variables to achieve greater branch execution coverage

Months 36-48

Develop an enhanced prototype capability to automatically identify and e xe rcise variab les

Pikewe rks

to achieve greater branch execution coverage

Table 12. Task 6 - Milestones, Completion Criteria and Deliverables

Planned

Per for mer

Milestones, Completi on Criteria and Deli ver ables

Date

Month 24

Deliver research paper and Windows proof of concept for using static and dynamic

HBGary

analysis to discern variables required for greater function tree execution.

Month 36

Deliver a Windows prototype capability to automatically identify and e xerc ise variab les to

HBGary

achieve greater branch execution coverage

Month 48

HBGary

Month 24

Deliver research paper and Linu x proof of concept for using static and dynamic analysis

Pikewe rks

to discern variables required for greater function tree execution.

Month 36

Deliver a Linu x prototype capability to automat ically identify and e xerc ise variables to

Pikewe rks

achieve greater branch execution coverage

Month 48

Pikewe rks

Task 6 Dependencies

Task 6 activities are not dependant on other DCG Tasks.

III.A.2.7

Task 7: Bayesian Reasoning & Inference Network: HBGary Federal Lead

HBGary Federal will conduct research and develop a belief network mode l that can be trained and used to

classify a malware ob ject into categories. This will require processing a large set of known malware and a large

set of known “clean” app lications and code so that the mode l can reliably judge the intent of a give n binary. A

stochastic approach, such as a Belief inference model, can be matched with the probabilities learned and

weights given to individual traits and be haviors.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxi x

restriction on the title page of this proposal.

Table 13. Task 7 - Detailed Task Description and Duration

Date

Effor t

Per for mer

Months 24-36

Perform research, design and proof of concept development.

HBGary

Federal

Months 36-48

Develop proof-of-concept of belief reasoning capability.

HBGary

Federal

Table 14. Task 7 - Milestones, Completion Criteria and Deliverables

Planned

Per for mer

Milestones, Completi on Criteria and Deli ver ables

Date

Month 36

Deliver research paper, design document and proof of concept demonstration.

HBGary

Federal

Month 48

Deliver de monstration of proof of concept belief reasoning capability.

HBGary

Federal

Task 7 Dependancies

Task 7 activities are dependant upon Task 4, 5, and 6.

III.B Description of the Results

A successful cyberdefense tool must not only offer the needed technical capabilities to identify and isolate

malware, b ut also o ffer the integration, utility and suppor t users expect from commercial tools. HBGary and

Pikewerks have track records of commercialization success. We know the difficulties in technology transition

and commercialization. Software won’t transition very far in government or to the public if it is not of

commercial grade. O ur team knows from experience that it costs considerably more money and effort to

develop commercial grade, production software than R&D prototypes. Q uality software that meets customer

needs do esn’t ensure success alone. Senior marketing a nd sales personnel with proven track records are needed

to take new prod ucts to market. Effective marketing requires messaging that resonates with paying customers,

sales collateral tools, full feature website, trade show presence, conference speaking, case studies, press

releases, press interviews, and strategic alliances. After the sale customers need training classes and ongoing

software maintenance and tech support. Furthermore, strategic commercialization alliances with larger

companies are critical to success. Our team has already begun to discuss eventually co- licensing and reselling

technologies developed as part of this Cyber Genome Program.

III.C Detailed Technical Rationale

The HBGary Federal Team has tremendous experience with leading malware analysis methods, techniques,

and capabilities to draw from to develop successful approaches to the challenges of the cyber genome project.

We will make advances in several state-of-the-art capabilities to create an automated malware system that will

discern good from bad behavior, classify the myriad of possible functions in software, and determine a

specimen’s overall capabilities and purpose.

The first challenge to be addressed is the best method for reliably extracting content from a given specimen for

analys is. There are a few approaches:

• Static Binary Analysis. This is the traditional method of analyzing malware. It relies upon too ls like IDA

Pro and a strong library of specialized tools to unpack/de-obfuscate code to get to analyzable data. One of

the largest negatives for this method is that code packers/obfuscators are usually a step ahead of the

unpackers/de-obfuscators. Another negative is that self- modifying code can be very difficult to analyze.

• Static Memor y Analysis. Image physical memory followed by automated reconstruction of the image

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxx

restriction on the title page of this proposal.

including the operating system, all running programs and overall state of the computer. It is possible that

malware could detect memory imaging is occurring then giving back false information to hide its existence

(but we have seen no evidence of any malware doing this). Once memory is successfully imaged, there is

no t hwarting memory analys is.

• Runtime Analys is. Involves execut ing the spe cimen in a controlled, instrumented, typically virtual

environment, and recording all of the API calls, registry entries, etc. This requires a system that avoids

detection by the binary (anti-debugging tricks). Runt ime analysis is limited to recording behaviors that a

binary exhibits in a small window of time. A large negative is that many potential behaviors are never

called or executed in a binary until specifically requested by an attacker. A negative is that complete

discovery of all code paths may be an intractable problem, either requiring too much processing power or

too much memory/space to solve in a reasonable time frame. A pos itive is that we do n’t have to worry

about packers and obfuscation, but we do have to prevent the binary from detecting that it is in a controlled

environment. Add itionally, this app roach allows for integrating different tools to probe or test malware,

making the overall system more extendable.

We assert the best specimen recording approach involves a combination of all three methods, mixi ng the

information gained from static file and memory analysis with a run-time execution system. This approach will

allow us to identify and mitigate anti-analysis and security techniques, get a true representation of the program

while executing, and recover a more significant amount of code paths.

We have selected a trait (gene) and pattern (genome) approach to discern malware functionality and behavior

because we believe this gives us maximum flexibility in evolving the system as well as the highest level of

fidelity of the compo nents of the specimen. In many cases the traits themselves will likely be neutral, however

the patterns and context exhibited will display malicious or benign behaviors. This approach allows us to

evolve the traits and patterns independently and to more dynamically mature trait and pattern libraries. This

approach should also provide benefit to evolution and lineage. We have experience and capability using this

approach to satisfy more simplified goals of malware detection that are very successful.

Lastly to reach the goa l of true automation you need a system that can learn from existing mode ls and de termine

functionality and behavior of future unidentified malware and its traits and patterns. Fitting within the overall

approach, we believe a Belief Reasoning Engine, like Dempster-Shafer, to be the most appropriate solution to

be developed for this area.

III.D Detailed Technical Approach

We believe the best approach is to start by researching the detailed mechanisms of software and develop a

language and ruleset that accurately qualifies discrete software functions and behaviors, followed by an

aggregate analysis of discrete functions to discern patterns; sequences and clusters of these traits that connote a

higher order of software functionality and behaviors. Part of our research will focus on best methods to

exercise software in an analysis environment to expand our visibility into variable dependent branches in code.

The research will be tied together through a reasoning engine that can make automatic probability decisions on

the behavior and functionality of malware based on historical inference models. The final goal will be to

submit an unknown malware specimen with previously undocumented functions and behaviors and

automatically generate a cyber physiology profile that characterizes the new traits and discerns and describes

the overall function, behavior, and intent of the malware with an easily d igestible visual format. This format we

are calling the Cyber Physiology Profile that will represent bo th the mathematical, visual, and descriptive

characterizations of the specimen.

III.D.1 Specimen Collection and Pre-Processing

Collection methods need to be addressed to ensure we are developing capabilities using the most recent and

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxxi

restriction on the title page of this proposal.

challenging malware specimens available. There are feeds for malware to which we have existing subscriptions

and will research to ensure we have the most relevant data available. In addition we will conduct research and

develop malware harvesters and honeynets to collect malware in the wild not contained in feeds. The challenge

here is in finding or attracting malware that has propagated under the radar enough so as not to have been

detected and collected by one of the feed providers. Variations of honeypo ts have been in existence for many

years on both windows and Linux platforms. Where our research differs is in an integrated approach between

collection and analysis that trains our sensors how to be have in order to maximize new collections.

We propose to research and develop a passive and active collection capability for Linux and Windows-based

malware using virtualized clients and webhosts configured with variations of operating systems, patches, and

services. The passive systems will emulate persistent, commercial web services, while the active systems will

emulate client systems that will browse websites, conduct p2p file transfers, ope n email attachments, and

perform numerous other high-risk activities. The personas of the passive and active systems will receive

periodic updates through scripts that pull from the malware repository ensuring maximum exposure to new

collections.

Increasingly malware employs sophisticated anti-detection and analysis techniques such as; obfuscation,

packing, encryption, and modularization. While conducting malware analysis on running programs alleviates

some of the complexity since binaries to run typically need to be complete, unpacked, and unencrypted, their

are exceptions and there are techniques used by malware authors to try and protect malware from analysis. The

goal of the research in this phase is to investigate methods used to protect malware from detection and analysis

and de velop capabilities that allow automated analysis to continue.

We propose to research and de velop binary evaluation metrics for the pur pos e of assessing the quality of the

unpacked code. The po st unpacking analysis capability will be delivered as an add-on to the Eureka

framework to enable further analysis and classification of malware and will integrate SRI's speculative API

resolution algor ithm to automatically resolve call sites. We will develop additional criteria that determine the

optimal moment for taking a memory snapshot of the running process and recovering the original entry po int.

We will also investigate novel ways of hiding Eureka from being detected by the running binary to avoid

triggering suicide logic and explore snapshot-stitching techniques for dealing with multi-stage packers and

block e ncryption.

As the origin entry po int of windo ws based malware binary is usually not known at the point of unpacking, we

will explore and implement novel strategies to uncover the O EP in the captured memory image of the process.

We will then automatically rewrite the binary's header to set the OEP, rebuild import tables and research

automated techniques for informed reconstruction of malware binaries to enable execution in a manner that

bypasses environment checks and suicide logic. The output from static analysis of malware samples will enable

guided executions of unpacked binaries.

Lastly, we will research and develop automated ways to recognize obfuscated code, identify various obfuscation

steps employed to hinder automated analysis, and systematically employ de-ob fuscation to restore the binary to

an equivalent but un-ob fuscated form. This will inspire new research and de velop ment of advanced and

automated binary rewriting techniques.

III.D.2 Specimen Repository

Each of the phases within the cyber physiology analysis framework collects, analyzes, and outputs some form

of data. It is the data output from each of these phases that interconnects within the rest of the framework. This

being the case the Specimen Repository, while not an advanced area of research, plays a critical role within the

overall effort. The various types of data that will need to be stored include; raw malware objects, specimen

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxxii

restriction on the title page of this proposal.

externals metadata, memory snapshot metadata, runt ime data, cyber physiology profile data. We will develop

mechanisms to check for duplications as well as upda tes to p reviously archived specimen.

Our database implementation will utilize both the database as a central repository for the data collected from the

varying applications and the file system for storing compressed versions of the specimens. We will also

normalize the data stored within the database to provide a system that will eliminate duplicate data, provide

faster access to the available data, as well as provide a means for comparisons and versioning to calculate

possible updates to specimens within the repo sitory.

III.D.3 Specimen Analysis and Visualization Interface (SAVI)

Even in an automated malware analysis system there needs to be a human interface to aid in training the system,

verifying data, and viewing results. Toda y most malware analysis is still a slow and tedious process that

requires highly trained and frequently unavailable reverse engineers and malware analysts to do the work. Even

too ls such as those develope d by the HBGary Federal team that expedite the reverse engineering process and

display information in far more digestible forms stop short of displaying more simplified visual representations

of malware that show at a glance the characteristics of a malware specimen.

We propose to research and develop a Specimen Analysis and Visualization Interface (SAVI), investigating

various representations of malware that can provide information at a glance to the analysts, and allow the

analyst to visualize malware in different ways from an aggregate view drilling down to a more interactive

detailed view. The displays will be interactive in the sense that the analyst will be able to flag code segments,

functions within the graphical view and pull up a more traditional analyst view for further inspection, make

modifications, then revert to the graphical view to see how the changes affected the overall specimen

representation.

Malware analysis based on multiple dimensions, and collection methods can lead to copious amounts of data

that needs to be presented to the operator. We propose to visually represent this copious data using multiple

coordinated views, starting out with a high level overview, and then providing details-on-demand. Figure

#, is an example of a Secure Decision’s developed visualization tool to represent running code. In our approach

we will provide the user with an interface that gui des the analyst’s analysis and d iscovery of traits and pa tterns.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxxiii

restriction on the title page of this proposal.

Figure #. Screenshot showing the contextual information of a running code (top) lined with the software

structure information (bottom)

We will develop prototype visualizations based on factors such as exhibited traits, external and environmental

artifacts, space and temporal artifact relationships, sequencing. This will support the identification and

understanding of functions and behaviors to aid malware analysts in developing new traits and patterns of

significance. They will also de velop visual representations of a Malware’s Physiology Profile to provide visual

fingerprinting capabilities to malware analysts and to provide graphical cues for physiology reports. Figure #, is

an example of a Secure Decisions developed visualization showing class dependencies in software.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxxiv

restriction on the title page of this proposal.

Figure #. iTVO screenshot showing dependencies between classes

This type of representation of traits, pa tterns, and other internal artifacts would b ring efficiency to the malware

analysis process. Secure Decisions has an extensive visualization too lkit that can be leveraged to create novel

visualization for malware analysis. O ur tools and skills have been used to prototype and field a variety of

visualizations for government and commercial cyber defense experts.

III.D.4 Traits Library

At its most fundamental level malware ob jects are a compilation o f discrete functions that do work. In order to

build a capability to automatically analyze malware for aggregate function and behavior we believe you must

first accurately qualify all of its discrete parts. We propose to build a body of knowledge about code (aka,

Traits), for example:

1. Ident ify Usage of API or system calls (WriteFile, RegOpenKey, InternetConnect, libc functions in Linux,

etc.)

2. Identify algorithms in code logic (copy loop, decrypt block, parse string, etc)

3. Identify typical coding structures such as (if/else blocks, do/while loops, class structures, etc)

We propose to research and develop a trait coding system, an example of which is HBGary's existing trait

coding system used to detect the presence of malware, as shown in Fig. #. The existing trait system is

compr ised of the rules, an expression language, and a fuzzy matching system. We will use the existing system

as a basis of research to determine the best methodology for developing a more complete trait coding system for

the purposes of enumerating the low level and high level functions and behaviors for a more sophisticated

analysis of the malware specimen.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxxv

restriction on the title page of this proposal.

Figure x: HBGary's Trait Cod ing System for Detecting Malware

III.D.5 Genomes Library

Using t he traits library we will research and develop a patterns or ge nomes library. While some traits alone can

aid in the detection or identification of potentially malicious activity in code, such as specimen uses a packer,

the traits alone are not enough to determine automatically the aggregate functions and behaviors of a specimen.

For example, some malware might try to elevate privileges, or open up a file and directly after open a network

connection, or try to use obfuscation techniques. In each of these cases there are legitimate programs, even

secur ity programs, which would employ these functions or exhibit this type of behavior. So with traits alone the

best you might be able to develop is a probability based on an aggregate of traits exhibited.

To truly develop a comprehensive view of malware behavior and function takes some analysis of the traits and

the patterns they exhibit in malware. As an example, noticing the following traits in a code sequence:

URLDownloadToF ile(somefile.exe) followed by CreateProcess(somefile.exe). This could be labeled as a

“Download and execute” pattern, and the intent could be identified as “Suspicious”, or the behavior as “Risky”

or “Dangerous”. We propose to research and develop patterns of traits, such as sequencing or clustering, of

good and bad software, to develop strong indicators that can be relied upon during automated analysis. In the

case of sequence patterns, all of the traits need to fall into a particular sequence to flag as true, whereas with a

cluster or grouping patterns they just have to occur in total or occur within certain proximity of each other. A

third example would be patterns that occur within the presence of certain variables.

One model might be to apply the use of the patterns within specific genomes. So the first genome applied

might be a classifier genome. The system would use weight values to de termine if a program is malware. Once

something has been determined as malware, it should be fed into a second genome. The second genome has

trait-codes for all the code idioms used to develop software functions. For example, it would contain traits for

all the ways a developer might code a TCP/IP recv loop. It would also contain all the trait patterns for

malicious behaviors; such as all the ways a develop er might sniff keystrokes. We could call this the lineage

genome.

Finally, using the results from the lineage genome, analysts can develop archetypes, building statistical tools

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxxvi

restriction on the title page of this proposal.

and visualization so that 'colonies' of largely similar malware can be grouped. When a new colony starts to

form in the data-set, we can construct a new archetype to represent it. The archetype will contain the traits from

the lineage genome that are common to most of the colony. Once the archetype has been created, malware can

be automatically classified into the archetype as it comes in. The archetypes are not a genome, b ut a secondary

layer of sorting over the lineage genome. This system should be able to predict upcoming attacks. When new

samples are collected from the wild, they will automatically be classified into an archetype. A sudde n growth

of a new colony would represent a new malware variant that needs to be addressed. Any such outbreak would

soon find a way into DoD and customer networks, so this offers a predictive capability for defense.

Finally, using the results from the lineage genome, analysts can develop archetypes, building statistical too ls

and visualization so that 'colonies' of largely similar malware can be grouped. When a new colony starts to

form in the data-set, we can construct a new archetype to represent it. The archetype will contain the traits from

the lineage genome that are common to most of the colony. O nce the archetype has been created, malware can

be automatically classified into the archetype as it comes in. The archetypes are not a genome, b ut a secondary

layer of sor ting over the lineage genome. This system should be able to predict upcoming attacks. When new

samples are collected from the wild, they will automatically be classified into an archetype. A sudde n growth

of a new colony would represent a new malware variant that needs to be addressed. Any such outbreak would

soon find a way into DoD and customer networks, so this offers a predictive capability for defense.

III.D.6 Static Memory Analysis and Runtime Tracing (SMART)

The SMART system will provide a nearly complete picture of the execution of any piece of software by

combining the data acquired from three primary technologies:

Runtime tracer

Physical memory imaging and reconstruction

Dataflow tracer

Runtime Trace r

The Runtime Tracer is a software tracing system and instrumented data collector capable of sampling and

capturing data while tracing every process and every thread, both usermode and kernel mode, system wide and

in real time. It will capture control and data flow at a single step resolution. Data sampling captures the

contents of registers, the stack, and target buffers of de-referenceable pointers. Symbo ls are resolved for all

known API calls, and when combined with argument sampling, will drastically reduce the time required to gain

program understanding.

The Runtime Tracer’s post-execution debugging is a paradigm shift from traditional interactive live debugging.

While traditional interactive debugging is useful for software development, it is cumbersome when used for

tracing program behavior. Traditional debugging tools are designed for control of software execution, as

opposed to observation only. The reverse engi neer only needs to observe the binary’s behavior and data. The

software under test is recorded during runtime. The analysis takes place later. Unlike traditional debuggers, the

Runtime Tracer can follow multiple processes and trace parent/child process execution. It can also follow a

process injecting a DLL into another process.

The Runtime Tracer operates at a very low level within the system, layering itself directly above the Hardware

Abstraction Layer (HAL) and underneath the Windows kernel to provide complete control over the operating

environment while at the same time maintaining performance levels to trace software in real time. It will not be

bound by dependency on the Windows userland Debugging API and therefore will not be thwarted by malware

anti-debugging tricks. The target software is not modified in any way. No breakpoints are injected. No thread

context is changed. No debugger is attached. Tracing is performed completely external to the process

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxxvii

restriction on the title page of this proposal.

operating environment.

Physical Memory Imaging and Reconstruction

Once the Runtime Tracer completes its runtime data collection, additional low level data can be harvested from

physical memory. SMART will image physical memory (including RAM and pagefile) and reconstruct the

operating system to recover all digital ob jects present in memory at the time of the image snaps hot. Low level

data collected will include executables, processes, drivers, modules, strings, symbols, network sockets, open

files and data buffers. Any digital ob ject can extracted, disassembled and examined down to its hexadecimal

representation in memory. Because all objects and data are recovered they can also be inspected in relation to

each other for contextual information.

Dataflow Tracer

To more fully understand a binary’s functions and behaviors a skilled reverse engineer will “follow the data” to

understand what code blocks operate on it and how. The engineer must emulate or mode l a computer system in

his mind and keep painstakingly detailed and exhaustive notes of ever changing buffer values and data states.

This work can take days or weeks depending on the program’s size and how deeply he seeks to understand its

behaviors.

We propose to develop an automated Dataflow Tracer to reveal complex relationships between code blocks and

data which will take us far beyond low level data collection from runtime tracing and physical memory

reconstruction. Dataflow tracing will associate different code blocks with each other by cross referencing

common data and data derivatives used by code. Suppose code section A uses some data in memory and at a

later time code section B uses the same data. It is very common that code blocks A and B can exist in different

modules or threads while not appearing to be related in the code logic, but the fact that they operate on the same

data establishes a relationship. Let’s look a t a simple example. Suppos e a binary reads in an encrypted

configuration file then later on other code decrypts it to reveal an IP address, which is copied and moved to

another location in memor y and then used to attempt a connection for command and control. By following the

data we can identify the code blocks that touch and operate on it even if the data is in its n^th generation and

morphed multiple times. Dataflow tracing follow and record many data mutations and data movements. Tying

the data together gives a more complete picture.

III.D.7 Belief Reasoning and Inference Node (BRaIN)

So we have an input layer that consists of nodes that are the traits of software. The output layer would consist

of nodes that represent what the software is, i.e. malware, spyware, virus, trojan, safe software, etc.

The DS Dempster-schaffer network would be able to show unknowns by having all of the input nodes having a

high value for unknown. Viewing the internal structure of the belief network will reveal where the logic breaks

down in trying to identify the unknown. For example, if the input layer shows that there is no significant traits

that are discernible then this would indicate that there is a lack of information on this type of software. There

could also be a mid level indicator that would show there is a lack of information on who created this software,

which in turn would fail to identify this as safe software. Basically, the network itself is a too l in preforming

analys is on the da ta. Another approach is to use data mining to correlate the unknowns to potentially knowns.

Research and develop an expert or AI mode l that can be trained and used to classify a malware ob ject into

categories. This will require processing a large set of known malware and a large set of known “clean”

app lications and code so that the mode l can reliably judge the intent of a give n binary. A stochastic approach,

such as a Belief inference model, can be matched with the probabilities learned and weights given to individual

traits and be haviors.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxxviii

restriction on the title page of this proposal.

Belief analysis is better thought of as probability theory. It is a model that can use the probability of events to

calculate the probability of a more complex probability. The simplest examples are usually given as a deck of

cards. The probability of drawing a spade from a normal deck of cards is 13 in 52 or 1 in 4. The probability o f

drawing a second spade is 12 in 51, or 4 in 17 times the probability of drawing the first, 1/4*4/17= 1/17

(0.0588235…). In Belief terms, the unconditional probability of the event (a card being a spade), with no

additional knowledge or events, is 1 in 4. The conditional probability of an event (drawing a second spade),

requires some additional evidence to compute (that we previously drew a spade). Belief probabilities are either

computed analytically, or sampled empirically. Every possible event and potential evidence increases the

complexity of Belief calculations, but is also likely to increase the accuracy and improve the understanding of

the relationship between events and evidence. For our system, we will likely be using empirically sampled

traits and behaviors and conditional probabilities between them to determine the probability of a binary being

malicious or not malicious.

[that was a very simplistic explanation of Belief reasoning, there is a lot more that

could be explained, such as negative information, avoiding circular reasoning, joint probabilities, belief

networks, etc]

Bayes' theorem shows the relation between one conditional proba bility and its inve rse; for example, the

probability of a hypothesis given observed evidence and the probability of that evidence given the hypothesis.

The key idea is that the probability of event A given event B depends not only on the relationship between A

and B but on the absolute probability of A independent of B, and the absolute probability of B independent of

Although Belief networks are often used to represent causal relationships, this need not be the case. A causal

network is a Belief network with an explicit requirement that the relationships be causal. The additional

semantics of the causal networks specify that if a node X is actively caused to be in a given state x, then the

proba bility de nsity function changes to the one of the network obt ained by cutting the links from X's parents to

X, and setting X to the caused value x. Using these semantics, one can predict the impact of external

interventions from data ob tained prior to intervention.

Because a Belief network is a complete model for the variables and their relationships, it can be used to answer

probabilistic queries about them. For example, the network can be used to find out updated knowledge of the

state of a subset of variables when other variables are observed. This process of computing the posterior

sufficient statistic Bayes' theorem to complex problems. The posterior gives a universal for detection

applications, when one wants to choose values for the variable subset, which minimize some expected loss

function, for instance the probability of decision error. A Belief network can thus be considered a mechanism

for automatically app lying Bayes' theorem to complex prob lems.

The most common exact inference method s are: variable elimination, which eliminates the non-observed non-

query variables one by one by distributing the sum over the product; clique tree propagation, which caches the

computation so that many variables can be queried at one time and new evidence can be propagated quickly;

and recursive conditioning, which allows for a space-time tradeoff and matches the efficiency of variable

elimination when enough space is used. All of these method s have complexity that is expo nential in the

network' s treewidth.

The purpos e of the Belief Reasoning Engine is to encode our prior knowledge about traits and genomes and to

provide a mechanism to reason over that prior knowledge when new evidence is collected. The model

construction process involves: identifying the evidence with discriminatory value, collecting that evidence, and

constructing the model. Models for different malware will have some common elements and some unique

elements. The goal for the mode l design is to maximize accuracy and generality. Generality is impor tant so that

each type of malware does not require a unique model, which would increase the effort to build the mode ls and

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xxxix

restriction on the title page of this proposal.

reduces the chances of detecting malware variants.

Demps ter-Shafer theory is a generalization of the Bayesian theory of subjective prob ability; whereas the latter

requires probabilities for each question of interest, Bayesian functions base degrees of belief for one question on

the probabilities for a related question. These degrees of belief may or may not have the mathematical

properties of probabilities; how much they differ depends on how closely the two questions are related. Put

another way, it is a way of representing epistemic plausibility but it can yield answers which contradict those

arrived at using probability theory.

Demps ter-Shafer theory is based on two ideas: obtaining degrees of belief for one question from subj ective

probabilities for a related question, and Dempster's rule for combining such degrees of belief when they are

based on independent items of evidence. In essence, the degree of belief in a proposition depends primarily

upo n the numbe r of answers containing the proposition, and the subjective probability of each answer. Also

contributing are the rules of combination that reflect general assumptions about the data.

In this formalism a degree of belief is represented as a belief function rather than a Belief prob ability

distribution. Probability values are assigned to sets of pos sibilities rather than single events. Beliefs

corresponding to independent pieces of information are combined using Dempster's rule of combination, which

is a generalization of the special case of Bayes' theorem where events are independent. The probability masses

from propositions that contradict each other can also be used to obtain a measure of how much conflict there is

in a system. This measure has been used as a criterion for clustering multiple pieces of seemingly conflicting

evidence around competing hypotheses. One of the computational advantages of the Dempster-Shafer

framework is that priors and conditionals need not be specified, unlike Belief methods, which often use a

symmetry argument to assign prior probabilities to random variables. However, any information contained in

the missing priors and conditionals is not used in the Dempster-Shafer framework unless it can be obtained

indirectly. Demps ter-Shafer theory allows one to specify a degree of ignorance in this situation instead of

being forced to supply prior probabilities, which add to unity.

III.E Comparison with Other Research

While there are many specific challenges related to automated malware analysis there are three main areas of

research that are at the heart of this challenge:

• Trait based analysis of malware

• Increased execution of code paths

• Automated analysis of malware

The majority of trait based analysis capabilities, which are few, focus on providing textual information to the

user on highlighted behaviors identified in an analyzed specimen. UCBerkley’s Anubis Sunbelt Security’s

CWSandbox are probably the best examples of working capabilities in this area. In research there have been

hypothesis made that suggest mathematical models for analyzing behaviors of malware, such as the MIST

model presented in [Trinius, 2009] which describes a high level categorization of malware exhibited behaviors

such as; thread, virtual memory, Winsock and some associated arguments. While this method could be

successful at identifying gross functionality the model lacks a level of detail to be highly capable of determining

to a level of detail malware function, behaviors, and intent. Our approach starts by developing a library of very

detailed, mathematically calculable and human readable traits that describe discrete functions and behaviors of

malware, not in the order of tens of traits but in the order of thousands of traits. The traits library combined

with a patterns library to discern relationships between traits will give us a much higher fidelity capability. The

challenge is the level of detail and understanding required to b uild the libraries is much more significant.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xl

restriction on the title page of this proposal.

Increased execution of code paths has traditionally been accomplished through a combination of static binary

analysis of branch points and brute force attempts using interactive debuggers. There is no existing technology

that exercises branch points effectively. There does exist promising research in taint analysis [Yin, 2009], which

involves instrumenting the system to monitor data flows of known variables as they flow through an executed

binary.

Lastly, completely automated analysis of malware is something that has been research and for which many

whitepapers are written with varying levels of specificity

indicating advantages and disadvantages of the proposed effort.

III.F Previous Accomplishments

The HBGary Federal Team brings signi ficant experience and capabilities directly related to the objectives of the

Cyber Genome Program with many successfully executed contracts in related areas for the Federal Government

and Department of Defense (DoD). To demonstrate our ability to successfully execute a contract under

DARPA’s Cyber Genome Program we have selected one past performance citation from each of the team

members.

III.F.1 HBGary Past Performance

Offeror Name: HBGary and HBGary

Customer Organization: DHS Science and Technology Directorate

Federal

Program Manager:

Address: 1120 Vermont Ave NW 8th Floor, Washington, DC 20528

Douglas Maughan

Phone Number: 202-254-6145

Contracting Officer:

Address: P.O. Box 12924, Fort Huachuca, AZ 85670

Doreen Vera-Cross

Phone Number: 520-533-8993

Contract Type: SBIR Phase II

Contract Value: $975,000

Dec 2007 - Nov 2010

Description of Worked Performed

While most researc hers approach the botnet problem by examining net work traffic, HBGary chose host based

examination bec ause the bot (malware) must reside on the host in memory to execute. Our research focused

on physical mem ory forensics including imaging memory, reconstructing memory and analyzing the recovered

digital objects. Bayesian Reasoning Networks were explored to aut omate and scale the reasoning of security

subject matter experts. Funding was added to research tools for autom ated Windows registry forensics and to

provide training to law enforcement agencies to aid technology transition

Relevance to DCG Technical Area 1

The automated physical memory forensics and Bayesian Reasoning Net works modeling from this contract will

be directly applicable to new research proposed for the Cyber Genome Program.

III.F.2 Pikewerks Past Performance

Offeror Name: Pikewerks

Customer Organization: Air Force Research Laboratory

Program Manager:

Address: 2310 Eighth Street, Bldg 167, Wright-Patterson AFB, OH 45433

Dr. David Kapp

Phone Number: 937-320-9068 x130

Contracting Officer:

Address: 2310 Eighth Street, Bldg 167, Wright-Patterson AFB, OH 45433

Erika Lindsey

Phone Number: 937-255-3379

Contract Type: CPFF

Contract Value: $750,000

PoP: Aug 2008 - Aug 2010

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xli

restriction on the title page of this proposal.

Description of Worked Performed

Anti-Forensics is the art and practice of obscuring data storage, transmission, and execution in such a way that

it remains hidden from even a professional, dedicated examiner. Traditionally, hackers have used anti-forensic

methods as a means of hiding their tools, techniques, and identities from forensic investigators. However, anti-

forensic methodologies can also be adopted for defensive purposes. In particular, Anti-Forensic techniques

have the ability to greatly increase the level of effort required to reverse-engineer malicious code. This is

especially useful when the attacker has full access to the memory, disk, and possibly even the processor of a

computer system running the protection software.

For this effort, Pikewerks has identified a number of anti-forensic research areas that would significantly

enhance the confidentiality and integrity of executable code, data, and cryptographic materials through all

stages of operation: at rest, in transit, and during execution. These areas include novel out-of-band storage and

transmission techniques within Commercial Off The Shelf (COTS) computers, which go beyond the highest

level of access available to an attacker and thus dramatically increase the level of effort required to fully

identify, understand, or reverse-engineer the underlying code. The end goal of this development effort is a

diverse suite of innovative anti-forensic capabilities that can be easily integrated into, and deployed with,

technologies where stealth is critical.

Relevance to DCG Technical Area 1

This effort has resulted in the identification of anti-forensic capabilities that could be employed by

sophisticated malware analysis authors, like the kind the Cyber GNOME Project is expected to engage. This

effort is particularly useful to the DCG effort as it demonstrates the advanced research and development

ongoing within Pikewerks Corporation. For the DCG effort revolutionary methods and techniques must be

employed to analyze sophisticated malware that will in the future likely employ many of the techniques being

studied by Pikewerks. Utilizing this research will assist in developing methods for identifying, analyzing, and

relating sophisticated anti-forensic techniques within malware. The approaches developed include anti-forensic

file system storage techniques, indirect function hooking, memory protection techniques using processor debug

registers, and BIOS-based anti-forensic strategies. As part of the development of these techniques, Pikewerks

has written several kernel modules and custom analysis capabilities for Windows and Linux that both

characterize and detect sophisticated anti-forensic techniques.

III.F.3 GDAIS Past Performance

Offeror Name: GDAIS

Customer Organization: Defense Cyber Crime Center (DC3)

Program Manager:

Address: 911 Elkridge Landing Road, Linthicum, MD 21090

Mike Buratowski

Phone Number: 410-981-0117

Contracting Officer:

Address: 2100 Crystal Drive, Suite 300, Arlington, VA 22202

Jim Hayes

Phone Number: 703-605-3600

Contract Type: T&M

Contract Value: $98M

PoP: Oct 2001 - Feb 2012

Description of Worked Performed

Department of Defense Cyber Crime Center (DC3) is a $126M multi-year T&M contract in support of the Air

Force Office of Special Investigations (AFOSI). Since 2001, the GD Team has been the prime contractor for

the Department of Defense Computer Forensics Laboratory (DCFL). In this capacity, the GD Team has

conducted extensive network intrusion examinations and generated detailed reports documenting the intrusions.

The DCFL, and DoD Cyber Crime Institute (DCCI) all fall under this contract.

Business Relationships & Customer Satisfaction: The GD management team provided the leadership that

organized, planned, and managed the resources for the contract’s major projects. Since careers and legal

convictions are dependent upon our findings, we insist on the highest standards of quality and cross-check. The

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xlii

restriction on the title page of this proposal.

GD Team is tightly integrated with the DC3 workforce of Government and Military personnel and work as

equals in all facets of forensic support. The GD Team provides onsite program management at the DC3 for all

contractor and subcontractor work. The Program Manager manages a staff of 140 personnel consisting of

General Dynamics engineers, technicians, support personnel, and subcontractors. In March 2007, General

Dynamics was awarded a new, 1-year (plus four option years) contract to provide Computer Forensic

Examination support as well as Research, Development, Testing and Evaluation for computer forensic

hardware and software.

Cost, Schedule & Timeliness: The GD Team has exceeded Government expectations by completing over 2,500

examinations, providing expert testimony in over 100 court proceedings (both CONUS and OCONUS), and

serving as the DoD authority on electronic media forensics. DC3 Incident Response Support has experience

with responses involving single system through large networks with enormous data storage capabilities. In its

role, the GD Team has created a Virtual Analysis Environment where various system configurations including

installed software packages and patch levels are already saved as Virtual Machines. The examiner can execute

the known malicious logic within a system that is configured exactly how the compromised system would have

been at the time of an intrusion.

Key Personnel: The GD Team accounts for over 80 percent of the personnel that perform data recovery,

imaging and extraction, and forensic examinations in support of criminal, fraud, counterintelligence, data

recovery, terrorism, and safety investigations in DC3. The team currently consists of 19 Cyber Intelligence

Analysts, 13 Forensic Technicians, 48 Forensic Examiners, 15 Software Developers, and 5 Forensic Managers

that perform casework for DC3.

Relevance to DCG Technical Area 1

This program has provided GDAIS with the operational knowledge and expertise of the latest intrusions and

cyber threats seeing in DoD and Defense Industrial Base networks. In turn, it has provided GDAIS with the

capabilities and knowledge to detect these cyber threats and their artifacts by using many of the forensics and

reverse engineering capabilities within our analysis and R&D team. Since the number of intrusion cases has

increase exponentially at DC3, we had the need to start performing automated behavior analysis and correlation

between malware binaries. Within the DCFL/Intrusions Section, our engineers and computer scientist are

developing a capability to automatically correlate these malicious binaries against malware found in previous

intrusion cases. This is done with the use of IDA Pro and various fuzzy hashing techniques to disassemble the

malicious binaries into individual function and perform correlation against the malware obtained through the

many different intrusion cases. By using open source, freeware, and government sponsored tools they have also

developed a capability to submit malicious binaries to perform automated behavioral analysis. This is the type

of capabilities that together with our vast knowledge of the latest intrusions, GDAIS could leverage and

enhanced for the DARPA Cyber Genome program. From the DCFL/NCIJTF perspective, our intelligence

analysts use the analysis report generated by our DCFL\IA examiners to perform additional correlation against

various events and data. Once this is done, reports and signatures (intrusion indicators) are distributed to the

community. The DCCI R&D team is constantly collaborating with different DoD, academia, and industry

organization to learn about their effort and share tools for addition into our DC3 operations. Many of these

tools are tested and validated by our DCCI T&E team to verify that the results are accurate and reliable.

For technical area one of the DARPA Cyber Genome program, GDAIS, together with their partners, will

employ revolutionary techniques to exploits our collective knowledge and expertise to automatically ingest

these malicious binaries and provide correlation, lineage, and provenance in order to gain a better

understanding of software evolution, detect zero-day malware, and when possible determine attribution.

III.F.4 SRI International

Offeror Name: SRI International

Customer Organization: Army Research Office

Program Manager:

Address: 4300 S. Miami Blvd, Durham, NC 27703

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xliii

restriction on the title page of this proposal.

Cliff Wang

Phone Number: 919-549-4207

Contracting Officer:

Address: P.O. Box 12211, Research Triangle, NC 27709

Kathy Terry

Phone Number: 919-549-4337

Contract Type: Grant

Contract Value: $13.4M

PoP: Jun 2006 - Jul 2010

Description of Worked Performed

Phillip Porras is the Principal Investigator of the Army Research Office sponsored Cyber-TA Project. Cyber-

TA is an ongoing 5-year research project to develop the next-generation of real-time national-scale Internet-

threat analysis technologies. Our team has developed many new sophisticated antimalware and malware

tracking technologies, produced over 50 publications in scientific peer reviewed venues, and has deployed its

technologies widely across DoD and the U.S. Government. The Cyber-TA research project has brought

together many of the world’s most established researchers across the fields of data privacy, cryptography,

malware and intrusion detection research, as well as operational experts in Internet-scale sensor management,

to develop leading edge solutions to the evolving threat of increasingly virulent and wide-spread self-

propagating malicious software. Examples of Cyber-TA research technologies include:

• Eureka - A binary unpacking and decompilation system designed to overcome a broad spectrum of

malware binary logic protection services: http://eureka.cyber-ta.org

• BLADE - A system to immunize Windows platforms from malicious drive-by malware exploits:

http://www.blade-defender.org

• Highly Predictive Blacklists - A link-analysis-based IP blacklist production system for producing high-

quality network blacklists: http://www.cyber-ta.org/releases/HPB/

• BotHunter - A network-based host infection diagnosis system: http://www.bothunter.net/

• Malware Threat Center - A portal for tracking Internet malware threats across the Internet:

http://mtc.sri.com

• Malware Cluster Lab - An example of SRI’s experience in appling malware forensic clustering to

detect malware binary lineage is available at http://cgi.mtc.sri.com/Cluster-Lab/ , and an example of our

ability to conduct a quantifiable comparison of pair-wise binary logic within two malware binary

samples that employ multi-layered packing is available at

http://mtc.sri.com/Conficker/addendumC/HMA_Compare_ConfB2_ConfC/.

A Cyber-TA project overview description is available at: http://www.cyber-ta.org/pubs/IEEE-SnP-Magazine-

Relevance to DCG Technical Area 1

Cyber-TA has provided an ongoing resource for SRI’s Computer Science Laboratory to conduct both breadth

and depth research in understanding and combating the modern Internet crimeware epidemic. Of particular

relevance to DCG is the extensive Cyber-TA research that our team has produced in the area of binary

unpacking, disassembly, decompilation, and deobfuscation. We have demonstrated our advanced deobfuscation

techniques in work such as (http://mtc.sri.com/Conficker/P2P/index.html ), which is to our knowledge the only

published description of the multi-layered obfuscated code base of the Conficker P2P subsystem. An example

of our ability to handle mobile malware binary reverse engineering on non-x86 binaries is available at

http://mtc.sri.com/iPhone/.

III.F.5 AVI/Secure Decisions

Offeror Name: AVI-Secure Decisions

Customer Organization: AFRL / IARPA / NSA

Program Manager:

Address: 525 Brooks Road, Rome, NY 13441

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xliv

restriction on the title page of this proposal.

Walter Tirenin

Phone Number: 315-330-1871

Contracting Officer:

Address: 26 Electronics Parkway, Rome, NY 13441

Rebecca Willsey

Phone Number: 315-330-4710

Contract Type: BAA

Contract Value: $2.3M

PoP: Sep 2005 - Dec 2008

Description of Worked Performed

VIAassist is a visualization framework used by computer security specialists to ensure the security of computer

networks. It was developed to visualize NetFlow data, and is currently used for classified applications by the IC

and being modified for adoption by DHS in US-CERT. In addition to NetFlow data, VIAssist can visualize

intrusion detection and other data sources. VIAssist converts network data into a collection of graphical

representations to make it easier to see patterns and trends. This technique takes advantage of the innate ability

of humans to perceive patterns in pictures that they might otherwise miss when looking at raw data. It provides

IC analysts and cyberdefense personnel with the following capabilities that have enhanced the overall mission,

meeting the performance, cost and schedule criteria.

• Provide workflow continuity & collaboration. Analysts record observations, and shared annotations

allow users to collaborate with colleagues about their findings.

• Provide effective reporting. Through the use of the Report Designer and pre-defined report templates,

VIAssist streamlines report

building for analysts.

• Provide global & detailed

situational awareness. Dual

monitor displays provide a

global, summarized view of

trends, as well as a focused view

of specific incidents.

• Provide multiple views of

the same data. Multiple

coordinated views of the data are

provided to make it easier to

identify anomalies, relationships

and interdependencies between data points.

• Correlate multiple data sources. Using an intermediary data store, integrates with and visualizes

multiple disparate data sources, such as firewall logs, IDS data and NetFlow data.

• Aggregate data. Through the use of Smart Aggregation technology, effectively displays voluminous data

by visually aggregating data into meaningful visualizations with drill-down capability and in so doing,

reduce load on system and response time. .

• Filter data. Through the use of an advanced Expression Builder, filters data based upon various pre-

defined or complex user-defined criteria, allowing analysts to focus on specific data, to the exclusion of

the mass of “noise” that can often obscure security risks.

Relevance to DCG Technical Area 1

Specific technologies developed for VIAssist that support smart data aggregation may be leveraged to assist in

providing compelling and scalable visualizations to support malware analysis.

III.G Place of Performance, Facilities, and Locations

The HBGary Federal team will perform work at their individual office locations. We propos e no classified

work, but will be able to support classified discussions, meetings and briefings at government facilities. Each

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xlv

restriction on the title page of this proposal.

team member has a primary location and may have a secondary location in which they will perform research

and development. A summary listing is provided in Table #.

Company

Location

HBGary Federal

Sacra mento, CA

HBGary

Sacra mento, CA

Pikewe rks

Ale xandria , VA

SRI International

Menlo Park, CA

Secure Dec isions

Northport, NY

General Dyna mics

Centennial, Co

Table #. Description of Facilities

III.H Detailed Support (Including Teaming Agreements)

HBGary Federal has fully executed teaming agreements with following companies for the purposes of preparing

a written proposal for DARPA-BAA-10-36_C yber_Genome and for the execut ion of said contract upo n award

(cop ies of teaming agreements available upon request): HBGary, Inc.; Pikewerks; General Dynamics AIS; SRI

International; and AVI/SecureDecisions.

III.I

Cost, Schedules and Measurable Milestones

including estimates of cost for each task in each year of the effort delineated by the primes and major

subcontractors, total cost, and any company cost share. Note: Measurable milestones should capture key

deve lopment poi nts in tas ks and should be clearly articulated and defined in time relative to start of

effort. These milestones should enable and suppo rt a decision for the next part of the effort. Add itional interim

non-critical management milestones are also highly encouraged at regular intervals.

Where the effort consists of multiple portions that could reasonably be partitioned for purposes of funding,

these should be identified as options with separate cost estimates for each. Additionally, proposals should

clearly explain the technical approach(es) that will be employed to meet or exceed each program metric and

provide ample justification as to why the approach(es) is/are feasible. Note: Tas k descriptions related to the

technical approach and associated technical elements need to be complete and clearly related to satisfying

the prog ram metrics as stated in Section 1.2.1.

Task

Contr actor

Year

Cost

Success Criteria

Task1

SRI

$499,997

Pikewe rks

$326,083

HBGary Federal

SRI

499,925

Pikewe rks

229,100

HBGary Federal

SRI

$543,018

Pikewe rks

$119,227

HBGary Federal

SRI

$557,007

Pikewe rks

$89505

HBGary Federal

Total Task 1

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xlv i

restriction on the title page of this proposal.

Task 2

HBGary Federal

Total Task 2

Task 3

Secure Dec isions

$435,937

GDAIS

$26,119

$462056

Secure Dec isions

$465,727

GDAIS

$26789

492,516

Total Task 3

$954,572

Task 4

HBGary Federal

HBGary

Pikewe rks

$52,346

HBGary Federal

HBGary

Pikewe rks

$119,227

HBGary Federal

HBGary

Pikewe rks

Total Task 4

Task 5

HBGary Federal

HBGary

Pikewe rks

$118,369

General

$80,366

Dynamics

HBGary Federal

HBGary

Pikewe rks

$52,346

General

$82,428

Dynamics

HBGary Fedreal

HBGary

Pikewe rks

$119.227

General

$84,795

Dynamics

HBGary Federal

HBGary

Pikewe rks

$122,804

General

$87,235

Dynamics

Total Task 5

Task 6

HBGary

Pikewe rks

$129,224

HBGary

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xlv ii

restriction on the title page of this proposal.

Pikewe rks

$119,227

HBGary

Pikewe rks

$122,804

Task 7

HBGary Federal

III.J

Data Description

HBGary Federal subscribes to commercial malware feeds and has an existing 500GB unique sample malware

repository that will be used for this effort. We will also acquire new feeds and develop malware harvesters to

find and capture new malware that is not available in the feeds. Collection of new malware will be through

seemingly normal web-based activities. The malware objects are binaries, PDF, documents that are or contain

malware. We will ensure the feeds we subscribe to acquire malware through legal, non- intrusive means.

Section IV. Additional Information

A brief bibliography of relevant technical papers and research notes (published and unpublished) that document

the technical ideas upon which the proposal is based. Copies of not more than three (3) relevant papers can be

included in the submission.

HB Gar y Fe deral, LLC.

3604 Fa ir Oa ks Blvd Bldg B STE 250 Sacra mento, CA 95684

Use or disclosure of data contained on this sheet is subject to the

Page - xlv iii

restriction on the title page of this proposal.

PREFACE

1. Purpose

This publication will ease coordination and improve understanding during multi-

Service operations. A Brevity code is a code which provides no security but which has

as its sole purpose the shortening of messages rather than the concealment of their

content (Joint Publication 1-02).

2. Scope

This publication standardizes air-to-air, air-to-surface, surface-to-air, and surface-to-

surface brevity codes. The scope is limited to those [voice] brevity codes used in multi-

Service operations and does not include words unique to single-service operations. While

not authoritative in nature, all services agree to these brevity code meanings. The

brevity codes have been forwarded for inclusion or modification of current North

Atlantic Treaty Organization (NATO) joint brevity words.

3. Applicability

This publication is intended for air and ground operations personnel at the tactical

level.

4. Implementation Plan

Participating service command offices of primary responsibility (OPRs) will review

this publication, validate the information, and reference and incorporate it in service

and command manuals, regulations, and curricula as follows:

Army The Army will incorporate the TTP in this publication in U.S. Army training

and doctrine publications as directed by the Commander, U.S. Army Training and

Doctrine Command (TRADOC). Distribution is in accordance with initial distribution

number (IDN) XXXXXXX.

Marine Corps. The Marine Corps will incorporate the procedures in this

publication in U.S. Marine Corps training and doctrine publications as directed by the

Commanding General, U.S. Marine Corps Combat Development Command (MCCDC).

Distribution is in accordance with the Marine Corps Publication Distribution System

(MCPDS).

Navy. The Navy will incorporate these procedures in U.S. Navy training and

doctrine publications as directed by the Commander, Navy Warfare Development

Command (NWDC)[I5]. Distribution is in accordance with Military Standard

Requisition and Issue Procedure Desk Guide (MILSTRIP Desk Guide) and Navy

Standing Operating Procedure Publication 409 (NAV SOP Pub 409).

Air Force. The Air Force will validate and incorporate appropriate portions of this

publication’s multi-Service tactics, techniques, and procedures (MTTP) into Air Force

doctrine documents as directed by the Commander, Air Force Doctrine Center (AFDC).

Distribution is in accordance with Air Force Instruction (AFI) 33-360.

Marine Corps PCN: 144 000015 00

c. We encourage recommended changes for improving this publication. Key your

comments to the specific page and paragraph and provide a rationale for each

recommendation. Send comments and recommendations directly to—

Army

U.S. Army Training and Doctrine Command

ATTN: ATDO-A

Fort Monroe, VA 23651-5000

DSN 680-3951 COMM (757) 788-3951

E-mail: doctrine@monroe.army.mil

Marine Corps

Commanding General

U.S. Marine Corps Combat Development Command

ATTN: C42

3300 Russell Road, Suite 318A

Quantico, VA 22134-5021

DSN 278-6233/6234 COMM (703) 784-6234

E-mail: deputydirectordoctrine@mccdc.usmc.mil

Navy

Commander

Navy Warfare Development Command

ATTN: N5

686 Cushing Road

Newport, RI 02841-1207

DSN 948-1164/4189 COMM (401) 841-1164/4189

E-mail: alsapubs@nwdc.navy.mil

Air Force

HQ AFDC/DJ

204 Dodd Blvd, Suite 301

Langley AFB, VA 23665-2788

DSN 574-8091 COMM (757) 764-8091

E-mail: afdc.dj@langley.af.mil

ALSA

ALSA Center

ATTN: Director

114 Andrews Street

Langley AFB, VA 23665-2785

DSN 575-0902 COMM (757) 225-0902

E-mail: alsa.director@langley.af.mil

iii

*FM 3-54.10 (FM 3-97.18)

*MCRP 3-25B

*NTTP 6-02.1

*AFTTP(I) 3-2.5

FM 3-54.10 (FM 3-97.18)

U.S. Army Training and Doctrine Command

Fort Monroe, Virginia

MCRP 2-25B

Marine Corps Combat Development Command

Quantico, Virginia

NTTP 6-02.1

Navy Warfare Development Command

Newport, Rhode Island

AFTTP(I) 3-25

Air Force Doctrine Center

Maxwell Air Force Base, Alabama

June 2003

BREVITY

Multi-Service Brevity Codes

TABLE OF CONTENTS

Page

CHAPTER I SUMMARY OF CHANGES

I-1

NEW TERMS

I-1

DELETED TERMS

I-2

CHANGED DEFINITIONS TO TERMS

I-2

CHAPTER II MULTI-SERVICE BREVITY CODES

II-1

CHAPTER III CATAGORY SYNOPSIS

III-1

GENERAL AIR OPERATIONS

III-1

AIR-TO-AIR

III-3

AIR-TO-SURFACE

III-5

CLOSE AIR SUPPORT

III-5

COMBAT SEARCH AND RESCUE

III-6

LASERS

III-6

BASIC NVD/IR/ILLUMINATION

III-6

DATA LINKS

III-7

JSTARS

III-7

MARITIME AIR OPERATIONS

III-7

BASIC SEAD/SIGINT/EW INTEGRATION

III-8

SURFACE-TO-AIR

III-9

SURFACE-TO-SURFACE

III-9

NATO-SPECIFIC TERMS

III-9

Glossary

Glossary-1

TABLES

Table II-1 KEY

II-1

*This publication supercedes FM 3-97.18, MCRP 3-25B, NTTP 6-02.1 and AFTTP(I) 3-2.5, 1 Feb 2002.

Chapter I

SUMMARY OF CHANGES

1. NEW TERMS

ANYFACE

FLAVOR

POPCORN

ASLEEP

FREEZE BURN

PULSE

ATTACK COMPLETE

FUEL STATE

QUAIL

AWAKE

GADABOUT

RACKET

BAY

GINGERBREAD

RED LIGHT

BEARING

GLOWWORM

REFERENCE

BEANSTALK

GOODWILL

RENO

BLOTTER

GOPHER

RENT

BUDDY LASE/GUIDE

GRIDIRON

REPEAT

BULLRING

HEADBUTT

RUMBA

BUMP

HOOK (descriptor)

SAME

BUTTON

HOUNDOG

SCAN

CAV-OKAY

HUFFDUFF

SEARCHER

CHANNEL

INTRUDER

SET

CHARLIE

KOBOLD

SINGLE

CHECKPRINT

LAME DUCK

SLIPPING

CINDER

LEVEL

SNEAKER

CLAM

LINER

SNOOPER

CLEARED TO ENGAGE

LONG RIFLE

SPOOFER

CLOWN

LOOKING

STARE

CRUISE

MARKPOINT

STOP (abort code)

DANCE

MIKEDUFF

TACTICAL

DANGER CLOSE

MOVE BURN

TIME CHECK

DELTA

NEGATIVE LASER

TRACK NUMBER

DIAMONDS

(system) OKAY

TRACKING

DIRTY

OILFIELD

TRAVEL

DOWN

ORBIT

TROUT

DUFFER

PACMAN

VECTOR

FAKER

PANCAKE

WEAPONS

FAN TACK

PEDRO

WOOF

FEELER

PINNACLE

FERRET

POINT

FLARE

POLAR BEAR

2. DELETED TERMS

AJAX

BIRDDOG

SHORT SKATE

SORT TIDS/TADS

TARGET TIDS/TADS

VERY HIGH

(system) WELL

WINGS LEVEL

I-1

ABORT

Directive call to cease action/attack/event/mission.

ACTION

Directive call to initiate a briefed attack sequence or

maneuver.

(system)ACTIVE

(EW) Referenced emitter is radiating at the stated location

(location/ direction)

or along the stated bearing.

ADD (system/

(EW) Directive call to add a specific (system) or (EOB

category)**

category) to search responsibilities.

ALARM

Directive/informative call indicating the termination of

EMCON procedures. Opposite of SNOOZE.

ALFA CHECK

Request for/confirmation of bearing and range from

requesting aircraft to described point.

ALLIGATOR

Link-11/ TADIL A.

ANCHOR(ED)

1. Informative call to indicate a turning engagement at the

(location)

specified location.

2. Directive call to orbit about a specific point.

3. Refueling track flown by tanker.

ANGELS

Height of friendly aircraft in thousands of feet from mean

sea level (MSL). (NOTE: NATO definition does not specify

MSL or AGL)

ANYFACE*

Friendly GCI/AEW command and control agency when

callsign is not known.

ARIZONA

No anti-radiation missile (ARM) ordnance remaining.

ARM**

CONTACT(s) resulting from target maneuvers exceeding

GROUP criteria.

ASLEEP **

Enemy air defense system is not operating and is not

expected to engage friendly aircraft. Opposite of AWAKE.

AS FRAGGED

Unit or element will be performing exactly as stated by the

air tasking order (ATO).

ATTACK(ING)

(A/S) Directive/(informative) call indicating aircraft are

committed to air-to-surface delivery on a specific ground

target. Direction/bearing from which the weapon will be

coming may be given.

ATTACK COMPLETE**

(A/S) Mandatory call from the attack aircraft to the Joint

Terminal Attack Controller (JTAC) during Type III control

indicating completion of ordnance release. (See also

CLEARED TO ENGAGE)

AUTHENTICATE

To request or provide a response to a coded challenge.

AUTOCAT

Any communications relay using automatic

retransmissions.

II-2

(weapon) AWAY

Release/launch of specified weapon (e.g. BIRDS AWAY,

PIGS AWAY, LONG RIFLE AWAY, etc.) NOTE: Include

launch location in bullseye format and weapons track

direction for PIGS and LONG RIFLE.

AWAKE**

Enemy Air Defense system is operating and may engage

friendly aircraft. Opposite of ASLEEP.

AZIMUTH*

(A/A) A picture label describing two GROUPs separated

laterally.

*GROUP names will be referenced by cardinal

directions. (e.g. NORTH GROUP, SOUTH GROUP, or

EAST GROUP, WEST GROUP) (NOTE: NATO definition

includes two or more GROUPS).

2*.

(S/A) Direction to the threat.

BANDIT

An aircraft identified as an enemy in accordance with (IAW)

theater ID criteria. The term does not necessarily imply

direction or authority to engage.

BANZAI

Informative/directive call to execute launch and decide

tactics.

BASE

Reference number used to indicate such information as

(+/- number)

headings, altitude, fuels, etc.

BAY

[NATO] (EW) Carry out deception plan indicated or in

accordance with previous orders.

BEAD WINDOW

Last transmission potentially disclosed unauthorized

information.

BEAM (w/cardinal

CONTACT stabilized within 70 to 110 degrees of aspect.

direction)*

(NOTE: NATO = 60-120 degrees aspect)

BEANSTALK

[NATO] Information call advising datalink users to check

equipment for spurious tracks.

BEARING (w/sub-

Inner GROUP formation with the trailer displaced

cardinal direction)**

approximately 45 degrees behind the leader.

(system) BENT

System indicated is inoperative. Cancelled by OKAY.

BINGO

Fuel state needed for recovery.

BIRD

Friendly surface-to-air missile (SAM).

BIRD(S) AFFIRM

(S/A) Surface-to-Air informative call indicating a FRIENDLY

unit is able and prepared to engage a specified target with

SAMs. Opposite of BIRD(S) NEGAT.

BIRD(S) NEGAT

(S/A) Surface-to-Air informative call indicating a FRIENDLY

unit is unable to engage a specified target with SAMs.

Opposite of BIRD(S) AFFIRM.

BITTERSWEET**

Notification of possible blue-on-blue (fratricide) or blue-on-

neutral situation relative to a designated track or

FRIENDLY aircraft.

II-3

BLIND

No visual contact with FRIENDLY aircraft/ground position.

Opposite of VISUAL.

BLOTTER

[NATO] (EW) ECM receiver.

BLOW THROUGH

Directive/informative call that aircraft will continue straight

ahead at the merge and not become ANCHORED with

target(s).

BOGEY

A radar or visual air CONTACT whose identity is unknown.

BOGEY DOPE

Request for target information as requested or for closest

GROUP in BRAA (with appropriate fill ins)

BOX

Picture label with GROUPs in a square or offset square

(See CHAMPAGNE and VIC for GROUP names).

BRAA

1. Following information is in a tactical control format

providing target bearing, range, altitude, and aspect,

relative to the specified friendly aircraft.

2.* Request/directive call to switch to tactical BRAA control

format.

BRACKET (direction)

Directive call to maneuver to a position on opposite sides,

either laterally or vertically from the target.

BREAK (direction)

Directive call to perform an immediate maximum

performance 180-degree turn (or as directed) in the

indicated direction.

BREAK AWAY

Tanker or receiver call indicating immediate vertical and

nose/tail separation between tanker and receiver is

required.

BREVITY**

Directive call indicating the radio frequency is becoming

saturated, degraded or jammed and briefer transmissions

must follow. (NOTE: See NATO term ZIPLIP)

BROADCAST

Request/directive call to switch to broadcast control format.

BROKE LOCK

Advisory call regarding loss of radar/IR lock-on.

BRUISER

Friendly air launched anti-ship missile.

BUDDY

(A/S) Request or informative communications to have

(LASE/GUIDE)**

guidance of a weapon from a source other than delivering

aircraft.

BUDDY LOCK

Radar locked to a known friendly aircraft. Normally a

response to a SPIKED or BUDDY SPIKE calls.

BUDDY SPIKE

Friendly aircraft radar lock-on indication on radar warning

(position /heading/alt)

receiver (RWR).

BUGOUT (direction)

Separation from that particular engagement / attack /

operation with no intent to reengage/return.

BULLDOG

(S/S) Friendly surface/submarine launched anti-ship

missile.

II-4

BULLRING

(AIR-MAR) Maritime aircraft patrol zone.

BULLSEYE

An established reference point from which the position of

an object can be referenced by bearing (Magnetic) and

range (NM) from this point.

BUMP/BUMP-UP

(A/S) A climb to acquire line of sight (LOS) to the target or

laser designation.

BURN**

(A/S) Informative call that Gated Laser Illuminator (GLINT)

is being used to provide illumination. Typically employed

by AC-130 to illuminate surface points of interest.

BUSTER

Directive call to fly at maximum continuous speed (military

power).

BUTTON

Radio channel setting.

BUZZER**

Electronic communications jamming. (NOTE: same as

NATO term, CHATTER)

CANDYGRAM**

(EW) Informative call to aircraft that electronic warfare

targeting information is available on a briefed secure net.

CAP/CAPPING

1. Directive call to establish a combat air patrol (CAP) at a

(location)

specified location.

2. Descriptive term for aircraft in a CAP.

CAPTURED

(A/S) Aircrew has acquired and is able to track a specified

surface target with an on-board sensor.

CAV-OK

Cloud and Visibility Okay (pronounced kav-okay). ICAO

term meaning no significant clouds below 5,000 feet,

visibility at least six miles, no precipitation or storms.

CEASE (activity)

Directive to discontinue stated activity; e.g. CEASE

BUZZER, CEASE LASER, etc.

CEASE ENGAGEMENT

(S/A) A fire control order used to direct air defense units to

stop tactical action against a specified target. Guided

missiles already in flight will continue to intercept.

CEASE FIRE

(S/A) Discontinue firing/do not open fire. Missiles in flight

are allowed to continue to intercept; continue to track.

CHAMPAGNE

A picture label of three distinct GROUPs with two in front

and one behind. *GROUP names should be NORTH LEAD

GROUP and SOUTH LEAD GROUP or WEST LEAD

GROUP and EAST LEAD GROUP and TRAIL

GROUP.(MAJOR CHANGE-USN/USMC)

CHANNEL**

Stacked net within a Link 16 Network.

II-5

CHARLIE

1.* (AIR-MAR) The expected landing time on the ship.

2. (AIR-MAR) Directive to land aircraft on ship.

3.* (time in minutes) (AIR-MAR) An advisory call

modifying/delaying the briefed recovery time (e.g.,

CHARLIE TEN).

CHATTERMARK

Directive call to begin using briefed radio procedures to

counter communications jamming.

CHEAPSHOT**

AIM-120 missile data link terminated between high and

medium PRF active.

CHECK (number,

Turn (number) degrees left or right and maintain new

LEFT/RIGHT)

heading.

CHECK FIRING**

(S/S) Directive call to cease firing immediately.

CHECKPRINT (track

1. Request by an Air Defense Commander for unit(s) to

#)**

provide amplifying information on a specified track.

2. Reply/informative to Air Defense Commander followed

by positive track information using format specified in

applicable OPTASK document.

CHERUBS**

Height of a friendly aircraft in hundreds of feet AGL.

(NOTE: NATO definition, when adopted, will not specify

AGL or MSL)

CHICKS

Friendly aircraft.

CLAM

[NATO] (EW) Cease all or indicated electromagnetic

and/or acoustic emissions in accordance with national

instructions and exercise orders. Potential intelligence

collector(s) in area (estimated duration of CLAM hours).

CLEAN

1. No sensor information on non-friendly group of interest.

2. No visible battle damage.

3. Aircraft not carrying external stores.

CLEARED

Response to requested action is authorized. No

engaged/support roles are assumed

CLEARED HOT

Ordnance release is authorized.

CLEARED TO

(A/S) JTAC Type III control clearance. Attack aircraft flight

ENGAGE**

leaders may initiate attacks within the parameters imposed

by the JTAC. Attack platform will provide ATTACK

COMPLETE call to JTAC, indicating completion of

ordnance release.

CLOAK

Directive/informative call to switch from normal/overt

external lighting to covert night vision device (NVD) only

compatible lighting.

CLOSING**

Decreasing in separation.

CLOWN

[NATO] (EW) Deception jammer.

II-6

COLD

1. A descriptive/directive call to initiate a turn in the CAP

away from the anticipated threats.

2. Defined area is not expected to receive fire (enemy or

friendly).

3. Intercept geometry will result in a pass or roll out behind

the target.

COLOR (system/

(EW) Request for information on a type (system) at stated

position)**

location; implies a request for ambiguity resolution. May be

used with datalink data message- COLOR, DATA.

COMEBACK

Directive call to reverse course.

(direction)

COMEOFF (direction)

1. (A/A) Directive call to maneuver as indicated to either

regain mutual support or to deconflict flight paths. Implies

both VISUAL and TALLY.

2.* (A/S) Directive call to maneuver or execute a specific

instruction (e.g., COMEOFF DRY).

COMMIT

Directive call to intercept a GROUP of interest.

COMPOSITION**

Request for number of contacts within a GROUP.

CONFETTI

Chaff lane or corridor.

CONS/CONNING

Descriptive term for nonfriendly aircraft leaving contrails.

CONTACT

1. Sensor contact at the stated position.

2. Acknowledges sighting of a specified reference point.

3.* Individual radar return within a GROUP or ARM.

CONTAINER**

Inner GROUP formation with four CONTACTs oriented in a

square or offset square.

CONTINUE

Continue present maneuver, does not imply a change in

clearance to engage or expend ordnance.

CONTINUE DRY

Continue present maneuver, ordnance release not

authorized. Training use only.

COVER*

Directive/Informative call to assign S/A weapons or

establish an A/A posture that will allow engagement of a

specified track or threat if required.

CRANK (direction)

F-Pole maneuver in the direction indicated; *implies

illuminating target at/near radar GIMBAL limits.

CROSSING**

Descriptive term for when two GROUPs initially separated

in azimuth decrease azimuth separation to pass each

other.

CRUISE

[NATO] Informative or directive call to return to cruise

speed (after BUSTER or GATE).

II-7

CUTOFF

Requests for, or directive to, intercept using cutoff

geometry.

CYCLOPS

Any UAV.

DANCE (column

[NATO] (EW) Shift all lines to COMPLAN (__).

codeword/ designator)

DANGER CLOSE**

(A/S, S/S) Informative call that friendly troops are within

close proximity of the target (determined by the

weapon/munition delivered/fired). NOTE: Specific

DANGER CLOSE distances, assumptions, and procedures

are contained in J-Fire guide.

DASH (#)

Aircraft position within a flight. Use if specific callsign is

unknown.

DATA (object,

Standby for data link message concerning object at stated

position)**

location.

DEADEYE

Informative call by a laser designator indicating the laser

system is inoperative.

DECLARE

Inquiry as to the identification of a specified track(s),

target(s), or correlated GROUP.

DEEP**

Descriptive term used to indicate separation between the

nearest and farthest GROUPs in range in a relative

formation of three or more groups, used to describe a

LADDER, VIC, CHAMPAGNE, BOX.

DEFENSIVE*

Aircraft is under attack, maneuvering defensively, and

unable to ensure deconfliction or mutual support.

DEFENDING

Aircraft is in a defensive position and maneuvering with

(direction)

reference to a surface-to-air threat.

DELOUSE**

Directive call to detect, identify, and engage (if required)

unknown aircraft trailing friendly aircraft.

DELTA(__)(__)

(AIR-MAR) Hold and conserve fuel at altitude and position

indicated during shipboard operations.

DEPLOY

Directive call for the element to maneuver to briefed

positioning.

DETAILS**

Request for modified J-FIRE 9-Line Brief from Joint

Surveillance Target Attack Radar System (Joint STARS).

DIAMONDS

An IR event location

(w/position)** .

DIRTY

Link is not encrypted.

DIVERT

Proceed to alternate base/*mission.

DOLLY

Link-4A/TADIL C.

II-8

(system) DOWN

(EW) Referenced emitter has stopped radiating at the

(location/ direction) **

stated location or along the stated bearing. (NOTE:

DOWN does not mean system destroyed)

DRAG (cardinal

Contact aspect stabilized at 0-60 degrees angle from tail or

direction)

120-180 degrees angle from nose.

DROP(PING)

1. Directive/informative call to stop monitoring a specified

emitter/target and resume search responsibilities.

2. Informative call that fighter has discontinued tracking

responsibility.

3. (TRACK___) Remove the emitter/target from tactical

picture/track stores.

4.*

(EW) Directive call to remove a specific system or EOB

category from search responsibilities.

DUCK

[NATO] Informative/directive call to descend and increase

speed.

DUFFER

(EW) DF equipped unit.

ECHELON (sub-

Fill-in to a picture label describing GROUPs aligned behind

cardinal direction)*

and to the side of the closest GROUP.

ECHO

Positive System M/Mode X (or comparable system) reply.

EMPTY**

(EW) No emitters of interest detected. (NOTE: equivalent to

NATO term, BLANK)

ENGAGE

A fire control order used to direct or authorize units and/or

weapon systems to fire on a designated target.

ENGAGED*

Informative inter-flight call from a fighter maneuvering in the

visual arena (NOTE: NATO definition is, “Descriptive call

indicating maneuvering with intent to kill”)

ESTIMATE

Estimate of the size, range, height, or other parameter of a

specified contact; implies degradation.

EXTEND(ING)

Short-term maneuver to gain energy, distance, or

(direction)

separation, normally with the intent of reengaging.

EYEBALL

1. Fighter with primary visual identification responsibility.

2. EO/IR acquisition of an aircraft. Normally followed by

number of aircraft observed.

FADED

Radar contact is lost on nonfriendly air/surface contact and

any positional information given is estimated.

FAKER

[NATO] A FRIENDLY track acting as a HOSTILE for

exercise purposes.

FAN __ TACK __

[NATO] (EW) Left and right hand edges of jammed sector

are___and___.

FAST*

Target speed is estimated to be 600 - 900 knots /Mach 1 -

1.5 (Note: NATO = 400 knots to 600 knots/Mach 1)

II-9

FATHER

(AIR-MAR) Shipboard TACAN station.

FEELER

[NATO] (EW) Shipborne fire control radar.

FEET WET/DRY

Flying over water/land.

FENCE (IN/OUT)

Set cockpit switches as appropriate before entering/exiting

the combat area.

FERRET

[NATO] (EW) Airborne electronic reconnaissance activity

or aircraft.

FLANK (direction)

CONTACT aspect stabilized at 120 to 150 degrees angle

from tail or 30 to 60 degrees angle from nose.

FLARE(S)

Directive to deploy flares.

FLASH (system)

Temporarily activate specified system for identification

purposes (IFF/afterburner/flare/chaff/etc.).

FLASHLIGHT**

Directive term for helicopter to turn on IR floodlight (pointed

at ground to aid visual acquisition by escort aircraft).

FLAVOR

Visually identified nationality of a contact.

FLOAT

Directive/informative call to expand the formation laterally

within visual limits to maintain radar contact or prepare for

a defensive response.

FLOW (direction)**

Directive call to fly stated heading.

FOX (number)

Simulated/actual launch of A/A weapons. ONE -

Semiactive radar-guided missile. TWO - IR-guided missile.

THREE - Active radar-guided missile.

2nd FOX THREE**

Simulated or actual launch of multiple active radar-guided

missiles on the same target.

FOX THREE (X) SHIP**

Valid missile shot against (x) separate targets (assumes 1

missile per target).

FOX MIKE

VHF/FM radio.

FREEZE BURN**

Directive call to AC-130 to freeze the GLINT position in the

present location.

FRIENDLY

A positively identified friendly aircraft, *ship, or *ground

position.

FUEL STATE (time)**

(AIR-MAR) A helicopter's fuel quantity, expressed in hours

and minutes before having to make a controlled emergency

landing.

FURBALL*

Descriptive/informative call indicating known non-friendly

aircraft and friendly aircraft are in close proximity to each

other. Can be response to a DECLARE request.

(NOTE:

NATO equivalent term is MIX-UP. NATO definition of

FURBALL is,: “A turning fight involving multiple aircraft”)

II-10

GADABOUT (#)

[NATO] Informative call indicating the upper limit of height

sanctuary for fighters in the MEZ. (“GADABOUT 25” means

the upper limit of the height sanctuary is 25,000 feet;

“Gadabout 16 to 24” means the height sanctuary is

between 16,000 to 24,000 feet).

GADGET

Radar or emitter equipment.

GATE

Directive/informative call to fly as quickly as possible, using

after-burner/max power.

GENIE**

(EW) Emitter is employing electronic protection measures.

GIMBAL

Radar target is approaching azimuth or elevation tracking

limits.

GINGERBREAD

Voice imitative deception is suspected on this net.

GLOWWORM

[NATO] Flare dropping aircraft.

GO ACTIVE

Go to briefed frequency agile net.

GO CLEAR

Use unencrypted voice communications.

GO SECURE

Activate encrypted voice communications.

GOGGLE/

Directive call to put on/take off NVDs.

DEGOGGLE**

GOGGLES ON/OFF**

Informative call that NVDs are on/off.

GOODWILL

Informative call indicating the boundary of an active friendly

MEZ.

GOPHER**

A BOGEY that has not conformed to safe passage routing,

airspeed, or altitude procedures. Will only be used when

safe passage or minimum risk routing procedures are part

of an ID matrix.

GORILLA

Large force of indeterminate numbers and formation.

GRANDSLAM

All HOSTILE aircraft of a designated track (or against

which a mission was tasked) are shot down.

GREEN (direction)

Direction determined to be clearest of enemy air-to-air

activity.

GREYHOUND**

Friendly ground attack cruise missile (e.g., TLAM).

GRIDIRON

[NATO] (EW) Jamming signal appears on my PPI scope or

jamming signal prevents determination of range and

bearing_____% of time.

GROUP*

Any number of air contacts within 3 NM in azimuth and

range of each other. (NOTE: NATO definition includes an

altitude discrimination of within 20,000 feet)

GUNS

Reference to A/A or A/S gun engagement.

HANDSHAKE**

Link 16 Air Control NPG initiation between air control unit

and controlled aircraft.

II-11

HARD (direction)

High-G, energy sustaining 180-degree turn (or as directed)

in the indicated direction.

HEADBUTT**

Directive term to fighters /interceptors to immediately divert

a track of interest clear of a restricted or prohibited area.

HEADS UP

Alert of an activity of interest.

HEAVY*

A GROUP known to contain three or more individual

entities. (NOTE: NATO definition: The largest GROUP of

factor BOGEYS/ BANDITS)

HIGH*

CONTACT is greater than 40,000 ft MSL. (NOTE: NATO is

25,000 to 50,000 ft MSL)

HIT(S)

1. Momentary radar return(s).

2. (altitude) (A/A) Indicates approximate target altitude

(e.g., GROUP BULLSEYE 360/10, HITS 15 THOUSAND).

(A/S) Weapons impact within lethal distance.

HOLD DOWN

Directive to key transmitter for DF steer.

HOLD FIRE

(S/A) An emergency fire control order to stop firing on a

designated target, to include destruction of any missiles in-

flight.

HOLDING HANDS

Aircraft in visual formation.

HOLLOW**

Any data link message not received.

HOME PLATE

Home airfield or ship.

HOOK

1. (direction) Directive call to perform an in-place 180-

degree turn.

2. (descriptor)** Datalink directive call to cue sensors to

described A/S point (point of interest, SAM, markpoint, TN,

etc.)

HOSTILE*

A contact identified as enemy upon which clearance to fire

is authorized in accordance with theater rules of

engagement.

NOTE: the above use of hostile is used as a brevity term

for air-to-air, and air-to-surface engagements and should

not be confused with the same term in TADIL and ROE.

NOTE: NATO “HOSTILE” brevity term does not necessarily

constitute authorization to fire. Theater Commander

should specify in ATO SPINS the exact definition of

HOSTILE brevity term for combined operations.

II-12

HOT

1. A descriptive/directive call to initiate a turn in the CAP

toward the anticipated threats.

2. *Defined area is expected to receive fire (enemy or

friendly).

3. (A/S) Ordnance employment intended or completed.

4. CONTACT aspect stabilized at 160-180 degrees angle

from tail or 0 - 20 degrees angle from nose.

5. Intercept geometry will result in passing in front of the

target.

HOTDOG (color)**

Informative/directive call that a friendly aircraft is

approaching or is at a specified standoff distance from the

sovereign airspace of a nation (as defined by national

boundaries or territorial sea and airspace). (Color may

indicate additional standoff distance.) Follow briefed

procedures.

HOTEL FOX

HF radio.

HOUNDOG

[NATO] (A/A) Call made by free fighter indicating that he is

in a position to employ weapons.

HUFFDUFF

[NATO] (EW) HFDF equipment or unit fitted with HFDF

equipment.

HUSKY

Informative call that the AIM-120 is at HPRF active range.

1. Directive call to identify the target.

2. Informative call that identification is accomplished,

followed by type.

IDLE**

Joint STARS call indicating surface vehicles are stationary.

IN (direction)

1. Informative call indicating a turn toward a known threat.

Opposite of OUT.

2.*

(A/S) Entering terminal phase of an air-to-ground

attack. Opposite of OFF.

IN PLACE (direction)**

Perform indicated maneuver simultaneously.

INDIA

Mode IV.

INTERROGATE

Interrogate the designated contact of the IFF mode

indicated.

INTRUDER

An individual, unit or weapon system in or near an

operational or exercise area, which represents the threat of

intelligence gathering or disruptive activity.

JACKAL

Surveillance network participating group (NPG) of Link

16/TADIL J.

JINK

Directive call to perform an unpredictable maneuver to

negate a tracking solution.

II-13

JOKER

Fuel state above BINGO at which separation/bugout/event

termination should begin.

JUDY

(A/A) Aircrew has radar or visual contact on the correct

target, has taken control of the intercept and only requires

situation awareness information; Controller will minimize

radio transmissions.

KILL

1.* Directive call to fire on designated target. (NOTE:

NATO term is ENGAGE)

2. (A/A) In training, an informative call by a fighter to

indicate kill criteria has been fulfilled.

KNOCK IT OFF

In training, a directive call to cease all air combat

maneuvers/attacks/ activities/exercises.

KOBOLD

[NATO] Informative call indicating that a specific friendly

MEZ is not active. (Opposite of OILFIELD).

LADDER

Picture label with three or more groups on the same

azimuth but separated by range. *Group names should be

LEAD GROUP, MIDDLE GROUP, TRAIL GROUP

LAME DUCK

An aircraft in a minor state of emergency.

LASER ON

Directive/informative call to start/acknowledge laser

designation.

LASING**

Informative call indicating that the speaker is firing the

laser.

LAST**

Command and control (C2) term that provides the last

contact altitude from a high fidelity source (fighter radar,

etc.).

LEAD-TRAIL*

Inner GROUP formation of two contacts separated in

range.

LEAKER(S)

Airborne threat has passed through a defensive layer. Call

should include amplifying information.

LEAN (direction)**

Directive/informative call to maneuver in a direction to

avoid the threat. (NOTE: equivalent NATO term is KICK)

LEVEL

(A/A) Inter-flight informative call that contact is co-altitude.

LIGHTS ON/OFF

Directive to turn on/off all exterior lights.

LIGHTBULB**

Directive call for flight to turn all position lights to bright.

LINE ABREAST

Inner GROUP formation of two or more contacts separated

in azimuth.

LINER

[NATO] Fly at speed giving maximum cruising range.

LOCKED

(w/GROUP label) Radar lock-on; SORT is not

assumed.

(w/position) Radar lock-on; correct targeting is not

assumed.

II-14

LONG RIFLE**

(A/S) Friendly, long range A/S missile launch (e.g. AGM-

130, SLAM- ER). See (weapon) AWAY.

LOOKING

Aircrew does not have the ground object, reference point,

or target in sight (opposite of CONTACT).

LOW*

Contact altitude below 10,000 ft MSL. (NOTE: NATO = 500

to 5,000 feet AGL)

LOWDOWN**

A request to provide tactical ground information pertinent to

the mission in a digital bullseye format.

MADDOG

Visual AIM-120 / AIM-54 launch.

MAGNUM (system/

(A/S) Launch of friendly antiradiation missile.

location)

MANEUVER (AZIMUTH

Informative call that specified GROUP is maneuvering in

/RANGE/ ALTITUDE)**

azimuth, range, and/or altitude.

MAPPING

(A/S) Multifunction radar in an A/G mode.

MARK**

1. Used when aircraft passes over pickup zone/landing

zone (PZ/LZ) team.

2. Directive term to record the location of a ground point of

interest.

(S/S) Spotting round (normally white phosphorus [WP]

or illumination on the deck to indicate targets to aircraft,

ground troops, or fire support.

MARKING**

Informative call indicating friendly aircraft is leaving

contrails. (NOTE: NATO term is CONNING)

MARKPOINT**

Datalink non-designated geographic point of interest.

MARSHAL(ING)

Establish(ed) at a specific point.

MEDIUM*

Contact altitude between 10,000 ft MSL and 40,000 ft MSL.

(NOTE: NATO: 5,000’ AGL to 25,000’ MSL)

MERGE(D)

1. Information that friendlies and targets have arrived in the

same visual arena.

2. Informative call indicating radar returns have come

together.

MICKEY

HAVE QUICK time-of-day (TOD) signal.

MIDNIGHT

Informative call advising that C2 radar functions are

unavailable due to degradation. Advisory information is still

available. Opposite of SUNRISE.

MIKEDUFF

[NATO] (EW) MFDF equipment or unit fitted with MFDF

equipment.

MILLER TIME**

(A/S) Informative call indicating completion of air-to-ground

ordnance delivery. Generally used by the last striker in

conjunction with a pre-coordinated egress plan.

II-15

Military reference books and manuals (2009-2023, Volume 1) - page 4