QE83H0p2

1CHAIRMAN OF THE JOINT
2CHIEFS OF STAFF
3MANUAL
4J-6 CJCSM 6510.01B
5DISTRIBUTION: A, B, C, JEL, S 10 July 2012
6CYBER INCIDENT HANDLING PROGRAM
7References: See Enclosure H.
81. Purpose. This manual describes the Department of Defense (DoD) Cyber
9Incident Handling Program and specifies its major processes, implementation
10requirements, and related U.S. government interactions.
112. Cancellation. CJCSM 6510.01A, 24 June 2009, “Information Assurance (IA)
12and Computer Network Defense (CND) Volume I (Incident Handling Program),”
13is canceled.
143. Applicability. This manual applies to the Joint Staff and to Combatant
15Commands, Services, Defense agencies, DoD field activities, and joint and
16combatant activities (hereafter referred to as CC/S/A/FAs).
174. Procedures. See Enclosures A through G.
185. Summary of Changes
19a. Updates manual to include the new mission, processes, and procedures
20of U.S. Cyber Command (USCYBERCOM), the subunified command of U.S.
21Strategic Command (USSTRATCOM).
22b. Updates manual based on Unified Command Plan (UCP) Change 1,
2312 September 2011.
246. Releasability. This manual is approved for public release; distribution is
25unlimited. DoD components (to include the Combatant Commands), other
26federal agencies, and the public may obtain copies of this manual through the
27Internet from the CJCS Directives Home Page--
28http://www.dtic.mil/cjcs_directives.
29Directive Current as of 18 December 20147. Effective Date. This manual is effective immediately.
30Enclosures:
31A-Cyber Incident Handling Program
32B-Cyber Incident Handling Methodology
33C-Cyber Incident Reporting
34D-Cyber Incident Analysis
35E-Cyber Incident Response
36F-Collaboration with Other Strategic Communities
37G-Computer Network Defense Incident Handling Tools
38H-References
39GL-Glossary
40'
41\,'·
42····.f.
432
44CJCSM 6510.018
4510 July 2012CJCSM 6510.01B
4610 July 2012
47i
48DISTRIBUTION
49Distribution A, B, C, and JEL plus the following:
50Copies
51Director, NSA/CSS Threat Operations Center ............................................... 1
52Director of Current Operations, Army Cyber Command................................. 1
53Director of Current Operations, Tenth Fleet................................................... 1
54Director of Current Operations, Marine Forces Cyber Command ................... 1
55Director of Current Operations, 24th Air Force.............................................. 1
56Director of Current Operations, Coast Guard Cyber Command...................... 1
57Director, Army Research Laboratory.............................................................. 1
58Director, High Powered Computing Center Management Office...................... 1
59Director, U.S. Strategic Command J6............................................................ 1
60The office of primary responsibility for the subject directive has chosen
61electronic distribution to the above organizations via e-mail. The Joint Staff
62Information Management Division has responsibility for publishing the subject
63directive to the SIPRNET and NIPRNET Joint Electronic Library (JEL) Web
64sites.CJCSM 6510.01B
6510 July 2012
66ii
67(INTENTIONALLY BLANK)CJCSM 6510.01B
6810 July 2012
69iii
70TABLE OF CONTENTS
71Page
72ENCLOSURE A CYBER INCIDENT HANDLING PROGRAM
73Introduction ...........................................................................................A-1
74Roles and Responsibilities ......................................................................A-3
75Computer Network Defense Overview .....................................................A-5
76Computer Network Defense Services.......................................................A-6
77Computer Network Defense Sustainment Functions ...............................A-6
78ENCLOSURE B CYBER INCIDENT HANDLING METHODOLOGY
79Introduction ...........................................................................................B-1
80Cyber Incident Handling Process and Life Cycle......................................B-3
81Submit Initial Report............................................................................B-14
82Preliminary Response Actions...............................................................B-16
83Cyber Incident Analysis........................................................................B-18
84Response and Recovery ........................................................................B-24
85Post-Incident Analysis ..........................................................................B-28
86First Responder Guidelines...................................................................B-29
87APPENDIX A TO ENCLOSURE B CYBER INCIDENT AND REPORTABLE
88CYBER EVENT CATEGORIZATION
89Introduction ....................................................................................... B-A-1
90Categories .......................................................................................... B-A-1
91Comparison of DoD and Department of Homeland Security (DHS)
92Categories .......................................................................................... B-A-4
93ENCLOSURE C CYBER INCIDENT REPORTING
94Introduction ...........................................................................................C-1
95Reporting Structures..............................................................................C-3
96Operational Reporting Practices............................................................C-12
97Reporting Vehicles................................................................................C-13
98Reporting Timelines..............................................................................C-15
99Reporting Formats................................................................................C-15
100Reporting Considerations .....................................................................C-16
101Exercise Reporting................................................................................C-18
102APPENDIX A TO ENCLOSURE C REPORTING TIMELINES
103Introduction ....................................................................................... C-A-1
104Reporting Timelines............................................................................ C-A-3
105APPENDIX B TO ENCLOSURE C GENERAL CYBER INCIDENT REPORT
106FORMAT
107General Cyber Incident Report Format................................................ C-B-1
108Initial Impact Assessment Matrix........................................................ C-B-5CJCSM 6510.01B
10910 July 2012
110iv
111Page
112APPENDIX C TO ENCLOSURE C CYBER INCIDENT REPORTING DIAGRAMS
113High-Level Overview of Reporting........................................................ C-C-1
114Cyber Event Detected by Installation .................................................. C-C-2
115Cyber Event Detected Within Combatant Command ........................... C-C-3
116Cyber Event Detected by External CND Group.................................... C-C-4
117Cyber Event Detected by Computer Network Defense Services
118Provider............................................................................................ C-C-5
119ENCLOSURE D CYBER INCIDENT ANALYSIS
120Introduction .......................................................................................... D-1
121Cyber Incident Analysis Framework....................................................... D-3
122Computer Forensics Analysis ................................................................ D-3
123System Analysis .................................................................................... D-7
124Malware Analysis .................................................................................D-10
125Network Analysis..................................................................................D-17
126Analysis and Correlation of Cyber Event and Cyber Incident Data ........D-21
127Legal Issues..........................................................................................D-21
128APPENDIX A TO ENCLOSURE D DELIVERY VECTORS
129Introduction ....................................................................................... D-A-1
130Delivery Vector Categories .................................................................. D-A-1
131APPENDIX B TO ENCLOSURE D SYSTEM WEAKNESSES
132Introduction .......................................................................................D-B-1
133Determining Information System Weaknesses.....................................D-B-1
134APPENDIX C TO ENCLOSURE D IMPACT ASSESSMENT MATRIX
135Impact Assessment.............................................................................D-C-1
136Levels of Impact..................................................................................D-C-1
137Determining Technical and Operational Impact ..................................D-C-2
138Cyber Incident Impact Table...............................................................D-C-3
139Cyber Incident and Event Potential Impact .........................................D-C-5
140ENCLOSURE E CYBER INCIDENT RESPONSE
141Introduction ...........................................................................................E-1
142Types of Responses ................................................................................E-1
143Developing and Implementing Courses of Action.....................................E-3
144Recovering Without Performing Technical Analysis .................................E-4
145Containment ..........................................................................................E-5
146Eradication ............................................................................................E-9
147Recovery...............................................................................................E-11
148Post-Incident Activity............................................................................E-13CJCSM 6510.01B
14910 July 2012
150v
151Page
152ENCLOSURE F COLLABORATION WITH OTHER STRATEGIC COMMUNITIES
153Introduction ...........................................................................................F-1
154Operational Cooperation with LE/CI.......................................................F-1
155International Coordination .....................................................................F-4
156Intelligence Community..........................................................................F-5
157Cyber Unified Coordination Group..........................................................F-6
158APPENDIX A TO ENCLOSURE F COORDINATION AND DECONFLICTION
159Introduction ........................................................................................F-A-1
160Types of Operations.............................................................................F-A-1
161APPENDIX B TO ENCLOSURE F INTELLIGENCE SUPPORT TO CYBER
162INCIDENT REPORTING
163Introduction ....................................................................................... F-B-1
164Joint Incident Management System (JIMS) ......................................... F-B-1
165Intelligence Reporting Procedures....................................................... F-B-2
166Product Dissemination ....................................................................... F-B-5
167Writing For Release ............................................................................ F-B-5
168USCYBERCOM “Smart Book” ............................................................ F-B-6
169ENCLOSURE G COMPUTER NETWORK DEFENSE INCIDENT HANDLING
170TOOLS
171Joint Incident Management System (JIMS) ............................................ G-1
172Joint Malware Catalog (JMC)................................................................. G-2
173Cyber Intelligence Analysis Tools ........................................................... G-2
174DoD Protected Traffic List...................................................................... G-3
175DoD Enterprise Incident Sets ................................................................ G-3
176DoD Information Network Deception Projects......................................... G-4
177Cyber Condition (CYBERCON) ............................................................... G-5
178ENCLOSURE H REFERENCES
179GLOSSARY
180PART I—ABBREVIATIONS AND ACRONYMS.........................................GL-1
181PART II—DEFINITIONS.........................................................................GL-5
182FIGURES
183B-1. Cyber Incident Life Cycle ............................................................B-4
184B-2. Relationship of Cyber Incident Handling Phases .........................B-5
185B-3. Detection of Cyber Event(s).........................................................B-8
186B-4. Preliminary Analysis and Identification of Cyber Incidents ........B-12
187B-5. Preliminary Response Actions...................................................B-16
188B-6. Cyber Incident Analysis ............................................................B-18CJCSM 6510.01B
18910 July 2012
190vi
191Page
192B-7. Response and Recovery.............................................................B-25
193B-8. Post-Incident Analysis ..............................................................B-28
194C-C-1. High-Level Overview of Reporting............................................ C-C-1
195C-C-2. Cyber Event Detected by Installation ...................................... C-C-2
196C-C-3. Cyber Event Detected Within Combatant Command ............... C-C-3
197C-C-4. Cyber Event Detected by External CND Group........................ C-C-4
198C-C-5. Cyber Event Detected by CNDSP............................................. C-C-5
199D-1. Cyber Incident Analysis Relationship to Preserving Data and
200Recovering Systems ................................................................. D-2
201D-2. Levels of Depth for Malware Analysis ........................................D-12
202TABLES
203A-1. Computer Network Defense Framework.......................................A-7
204B-1. Relationship of Cyber Incident Handling Process and Ongoing
205Supporting Activities ..................................................................B-7
206B-A-1. Category Precedence............................................................... B-A-1
207B-A-2. Cyber Incident and Reportable Event Categories..................... B-A-2
208B-A-2. Comparison of DoD and DHS Cyber Incident and Cyber
209Event Categories................................................................... B-A-4
210C-1. Reporting Vehicles ....................................................................C-14
211C-A-1. Reporting Timelines................................................................ C-A-2
212C-B-1. General Cyber Incident Report Format.................................... C-B-1
213C-B-2. Initial Impact Assessment....................................................... C-B-6
214D-1. Levels of Analysis for Requesting Malware Analysis...................D-16
215D-A-1. Delivery Vectors Categories .................................................... D-A-1
216D-C-1. Cyber Incident Impact Table...................................................D-C-3
217D-C-2. Technical Impact Examples....................................................D-C-5
218D-C-3. Operational Impact Examples.................................................D-C-7
219F-B-1. NIR Report Format.................................................................. F-B-4CJCSM 6510.01B
22010 July 2012
221A-1 Enclosure A
222ENCLOSURE A
223CYBER INCIDENT HANDLING PROGRAM
2241. Introduction
225a. Purpose
226(1) The Department of Defense maintains a comprehensive cyber
227incident handling program.
228(2) This program ensures an integrated capability to continually
229improve the Department of Defense’s ability to rapidly identify and respond to
230cyber incidents that adversely affect DoD information networks and
231information systems (ISs). It does so in a way that is consistent, repeatable,
232quality driven, measurable, and understood across DoD organizations.
233(3) This enclosure provides requirements and methodology for
234establishing, operating, and maintaining a robust DoD cyber incident handling
235capability for routine response to events and incidents within the Department
236of Defense. Additional guidance for cyber incident handling for a crisis or in
237case of active hostilities will be issued by USCYBERCOM as required.
238b. Background
239(1) DoD information networks, including Defense Industrial Base (DIB)
240networks, face a full range of Internet threats, including advanced and
241persistent threats that can evade commercially available security tools and
242defeat generic security best practices.
243(2) In this dynamic environment, it is critical that those responsible for
244building, operating, defending, maintaining, and ensuring the continuity of
245these information networks maintain a unified and resilient capability to
246minimize the impact of these threats on mission operations. This capability
247must be able to adapt over time to changes in the threat environment.
248(3) The threat from adversaries to DoD information degrades the
249Department of Defense’s ability to maintain current and future warfighting
250capabilities.
251(4) This threat also severely hinders the ability to maintain a high level
252of confidence in net-centric operations relied upon by all levels of personnel,
253from generals to Soldiers on the ground.CJCSM 6510.01B
25410 July 2012
255A-2 Enclosure A
256(5) While this threat cannot be completely eliminated and will likely
257evolve over time, it is crucial to maintain a proactive, progressive, and
258coordinated approach to detecting and responding to cyber events and
259incidents that can adversely affect DoD information networks and ISs.
260(6) Federal agencies are required to have in place cyber incident
261handling mechanisms in accordance with (IAW) the Federal Information
262Security Management Act (FISMA) (reference a) and Appendix III, Office of
263Management and Budget (OMB) Circular No. A-130, “Management of Federal
264Information Resources” (reference b).
265(7) Computer Network Defense Service Providers (CNDSPs)
266(a) The Department of Defense requires Tier II CNDSPs to provide
267three services: (1) protect; (2) monitor, analyze, and detect; and (3) respond
268IAW DoD Instruction (DoDI) O-8530.2, “Support to Computer Network Defense
269(CND)” (reference c).
270(b) These services must be certified, accredited, and sustained at an
271acceptable level of quality for their subscribers.
272(8) The Department of Defense developed the Cyber Incident Handling
273Program to provide specific guidance for CC/S/A/FAs regarding the
274requirements for cyber incident handling and reporting.
275c. Scope
276(1) The Department of Defense is a global presence composed of
277multiple military commands, agencies, organizations, and functions that must
278coordinate, manage, and respond to technology threats, attacks, and
279incidents—any of which could, without proper controls to protect, detect, and
280manage their effects, adversely affect DoD information networks and ISs. It is
281therefore critical that appropriate guidance be developed and disseminated to
282CC/S/A/FAs responsible for effectively and efficiently managing these
283information networks, ISs, and the DIB.
284(2) It is the responsibility of the network defenders and users to ensure
285the security of computing and communication systems for executing successful
286military operations and maintaining the integrity of information within the
287cyber domain and throughout the Department of Defense.CJCSM 6510.01B
28810 July 2012
289A-3 Enclosure A
290(3) This enclosure provides overarching guidance that fosters a shared
291and thorough understanding of how the Department of Defense’s global,
292regional, and local organizations coordinate efforts to positively affect response
293actions.
294(4) Effective response requires consistent and complete end-to-end
295reporting using a framework that enables tactical and strategic analytical
296functions. These functions help to characterize the threat environment and
297support development and implementation of effective countermeasures to
298protect and defend DoD information networks and information. Maintaining
299the availability, confidentiality, and integrity of DoD information networks and
300information to support DoD operations is critical for national security.
301(5) Guidance contained herein will cover the high-level procedures
302related to the Protect, Monitor, Analyze, Detect, and Respond phases of the
303Computer Network Defense (CND) life cycle. It will describe the policies and
304processes required to operate a comprehensive DoD cyber incident-handling
305program. More specific guidance tailored for the individual requirements of
306CC/S/A/FAs will be provided through operation orders (OPORDs), warning
307orders (WARNORDs), fragmentary orders (FRAGOs), tasking orders
308(TASKORDs), or similar command authority orders and directives (reference ff).
309This document is a framework that will be used by DoD entities and
310individuals to provide a unified approach to cyber incident handling to enable
311effective collaboration between and across DoD distributed organizations in a
312way that improves the Department of Defense’s ability to protect and defend
313DoD information networks and information.
3142. Roles and Responsibilities
315a. Joint Staff and CC/S/A/FAs will:
316(1) Comply with DoD Cyber Incident Handling Program responsibilities
317IAW reference d, CJCSI 6510.01, “Information Assurance (IA) and Support to
318Computer Network Defense (CND),” and DoDI O-8530.2 (reference c).
319(2) Document and report events and incidents IAW this manual.
320(3) Ensure Tier II CNDSPs are established or appointed and registered
321with DISA to provide CND services for CC/S/A/FA information networks and
322ISs.CJCSM 6510.01B
32310 July 2012
324A-4 Enclosure A
325(4) Coordinate horizontally and vertically with appropriate
326organizations (e.g., Tiers I, II, and III; law enforcement/counterintelligence
327(LE/CI); and the Intelligence Community (IC)) for cyber incidents.
328(5) Comply with orders and directives (including, but not limited to,
329OPORDS, WARNORDs, FRAGOs, TASKORDs, and other approved order
330formats).
331(6) Include requirements to comply with all portions of this program
332and stipulate its enforcement within DoD information technology (IT)/service
333contracts. CC/S/A/FAs, vendors, contractors, and suppliers must comply
334with the procedures contained in this manual.
335(7) Coordinate with USCYBERCOM, through its Tier II CNDSP, on cyber
336incidents prior to taking action outside the Department of Defense, consistent
337with National Security Presidential Directive 38 and the Trilateral
338Memorandum of Agreement.
339(8) Coordinate with the Defense Intelligence Agency (DIA), National
340Security Agency/Central Security Service Threat Operations Center (NTOC),
341and appropriate DoD agency centers on cyber incidents involving intelligence
342systems prior to coordinating or taking actions outside the Department of
343Defense consistent with Enclosure F.
344b. USSTRATCOM will:
345(1) Direct operation and defense of DoD information networks IAW the
346UCP (reference e).
347(2) Execute cyberspace operations as directed.
348(3) Delineate USCYBERCOM responsibilities to:
349(a) Issue cyber incident or reportable event response orders and
350alerts through USCYBERCOM to the CC/S/A/FAs.
351(b) Coordinate with the IC Incident Response Center (IC-IRC), which
352operates under the authority of the IC Chief Information Officer (CIO), on
353matters relating to the governance, secure operations, and defense of the IC
354networks.CJCSM 6510.01B
35510 July 2012
356A-5 Enclosure A
357(c) Coordinate with the Department of Homeland Security (DHS)
358and other federal agencies for incidents related to cyberspace involving the
359Department of Defense. As appropriate, notify and/or coordinate with the
360United States Computer Emergency Readiness Team (US-CERT) on cyberspace
361incidents.
362(d) Coordinate with USNORTHCOM, National Guard Bureau, and
363USPACOM for cyber incidents that involve the DHS and other federal agencies
364where Defense Support of Civil Authorities is involved.
365(e) Maintain and disseminate DoD intrusion detection system (IDS)
366signature sets for DoD level sensors (Tier I) and provide necessary threat
367information to assist Tier II and Tier III CNDSP organizations developing IDS
368signature sets for their sensors.
369(f) Provide reports (summaries, significant cyber incidents, trends,
370enterprise-wide issues) to the Office of the Secretary of Defense (OSD) and
371Joint Staff through USSTRATCOM and to CC/S/A/FAs as necessary.
3723. Computer Network Defense Overview
373a. Cyber Incident Handling Program. The DoD Cyber Incident Handling
374Program is a component of the overall Computer Network Defense (CND)
375strategy for the Department of Defense. The Cyber Incident Handling Program
376aligns with the three services of CND IAW DoDI O-8530.2 (reference c):
377(1) Protect.
378(2) Monitor, analyze, and detect.
379(3) Respond.
380b. Cyber Incident Handling. To protect the interests of national security,
381cyber incidents must be coordinated among and across DoD organizations and
382sources outside the Department of Defense, such as LE/CI, IC, DIB partners,
383and critical infrastructure and critical infrastructure sector Information
384Sharing and Analysis Centers (ISACs). Where applicable, this document
385attempts to draw relationships among these services to foster a common
386understanding of the process by everyone responsible for directing and
387coordinating cyber incident response efforts.
388c. CND Framework
389(1) CND directs the actions taken, within the Department of Defense, to
390protect, monitor, analyze, detect, and respond to unauthorized activity withinCJCSM 6510.01B
39110 July 2012
392A-6 Enclosure A
393DoD information networks and ISs. CND protection activity employs IA
394principles and security controls, and includes deliberate actions taken to
395modify an assurance configuration or condition in response to a CND alert or
396threat information.
397(2) The Department of Defense is organized into three tiers to conduct
398CND.
399(a) Tier I (Global). This tier provides DoD-wide CND operational
400direction or support to CC/S/A/FAs. Tier I entities include USCYBERCOM as
401a USSTRATCOM subunified command including supporting entities such as
402the Defense Criminal Investigative Organization, NTOC, and appropriate DoD
403LE/CI organizations.
404(b) Tier II (Regional/Theater). Tier II provides DoD component-wide
405operational direction or support and responds to direction from Tier I. Tier II
406includes CC/S/A/FA CNDSPs designated by heads of components to
407coordinate component-wide CND.
408(c) Tier III (Local). Tier III provides local operational direction or
409support and responds to direction from a designated Tier II entity. Tier III
410includes bases, posts, camps, stations, and all entities responding to direction
411from a CC/S/A/FA Tier II CNDSP (e.g., manage and control information
412networks, ISs, and services, either deployed or fixed at DoD installations).
4134. CND Services. As defined in DoDI O-8530.2 (reference c), there are three
414primary CND services: (1) protect; (2) monitor, analyze, and detect; and
415(3) respond.
416a. These services define actions employed to prevent or lessen cyber
417attacks that may disrupt, deny, degrade, destroy, exploit, allow unauthorized
418access to, or facilitate information theft from DoD information networks, ISs, or
419their contents. A fourth area, capability sustainment, reflects actions that the
420CC/S/A/FA or its designated CNDSP must perform to ensure services are
421provided. CC/S/A/FAs must acquire these CND services through service
422relationships with CNDSPs. The CND services are enumerated and illustrated
423in Table A-1 (Computer Network Defense (CND) Framework).
424b. CND Protection Services
425(1) CND protection services include managing DoD’s Cyber Condition
426(CYBERCON) system and creating or enhancing an information network or IS’s
427configuration or assurance posture in response to a CND alert or threat.CJCSM 6510.01B
42810 July 2012
429A-7 Enclosure A
430(2) Protection services are often proactive (e.g., red teaming, subscriber
431protection, and training) and may or may not result from a cyber incident.
432COMPUTER NETWORK DEFENSE FRAMEWORK
433PROTECT MONITOR,
434ANALYZE, AND
435DETECT
436RESPOND CAPABILITY
437SUSTAINMENT
438Vulnerability Scanning
439Support
440CND External
441Assessments
442Malware Protection
443Support
444Subscriber Protection
445Support and Training
446CYBERCON
447Implementation
448Information Assurance
449Vulnerability
450Management (IAVM)
451Network Security
452Monitoring/Intrusion
453Detection
454Attack Sensing and
455Warning (AS&W)
456Indications and Warnings
457(I&W)/Situational
458Awareness
459Incident Reporting
460Incident Response
461Incident Analysis
462MOUs and Contracts
463CND Policies/Procedures
464CND Technology
465Development, Evaluation
466and Implementation
467Personnel Levels and
468Training/Certification
469Security Administration
470CNDSP Information
471Systems
472Table A-1. Computer Network Defense Framework
473c. CND Monitor, Analyze, and Detect Services
474(1) CND monitor, analyze, and detect services provide CND situational
475awareness, attack sensing and warning (AS&W), and indications and warning
476(I&W).
477(2) Multiple communities within the Department of Defense (e.g.,
478network operations, CND services, intelligence, CI, and LE) contribute to
479situational awareness.
480(3) AS&W data gives the Department of Defense the ability to sense
481changes in DoD information networks. AS&W includes the detection,
482correlation, identification, and characterization of a large spectrum of
483intentional unauthorized activity, including an intrusion or attack. It couplesCJCSM 6510.01B
48410 July 2012
485A-8 Enclosure A
486these activities with notification to command and decision-makers so they can
487develop an appropriate response. AS&W is enabled through a managed
488network of intrusion, misuse, and anomaly detection systems, supporting data
489fusion and analysis, diagnostics, long-term trend and pattern analysis, and
490warning communications channels and procedures.
491(4) I&W data gives the Department of Defense the ability to sense
492changes in adversary activities. I&W includes those intelligence activities
493intended to detect and report time-sensitive intelligence information on foreign
494developments that could involve a threat to the United States or allied military,
495political, or economic interests or to U.S. citizens abroad. The IC provides I&W
496for foreign threats from nation states and transnational groups.
497(5) The LE community investigates criminal activity and disseminates
498threat data that may pertain to domestic or foreign individuals and groups who
499constitute threats to the Department of Defense. The CI community conducts
500investigations, collections, operations, functional services, and analysis that
501may result in the dissemination of threat data relative to information gathered
502and cyber activities conducted to protect against espionage, other intelligence
503activities, sabotage, or assassinations by or on the behalf of foreign
504governments or elements thereof, foreign intelligence and security services,
505foreign organizations, foreign persons, or international terrorist activities.
506d. CND Response Services
507(1) CND response services include the actions taken to report, analyze,
508coordinate, and respond to any event or cyber incident for the purpose of
509mitigating any adverse operational or technical impact.
510(2) Cyber incident reporting includes a well-defined framework for the
511timely reporting of any cyber event or incident. The report provides an
512accurate, meaningful, and complete understanding of the cyber incident from
513initial detection to analysis and remediation. This information feeds into the
514User-Defined Operational Picture, which provides local, intermediate, and DoDwide situational awareness of CND actions and their impact.
515(3) Cyber incident analysis identifies several critical elements of an
516incident to determine and characterize its possible effects on DoD information
517networks, operational missions, and other defense programs. This activity
518relies on effective acquisition, preservation, and timely reporting of cyber
519incident data.
520(4) Cyber incident response includes the coordinated development and
521implementation of courses of action (COAs) that focus on containment,
522eradication, and recovery. At the same time, it ensures the acquisition andCJCSM 6510.01B
52310 July 2012
524A-9 Enclosure A
525preservation of data required for tactical analysis, strategic analysis, and/or LE
526investigations.
5275. CND Sustainment Functions. CND sustainment functions are designed to
528ensure the provider continues to provide CND services to all subscribers at an
529acceptable level of quality and are a component of the overall DoD CND
530strategy. They are also an integral part of the CNDSP certification and
531accreditation process per the CNDSP Evaluator Scoring Metrics (v8.0)
532(reference oo), which include:
533a. Eighteen Priority I metrics.
534b. Fourteen Priority II metrics.
535c. Twelve Priority III metrics.
536d. Seven Priority IV metrics.CJCSM 6510.01B
53710 July 2012
538A-10 Enclosure A
539(INTENTIONALLY BLANK)CJCSM 6510.01B
54010 July 2012
541B-1 Enclosure B
542ENCLOSURE B
543CYBER INCIDENT HANDLING METHODOLOGY
5441. Introduction
545a. The methodology described in this section provides a general,
546standardized process that establishes the intent and requirements for
547detecting, analyzing, and responding to information or technology events or
548cyber incidents for the purpose of mitigating any adverse operational or
549technical impact on DoD data, ISs, and information networks.
550b. An effective cyber incident handling capability relies on disciplined
551processes, procedures, and ISs. These must communicate timely, accurate,
552and accessible information about the cyber incident’s cause, impact, and
553current situation to incident responders, command authorities, and others
554involved in directing incident response actions.
555c. Given the diverse, highly distributed, and complex environment in
556which the Department of Defense operates, the means by which CC/S/A/FAs
557implement this methodology may vary depending on the resources, technical
558capabilities, and local policies/procedures provided by the command authority.
559d. It is expected that CC/S/A/FAs will implement and institutionalize the
560guidance, procedures, and policies described in this methodology in a way that
561yields the intended results (as described throughout) and sustains the global,
562regional, and local capabilities necessary to maintain and operate a robust and
563effective cyber incident handling program.
564e. The primary objectives of the cyber incident handling process are to:
565(1) Maintain a robust detection capability to ensure all suspicious
566activity is detected and reported so that further analysis can take place to
567determine if it is a reportable cyber event or incident.
568(2) Ensure the timely reporting of cyber incidents through
569appropriate technical and operational channels in a way that promotes an
570accurate, meaningful, and comprehensive understanding of the cyber incident
571throughout its life cycle.
572(3) Effectively contain events and incidents and isolate ISs to
573minimize any damage or impact to DoD information networks, ISs, data, and
574services.CJCSM 6510.01B
57510 July 2012
576B-2 Enclosure B
577(4) Safely acquire and preserve the integrity of data required for
578cyber incident analysis to help determine the technical/operational impact,
579root cause(s), scope, and nature of the cyber event or incident.
580(5) Ensure the effective coordination and communication of cyber
581incident information through appropriate channels and with appropriate
582stakeholders, higher CND organizations, and/or CC/S/A/FAs’ headquarters
583(HQ).
584(6) Provide an effective and comprehensive response that includes
585the recovery of any affected ISs and the return to a fully functioning, secure,
586operational state for all services and ISs.
587(7) Identify lessons learned to help improve infrastructure
588component protection strategies and cyber incident handling procedures to
589prevent a recurrence of the cyber event or incident. Observations should be
590entered into the Joint Lessons Learned Information System (JLLIS) at
591http://www.jllis.smil.mil. JLLIS is the DoD system of record for lessons
592learned. Use of JLLIS allows for the dissemination of lessons learned
593throughout the Joint Force.
594(8) Understand patterns of activity and trends to characterize the
595threat and direct protective and defensive strategies.
596f. All tiers must cooperate with each other (and other organizations when
597appropriate). This cooperation is critical to sustaining a robust cyber incident
598handling capability.
599(1) The quality, timeliness, and consistency of reporting across all
600the tiers do much to determine the overall effectiveness of DoD incident
601handling.
602(2) Effective reporting practices ensure the availability of valuable
603data to help military decision making and shape tactical and strategic response
604actions.
605(3) Incident response requires coordination across various
606CC/S/A/FAs and is similar to coordination for other military operations.
607(4) Sometimes intelligence and technical information may come
608from sources unique to the CND environment, including sources outside the
609Department of Defense. Consequently, extensive coordination can be required
610with the US-CERT, LE/CI organizations, the IC, industry partners, and critical
611infrastructure such as electric power supply system providers,CJCSM 6510.01B
61210 July 2012
613B-3 Enclosure B
614telecommunications backbone providers, transportation management systems
615providers, etc.
616(5) Critical Infrastructure. DoD operations depend on the
617availability and robustness of numerous critical infrastructure elements. The
618first manifestation of interference with DoD operations might appear in such
619systems. As a result, DoD installations and organizations should maintain
620awareness of the status of the critical infrastructure components upon which
621they depend. In addition, cyber incidents that impact critical infrastructure
622components upon which the DoD depends should be entered into an
623appropriate reporting channel (US-CERT, local LE, etc.) in a timely manner to
624allow all parties to maintain situational awareness of the nation’s cyber
625posture.
626(6) It is imperative that information related to incidents be protected
627to prevent adversaries from determining impact or lack thereof. CC/S/A/FAs
628shall coordinate with their operations security (OPSEC) personnel to ensure
629appropriate OPSEC countermeasures are in place.
6302. Cyber Incident Handling Process and Life Cycle
631a. The basic process for DoD cyber incident handling can be grouped into
632the following processes or phases:
633(1) Detection of events.
634(2) Preliminary analysis and identification of incidents.
635(3) Preliminary response actions.
636(4) Incident analysis.
637(5) Response and recovery.
638(6) Post-incident analysis.
639b. Figure B-1 illustrates the relationship of each phase to other life cycle
640phases. The life cycle is circular. What is learned throughout the process can
641be leveraged to improve the state of the practice in defending against future
642attacks. However, many of these activities can happen in parallel or
643sequentially. Figure B-2 illustrates how these activities overlap with each
644other.CJCSM 6510.01B
64510 July 2012
646B-4 Enclosure B
647Figure B-1. Cyber Incident Life Cycle
648c. Several supporting activities cross any one stage in the life cycle.
649(1) Reporting and Notification
650(a) Those responsible for incident handling activities must
651constantly refine their ability to assess an incident as it unfolds, handle the
652information appropriately (e.g., within security, legal, and investigative
653contexts), and rapidly provide accurate and accessible information to military
654decision-makers.
655(b) This includes the submission of the initial incident report
656and any updates that result from analysis or response actions taken. It also
657includes any notification to other CND organizations, HQ, and stakeholders.
658(c) Reporting and notification happen throughout the entire
659cyber incident handling process rather than just one time. As more
660information is obtained or learned, it is passed on to relevant stakeholders.CJCSM 6510.01B
66110 July 2012
662B-5 Enclosure B
663Figure B-2. Relationship of Cyber Incident Handling Phases
664(2) Documentation
665(a) Documentation is not limited to initial documentation of an
666incident in an incident reporting form as a submission to the Joint Incident
667Management System (JIMS). It also includes documentation of additional
668information gathered during analysis and response. The primary vehicle for
669reporting and recording all cyber incidents (and reportable events) is JIMS.
670JIMS replaced the Joint Threat Intelligence Database as the Department of
671Defense’s central repository for this key intelligence.
672(b) Any response actions taken may also be part of this
673documentation, including preliminary response actions, first responder
674actions, or actions taken to preserve and protect incident artifacts, evidence, or
675chain of custody.
676(3) Coordination. This includes coordination between CC/S/A/FAs
677and other stakeholders to:
678(a) Gather information such as log and artifact collection.
679(b) Share information such as situational awareness and
680intelligence information.CJCSM 6510.01B
68110 July 2012
682B-6 Enclosure B
683(c) Plan and implement response strategies across affected
684components.
685d. Table B-1 presents the relationship between the ongoing support
686activities and the basic phases of incident handling.
687(1) These activities are part of an iterative process. They are required
688when there are changes to the status of activities, reportable events, and
689incidents and continue throughout the incident handling life cycle. The
690incident handling life cycle shares similar characteristics with a business and
691military strategy known as the Observe, Orient, Decide, and Act Loop.
692(a) Observe. Monitor and detect anomalous or suspicious activity
693within DoD information networks and ISs.
694(b) Orient. Collect, validate, and analyze information available
695about an incident to characterize the perceived threat and identify, with
696confidence, the nature, scope, root cause(s), and potential impact of an
697incident.
698(c) Decide. Based on the available information, identify the
699necessary COA required to contain the incident, eradicate the risk, and recover
700from the incident.
701(d) Act. Execute the COA required to resolve and close the incident
702and subsequently perform a postmortem. As with military combat, the goal is
703to be more effective and to execute defensive actions more quickly than the
704adversary is able to attack. The following sections discuss the incident
705handling process and activities in more depth. Although they are presented in
706a logical, sequential order during the life cycle of an incident, they may be done
707repetitively, in parallel, or sequentially, depending on the requirements of the
708incident.CJCSM 6510.01B
70910 July 2012
710B-7 Enclosure B
711Reporting
712and
713Notification
714Documentation Coordination
715Detection of
716Events
717Submission
718of report of
719events of
720interest
721Initial
722documentation of
723event activity
724Global information sharing
725and gathering between tiers
726and with other CND
727components, LE/CI, or IC
728Preliminary
729Analysis
730and
731Identification
732Submission
733of initial
734incident
735report
736If no
737documentation has
738been started,
739initial
740documentation
741should occur here
742Coordination to identify
743additional sources of
744information and artifacts
745Preliminary
746Response
747Action
748Update of
749actions
750taken
751Documentation of
752any actions taken
753Coordination of technical and
754organizational steps taken to
755implement preliminary
756actions across all affected
757CC/S/A/FAs
758Incident
759Analysis
760More detailed
761updates of
762analysis
763performed
764Documentation of
765analysis results
766Coordination of incident
767analysis activities between
768CND and technical and
769management components
770and internal/external subject
771matter experts
772Response
773and
774Recovery
775Updates on
776actions
777taken and
778submission
779of final
780report for
781closure
782Documentation of
783response plan,
784analysis
785performed, and
786COAs
787Coordination of response
788actions among CC/S/A/FAs,
789CNDSPs, installations, and
790CND service subscribers, and
791with LE/CI, IC, and others as
792required
793PostIncident
794Analysis
795Submission
796of PostIncident
797Analysis
798report
799Documentation of
800lessons learned
801and resulting
802improvement plan
803Coordination between
804CC/S/A/FAs to implement
805any process improvement
806activities resulting from postincident analysis
807Table B-1. Relationship of Cyber Incident Handling Process and Ongoing
808Supporting ActivitiesCJCSM 6510.01B
80910 July 2012
810B-8 Enclosure B
811e. Detection of Cyber Events
812(1) Detection of cyber events is the continuous process of identifying
813any unusual network or IS activity that has the potential to adversely affect
814DoD information networks, ISs, or operational missions.
815Figure B-3. Detection of Cyber Event(s)
816(2) The primary objectives of detecting cyber events include:
817(a) Ensuring all suspicious activity is detected and reported so
818that further analysis can take place to determine if it is a reportable cyber
819event or incident.
820(b) Ensuring suspicious activity is reported in a timely manner
821consistent with required reporting timelines.
822(c) Effectively coordinating with command channels and other
823DoD organizations.
824(3) As part of this process, information about potential incidents,
825vulnerabilities, or other security or incident information is gathered and
826reported to the appropriate area for analysis and response. This process is
827important because it is the point where an anomalous or unusual cyber event
828is first noticed and identified as something that must be reviewed. It may also
829be the first point at which a cyber event is reported.
830(4) Detection starts the reporting process. Gathering report
831information in a database helps analysts identify emerging trends and
832patterns. This knowledge can help the CC/S/A/FAs learn from ongoing
833activity and incidents so they can properly secure and defend their
834infrastructures.
835(5) Detecting Cyber Events
836(a) For proper detection to take place, guidelines must be
837established defining what is abnormal or suspicious. This information must beCJCSM 6510.01B
83810 July 2012
839B-9 Enclosure B
840passed on to appropriate network and IS administrators or incorporated into
841the configuration of automated detection systems.
842(b) Without the detection process, CC/S/A/FAs and CNDSPs would
843not be alerted that something must be checked or resolved. If this does not
844happen in a timely, standard, consistent manner, it is possible that a serious
845incident will not be properly reported, and significant damage and loss to the
846component infrastructure can occur.
847(c) Detection of a cyber event may occur in various ways, including
848by:
8491. An automated detection system or sensor.
8502. A report from an individual or user.
8513. An incident report or situational awareness update from
852other internal or external organizational components, such as other CNDSPs,
853USCYBERCOM, US-CERT, IC, LE/CI, or other external Computer Security
854Incident Response Team entities.
855(d) Cyber incident detection can be from any stakeholder, and
856initial event detail can vary. Alerts from automated detection systems might
857include more specific details than a report from a non-technical user.
858Additional information may need to be collected as part of the incident analysis
859phase.
860(e) Examples of cyber events and the various ways they are detected
861are provided below.
8621. The network intrusion detection sensor sends alerts for
863suspicious network traffic.
8642. The antivirus (AV) software alerts that a device is infected
865with a worm, virus, or other form of malicious logic.
8663. A Web server crashes.
8674. Users complain of slow access to hosts on the Internet or
868mail servers.
8695. The IS administrator sees a filename with unusual
870characters.CJCSM 6510.01B
87110 July 2012
872B-10 Enclosure B
8736. The user calls the help desk to report a suspicious e-mail
874message (e.g., phishing).
8757. The IS records a suspicious configuration change in its log.
8768. The IS logs multiple failed login attempts from an unfamiliar
877remote IS.
8789. The e-mail administrator sees a large number of e-mails with
879suspicious content.
88010. The network administrator notices deviation from typical
881network traffic flows.
88211. The firewall administrator sees unauthorized outbound
883connections not seen by other means.
884(f) An event is not determined to be an incident until some
885preliminary analysis is done to assess and validate the event against the
886criteria for determining if it is an incident.
887(g) If it is a reportable cyber event or confirmed incident, it is
888categorized, and the incident handling process should be followed.
889(6) Detecting Cyber Events Methodology
890(a) Detect cyber event. Identify suspicious behavior or cyber
891events of interest. A person or an automated system may detect cyber events.
892(b) Cyber event detected by a person
8931. If a cyber event is witnessed by a user or an
894administrator, that person must report the information to the designated point
895of contact (POC). The POC might be a help desk, Information System Security
896Officer, a CNDSP, or a local IS and network administrator.
8972. The report can be submitted by phone, e-mail,
898reporting form, or some other identified mechanism as identified in Enclosure
899C or based on the guidance distributed within the affected component. It is
900important to note that, in most cases, incidents occurring on a classified
901system are classified. Ensure these types of reports are not reported via
902unclassified methods.
9033. CC/S/A/FAs must ensure that DoD personnel within
904their area of responsibility (AOR) know what type of activity constitutes anCJCSM 6510.01B
90510 July 2012
906B-11 Enclosure B
907incident and where and how to submit information about suspicious activity,
908including reportable cyber events and incidents.
909(c) Cyber event detected by an automated system
9101. If the cyber event is detected by an automated system, an
911alert will be sent to the POC designated for receiving such automated alerts.
9122. CC/S/A/FAs that maintain automated detection systems
913and sensors must ensure that a POC for receiving the alerts has been defined
914and that the IS is configured to send alerts to that POC.
9153. The POC must then ensure that the cyber event is reviewed
916as part of the preliminary analysis phase and reported to the appropriate
917individuals if it meets the criteria for a reportable cyber event or incident.
918(d) Document cyber event information. Present a basic
919characterization of the activity.
9201. If the cyber event is detected by a person, the POC to whom
921the cyber event is reported or the first responder will collect the symptoms and
922indicators from the person who noticed or reported the cyber event as the start
923of documentation.
9242. If the cyber event is detected by an automated system, the
925initial logging and alert will be considered the start of the documentation
926process.
927(e) Coordinate with others
9281. Coordinate with the appropriate Tier II CNDSP, command,
929and technical channels so they are informed of the issue.
9302. As appropriate, share or corroborate this information with
931other CC/S/A/FAs for validation or situational awareness.
932f. Preliminary Analysis and Identification of Cyber Incidents
933(1) Performing preliminary analysis and identifying incidents is the
934process of performing initial analysis of a detected cyber event to determine if it
935is a reportable cyber event or incident (Figure B-4).CJCSM 6510.01B
93610 July 2012
937B-12 Enclosure B
938Figure B-4. Preliminary Analysis and Identification of Cyber Incidents
939(2) The primary objectives for this phase include the following:
940(a) Determining whether a detected event is a reportable cyber event
941or incident.
942(b) Ensuring all appropriate DoD organizations are notified through
943technical and operational reporting channels.
944(c) Ensuring the timely submission of an initial incident report that
945contains as much complete and useful information as is available (or possible).
946(3) A standardized benchmark is used for defining a reportable cyber
947event or incident. If an event does not meet the incident criteria, it can be
948removed from consideration. If the proper preliminary analysis is not done,
949some incidents may not be identified and therefore never be reported. Such a
950failure can impact the global security posture of the DoD information networks,
951resulting in an inaccurate operational picture and potentially allowing an
952incident to continue, thereby increasing the damage and loss resulting from the
953unidentified and unreported malicious activity. During this phase of the
954incident life cycle, the incident handler or automated detection systems will
955review the incoming event data, identify what type of activity is occurring, and
956determine if an anomalous event shall be treated as a reportable cyber event or
957incident. Initial information to be reviewed will include, where available:
958(a) General description of the problem, event, or activity.
959(b) Status (ongoing or ended; successful or unsuccessful).
960(c) Number of ISs affected.
961(d) Source and destination Internet Protocol (IP) addresses.
962(e) Source and destination ports.CJCSM 6510.01B
96310 July 2012
964B-13 Enclosure B
965(f) Hostname(s).
966(g) IS location.
967(h) User information.
968(i) Timestamps.
969(j) IDS alert and payload data (if relevant).
970(4) Assignment of Category Type
971(a) A cyber incident or reportable event category is a collection of
972events or incidents that share a common underlying cause for which an
973incident or event is reported. Each cyber event or incident is associated with a
974category as part of the incident handling process. Cyber incident and
975reportable event categorization is outlined in Appendix A to Enclosure B (Cyber
976Incident and Reportable Event Categorization).
977(b) An event can be declared an incident at various points in the
978incident handling process, including during the preliminary analysis phase or
979the more detailed incident analysis phase. Sometimes, if an automated
980detection system is used, the criteria used to benchmark network traffic or IS
981activity may flag an event as an incident at the time it is detected.
982(c) After further investigation, a single cyber event or incident can
983lead to discovery of additional events. For instance, a network scan (Category
9846) of a large number of hosts may be reported. Upon further analysis, it is
985determined that one of the hosts scanned is also misconfigured (Category 5).
986This should result in an additional Category 5 report being submitted along
987with the original Category 6 report. Incident and reportable event
988categorization is outlined in Appendix A to Enclosure B (Cyber Incident and
989Reportable Event Categorization).
990(5) Preliminary Analysis and Identification Methodology
991(a) Assess and Categorize. Assess the event against the incident
992criteria to determine if it is a reportable cyber event or incident.
9931. Confirmed reportable events or incidents shall be categorized
994using Appendix A to Enclosure B (Cyber Incident and Reportable Cyber Event
995Categorization). In cases where more than one category applies, the category of
996highest precedence is used as outlined in the appendix.CJCSM 6510.01B
99710 July 2012
998B-14 Enclosure B
9992. The security classification of the incident is determined at
1000this stage in accordance with DoDI O-3600.02, “Information Operations (IO)
1001Security Classification Guidance” (reference f), or local CC/S/A/FA original
1002classification authority approved classification guidance.
10033. Based on the incident’s category, nature, and impact,
1004determine if the computer forensics process should be initiated.
1005(b) Perform preliminary impact assessment. Determine the
1006potential damage of the reportable cyber event or incident.
10071. This preliminary impact assessment should be conducted in
1008accordance with Appendix C to Enclosure D (Impact Assessment Matrix).
10092. The initial assessment shall be performed quickly, even with
1010limited details and analysis. As the investigation continues and a more
1011accurate characterization of the true impact is understood, the report is
1012reassessed and modified.
10133. To make an accurate impact assessment, the analyst
1014performing the preliminary assessment must have access to personnel with a
1015good understanding of the function and criticality of the IS, information
1016network, or data in question and its role in fulfilling the CC/S/A/FA mission
1017(or ensure that those who do have that knowledge are informed).
1018(c) Begin or continue documentation. Begin to document the
1019incident if documentation has not already begun. If it has been determined
1020that computer forensics are required (e.g., LE investigation), then begin to
1021document the chain of custody. Documentation should include:
10221. All known information about the cyber event or incident.
10232. All actions taken during the preliminary analysis activities
1024and the results of that analysis.
10253. A chain of custody record initiation determination made by
1026LE/CI if forensic evidence is collected and further prosecutorial investigation
1027may be a consideration.
10283. Submit Initial Report. Prepare and submit the initial report to the
1029appropriate organizations and commands and through the appropriate
1030reporting mechanisms.
1031a. There are two different types of reporting.CJCSM 6510.01B
103210 July 2012
1033B-15 Enclosure B
1034(1) Technical Reporting. This technical channel is designed to assist
1035with the handling of incidents and provide fixes to mitigate the operational
1036and/or technical impact of an incident. It may include submitting an incident
1037report to the JIMS, appropriate CNDSP, or any other appropriate reporting
1038channels. Report submission should follow the procedures and formats
1039outlined in the incident reporting procedures in Enclosure C (Cyber Incident
1040Reporting).
1041(2) Operational Reporting. This channel provides notification to
1042commanders at all levels about the status of their ISs or information networks
1043and the operational impact of the incident on the mission(s). It is a vital
1044conduit for the commanders to identify the operational impact and direct the
1045incident handling process to mitigate unnecessary negative impact on their
1046mission(s).
1047b. The type of reporting is based on the nature and category of the
1048incident. If appropriate, this is when the LE/CI community should be notified
1049of an incident that may require an investigation IAW DoDI 5505.3, “Initiation of
1050Investigation by Military Criminal Investigative Organizations” (reference g).
1051c. Incident reports must be submitted to the JIMS by the CNDSP and
1052updated as the status changes. See Appendix A to Enclosure C (Reporting
1053Timelines).
1054d. Initial incident reporting can include verbal notifications, e-mail
1055summaries, and technical incident reports as appropriate.
1056e. Incident reporting procedures identified in Enclosure C (Cyber Incident
1057Reporting) will be followed.
1058f. Timelines for reporting are outlined in Table C-A-1 (Reporting Timelines).
1059Additional guidance on reporting timeframes are provided by command
1060authority OPORDs or other specific guidance.
1061g. Incidents and reportable events shall be reported at the appropriate
1062classification level using the appropriate means (i.e., Nonsecure Internet
1063Protocol Router Network (NIPRNET) e-mail or normal telephone for unclassified
1064incidents and Secret Internet Protocol Router Network (SIPRNET) or secure
1065telephone for Secret incidents). E-mails reporting an incident must be digitally
1066signed at a minimum.CJCSM 6510.01B
106710 July 2012
1068B-16 Enclosure B
1069h. Incident reporting will be conducted out of band from the involved
1070network. Do not use assets on an information network that is (or potentially
1071has been) compromised because an attacker may be monitoring the
1072compromised network and could be warned of detection.
10734. Preliminary Response Actions. Preliminary response includes the
1074coordinated and initial action(s) taken to protect the information network or IS
1075from any further malicious activity and to acquire the data required for further
1076analysis (Figure B-5).
1077Figure B-5. Preliminary Response Actions
1078a. Preliminary Response Action Objectives. Preliminary response actions
1079are the immediate steps taken once an incident has been detected and
1080declared. These actions are important as they provide information to help
1081protect the ISs and information network from more damage while more detailed
1082analysis is completed. More detailed response steps may be taken after a more
1083thorough analysis is performed. These will be based on the nature, scope, and
1084potential impact of the incident. The primary objectives of preliminary
1085response include:
1086(1) Preventing a reportable cyber event or incident from causing further
1087damage.
1088(2) Maintaining control of the affected IS(s) and the surrounding
1089environment.
1090(3) Ensuring forensically sound acquisition of data necessary.
1091(4) Maintaining and updating the incident report and actively
1092communicating updates through the appropriate technical and operational
1093command channels.
1094b. Preliminary Response Action Methodology
1095(1) Contain the incidentCJCSM 6510.01B
109610 July 2012
1097B-17 Enclosure B
1098(a) Contain any potential threat to protect the affected IS or
1099information network and prevent any further contamination, intrusion, or
1100malicious activity.
1101(b) Containment can be done by an automated detection system or
1102by incident handling staff working in conjunction with technical and
1103management staff.
1104(c) Containment will be coordinated with the supporting CNDSP.
1105The commander and supporting CNDSP will coordinate with LE/CI as required.
1106(d) Containment actions that may affect the ability to acquire and
1107preserve data about the incident must be decided on carefully. When making
1108these decisions, it is important to assess the relative value of ensuring mission
1109success by preventing further damage against the potential for containment
1110actions to hinder further analysis.
1111(2) Acquire and Preserve Data. Safely acquire and preserve the
1112integrity of all data (as directed) to allow for further incident analysis.
1113(a) All incidents require that as much data as possible be acquired
1114and its integrity preserved. This includes volatile data (system registers, cache,
1115and Random-Access Memory (RAM)), persistent data (system images, log files,
1116and malware), and environmental data (environment, location, and
1117configuration around the system). This data is necessary to support LE/CI
1118investigations and to conduct incident analysis to fully understand the scope
1119and impact of the incident.
1120(b) The IS will not be shut down or disconnected from the
1121information network prior to acquiring and preserving the data (e.g., making a
1122system image) unless authorized by the CNDSP or command authority.
1123However, an exception to this requirement should be made if the machine
1124begins to perform destructive tasks such as deleting files or formatting drives.
1125In that case, the computer should be shut down quickly.
1126(c) Data from related systems or devices (e.g., routers,
1127IDS/intrusion prevention system (IPS), domain controllers, and AV servers)
1128that potentially aid in incident analysis will be acquired and preserved.
1129(d) If an incident affects a large number of ISs, it may be
1130impractical to acquire and preserve the data from each IS. An example would
1131be an incident involving 100 user workstations containing no sensitive data
1132that were compromised using the same delivery vector. In such cases, data
1133must be acquired and preserved to the extent that the data provides new
1134and/or additional information that could help in the technical analysisCJCSM 6510.01B
113510 July 2012
1136B-18 Enclosure B
1137required to understand the nature, scope, and potential impact of the incident.
1138Therefore, each IS may not require data acquisition and preservation (e.g.,
1139system images). However, prior to invoking this COA, the relevant CNDSP or
1140command authority must approve that such data acquisition and preservation
1141is not required.
1142(e) Extenuating circumstances may prohibit the acquisition of data.
1143For instance, there may be insufficient tools and/or resources. Alternatively,
1144the acquisition may jeopardize mission-critical responsibilities or cause major
1145operational mission degradation. In all cases, the CNDSP or command
1146authority must approve that such data acquisition is not to be done.
1147(3) Continue Documentation
1148(a) Update the incident report with any actions taken during the
1149preliminary response step and other useful information that may help to better
1150characterize the incident.
1151(b) Any steps taken by first responders that potentially change the
1152status or state of the affected IS must be documented. For example, actions
1153such as taking the IS offline or touching any files on the IS will change the
1154state of the information to be collected—including file access times, running
1155processes, and memory contents. If this information is changed and not
1156documented, it can potentially corrupt the admissibility of the forensic evidence
1157collected in an investigation. For this reason, it is important to document any
1158actions taken on the affected IS or service.
11594. Cyber Incident Analysis
1160a. Cyber incident analysis is a series of analytical steps taken to find out
1161what happened in an incident. The purpose of this analysis is to understand
1162the technical details, root cause(s), and potential impact of the incident. This
1163understanding will help in determining what additional information to gather,
1164coordinating information sharing with others, and developing a COA for
1165response (Figure B-6).
1166Figure B-6. Cyber Incident AnalysisCJCSM 6510.01B
116710 July 2012
1168B-19 Enclosure B
1169b. The primary objectives of this phase include:
1170(1) Ensuring the accuracy and completeness of incident reports.
1171(2) Characterizing and communicating the potential impact of the
1172incident.
1173(3) Systematically capturing the methods used in the attack and the
1174security controls that could prevent future occurrences.
1175(4) Researching actions that can be taken to respond to and eradicate
1176the risk and/or threat.
1177(5) Understanding patterns of activity to characterize the threat and
1178direct protective and defensive strategies.
1179(6) Identifying the root cause(s) of the incident through technical
1180analysis.
1181c. Cyber Incident Analysis Framework. It is important to understand the
1182different types of incident analysis.
1183(1) For most incidents, the CNDSP incident handlers will conduct (or
1184coordinate) a system analysis to gather any necessary information from or
1185about the affected IS(s).
1186(2) Depending on the type of incident (or reportable event) activity, if
1187network or malware information is also available, then the CNDSP will also
1188conduct (or coordinate) a network analysis and/or malware analysis, as
1189appropriate.
1190(3) If there is a chance the incident might meet the criteria for reporting
1191an incident to LE/CI for the purposes of pursuing a disciplinary, criminal, or
1192CND investigation, then computer forensics evidence collection and analysis
1193must be performed.
1194(4) See Enclosure D (Cyber Incident Analysis) for additional guidance.
1195d. Cyber Incident Analysis Methodology
1196(1) Gather Information. Identify and collect all relevant information
1197about the incident for use in incident analysis.
1198(a) Information gathered may include data previously acquired and
1199preserved, external logs, personal accounts, all-source intelligence, technical
1200information, or the current operational situation.CJCSM 6510.01B
120110 July 2012
1202B-20 Enclosure B
1203(b) Any software artifacts suspected of being malware should be
1204submitted to the Joint Malware Catalog (JMC).1 Additional guidance may be
1205found in Enclosure G (Computer Network Defense Incident Handling Tools).
1206(2) Validate the Incident. Review, corroborate, and update (if
1207applicable) the reported incident to ensure all information is accurate as
1208reported.
1209(a) Reports should be reviewed and updated to maintain situational
1210awareness, to add to incomplete information, or to correct erroneous
1211information contained in the report.
1212(b) Report validation may require the review of trusted network and
1213system logs or affected ISs to determine if the suspected activities happened as
1214reported.
1215(c) Verify that the incident is categorized properly, in accordance
1216with Appendix A to Enclosure B (Cyber Incident and Reportable Event
1217Categorization).
1218(3) Determine Delivery Vector(s). Analyze the information to determine
1219the delivery vector(s) used by the threat actor. The delivery vector is the
1220primary path or method used by the adversary to cause the incident or event to
1221occur.
1222(a) Delivery vectors are used to systematically record major classes
1223of delivery vectors used by adversaries. They do not identify the systemspecific root cause(s) of an incident.
1224(b) If more than one delivery vector is identified, distinguish
1225between the primary and secondary delivery vectors used by the threat actor.
1226For example, use of socially engineered e-mail delivering a malicious payload
1227exploiting a known vulnerability that was preventable. Delivery vectors should
1228be assessed in accordance with Appendix A to Enclosure D (Delivery Vectors).
1229(4) Determine System Weaknesses. Analyze the information to
1230determine any underlying system weaknesses, vulnerabilities, or security
1231controls that could have prevented or mitigated the impact of the incident.
1232(a) Identification of system weaknesses is a process used to
1233systematically record and categorize major classes of security controls that
1234could prevent similar incidents from occurring in the future. They cannot
1235identify the system-specific root cause(s) of an incident.
12361 The JMC is currently under development.CJCSM 6510.01B
123710 July 2012
1238B-21 Enclosure B
1239(b) System weakness identification should be performed IAW
1240Appendix B to Enclosure D (Information System Weaknesses).
1241(5) Identify Root Cause(s). Analyze the information to determine the
1242system-specific cause(s) of the incident.
1243(a) Root cause identification expands upon the identified delivery
1244vector(s) and system weaknesses by precisely identifying the sets of conditions
1245allowing the incident to occur. For example, a delivery vector may identify an
1246unpatched system. This is useful for correlation and trending but is
1247insufficient in identifying the specific cause of the incident and preventing
1248against future occurrences. Root cause identification would determine missing
1249patches or system configurations that allowed the incident to occur.
1250(b) The root cause(s) of an incident should (unless not practical) be
1251determined prior to the recovery and reconstitution of any system, unless
1252otherwise approved by your command authority. The decision to restore a
1253system without identifying the root cause(s) of an incident must be weighed
1254carefully as it may leave the system vulnerable. For example, if the root cause
1255of an incident stemmed from a missing patch in the baseline configuration, a
1256system restoration using the same baseline configuration would leave the IS
1257open to future compromise.
1258(c) A risk assumed by one is potentially a risk shared by many.
1259Failing to identify the root cause of an incident may expose multiple commands
1260and organizations to increased risk, especially in situations where they share
1261similar configurations or defensive measures.
1262(6) Determine Impact. Analyze the information gathered to validate and
1263expand on the original impact assessment done during the preliminary
1264analysis. Impact should be assessed in accordance with Appendix C to
1265Enclosure D (Impact Assessment Matrix). The impacts to be determined are as
1266follows:
1267(a) Technical Impact (TI). TI refers to an incident’s detrimental
1268impact on the technical capabilities of the organization. TI typically refers to
1269impacts on the information network or IS machines directly or indirectly
1270affected by the incident. Examples include:
12711. Network health status.
12722. Potential data compromise or loss.CJCSM 6510.01B
127310 July 2012
1274B-22 Enclosure B
12753. Equipment downtime or destruction.
12764. Impact on other ISs or components (e.g., a machine removed
1277from operations takes 8 hours to be rebuilt).
1278(b) Operational Impact (OI). OI refers to a detrimental impact on an
1279organization’s ability to perform its mission. This may include direct and/or
1280indirect effects that diminish or incapacitate IS or information network
1281capabilities, the compromise and/or loss of DoD data, or the temporary or
1282permanent loss of mission-critical applications or ISs.
12831. Examples of direct impact include the following:
1284a. Stolen national intelligence, operational plans,
1285Commander’s COP, and decision briefs that provide an adversary with a critical
1286advantage.
1287b. Corrupted databases (leading to loss of confidence in the
1288intelligence); execution of corrupted/degraded air tasking orders or timephased force deployment data (TPFDD) leading to loss of mission and/or lives.
1289c. Hard drive data lost from the DoD networks.
1290d. Degraded or denied C2 of all networked weapon systems.
1291e. Degraded, denied, or misdirected C2 from leadership to
1292subordinate units.
1293f. Loss of control of DoD Supervisory Control and Data
1294Acquisition networks.
12952. Examples of indirect impact on a supply organization include
1296the following:
1297a. An Army division is unable to order/track/process repair
1298parts using a networked IS and is therefore unable to conduct combat
1299operations due to insufficient availability of repair parts.
1300b. Barges on the Mississippi River are unable to deliver
1301supplies because their crews cannot access DoD-supplied river hazard data.
1302c. A Reserve unit goes unpaid because of an incident
1303affecting TPFDD, and the unit does not meet its deployment timeline.CJCSM 6510.01B
130410 July 2012
1305B-23 Enclosure B
1306(c) TIs are normally reported by the communications and technical
1307component of an organization (J, G, S, N, A-6), while OIs are typically reported
1308by and/or to the operational component of an organization (J, G, S, N, A-3).
1309Examples follow:
13101. J-6 reports that an attack accessed 3 megabytes (MB) of data
1311from a server.
13122. J-3 reports the attack accessed 3 MB of unclassified family
1313support group data and determines no operational impact.
1314(d) Determine if the incident has any strategic significance and
1315whether it is a Commander’s Critical Information Requirement (CCIR) of
1316USCYBERCOM or other commands and report appropriately.
1317(7) Research and Develop COAs. Identify actions necessary to respond
1318to the reportable cyber event or incident, fix the IS, and assess the risk for the
1319IS or information network.
1320(a) Analysis, comparison, and selection of the best COA could be
1321done at the lowest command possible. For instance, a commander could be
1322the approving authority for an incident response COA for his or her base.
1323USSTRATCOM, through USCYBERCOM, reserves the right to redirect all
1324response actions for incidents that fall into a DoD Enterprise Incident Set.
1325(b) In some cases, in coordination with the Tier II CNDSP, AO
1326(DAA), and USSTRATCOM, the commander may decide to leave the IS
1327vulnerable and accessible in order to monitor the attacker’s activities. This
1328may be done to assist an LE/CI investigation or for network defense and
1329operational purposes.
1330(c) COA may include CND Response Actions (CND RAs) as outlined
1331in CJCSI 3121.01, “Standing Rules of Engagement/Standing Rules for the Use
1332of Force for U.S. Forces.”
1333(d) Actions that potentially affect traffic on the DoD Protected Traffic
1334List (see Enclosure G) must be coordinated with USCYBERCOM.
1335(8) Coordinate with Others. Work with other appropriate parties to
1336collect additional information, obtain assistance and additional expertise or
1337guidance, and notify appropriate operational and technical channels regarding
1338changes in the status of reportable events, incidents, and incident handling
1339activities. Timely interagency coordination and deconfliction of operations are
1340crucial to conducting an effective incident response. For additional guidance,
1341refer to Appendix A to Enclosure F (Coordination and Deconfliction).CJCSM 6510.01B
134210 July 2012
1343B-24 Enclosure B
1344(a) Coordination ensures that the identification and deconfliction of
1345response is vetted through all the parties that may be affected by the response.
1346Coordination may include the following:
13471. Reporting vertically to alert higher HQ and other CND
1348organizations.
13492. Reporting horizontally to other peer organizations that have
1350ISs that may be affected.
13513. Researching and planning response strategy and COA.
1352(9) Perform Correlation and Trending. This involves analyzing and
1353identifying relationships and trends between incidents in the short term and
1354patterns across incidents in the long term. Effective and complete reporting
1355throughout the incident handling life cycle ensures that the Department of
1356Defense has the ability to conduct and identify these trends and patterns.
1357(a) Trending Analysis. Trending analysis involves understanding
1358and accurately characterizing the relationship of incidents reported and
1359providing awareness of the cyber security trends as observed by the affected
1360parties. It includes analysis based on incident information that has been
1361reported to the constituent, incidents identified by the constituent, and
1362public/private sector information identified when correlating and analyzing the
1363data.
1364(b) Enterprise Threat Fusion and Correlation. This process involves
1365correlating incident activity to assess and direct operation and defense of the
1366DoD information networks across strategic, operational, and tactical
1367boundaries. It includes developing, disseminating, and directing the
1368implementation of countermeasures to specific weaknesses against known
1369adversarial tactics, techniques, and procedures (TTPs) to preserve the
1370Warfighter’s ability to carry out current and future missions.
13715. Response and Recovery. Response and recovery include the detailed
1372response steps performed to prevent further damage, restore the integrity of
1373affected ISs, and implement follow-up strategies to prevent the incident from
1374happening again (Figure B-7).CJCSM 6510.01B
137510 July 2012
1376B-25 Enclosure B
1377Figure B-7. Response and Recovery
1378a. The primary objectives for performing response and recovery include:
1379(1) Resolving the incident according to policy, procedures, and quality
1380requirements.
1381(2) Mitigating the risk or threat.
1382(3) Restoring the integrity of the IS and returning it to an operational
1383state.
1384(4) Implementing proactive and reactive defensive and protective
1385measures to prevent similar incidents from occurring in the future.
1386(5) Completing a battlefield damage assessment (BDA) IAW Appendix C
1387to Enclosure D (Impact Assessment Matrix).
1388b. Response and recovery may require a combination of technical,
1389management, and/or LE/CI actions.
1390(1) Technical actions include changes in the network and IS
1391infrastructure to remove the risk or threat.
1392(2) Management steps can include administrative, human resources,
1393public relations, or policy creation and management activities. LE/CI actions
1394can include further investigation or criminal prosecution. Other management
1395issues may involve legal actions to handle liability, service level agreements, or
1396contracting issues.
1397c. Response and Recovery Methodology
1398(1) Implement Containment
1399(a) Implement (if applicable) additional containment actions to
1400regain control of or isolate the system and prevent further malicious activity.CJCSM 6510.01B
140110 July 2012
1402B-26 Enclosure B
1403(b) Determine the appropriate containment strategy based on the
1404type of incident. Examples of strategies might include modifying network
1405access controls (e.g., firewalls), installing new AV or IDS/IPS signatures, or
1406making physical changes to the infrastructure.
1407(c) Collaborate with partners since investigative or intelligence
1408equities may need to be considered before certain containment measures are
1409taken. See Enclosure F for a full discussion of collaboration.
1410(2) Eradicate Risk. Eradicate the risk and take actions that remove the
1411cause of the incident from the IS/network.
1412(a) No system should be rebuilt until system data has been
1413adequately preserved and the vulnerability has been mitigated.
1414(b) ISs having a Category (CAT) 1, 2, and 7 cyber incident must be
1415rebuilt from trusted media and have up-to-date AV software loaded and
1416configured IAW Security Technical Implementation Guides (STIGs) and warning
1417and tactical directives/orders (e.g., WARNORDs, FRAGOs, TASKORDs, etc.)
1418prior to connecting the IS to the information network.
1419(c) Mission impact may require patching the affected component
1420and instituting temporary vulnerability mitigation until the mission allows the
1421IS to be rebuilt.
1422(3) Recover from Incident. Fully restore affected data and ISs to normal
1423operation (if applicable). Harden ISs to prevent similar incidents and monitor
1424them to ensure the IS is completely free from the original IS weakness.
1425(a) For some incidents, eradication is either not necessary or is
1426performed during recovery.
1427(b) Preventing similar incidents may involve changing baseline
1428configurations, tightening network perimeter security, updating AV and
1429scanning tool signature files, rebuilding the system from trusted media,
1430conducting user training, or implementing countermeasures that mitigate the
1431risk.
1432(4) Coordinate with Others. Work with appropriate parties to
1433implement COAs and resolve cyber events or incidents.
1434(5) Notify Others. Notify any relevant stakeholders or participants of
1435actions they need to take. Notify involved parties (as appropriate) of the status
1436of the incident and progress of the response. Submit updated information on
1437the incident and the progress of the response to keep higher CND organizationsCJCSM 6510.01B
143810 July 2012
1439B-27 Enclosure B
1440and/or HQ updated on the status of the incident response. CC/S/A/FAs must
1441ensure that program managers for centrally managed programs are notified of
1442CAT 1, 2, 4, 5, or 7 cyber incidents impacting their programs (Appendix A to
1443Enclosure B).
1444(6) Continue Documentation. Update the incident record in JIMS with
1445information on any response and recovery steps that were taken. Each update
1446to the JIMS report provides a more complete understanding of the incident.
1447Consistent and frequent updates provide a platform to broadly characterize
1448adversarial activity and enable USCYBERCOM to direct appropriate defensive
1449actions for all DoD information networks.
1450(7) Update Response Actions and Battlefield Damage Assessment (BDA)
1451and Close Incident. Update the incident record in JIMS that closes out the
1452incident.
1453(a) Ensure all parties have completed the necessary actions for the
1454response.
1455(b) The BDA documents the technical and operational impact (i.e.,
1456OPSEC assessment) of the incident on the organization. It should be
1457determined IAW Appendix C to Enclosure D (Impact Assessment Matrix).
1458(c) Update the JIMS incident record with the BDA within 24 hours
1459after the incident is resolved.
1460(d) Declare the incident closed, change the status in the JIMS to
1461closed, and perform any other actions to close the incident.
14621. Incidents cannot be closed as a CAT 8—Investigating.
14632. An incident might be closed for the CC/S/A/FA or the
1464CNDSP but still remain open for LE/CI investigation.
14653. CNDSPs are responsible for closing an incident. Incidents
1466may be reopened by USCYBERCOM if necessary, in which case the affected
1467CNDSP would be contacted and given direction as to what additional actions
1468should be taken.
1469(8) Additional information about responding to incidents is described in
1470Enclosure E (Cyber Incident Response).CJCSM 6510.01B
147110 July 2012
1472B-28 Enclosure B
14736. Post-Incident Analysis
1474a. Post-incident analysis involves a postmortem on an incident to review
1475the effectiveness and efficiency of incident handling. Data captured in the
1476postmortem includes lessons learned, initial root cause, problems with
1477executing COAs, missing policies and procedures, and inadequate
1478infrastructure defenses (see Figure B-8).
1479b. Postmortem results should be used to improve the incident management
1480process and methodology and the security posture and defenses of the
1481CC/S/A/FAs.
1482Figure B-8. Post-Incident Analysis
1483c. One of the most important parts of incident handling is learning how to
1484improve operations, processes, and infrastructure defenses by reviewing how
1485an incident happened and how the response was handled. The primary
1486objectives for post-incident analysis include:
1487(1) Identifying infrastructure problems to address.
1488(2) Identifying organizational policy and procedural problems to be
1489addressed.
1490(3) Identifying technical or operational training needs.
1491(4) Determining unclear or undefined roles, responsibilities, interfaces,
1492and authority.
1493(5) Improving tools required to perform protection, detection, analysis,
1494or response actions.
1495d. CC/S/A/FAs will establish a formal postmortem process and will
1496establish criteria governing which incidents require a postmortem.
1497e. Not all incidents require a postmortem. Usually, incidents that are large
1498in scope, handled poorly, involved LE, or caused severe damage require a
1499postmortem.CJCSM 6510.01B
150010 July 2012
1501B-29 Enclosure B
1502f. Incidents that do require a postmortem will be sent to USCYBERCOM.
15037. First Responder Guidelines
1504a. The first responder is the first person who arrives to investigate and
1505respond to any detected activity. First responders include, but are not limited
1506to, system administrators, CNDSP technical staff, and LE. A first responder’s
1507role and responsibilities are to:
1508(1) Determine the initial impact of the incident.
1509(2) Collect as much information about the incident as possible.
1510(3) Document all findings.
1511(4) Share this collected information with appropriate points of contact
1512to support root cause identification.
1513b. First responder procedures and processes must be in place to ensure
1514the consistent and proper initial response to events, incidents, or other
1515suspicious activities.
1516(1) Detectors. People who detect events or incidents must be properly
1517trained to ensure they do not damage or contaminate evidence. They must be
1518taught to step away from the affected or involved IS and to touch nothing;
1519instead, they should report what they have found or seen to the appropriate
1520POC or CNDSP. The POC or CNDSP is responsible for ensuring a qualified
1521person is assigned to handle collection, analysis, and response.
1522(2) Responders. The people who arrive to investigate and respond to a
1523cyber event or incident are true first responders, just as firefighters or police
1524are the first responders to physical security events. Guidance to these first
1525responders is vital to ensuring proper methods are initiated for appropriate
1526response actions.
1527(a) First responders must have a defined process and procedure in
1528place governing what they can and cannot do at the scene. First responders
1529who will not handle the investigation or analysis must be ready to turn over all
1530their information in a clear, concise manner that is easily understood by
1531others.
1532(b) First responders must be knowledgeable and prepared to collect
1533data and forensic evidence. Along with a standard incident response and
1534reporting plan, they must also have a tested and documented toolkit that canCJCSM 6510.01B
153510 July 2012
1536B-30 Enclosure B
1537be used for collection (data acquisition) and response in a forensically sound
1538manner.
1539c. Policies and Procedures
1540(1) Policies and procedures are required to ensure a consistent and
1541proper response to events and incidents that includes:
1542(a) Determination of a designated first responder and his or her
1543responsibilities. If the first responder will not be the person to handle the
1544incident or does not have the skills or tools needed, the first responder must be
1545carefully instructed to not touch the IS or make any changes and wait to hand
1546over the investigation to the assigned analyst.
1547(b) Guidance for non-expert or technical personnel who detect a
1548cyber event or incident to ensure they do not make changes to the IS and to
1549ensure they report the event to the appropriate command authority or CNDSP.
1550(c) Instructions for creating, using, and maintaining a first
1551responder trusted toolkit.
1552(d) Infrastructure to create and maintain a trusted test bed to test
1553and document tools before adding them to the toolkit.
1554(e) A defined collection strategy that outlines what type of
1555information and data will be collected, with what tools, and how information
1556and data will be stored and documented.
1557(f) Instructions for performing forensic data acquisition and
1558maintaining a corresponding chain of custody.
1559(g) Instructions about what type of preliminary response actions the
1560first responder is approved to make related to containment, notification, or
1561documentation actions.
1562(2) Each CC/S/A/FA, in coordination with its CNDSP, will define first
1563responder policies and procedures for its areas and provide guidance to Tier III.
1564d. Precautionary Measures. Prior to the arrival of an authorized incident
1565response analyst, first responders are responsible for taking precautionary
1566measures to ensure the successful acquisition and preservation of data.
1567(1) Maintain Control. Prevent unauthorized access to the IS and
1568maintain physical control of the surrounding environment. Protect the
1569integrity of other devices that may have witnessed or captured information
1570related to the incident such as log servers, video cameras, remote accessCJCSM 6510.01B
157110 July 2012
1572B-31 Enclosure B
1573servers, etc. Be aware of unintentional destructive activity such as
1574maintenance procedures that purge and rotate log files, processes that delete
1575files and e-mails after a certain date, etc.
1576(2) Document Events and Activities. Immediately start a log of
1577activities as soon as a security incident is detected. This log should note when
1578the incident was detected, by whom, and how it was detected. All activities
1579pertaining to the incident should be included in the log, such as opening log
1580files for viewing, printing reports, etc. At a minimum, document the following
1581items:
1582(a) Time and date of incident.
1583(b) State of the IS when incident was discovered (on, off, connected,
1584or disconnected).
1585(c) All activities and commands done to the IS, noting the time,
1586date, and who performed the actions.
1587(d) People present or knowledgeable about the incident.
1588(e) Owner or user of the IS.
1589(3) Determine if Shutdown is Necessary. As soon as it is determined an
1590incident has occurred, the computer should be kept on and in the same state
1591as when the incident was discovered. Guidance for shutting down, altering
1592settings, saving settings, or any other action will be determined by the incident
1593responder (i.e., analyst and LE).
1594(4) Log Actions. Ensure all actions are logged as part of documenting
1595the chain of evidence.
1596e. First Responder Toolkits
1597(1) A first responder toolkit is a set of scripts, programs, and other
1598resources used to safely acquire, examine, and preserve volatile and nonvolatile data from an IS.
1599(2) These trusted toolkits must be approved by the AO, formally known
1600as the DAA, and then must be acquired, described, and fully understood prior
1601to their use.
1602(3) Information about what the tool does, how it interfaces with an IS
1603and network, what type of outputs it produces, and what type of impact or
1604fingerprint it leaves on the analyzed IS must be determined and documented.CJCSM 6510.01B
160510 July 2012
1606B-32 Enclosure B
1607If this is not done or if untested tools are used, then changes may be
1608introduced to the IS that will inhibit a complete analysis, cause a
1609misinterpretation of the activity, or cause the evidence to be contaminated.
1610(4) First responders must also ensure that any actions they take do not
1611violate any existing CC/S/A/FA computer and network usage policies.
1612(5) More in-depth information about performing forensic data
1613acquisition and analysis, documenting the analysis and chain of custody, and
1614protecting the collected data is provided in Enclosure D (Cyber Incident
1615Analysis).CJCSM 6510.01B
161610 July 2012
1617Appendix A
1618B-A-1 Enclosure B
1619APPENDIX A TO ENCLOSURE B
1620CYBER INCIDENT AND REPORTABLE CYBER EVENT CATEGORIZATION
16211. Introduction
1622a. A Cyber Incident or Reportable Cyber Event Category is a collection of
1623events or incidents sharing a common underlying cause for which an incident
1624or event is reported.
1625b. Each cyber event or incident is associated with one or more categories
1626as part of the incident handling process.
16272. Categories
1628a. In cases where more than one category applies, the category assigned
1629should be determined using the following precedence in Table B-A-1.
1630Precedence Category Description
16310 0 Training and Exercises
16321 1 Root Level Intrusion (Incident)
16332 2 User Level Intrusion (Incident)
16343 4 Denial of Service (Incident)
16354 7 Malicious Logic (Incident)
16365 3 Unsuccessful Activity Attempt (Event)
16376 5 Non-Compliance Activity (Event)
16387 6 Reconnaissance (Event)
16398 8 Investigating (Event)
16409 9 Explained Anomaly (Event)
1641Table B-A-1. Category Precedence
1642b. For instance, an incident could be reported either as a User Level
1643Intrusion (Category 2) or a Non-Compliance Event (Category 5). The User Level
1644Intrusion takes precedence based on Table B-A-1, and the incident should be
1645reported as a User Level Intrusion (Category 2) incident.
1646c. Investigating (Category 8) reports will include an initial assessed
1647incident category (Categories 1-7 or 9) and be recategorized based on continued
1648investigation. No reports will be closed as a Category 8.
1649d. Table B-A-2 provides incident and reportable event categories.CJCSM 6510.01B
165010 July 2012
1651Appendix A
1652B-A-2 Enclosure B
1653Category Description
16540
1655Training and Exercises—Operations performed for training
1656purposes and support to CC/S/A/FA exercises.
16571
1658Root Level Intrusion (Incident)—Unauthorized privileged access
1659to an IS. Privileged access, often referred to as administrative or
1660root access, provides unrestricted access to the IS. This category
1661includes unauthorized access to information or unauthorized
1662access to account credentials that could be used to perform
1663administrative functions (e.g., domain administrator). If the IS is
1664compromised with malicious code that provides remote interactive
1665control, it will be reported in this category.
16662
1667User Level Intrusion (Incident)—Unauthorized non-privileged
1668access to an IS. Non-privileged access, often referred to as userlevel access, provides restricted access to the IS based on the
1669privileges granted to the user. This includes unauthorized access
1670to information or unauthorized access to account credentials that
1671could be used to perform user functions such as accessing Web
1672applications, Web portals, or other similar information resources. If
1673the IS is compromised with malicious code that provides remote
1674interactive control, it will be reported in this category.
16753
1676Unsuccessful Activity Attempt (Event)—Deliberate attempts to
1677gain unauthorized access to an IS that are defeated by normal
1678defensive mechanisms. Attacker fails to gain access to the IS (i.e.,
1679attacker attempts valid or potentially valid username and password
1680combinations) and the activity cannot be characterized as
1681exploratory scanning. Reporting of these events is critical for the
1682gathering of useful effects-based metrics for commanders.
1683Note the above CAT 3 explanation does not cover the “run-of-themill” virus that is defeated/deleted by AV software. “Run-of-themill” viruses that are defeated/deleted by AV software are not
1684reportable events or incidents and should not be annotated in
1685JIMS.
16864
1687Denial of Service (Incident)—Activity that denies, degrades, or
1688disrupts normal functionality of an IS or DoD information network.
16895
1690Non-Compliance Activity (Event)—Activity that potentially
1691exposes ISs to increased risk as a result of the action or inaction of
1692authorized users. This includes administrative and user actions
1693such as failure to apply security patches, connections acrossCJCSM 6510.01B
169410 July 2012
1695Appendix A
1696B-A-3 Enclosure B
1697security domains, installation of vulnerable applications, and other
1698breaches of existing DoD policy. Reporting of these events is
1699critical for the gathering of useful effects-based metrics for
1700commanders.
17016
1702Reconnaissance (Event)—Activity that seeks to gather information
1703used to characterize ISs, applications, DoD information networks,
1704and users that may be useful in formulating an attack. This
1705includes activity such as mapping DoD information networks, IS
1706devices and applications, interconnectivity, and their users or
1707reporting structure. This activity does not directly result in a
1708compromise.
17097
1710Malicious Logic (Incident)—Installation of software designed
1711and/or deployed by adversaries with malicious intentions for the
1712purpose of gaining access to resources or information without the
1713consent or knowledge of the user. This only includes malicious
1714code that does not provide remote interactive control of the
1715compromised IS. Malicious code that has allowed interactive access
1716should be categorized as Category 1 or Category 2 incidents, not
1717Category 7. Interactive active access may include automated tools
1718that establish an open channel of communications to and/or from
1719an IS.
17208
1721Investigating (Event)—Events that are potentially malicious or
1722anomalous activity deemed suspicious and warrant, or are
1723undergoing, further review. No event will be closed out as a
1724Category 8. Category 8 will be recategorized to appropriate
1725Category 1-7 or 9 prior to closure.
17269
1727Explained Anomaly (Event)—Suspicious events that after further
1728investigation are determined to be non-malicious activity and do
1729not fit the criteria for any other categories. This includes events
1730such as IS malfunctions and false alarms. When reporting these
1731events, the reason for which it cannot be otherwise categorized
1732must be clearly specified.
1733Table B-A-2. Cyber Incident and Reportable Cyber Event CategoriesCJCSM 6510.01B
173410 July 2012
1735Appendix A
1736B-A-4 Enclosure B
17373. Comparison of DoD and Department of Homeland Security Categories.
1738Table B-A-3 provides a comparison between categories utilized by the
1739Department of Defense and Department of Homeland Security (DHS).
1740DoD Cyber Incident and Reportable
1741Cyber Event Categories
1742DHS Incident and Reportable Event
1743Categories
1744Category 0: Training and Exercises Category 0: Exercise/Network
1745Defense Testing
1746Category 1: Root-Level Intrusions Category 1: Unauthorized Access
1747Category 2: User-Level Intrusions Category 1: Unauthorized Access
1748Category 3: Unsuccessful Activity
1749Attempt
1750Category 5: Scans/Probes/Attempted
1751Access
1752Category 4: Denial of Service Category 2: Denial of Service
1753Category 5: Non-Compliance Activity Category 4: Improper Usage
1754Category 6: Reconnaissance Category 5: Scans/Probes/Attempted
1755Access
1756Category 7: Malicious Code Category 3: Malicious Code
1757Category 8: Investigating Category 6: Investigation
1758Category 9: Explained Anomaly
1759Table B-A-3. Comparison of DoD and DHS Incident and Event Categories2
17602 The eventual goal is to coordinate common incident and event categories
1761between the Department of Defense and DHS.CJCSM 6510.01B
176210 July 2012
1763C-1 Enclosure C
1764ENCLOSURE C
1765CYBER INCIDENT REPORTING
17661. Introduction
1767a. Incident reporting comprises a well-defined framework for the timely
1768reporting of any reportable cyber event or incident. It ensures the report
1769provides an accurate, meaningful, and complete understanding of the incident,
1770from initial detection through analysis to resolution and closure.
1771b. Reporting provides valuable input into the combined and coordinated
1772analysis of data from a variety of sources.
1773(1) This analysis provides the joint forces, CC/S/A/FA CNDSPs, and
1774USCYBERCOM with indications of adversary reconnaissance, probing,
1775intrusions, network exploitations, and/or attacks that have occurred or are
1776occurring on DoD information networks.
1777(2) It also enables regional and theater entities to understand what is
1778happening across their joint/theater operations, and, in turn, provides
1779information to Tier Is, which are able to gain a global situational awareness of
1780attacks occurring on DoD information networks.
1781c. This section provides guidance on the reporting requirements for
1782reportable cyber events and incidents.
1783(1) Further requirements shall be articulated in OPORDs issued by
1784relevant commands.
1785(2) DoD, contractor, or other personnel who access DoD ISs and
1786information networks must report to their appropriate organization and
1787commands (whether that is a supervisor, information assurance manager,
1788information assurance officer, commander, CNDSP, etc.).
1789d. The primary objectives for the incident reporting process are to:
1790(1) Ensure all suspicious activity on DoD information networks and ISs
1791is reported according to defined policies, procedures, and within established
1792timeframes.
1793(2) Ensure incident reports provide an accurate, meaningful, and
1794complete understanding of the incident throughout its life cycle.CJCSM 6510.01B
179510 July 2012
1796C-2 Enclosure C
1797(3) Ensure the effective and timely coordination and communication of
1798incident information through appropriate channels and with higher CND
1799organizations and/or DoD CC/S/A/FA HQ.
1800(4) Provide the Department of Defense with the ability to direct
1801protective and defensive strategies based on incident reporting trends and
1802adversarial activity.
1803e. Events and incidents are reported and communicated across multiple
1804tiers within the Department of Defense, including the Joint Staff, CC/S/A/FAs,
1805CNDSPs, and the installations at Tier III levels. Each tier plays a role in this
1806incident reporting process to support situational awareness and operational
1807impact reporting about activities that affect CC/S/A/FAs. Such reporting
1808serves multiple purposes and serves different needs within the Department of
1809Defense, for example:
1810(1) Initial detection and notification alert appropriate organizations that
1811activity has occurred (or is occurring) that requires attention.
1812(2) Follow-up notification provides further details and updates
1813regarding status or changes in the activity to support ongoing analysis,
1814remediation, or development of response COAs.
1815(3) Accurate and complete information gives analysts data used to
1816assess the impact of an incident and the impact it has on mission operations.
1817(4) Accurate and complete reporting assists analysts in determining
1818root cause(s), in identifying delivery vectors, and/or identifying IS weaknesses.
1819(5) Accurate and complete reporting provides relevant input to the
1820intelligence community and supports LE/CI investigations.
1821(6) Timely reporting provides input to Tier I to enable a DoD-wide
1822understanding of the current defensive operational picture.
1823(7) Comprehensive incident reporting provides data that can be used in
1824other correlation, trending, or retrospective analysis tasks.
1825(8) Increased knowledge and awareness can help keep other incidents
1826from happening or going undetected.
1827f. Effective end-to-end reporting serves as input to the defensive operational
1828picture, which provides local, intermediate, and DoD-wide visual situational
1829awareness of incidents, events, CNDSP actions, and their impact. To
1830accurately identify, characterize, and understand activity occurring across DoDCJCSM 6510.01B
183110 July 2012
1832C-3 Enclosure C
1833information networks, commanders at all levels must ensure their
1834subordinates participate in the reporting process.
1835g. There are requirements and benefits across all tiers from appropriately
1836sharing information about incident reports. For example, activity identified at
1837a Tier II entity that is reported up to Tier I and pushed down to Tier III can
1838additionally be passed on to peer CC/S/A/FAs to alert them to similar activity.
1839Sharing information about an incident at one location with peer organizations
1840can facilitate improvements or enable peer entities to protect their ISs and DoD
1841information networks proactively.3
18422. Reporting Structures
1843a. Effective response requires coordinated reporting and information
1844sharing with multiple communities of interest within and outside the
1845Department of Defense. There are two primary reporting structures, which are
1846described below.
1847(1) Technical Reporting Structure. This structure consists primarily of
1848global USCYBERCOM (Tier I), regional/theater/CC/S/A/FAs (Tier II) CNDSPs,
1849and local (Tier III) organizations and describes the interactions between each of
1850the tier levels and how reporting, notification, and communications shall occur.
1851(2) Additional Reporting Structures. This group includes other
1852reporting structures that may be required in support of the IC, LE/CI, and
1853operational and any other external organizations as appropriate.
1854b. Technical Reporting Structure
1855(1) All reportable events and incidents are reported to USCYBERCOM.
1856Defined processes and procedures will be followed at each tier to ensure
1857reportable incidents and events contain relevant information IAW this manual
1858to enable the Department of Defense to appropriately handle those incidents
1859and events, as well as to gain an in-depth view of activity and any operational
1860impact on DoD mission operations.
1861(2) The level and type of information to be reported will depend on the
1862operational roles and responsibilities of the individuals involved, as well as any
1863specific OPORDs. When incidents and reportable events are identified, it
18643 Online collaborative tools provide a proven environment to conduct these
1865information sharing activities. Persistent sessions between tier entities can be
1866established to track and collaborate on ongoing incidents and events.CJCSM 6510.01B
186710 July 2012
1868C-4 Enclosure C
1869should be recognized that reporting occurs through a management channel as
1870well as a technical channel. These channels are described below:
1871(a) Technical Reporting. This technical channel is designed to
1872assist with the handling of incidents and provide fixes to mitigate the
1873operational and/or technical impact of an incident.
18741. Technical activities include reporting incidents and events
1875through appropriate channels, updating information throughout the life cycle
1876of the cyber event or incident, and conducting other communications related to
1877them.
18782. The dissemination of information and types of
1879communications will vary depending on the roles involved in the activity (Tier I,
1880II, or III; LE/CI; joint commands; etc.).
1881(b) Operational Reporting. The management and oversight channel
1882is designed to notify commanders at all levels of the ability of their ISs to
1883support operations and the operational impact of any reported incidents.
18841. Commanders determine when to initiate communications
1885with the LE/CI community, for example, when an incident requires a criminal
1886investigation.
18872. The type of reporting will also depend on the leadership role
1888involved in the notification path (e.g., communicating with control centers,
1889CNDSPs, USCYBERCOM, LE/CI, or the IC).
18903. The leadership and oversight channel also provides a conduit
1891for commanders to guide the incident handling process to mitigate any
1892additional negative impact on their ISs.
1893(c) These technical and operational reporting channels occur in
1894parallel. They ensure that incidents and their potential impact are addressed
1895not only at the technical (detection, analysis, and response) levels, but that
1896commanders and other appropriate DoD personnel receive details to enable
1897appropriate tactical and strategic military decision making. Commanders are
1898ultimately responsible and accountable for their information networks and for
1899ensuring that appropriate reporting occurs.
1900(3) Tier I Reporting. Tier I receives reports from Tier II and external
1901entities. It is positioned for centralized coordination and control in a way that
1902allows it to broadly characterize attacks occurring across the Department of
1903Defense. This vantage point allows it to provide tactical and strategic direction
1904to subordinate levels and determine defensive and/or protective strategies thatCJCSM 6510.01B
190510 July 2012
1906C-5 Enclosure C
1907help improve the overall security posture of the DoD Information Networks.
1908Tier I includes USCYBERCOM and supporting entities.
1909(a) Incidents are reported to USCYBERCOM according to published
1910CCIRs.
1911(b) USCYBERCOM provides reports (summaries, significant
1912incidents, trends, enterprise-wide issues) to OSD through USSTRATCOM and
1913the Joint Staff as required.
1914(c) USCYBERCOM receives reports of all reportable events and
1915incidents from Tier II (CNDSP) through the JIMS.
1916(d) USCYBERCOM analyzes, correlates, and fuses reports to
1917understand attacks against DoD information networks and to direct defensive
1918measures. This information, in turn, is shared (as appropriate) with other
1919tiers.
1920(e) USCYBERCOM disseminates information to the USSTRATCOM
1921Joint Intelligence Center (STRATJIC) about DoD Enterprise Incident Sets.
1922(f) USCYBERCOM coordinates with LE/CI regarding incidents that
1923involve LE/CI investigations.
1924(g) USCYBERCOM provides tactical and strategic information to
1925subordinate tiers based on the results of report trending analysis and the
1926correlation and enterprise fusion of threat information. This information is
1927provided in a variety of reports including, but not limited to:
19281. Operation orders (e.g., OPORDs, WARNORDs, TASKORDs)
19292. Situational awareness reports, bulletins, and alerts
19303. Web portals, e-mails, and Defense Connect Online sessions
1931(h) USCYBERCOM provides releasable incident reporting material
1932to bilateral and multilateral partners as appropriate.
1933(i) USCYBERCOM J-2 and the Service Component CERT/computer
1934incident response team (CIRT) intelligence support elements are required to
1935perform IAW Appendix B to Enclosure F (Intelligence Support to Incident
1936Reporting).CJCSM 6510.01B
193710 July 2012
1938C-6 Enclosure C
1939(j) The LE/CI organizations (at USCYBERCOM) receive reports of
1940incidents that may support LE/CI actions.
1941(k) The LE/CI organizations (at USCYBERCOM) coordinate the
1942release of CND LE/CI information, with appropriate release authority, from
1943originating agencies to support information sharing across the CC/S/A/FAs.
1944(l) The NTOC provides AS&W and a variety of technical alerts to
1945USCYBERCOM that are shared (as appropriate) with other tiers to direct
1946response actions.
1947(4) Tier II Reporting. Tier II receives reports from the subordinate levels
1948(Tier III). This information can also be shared (if applicable) with other Tier II
1949entities to provide insight into activity that can potentially affect its region or
1950theater of operations. Tier II organizations report incidents to USCYBERCOM
1951IAW Appendix A to Enclosure B (Cyber Incident and Reportable Cyber Event
1952Categorization). All incident reports should be submitted through the JIMS
1953unless prevented by extenuating circumstances (e.g., no access to JIMS). All
1954organizations must report through their CNDSP. The CNDSP enters the report
1955into the JIMS. Lateral reporting may be required by their operational or
1956administrative chain of command. Tier II entities include:
1957(a) CND Service Providers (CNDSPs)
19581. CNDSPs report incidents within their subscriber community
1959to USCYBERCOM through the JIMS.
19602. CNDSPs share valuable information about incidents being
1961reported (if applicable) with other peer organizations.
19623. CNDSPs provide feedback to reporting organizations as
1963information is developed. Subordinate echelons in the reporting chain are
1964responsible for relaying information to the originating point and developing
1965procedures to disseminate the information, as appropriate, within their
1966constituent communities (e.g., Network Operations Security Center (NOSC),
1967Theater Network Control Center (TNCC), or Global Network Control Center
1968(GNCC) within the CC/S/A/FA and/or DISA NetOps Center (DNC) within its
1969AOR).
1970(b) Theater NetOps Center
19711. Incidents are reported from the joint HQ or activity to its Tier
1972II CNDSP, the Regional C4I Control Center (CCC)/TNCs, and the Combatant
1973Command HQ.CJCSM 6510.01B
197410 July 2012
1975C-7 Enclosure C
19762. Reports are submitted from the CCC/TNCs to the Joint Staff
1977National Military Command Center as appropriate. CCC/TNCs and Combatant
1978Command HQ report information about events and incidents to Tier I.
19793. The TNCs issue technical and operational directives to
1980Service theater NOSCs and agency theater NOSCs.
1981(c) Service or Defense Agency Network Operations Security Center
19821. Each Service and Defense agency NOSC providing CND
1983services to a Service or Defense agency component supporting a regional
1984Combatant Command makes available warnings, reports, information, data,
1985and statistics pertinent to the protection of resources assigned to the regional
1986Combatant Command.
19872. Service and Defense agency NOSCs coordinate and report
1988network deception systems to their Tier II CNDSP and USCYBERCOM, for
1989awareness and correlation purposes, prior to connection to any DoD
1990information network. In addition, for situation awareness purposes, they
1991report network deception system deployments (e.g., honey pots) within
1992Combatant Command Service components to that Combatant Command.
19933. Service and Defense agency NOSCs report information to
1994USCYBERCOM through their Tier II CNDSP for inclusion into the DoD
1995Protected Traffic List.
19964. Service and Defense agency elements subordinate to a
1997Combatant Commander (geographic and/or functional) simultaneously report
1998to a Combatant Command NetOps organization and to their Service or Defense
1999agency NOSC or DNC. Reporting should be accomplished IAW Combatant
2000Command guidance.
2001(d) Combatant Command HQ. Joint HQ or Regional CCC/TNCs
2002must forward, or make available through the JIMS, information about events
2003and incidents reported to them from the affected components to CC HQ. This
2004helps CC HQ maintain an accurate operational view in its AOR.
2005(e) Global NetOps Control Center
20061. GNCCs receive informational reports from Service elements
2007and Global NetOps Support Centers (GNSCs).
20082. GNCCs disseminate CNDSP feedback within the constituent
2009communities as appropriate.CJCSM 6510.01B
201010 July 2012
2011C-8 Enclosure C
20123. GNCCs provide recommendations and advise senior
2013leadership on COAs as appropriate.
2014(f) Global NetOps Support Center
20151. GNSCs report incidents through defined channels (e.g.,
2016CNDSP) or as directed by command instructions or policy.
20172. GNSCs issue technical and operational directives to Service
2018theater NOSCs and agency theater NOSCs.
2019(g) Theater Network Control Center
20201. TNCCs receive informational reports from Service elements
2021and TNCs.
20222. TNCCs provide recommendations and advise senior
2023leadership on COAs as appropriate.
2024(h) Theater C4I Control Center (TCCC)
20251. TCCCs receive informational reports from Service elements
2026and TNCs.
20272. TCCCs provide recommendations and advise senior
2028leadership on COAs as appropriate.
2029(i) CC/S/A/FAs. Incidents (or reportable events) that occur within
2030their subordinate levels regardless of classification are reported to the
2031appropriate CNDSP.
2032(5) Tier III Reporting. Tier III initiates local operational reporting and
2033receives support from and responds to direction from a designated Tier II
2034CNDSP. Tier III reporting, notification, and communication provides
2035information about what is occurring to the Network Service Centers (NSCs) at
2036Service component headquarters, major commands, and Service elements at
2037installations (e.g., base, post, camp, and station (B/P/C/S) information
2038systems or joint activities that serve as a focal point for reporting and handling
2039incidents and network management at the lowest level). Tier III entities
2040include:
2041(a) Base/Post/Camp/Stations (B/P/C/Ss). B/P/C/Ss represent
2042the lowest level in which reportable events and incidents occur and from which
2043they must be reported.CJCSM 6510.01B
204410 July 2012
2045C-9 Enclosure C
20461. Service elements at B/P/C/Ss report through Service-defined
2047channels to the Service or agency NOSC, or their CNDSP, which report to
2048USCYBERCOM.
20492. Service elements subordinate to a commander of a
2050Combatant Command simultaneously report to a Combatant Command GNCC
2051and a TNCC, as directed by Combatant Command instructions or policy.
20523. Joint activities report incidents to their host command NSC,
2053Combatant Command, and TNC.
2054(b) Network Service Centers. NSCs serve as focal points for
2055reporting and handling incidents and network management at the lowest level.
2056c. Additional Reporting Structures. Additional reporting structures exist in
2057order to support the IC, LE, CI, and other operational reporting requirements.
2058(1) Operational Report (OPREPs)
2059(a) OPREPs are issued by any unit commander to provide
2060appropriate senior leadership immediate notification of an incident that has
2061impacted or may impact the mission and/or operations.
2062(b) Specifically, Category 1, 2, 4, and 7 events or incidents affecting
2063Mission Assurance Category (MAC) I or II ISs must be reported using OPREP-3
2064reporting procedures and structure.
20651. Root Level Intrusion (Category 1). Unauthorized privileged
2066access to MAC I or MAC II IS(s).
20672. User Level Intrusion (Category 2). Unauthorized nonprivileged access to MAC I or MAC II IS(s).
20683. Denial of Service (Category 4). Denial of Service (DoS)
2069against MAC I or MAC II IS(s).
20704. Malicious Logic (Category 7). Active propagation of malware
2071infecting an IS or malicious code adversely affecting the operations and/or
2072security of an IS. OPREPs for previously reported outbreaks are not submitted
2073(e.g., outbreak of virus reported 2 months ago).
2074(c) OPREP-3 reports will be submitted as soon as possible after
2075cyber incidents have been detected. Speed takes priority over detail.CJCSM 6510.01B
207610 July 2012
2077C-10 Enclosure C
2078(d) OPREP-3 initial reports will contain only as much of the
2079requested information as is immediately available. The initial report must not
2080be delayed to gain additional information.
2081(e) USCYBERCOM submits OPREP-3 for DoD-wide computer
2082network incidents to USSTRATCOM.
2083(2) Law Enforcement and Counterintelligence Reporting Structure
2084(a) CND reportable events or incidents that may lead to criminal
2085investigations require notification and reporting to LE/CI. Data from the
2086incident will be preserved in a forensically sound manner to enable possible
2087criminal prosecution or LE/CI operations.
2088(b) At minimum, Category 1, 2, and 4 incidents are reported to DoD
2089LE/CI IAW established CC/S/A/FA procedures. Incidents involving potential
2090or actual compromise of classified ISs or DoD information networks are
2091reported through standard CND technical reporting channels.
20921. Commanders request investigations and the servicing LE/CI
2093organization determines if investigations are to be opened IAW DoDI 5505.3
2094(reference g).
20952. Incidents are reported to the appropriate LE/CI organization
2096at the lowest level at which they are discovered IAW established CC/S/A/FA
2097procedures.
20983. The investigative community has substantial authority to
2099access official government and private sector information, consistent with
2100normal investigative procedures. Ideally, the operational community should
2101cooperate with the servicing LE/CI organization, which will in turn coordinate
2102with LE/CI organizations (at USCYBERCOM). The LE/CI organizations
2103disseminate information to other LE/CI organizations, including non-DoD
2104LE/CI organizations if appropriate.
21054. Reporting incidents through LE/CI channels does not
2106eliminate the requirement to report incidents through standard technical and
2107operational reporting channels.
21085. LE/CI matters and investigations regarding sensitive
2109compartmented information (SCI) networks, ISs, and cleared SCI personnel will
2110be forwarded to SCI LE/CI authorities.
2111(3) Intelligence Community Reporting Structure. IC reporting is
2112required for any reportable events or incidents that affect classified ISs orCJCSM 6510.01B
211310 July 2012
2114C-11 Enclosure C
2115involve foreign threats to DoD information networks and ISs. CC/S/A/FAs
2116report incidents (or reportable events) affecting Top Secret (TS)/SCI networks
2117directly to organizations as directed under SCI directives and policies as
2118provided by the principal accrediting authority.
2119(a) DoD SCI organizations will provide reporting directly to the DIA
2120Information Assurance Protection Center (IAPC).
2121(b) Member organizations operating under the authority of the NSA,
2122NRO, and NGA shall report to their agency authority IAW internal agency
2123policy.
2124(c) DoD IC members will report all reportable events directly to the
2125IC-IRC within established reporting timelines.
21261. The IC-IRC will ensure all TS/SCI reports are reported to
2127USCYBERCOM to ensure information about new vulnerabilities, exploits, or
2128incidents reported on compartmented ISs is disseminated to the appropriate IC
2129member organization for remediation.
21302. All requests for DoD SCI information will be vetted through
2131the IC-IRC to the responsible community member organization.
21323. Additional guidance on phased reporting procedures for
2133intelligence reporting can be found in Appendix B to Enclosure F (Intelligence
2134Support to Cyber Incident Reporting).CJCSM 6510.01B
213510 July 2012
2136C-12 Enclosure C
21373. Operational Reporting Practices
2138a. Incident reporting plays an essential role in understanding how and
2139when DoD information networks and ISs are being attacked. Achieving this
2140understanding requires a disciplined reporting framework, and individuals
2141responsible for incident reporting are expected to follow some general best
2142practices as part of this process.
2143b. Critical success factors for incident reporting include the following:
2144(1) Timeliness. Reporting incidents aids in identifying,
2145characterizing, and responding to adversarial activity. The Department of
2146Defense’s ability to respond effectively while minimizing damage is highly
2147dependent on the length of time between when activity is detected and when it
2148is first reported. Reporting incidents in a timely manner accelerates the
2149Department of Defense’s ability to develop and implement defensive measures.
2150(2) Quality and Completeness. An incident report’s value is
2151determined by the quality of the information. The more useful information
2152contained in the report, the better it can help analysts understand the
2153technical details, root cause(s), and potential impact of the incident. Incident
2154reports should be regularly updated with as much useful information as is
2155available at the time.
2156(3) Enterprise-Wide Visibility of Reporting. All incident reports
2157shall be submitted to the JIMS. The consistent, complete, and timely reporting
2158of incident data into a single database is necessary in order to reflect the
2159collective reporting of adversarial activity and can help shape tactical, strategic,
2160and military strategies for response. This information can then later be used to
2161perform trending analysis, correlation, and fusion.
2162(4) Operational Effectiveness. Incident reports should be managed
2163effectively from creation to resolution. This management is an ongoing and
2164iterative process. Once an incident is reported, it should be updated when its
2165status changes and until the incident is resolved. This allows commanders
2166and others responsible for directing incident response strategies to remain
2167informed about the status of their ISs or DoD information networks and the
2168impact of the incident on their missions. Timely updates and the effective
2169sharing of relevant incident information can also help other DoD organizations
2170recognize the activity and mitigate any negative impact on their mission(s).CJCSM 6510.01B
217110 July 2012
2172C-13 Enclosure C
2173c. Organizations at all levels report changes in the status of reportable
2174events, incidents, and incident handling actions. There are a variety of reasons
2175why status reports are issued to the appropriate organizations. Some reasons
2176may include, but are not limited to:
2177(1) Changes in the characteristics of the reportable cyber event or
2178incident activity.
2179(a) Increase or decrease in activity.
2180(b) Operational impact(s) on an IS, DoD information network, or
2181mission.
2182(2) Corrective actions that change the status of the reportable cyber
2183event or incident activity.
2184(3) Closure of a reportable cyber event or incident.
21854. Reporting Vehicles
2186a. All reportable events and incidents must be reported in a timely manner
2187through approved reporting mechanisms. The primary vehicle for reporting
2188incidents (and reportable events) is the JIMS. Other mechanisms are available,
2189but the JIMS maintains the canonical records for all incident reports.
2190b. Table C-1 (Reporting Vehicles) summarizes reporting vehicles available
2191in order of preference. Other mechanisms should only be used when the JIMS
2192cannot be accessed or when circumstances require the use of other reporting
2193channels. Regardless of how initial reporting is done, information regarding
2194the report must be added to the JIMS.CJCSM 6510.01B
219510 July 2012
2196C-14 Enclosure C
2197Table C-1. Reporting Vehicles
2198c. The principal reporting vehicle for DoD SCI ISs is a Joint Worldwide
2199Intelligence Communications System (JWICS) e-mail to the IAPC at
2200iapc@dia.ic.gov. Reporting instructions and format can be found at
2201http://www.dia.ic.gov/admin/ds/iapc at the “DIA Incident Reporting Form.”
2202d. Submit reports using the most protected means available for the
2203affected IS.
2204(1) Use SIPRNET or secure phone/fax if those ISs are available.
2205(2) Unclassified reporting vehicles (NIPRNET, non-secure fax) should
2206only be used for incidents on unclassified ISs.
2207(3) USCYBERCOM will work with NOSCs, TNCs, and GNCCs/TNCCs/
2208Tier II CNDSPs to correlate and deconflict incident reporting information.
2209(4) If necessary, potentially compromised assets will be removed from
2210the DoD information network prior to reporting an incident.
2211e. Reporting will be done on a DoD information network other than the
2212potentially compromised IS to remove the possibility of an attacker monitoring
2213the compromised DoD information network and potentially intercepting the
2214incident report.CJCSM 6510.01B
221510 July 2012
2216C-15 Enclosure C
22175. Reporting Timelines
2218a. The reporting timelines establish the minimum requirements and
2219timeframes for which incidents will be reported. They are designed to expedite
2220reporting of incidents where national-level coordination and action may serve
2221to mitigate or prevent damage to DoD information networks.
2222b. All incidents will be reported IAW the requirements and timeframes
2223defined in Appendix A to Enclosure C (Reporting Timelines).
2224c. These requirements will not preclude the rapid reporting of any cyber
2225event or incident deemed necessary by the responsible CNDSP or CCIR and do
2226not supersede any requirements established by USCYBERCOM CND CCIRs.
2227These CCIRs may be found on USCYBERCOM’s Web site at
2228https://www.cybercom.smil.mil/J3/orders/default.aspx.
2229d. Additionally, as noted in Appendix A to Enclosure C (Reporting
2230Timelines), some incidents are also reportable using OPREP-3 reporting
2231procedures and structure IAW CJCSM 3150.03, “Joint Reporting Structure
2232Event and Incident Reports” (reference i).
22336. Reporting Formats
2234a. The preferred method for reporting incidents is through the JIMS. The
2235JIMS provides a structured format to conveniently record and submit
2236information about the reportable cyber event or incident to a central database
2237maintained by USCYBERCOM.
2238b. JIMS Report Format. The JIMS reporting format is used by Tier II
2239CNDSP4 to report incidents to the USCYBERCOM. It is the primary reporting
2240format and mechanism for submitting reports.
22414 Tier II CNDSPs are responsible for ensuring incidents and events are reported
2242in JIMS. However, CC/S/A/FAs, in conjunction with their Tier II CNDSP, may
2243authorize their Tier III organizations to also report incidents in JIMS.CJCSM 6510.01B
224410 July 2012
2245C-16 Enclosure C
2246c. General Report Format
2247(1) This format is used to report incidents and reportable events from
2248Tier III entities to the respective Tier II CNDSP. CNDSPs are then responsible
2249for submitting these reports into the JIMS.
2250(2) Appendix B to Enclosure C (General Cyber Incident Report Format)
2251lists the types of information that will be provided.
2252(3) The format provides a structure for initially reporting incidents and
2253reportable events by JIMS, telephonically, by secure fax, or by other electronic
2254means.
2255(4) On initial discovery of an incident, not all information will be
2256known; however, as much information as possible should be provided,
2257regardless of the means used to report. Over time, as additional information is
2258identified, follow-on reporting shall be made to complete the form.
2259(5) Information provided in this format is then used to submit an
2260incident to the JIMS.
2261(6) CC/S/A/FAs may append more information to the report format to
2262require further information for internal analysis or uses.
2263(7) As more information becomes available, provide additional details as
2264updates to the initial report in follow-on incident and reportable event
2265reporting.
2266(8) In order for a report to be considered “complete,” it must contain, at
2267a minimum, the information listed in Appendix B to Enclosure C (General
2268Cyber Incident Report Format).
22697. Reporting Considerations
2270a. In addition to the reporting requirements already described, there are
2271several other factors to consider when reporting incidents, to include
2272classification level and whether or not they involve personally identifiable
2273information (PII). Both will have an effect and impose additional requirements
2274on the reporting, including the timeframes and methods.CJCSM 6510.01B
227510 July 2012
2276C-17 Enclosure C
2277b. Loss or Suspected Loss of Personally Identifiable Information (PII) Data
2278(1) PII is any information about an individual maintained by a DoD
2279entity, including, but not limited to, education, financial transactions, medical
2280history, and criminal or employment history. It also includes information that
2281can be used to distinguish or trace an individual’s identity, such as his or her
2282name, social security number, date and place of birth, mother’s maiden name,
2283biometric records, etc., including any other personal information linked or
2284linkable to an individual.
2285(2) Incidents5 that also involve loss or suspected loss of PII data require
2286CC/S/A/FAs to augment their processes to report this activity separately IAW
2287DoD 5400.11-R, “Department of Defense Privacy Program” (reference j).
2288(3) The Department of Defense has established guidance to protect PII.
2289This is mandated through legal, federal and DoD guidance to include FISMA
2290(reference a), OMB Circular A-130 (reference b), DoD 5400.11 (reference j), the
2291Privacy Act of 1974 (reference k), and OMB memorandum M-07-16,
2292“Safeguarding Against and Responding to the Breach of Personally Identifiable
2293Information” (reference l). CC/S/A/FAs must ensure that PII not explicitly
2294cleared for public release is protected IAW DoD policy. This includes meeting
2295or exceeding requirements described in OMB memorandum M-06-16,
2296“Protection of Sensitive Agency Information (reference m) and OMB
2297memorandum M-06-19, “Reporting Incidents Involving Personally Identifiable
2298Information and Incorporating the Cost for Security in Agency Information
2299Technology Investments” (reference n).
2300(4) The policy applies to any DoD-owned or controlled ISs or services,
2301regardless of classification or sensitivity, that receive, process, store, display or
2302transmit DoD information.
2303(5) Loss or suspected loss of PII shall be reported as follows:
2304(a) Reports must be submitted to the US-CERT within 1 hour of the
2305incident. Loss of PII information on DoD or IC information networks must also
2306be reported to US-CERT within 1 hour of the incident.
23075 Incidents or events (e.g., CAT 1, 2, or 5) could involve the loss of PII and
2308require additional reporting requirements.CJCSM 6510.01B
230910 July 2012
2310C-18 Enclosure C
2311(b) Reports must be submitted to the CC/S/A/FA Privacy Office
2312POC within 24 hours. The POC then reports to the DoD Privacy Office within
231348 hours or as established by the Defense Senior Privacy Official.
2314(6) Criteria for determining the risk include:
2315(a) Will the breach cause harm?
2316(b) What is the risk level?
2317(c) How many individuals are affected?
2318(d) Is the information accessible and usable?
2319(7) Failing to protect PII can result in civil penalties against DoD
2320components and criminal penalties against individuals.
2321c. Classification Level. The security classification of an incident is
2322determined IAW DoDI O-3600.02 (reference f). Incident reports will be
2323protected based on their classification and sensitivity. All incidents occurring
2324on the SIPRNET shall be classified at least Secret. Incident classifications
2325higher than Secret depend on the classification level of the material involved
2326(e.g., Top Secret or compartmented), overall impact, and compromise potential.
2327Incidents occurring on NIPRNET ISs will be unclassified and marked Controlled
2328Unclassified Information (CUI) unless exploitation of information in the report
2329by an adversary would result in a classified information compromise or
2330significant negative impact on a national security mission.
23318. Exercise Reporting
2332a. Incident and event categorization and reporting will be IAW this manual.
2333b. USCYBERCOM will provide separate guidance on identifying exercise
2334incidents/events reported in the JIMS and the processes for deconflicting realworld and exercise activities.CJCSM 6510.01B
233510 July 2012
2336Appendix A
2337C-A-1 Enclosure C
2338APPENDIX A TO ENCLOSURE C
2339REPORTING TIMELINES
23401. Introduction
2341a. The reporting timelines establish the minimum requirements and
2342timeframes by which incidents will be reported. USCYBERCOM may issue
2343changes to reporting requirements and timeframes based on ongoing
2344operations or activities. The reporting timelines are designed to expedite
2345reporting of incidents where national-level coordination and action may serve
2346to mitigate or prevent damage to the DoD information networks.
2347b. Included below are definitions for the reporting timelines columns:
2348(1) Impact. The degree to which an incident or event adversely
2349impacts, or has the potential to impact, the successful accomplishment of
2350operational missions and the confidentiality, integrity, or availability of DoD
2351information networks and ISs. Impact helps characterize the estimated
2352damage or loss resulting from the incident and contributes to the collective
2353understanding of the DoD-wide security posture. Additional information is
2354available in Appendix C to Enclosure D (Impact Assessment Matrix).
2355(2) Initial Notification to Next Tier. The required notification timeframe
2356between the discovery or awareness of an incident or event and the initial
2357notification to the designated upstream tier. Initial notification serves to
2358provide preliminary information that an incident or event has occurred to those
2359responsible for directing response actions within organizations and commands.
2360(3) Initial Report to Next Tier. The required reporting timeframes
2361between the discovery or awareness of an incident or event and the initial
2362electronic submission of a report such that it is available to the upstream tier.
2363Initial reports serve to provide details about the incident or event and contain
2364preliminary analysis to characterize the potential technical and organizational
2365implications. Initial reports are updated throughout the life cycle as further
2366analysis and information become available.
2367(4) Initial Submission to JIMS. The required reporting timeframe
2368between the discovery and awareness of an incident or event and the initial
2369entry into the JIMS such that it is available to the upstream tier(s). The JIMS
2370is the central catalog for managing event and incident reports. Consistent and
2371comprehensive reporting is required in order to accurately characterize the
2372threat environment and security posture of DoD information networks such
2373that a strategic and tactical COA may be developed and implemented.CJCSM 6510.01B
237410 July 2012
2375Appendix A
2376C-A-2 Enclosure C
2377(5) Minimum Reporting. This defines the lowest tier for which an
2378incident or event will be reported. The minimum reporting requirement can be
2379changed by USCYBERCOM direction.
2380Category
2381Impact
2382Initial
2383Notification to
2384Next Tier
2385Initial Report
2386to Next Tier
2387Initial
2388submission to
2389JIMS
2390Minimu
2391m
2392Reportin
2393g
23941
2395Root Level
2396Intrusion*
2397(Incident)
2398High Within 15
2399minutes Within 4 hours Within 6 hours Tier I
2400Moderate Within 2 hours Within 8 hours Within 12 hours Tier I
2401Low Within 4 hours Within 12 hours Within 24 hours Tier I
24022
2403User Level
2404Intrusion*
2405(Incident)
2406High Within 15
2407minutes Within 4 hours Within 6 hours Tier I
2408Moderate Within 2 hours Within 8 hours Within 12 hours Tier I
2409Low Within 4 hours Within 12 hours Within 24 hours Tier I
24103
2411Unsuccessful
2412Activity
2413Attempt
2414(Event)
2415Any Within 4 hours Within 12 hours Within 24 hours Tier II
24164
2417Denial of
2418Service*
2419(Incident)
2420High Within 15
2421minutes Within 4 hours Within 6 hours Tier I
2422Moderate Within 15
2423minutes Within 4 hours Within 6 hours of discovery Tier I
2424Low
2425As directed by
2426CC/S/A/FA
2427Guidance
2428As directed by
2429CC/S/A/FA
2430Guidance
2431As directed by
2432CC/S/A/FA
2433Guidance
2434Tier I
24355
2436NonCompliance
2437Activity
2438(Event)
2439All NonCompliance
2440Events
2441Within 4 hours Within 12 hours Within 48 hours Tier II
24426 Reconnaissance (Event) Any
2443As directed by
2444CC/S/A/FA
2445Guidance
2446As directed by
2447CC/S/A/FA
2448Guidance
2449As directed by
2450CC/S/A/FA
2451Guidance
2452Tier II
2453Table C-A-1. Reporting TimelinesCJCSM 6510.01B
245410 July 2012
2455Appendix A
2456C-A-3 Enclosure C
24577
2458Malicious
2459Logic
2460(Incident)
2461High Within 15
2462minutes Within 4 hours Within 6 hours Tier I
2463Moderate Within 2 hours Within 8 hours Within 12
2464hours Tier II
2465Low
2466As directed by
2467CC/S/A/FA
2468Guidance
2469As directed by
2470CC/S/A/FA
2471Guidance
2472As directed by
2473CC/S/A/FA
2474Guidance
2475Tier II
24768
2477Investigating
2478(Event)
2479N/A Within 2 hours of
2480notification6
2481Consistent with
2482the most severe
2483possible
2484interpretation
2485Within 24
2486hours Tier II
24879
2488Explained
2489Anomaly
2490(Event)
2491N/A N/A Within 24 hours Within 72
2492hours Tier II
2493Table C-A-1. Reporting Timelines (continued)
24942. Reporting Timelines
2495a. Reporting timelines will be based on the current and potential impact of
2496the incident or event on the confidentiality, availability, and integrity of
2497organizational operations, organizational assets, or individuals.
2498b. Additionally, abbreviated reporting timelines give the CNDSP more time
2499to collect, process, and correlate information concerning reportable events and
2500incidents before reporting them at the national level.
2501c. Follow-on reports are submitted as directed by the higher CND
2502organizations or headquarters.
2503(1) If no direction is provided, follow-on reports are submitted within 8
2504hours of the discovery of new information about the incident.
2505(2) Follow-on reports provide the raw details needed for the regional or
2506global teams to understand the technical nature of the problem and is merged
2507with information obtained from other reports to highlight regional or global
2508trends.
2509(3) This report is forwarded IAW Table C-1 (Reporting Vehicles).
25106 Acknowledgement from the asset owner that it is investigating the issue.CJCSM 6510.01B
251110 July 2012
2512Appendix A
2513C-A-4 Enclosure C
2514d. USCYBERCOM provides feedback to reporting organizations as more
2515information becomes known. Subordinate layers in the reporting channels are
2516responsible for relaying this information to the originating point and developing
2517procedures to disseminate the information as appropriate within their
2518constituent communities (NOSCs, TNCC, or GNCC within the CC/S/A/FAs
2519and/or TNC within their AOR). The format is also used by NOSCs or
2520Combatant Command TNCCs and GNCCs and/or TNC organizations to report
2521information developed through observation, correlation, analysis, or other
2522means.CJCSM 6510.01B
252310 July 2012
2524Appendix B
2525C-B-1 Enclosure C
2526APPENDIX B TO ENCLOSURE C
2527GENERAL CYBER INCIDENT REPORT FORMAT
25281. General Cyber Incident Report Format. Table C-B-1 describes the report
2529format used for the initial report of an incident or reportable event. The format
2530provides a structure for reporting initial incidents by secure fax, telephonically,
2531or by other electronic means. Initial reports may be incomplete. Reporting
2532organizations should balance the necessity of timely reporting (reports with
2533critical information) versus complete reports (those with all blocks completed).
2534Timely reporting is vital, and complete information should follow as details
2535emerge.
2536Field Description
2537Cyber Incident Tracking Information
2538Reporting Incident
2539Number
2540Identify the reporting CNDSP (e.g., CERT/CIRT) reference number for
2541tracking the incident. (Generated by JIMS.)
2542Organization Tracking Identify the organization responsible for tracking the incident.
2543Reporting Information
2544Name The first and last name of the individual reporting the incident.
2545Organization The name of the organization reporting the incident.
2546Telephone The telephone or Defense Switch Network (DSN) number to be used to
2547reach the reporting entity for additional information. The number can
2548be for an individual’s number or the central number for the organization
2549(e.g., operations center).
2550E-mail The e-mail address that should be used to reach the reporting entity for
2551additional information. This may be the e-mail address of an individual
2552or central e-mail for the organization (e.g., operations center).
2553Fax The fax number to be used to reach the reporting entity for additional
2554information.
2555Alternative Contact The name, telephone number, and e-mail of an alternative contact in the
2556event the reporter is not available.
2557Table C-B-1. General Cyber Incident Report FormatCJCSM 6510.01B
255810 July 2012
2559Appendix B
2560C-B-2 Enclosure C
2561Field Description
2562Categorization Information
2563Primary Incident
2564Category
2565Identify the primary underlying cause of the incident being reported IAW
2566Appendix A to Enclosure B (Incident and Reportable Event
2567Categorization).
2568Secondary Incident
2569Category Identify any secondary causes for which the incident is being reported, if
2570more than one category applies, IAW Appendix A to Enclosure B (Incident
2571and Reportable Event Categorization).
2572Delivery
2573Vector
2574Identify delivery vector IAW Appendix A to Enclosure D (Delivery Vectors.)
2575System Weaknesses Identify delivery vector IAW with Appendix B to Enclosure D (System
2576Weaknesses).
2577Incident Status
2578Status Status of the incident (“OPEN,” “INVESTIGATING,” “MITIGATED,” or
2579“CLOSED”).
2580Incident Start Date ZULU date-time group (DTG) of the earliest event that was incorporated
2581into the incident. Provide year/month/day/hour/minute/ seconds.
2582Incident End Date ZULU DTG that incident actually ended. Provide year/month/day/hour/
2583minute/seconds.
2584Last Update ZULU DTG of the last time the report was updated. Provide
2585year/month/day/hour/minute/seconds.
2586Date Reported ZULU DTG of when the incident was first reported to the CNDSP. Provide
2587year/month/day/hour/minute/seconds.
2588System
2589Classification
2590Report the classification of the IS under attack (i.e., Unclassified,
2591Confidential, Secret, TS, SCI). This field is NOT used to classify the
2592reported incident.
2593Action Taken Indicates what action has been taken in response to the incident. Include
2594notifications and associated reports. Additionally, include whether a copy
2595of a media was taken (image hard drives), or logs collected and
2596disposition of mediums and logs.
2597Table C-B-1. General Cyber Incident Report Format (continued)CJCSM 6510.01B
259810 July 2012
2599Appendix B
2600C-B-3 Enclosure C
2601Field Description
2602Technical Details
2603Event/Incident
2604Description
2605Provide a narrative description of the incident with technical
2606details. Include DTGs of significant events (start, stop, or change
2607of activity). State the use of the targeted IS and whether the IS is
2608online or offline. Indicate whether the incident is ongoing.
2609Root Cause(s) Identify the IS specific cause(s) of the incident. The root cause
2610expands upon the identified delivery vector(s) and IS weaknesses
2611by precisely identifying the sets of conditions allowing the
2612incident to occur. Indicate whether the DAA or CIO had accepted
2613a risk that led to the incident.
2614Source IP and Port Provide source IP with resolution data identifying owner and
2615country of source IP machine. Note: The source IP could be a
2616DoD IP. If the intruder is known, provide all identifying
2617information to include the intruder’s objective, if known. Source
2618IP is not necessarily indicative of true origin. Footnote the source
2619of resolution/attribution data (i.e., ARIN.org). Insert “Not
2620Applicable” for incidents that do not involve source IP or port.
2621Intruder(s) (if
2622known)
2623Identify the intruder or group responsible for the incident, if
2624known.
2625Origin (Country) Identify the source IP’s country of origin.
2626Target IP(s) and
2627Port
2628Provide target IP with resolution identifying responsible
2629command and physical location of target IP machine (e.g.,
2630B/C/P/S, etc.). Footnote the source of resolution/attribution
2631data (i.e., DDD NIC, nslookup, and whois). If machine is behind
2632a network address translation enabled (NAT’ed) router or firewall
2633then also provide the wide area network (WAN) routable address
2634(i.e., the Internet/SIPRNET routable IP address).
2635Technique, Tool,
2636or Exploit Used
2637Identify the technique, tool, or exploit used.
2638Operating System
2639(OS) and OS
2640Version
2641Record the OS and version number of the OS where the incident
2642occurred.
2643Use of Target (e.g.,
2644Web Server, File
2645Server, Host)
2646What the intruder/attacker used the target IS for, after it was
2647exploited, if applicable.
2648Method of
2649Detection
2650Identify how the intrusion was detected (e.g., external
2651notification, log files, network monitoring, IDS, user).
2652Table C-B-1. General Cyber Incident Report Format (continued)CJCSM 6510.01B
265310 July 2012
2654Appendix B
2655C-B-4 Enclosure C
2656Field Description
2657Sites Involved
2658Major Command Identify the CC/S/A/FAs targeted based on owner of target IP
2659address (e.g., USN, USAF, USSTRATCOM, and DISA).
2660Combatant
2661Command
2662Identify the Combatant Command (geographical and/or
2663functional) targeted based on the owner of the target IP address.
2664Physical Location
2665(base, camp, post,
2666or station)
2667Identify the B/C/P/S affected by the intrusion and/or who owns
2668the target IP and where the physical system resides.
2669DoD Information
2670Network
2671Identify the DoD information network on which the incident
2672occurred (e.g., NIPRNET or SIPRNET).
2673Detecting Unit or
2674Organization
2675The name of the reporting unit or organization.
2676Affected Unit or
2677Organization
2678The name of the reporting affected unit or organization.
2679Impact Assessment
2680Systems Affected Number of ISs affected by the incident.
2681Operational
2682Impact
2683Identify any detrimental effects on ability to perform mission by
2684organization directly affected. Include organizations affected
2685(e.g., due to being network users). Include impact on the ability
2686of other organization(s) to perform mission. This includes an
2687operational impact assessment IAW Appendix C to Enclosure D
2688(Impact Assessment Matrix).
2689Technical Impact Identify any detrimental effects on the technical capabilities of
2690the organization (e.g., data loss, service degradation, effects on
2691other systems). This includes a technical impact assessment
2692IAW Appendix C to Enclosure D (Impact Assessment Matrix). If
2693the technical impact cannot be determined for some reason (e.g.,
2694limited details or analysis), use Table C-B-2 (Initial Impact
2695Assessment) for a limited impact assessment.
2696Staff Hours Lost This is reported as an update record and may cause the impact
2697field to be updated. Amount of time technical support is required
2698to identify, isolate, mitigate, resolve, and recover from the attack
2699and repair the attacked IS (do not include analyst time spent
2700analyzing the incident).
2701Encompassing
2702Cost
2703Costs (both direct and indirect), to include all actions from initial
2704detection through investigation, response, and recovery. This
2705should include, but is not limited to, workforce expenses, analyst
2706time, hardware / software, travel and shipping costs, and lost
2707productivity.
2708Table C-B-1. General Cyber Incident Report Format (continued)CJCSM 6510.01B
270910 July 2012
2710Appendix B
2711C-B-5 Enclosure C
2712Field Description
2713Additional Reporting or Coordination
2714OPREP 3
2715Reporting
2716State whether the incident was reported via OPREP 3 and what
2717HQ received the report. Attach a copy of the OPREP 3 report to
2718this incident report, if applicable.
2719Intel Reporting State whether the incident was reported to the IC. If reported,
2720identify the agency contacted and any specific actions that have
2721been coordinated.
2722LE/CI Reporting State whether the incident was reported to the LE/CI
2723community. If reported, identify the agency contacted and any
2724specific actions that have been coordinated.
2725DAA/CIO
2726Reporting
2727Notify and coordinate with the DAA/CIO on cyber incidents.
2728Other
2729Exercise Name Name of the exercise, if applicable.
2730Operation Name Name of the operation or focused operation, if applicable.
2731Table C-B-1. General Cyber Incident Report Format (continued)
27322. Initial Impact Assessment Matrix. The System Impact Matrix that follows
2733may be used to provide an initial impact assessment when submitting a report.
2734Initial assessment should be performed quickly even with limited details and
2735analysis. This table calculates impact based on the type of device affected and
2736the incident category. It should only be used during the initial reporting
2737process. The more complete impact assessment conducted later in the incident
2738handling process is done IAW Appendix C to Enclosure D (Impact Assessment
2739Matrix).CJCSM 6510.01B
274010 July 2012
2741Appendix B
2742C-B-6 Enclosure C
2743Cyber Incident and Reportable Cyber Event Category
2744Network
2745Device CAT 1 CAT 2 CAT 3 CAT 4 CAT 5 CAT 6 CAT 7
2746Backbone High High Low High Low Low Low
2747Router High High Low High Moderate Low Low
2748Network
2749Management
2750/ Security
2751Server
2752High High Low High Moderate Low Moderate
2753Non-Public
2754Server Moderate Moderate Low Moderate Moderate Low Moderate
2755Public Server Low Low Low Moderate Low Low Moderate
2756Workstation Low Low Low Moderate Low Low Moderate
2757Table C-B-2. Initial Impact AssessmentCJCSM 6510.01B
275810 July 2012
2759Appendix C
2760C-C-1 Enclosure C
2761APPENDIX C TO ENCLOSURE C
2762CYBER INCIDENT REPORTING DIAGRAMS
27631. High-Level Overview of Reporting. The following reporting scenario depicts
2764the general DoD-wide process for reporting incidents, exchanging information,
2765and providing feedback to the DoD community.
2766Figure C-C-1. High-Level Overview of ReportingCJCSM 6510.01B
276710 July 2012
2768Appendix C
2769C-C-2 Enclosure C
27702. Cyber Event Detected by Installation. The following reporting scenario
2771depicts the general process for how incidents detected at a DoD installation
2772(e.g., B/P/C/S) are reported. The actions outlined in process may occur
2773simultaneously following the initial detection of an anomalous activity.
2774Figure C-C-2. Cyber Event Detected by InstallationCJCSM 6510.01B
277510 July 2012
2776Appendix C
2777C-C-3 Enclosure C
27783. Cyber Event Detected Within Combatant Command. The following
2779reporting scenario depicts the general process for how incidents detected
2780within a Combatant Command are reported. One of the key elements in this
2781scenario is that the Combatant Command HQ is provided DoD data necessary
2782to maintain situational awareness to exercise command and control authority
2783within its AOR.
2784Figure C-C-3. Cyber Event Detected Within Combatant CommandCJCSM 6510.01B
278510 July 2012
2786Appendix C
2787C-C-4 Enclosure C
27884. Cyber Event Detected by External CND Group. The following reporting
2789scenario depicts the general process for reporting incidents detected by an
2790external entity affecting a DoD installation (e.g., B/P/C/S).
2791Figure C-C-4. Cyber Event Detected by External CND GroupCJCSM 6510.01B
279210 July 2012
2793Appendix C
2794C-C-5 Enclosure C
27955. Cyber Event Detected by Computer Network Defense Service Provider. The
2796following reporting scenario depicts the general process for reporting incidents
2797detected by a Tier II CNDSP affecting a DoD installation (e.g., B/P/C/S).
2798Figure C-C-5. Cyber Event Detected by CNDSPCJCSM 6510.01B
279910 July 2012
2800Appendix C
2801C-C-6 Enclosure C
2802(INTENTIONALLY BLANK)CJCSM 6510.01B
280310 July 2012
2804D-1 Enclosure D
2805ENCLOSURE D
2806CYBER INCIDENT ANALYSIS
28071. Introduction
2808a. Incident analysis is the series of analytical steps taken to determine
2809what occurred in an incident. The purpose of this analysis is to understand
2810the technical details, root cause(s), and potential impact of the incident. This
2811understanding will help to establish what additional information to gather, how
2812to coordinate information sharing with others, and how to develop a COA and
2813response. If there is a chance the incident might require the pursuit of
2814disciplinary or criminal actions, the appropriate LE/CI organization must be
2815contacted to ensure proper legal procedures are taken in the investigation of
2816the incident.
2817b. This section provides additional guidance on incident analysis
2818requirements for reportable events and incidents. Further requirements will be
2819articulated in OPORDs issued by relevant commands.
2820c. The primary objectives for the incident analysis process are:
2821(1) Identify the root cause(s) of the incident through technical analysis.
2822(2) Ensure the accuracy and completeness of incident reports.
2823(3) Characterize and communicate the potential impact of the incident.
2824(4) Capture the methods used in the attack and the security controls
2825that could prevent future occurrences.
2826(5) Research actions that can be taken to respond to and eradicate the
2827risk and/or threat.
2828(6) Understand patterns of activity to characterize the threat and direct
2829protective and defensive strategies,
2830d. Technical analysis is iterative in nature. It is conducted many times
2831throughout the incident handling life cycle. Some degree of analysis must
2832occur in order to detect and adequately report an incident. Once an incident
2833has been reported, it may go through several levels of analysis to identify the
2834root cause(s). Each successive level requires personnel that possess more
2835sophisticated skills and have access to additional tools or systems.CJCSM 6510.01B
283610 July 2012
2837D-2 Enclosure D
2838e. Incident analysis seeks to identify the root cause(s) of an incident and is
2839required to fully understand the scope, potential implications, and extent of
2840damage resulting from the incident. Figure D-1 below illustrates the basic
2841relationship between data preservation, technical analysis, root cause
2842identification, and IS recovery. Depending on the complexity of the incident
2843and the level of analysis required, the amount of time necessary to analyze an
2844incident may vary from minutes to hours to months.
2845Figure D-1. Cyber Incident Analysis Relationship to Preserving Data and
2846Recovering Systems
2847f. In some cases, technical analysis may not be able to conclusively identify
2848the root cause of an incident. The intruder may have deleted or tampered with
2849logs and files, making them untrustworthy, or the existence of multiple
2850unpatched vulnerabilities may make it impossible (or not worth the effort) to
2851try to identify which specific vulnerability was exploited. In such cases, it may
2852be more expedient simply to begin IS recovery and hardening.
2853g. The decision to restore an IS without identifying the root cause(s) of the
2854incident must be weighed carefully as it may leave the IS vulnerable. For
2855example, if the root cause of an incident stemmed from a missing patch in the
2856baseline configuration, an IS restoration using the same baseline configuration
2857will leave the IS open to future compromise.CJCSM 6510.01B
285810 July 2012
2859D-3 Enclosure D
28602. Cyber Incident Analysis Framework
2861a. The type of analysis conducted will depend on the nature of the incident
2862under analysis. Typically, responding to an incident will require some
2863combination of the following types of analysis:
2864(1) System Analysis. The process of acquiring, preserving, and
2865analyzing IS artifacts (e.g., log files or registry information, creating an image,
2866or capturing a screen shot) that help characterize the incident and develop
2867COA.
2868(2) Malware Analysis. The process of identifying, analyzing, and
2869characterizing reported software artifacts suspected of being adversarial
2870tradecraft to help defense in depth mitigation actions and strategies, CI
2871activities, and LE activities.
2872(3) Network Analysis. The process of collecting, examining, and
2873interpreting network traffic to identify and respond to events that violate the
2874security policy or posture of the resources attached to the information network
2875or the network infrastructure and used to support computer security incident
2876investigations. Network incident analysis will include the networks log file to
2877show the threat (e.g., router logs, firewall logs, IDS/IPS logs).
2878b. This set of categories is somewhat arbitrary, as there are no clear lines
2879of separation between them. For example, malware may leave traces on an IS
2880under analysis, as well as in network data. The principles of sound forensic
2881data collection and analysis, particularly in cases that may lead to legal
2882prosecutions, apply across all the above types of analysis.
2883c. The level, or depth, of analysis conducted can often depend on the
2884context of the analysis request or mission of the organization. For instance,
2885some organizations may be tasked with recovering from a compromise and
2886wish to determine the extent of the damage. This may differ greatly from
2887analysis required to support a law enforcement investigation where data
2888preservation and chain of custody must be strictly managed.
2889d. The level of incident analysis to be conducted will also vary depending
2890on the incident category, the operational and technical impacts, and any
2891identifiable delivery vectors or IS weaknesses. It will also depend on the
2892availability of relevant information for analysis and available resources.
28933. Computer Forensics Analysis
2894a. Computer forensics is considered the application of science to the
2895identification, collection, examination, and analysis of data while preserving theCJCSM 6510.01B
289610 July 2012
2897D-4 Enclosure D
2898integrity of the information and maintaining a strict chain of custody.
2899Guidance on integrating forensic techniques into incident response can be
2900found in NIST SP 800-86, “Guide to Integrating Forensic Techniques into
2901Incident Response” (reference o).
2902b. CNDSPs will establish and maintain a computer forensics program IAW
2903the Evaluators Scoring Metrics for the Certification and Accreditation of
2904CNDSPs. A computer forensics program will include the following:
2905(1) Policies, including criteria for determining when forensics collection
2906and analysis should be performed.
2907(2) Guidelines and procedures for forensic collection of evidence,
2908forensics analysis, and chain of custody.
2909(3) Forensics staff, technology, and facility resources—including trained
2910and knowledgeable staff, tools, and equipment for forensics collection and
2911analysis of evidence—and necessary infrastructure, such as a forensics lab.
2912c. Many forensics collection and analysis tasks are similar to or overlap
2913with other incident analysis activities, which are generally more focused on
2914gaining a technical understanding of the incident. When these informationgathering and analysis activities are performed for forensics purposes, the
2915forensic activities focus on processing and preserving the authenticity and
2916integrity of the data in a manner that ensures the evidence can be admissible
2917in a court of law.
2918d. For incidents to be investigated for computer crime, incident handlers
2919and first responders must understand proper forensics and evidence handling
2920policies and procedures, even if that means keeping “hands off” until a trained
2921analyst can start the proper evidence collection. Data and information to be
2922gathered for forensics analysis or evidence must be obtained and handled IAW
2923various applicable laws, possibly spanning many jurisdictions, in order to
2924ensure the authenticity and reliability of the information for forensics analysis
2925as well as to be admissible in a court.
2926e. Electronic data from a computer to be used for forensics and/or
2927evidence can consist of both volatile data and persistent data from the affected
2928IS(s) (see paragraph 4 (System Analysis)). The use of approved forensics tools
2929and methods to collect and handle volatile and non-volatile data will help
2930ensure that incident handlers and first responders satisfy forensics and
2931evidence requirements.CJCSM 6510.01B
293210 July 2012
2933D-5 Enclosure D
2934f. Forensics Process
2935(1) One model for the forensics process, presented in NIST 800-86
2936(reference o), describes four basic phases:
2937(a) Collection. The first phase in the process is to identify, label,
2938record, and acquire data from the possible sources of relevant data, while
2939following guidelines and procedures that preserve the integrity of the data.
2940Collection is typically performed in a timely manner because of the likelihood of
2941losing dynamic data such as current network connections as well as data from
2942battery-powered devices (e.g., cell phones or Personal Digital Assistants).
2943(b) Examination. Examinations involve forensically processing
2944large amounts of collected data. A combination of automated and manual
2945methods is used to assess and extract data of particular interest while
2946preserving its integrity.
2947(c) Analysis. The next phase is to analyze the results of the
2948examination, using legally justifiable methods and techniques, to derive
2949information that addresses the questions driving the analysis.
2950(d) Reporting. The final phase is reporting the results of the
2951analysis. This may include describing the methods used, explaining how tools
2952and procedures were selected, determining what other actions need to be
2953performed (e.g., forensic examination of additional data sources, securing
2954identified vulnerabilities, improving existing security controls), and providing
2955recommendations for improvement to policies, guidelines, procedures, tools,
2956and other aspects of the forensic process. The formality of the reporting step
2957varies greatly depending on the situation.
2958(2) The reporting phase of forensics can also present the evidence and
2959the results of the analysis in a court of law. Individuals involved in conducting
2960any activities for forensics purposes (particularly the collection phase) must
2961understand the forensics process and be prepared to explain their actions in
2962court.
2963g. Forensics Policies, Guidelines, and Procedures
2964(1) In accordance with NIST 800-86 (reference o), forensics policies
2965“should allow authorized personnel to monitor systems and networks and
2966perform investigations for legitimate reasons under appropriate
2967circumstances.” In addition, each organization “should ensure that their
2968policies contain clear statements that address all major forensic
2969considerations, such as contacting law enforcement, performing monitoring,
2970and conducting regular reviews of forensic policies, guidelines, andCJCSM 6510.01B
297110 July 2012
2972D-6 Enclosure D
2973procedures.” CC/S/A/FAs, CND incident handlers, and first responders must
2974understand and abide by their organization’s forensics policies.
2975(2) Forensics Guidelines and Procedures
2976(a) NIST 800-86 (reference o) provides organizations a starting point
2977for developing a forensic capability, in conjunction with extensive guidance
2978provided by legal advisors, law enforcement officials, and management.
2979(b) The guidelines and procedures should support the admissibility
2980of evidence into legal proceedings including:
29811. Information on gathering and handling evidence properly.
29822. Preserving the integrity of tools and equipment.
29833. Maintaining the chain of custody.
29844. Storing evidence securely.
2985(c) Although it may not be feasible to record every event or action
2986taken in response to an incident, having a record of the major events and
2987actions taken help to ensure that nothing has been overlooked and explains
2988how the incident was handled. This documentation can be useful for case
2989management, report writing, and testifying. Keeping a record of the dates and
2990times that people worked on an incident, including the time needed to recover
2991ISs, can also help calculate the costs of damages. Also, handling evidence in a
2992forensically sound manner puts decision makers in a position where they can
2993confidently take the necessary actions.
2994(d) Guidelines and procedures for forensics evidence collection,
2995handling, and analysis will be more extensive and less flexible than those for
2996general incident data collection and analysis. Forensics processing
2997requirements generally exceed typical incident collection and analysis
2998procedures in the following areas:
29991. Increased preparation and use of specialized tools for
3000acquisition and analysis of evidence.
30012. Increased level of detail in documenting the scene (e.g.,
3002recording model numbers and serial numbers of equipment, photographing
3003hardware, peripherals, wiring and network connections, photographing the
3004monitor/screen, etc.).CJCSM 6510.01B
300510 July 2012
3006D-7 Enclosure D
30073. Stricter attention to the order in which volatile system data is
3008acquired (to avoid loss of volatile data).
30094. Increased care taken to capture persistent data while
3010preventing contamination of evidence (e.g., removing/seizing hard drives and
3011storage media, or creating forensically sound duplicate images on prepared
3012storage devices; using hardware and/or software write blockers to prevent
3013changes to data; and creating hashes of the suspect data and duplicate images
3014to verify authenticity).
30155. Increased documentation of steps taken during evidence
3016examination and analysis (including date- and time-stamping of all actions
3017taken).
30186. Increased controls limiting access to evidence and
3019maintenance of a chain of custody.
30207. Different details to be included in reports of the analysis
3021results (different audience).
30228. Different evidence storage/retention timeframes, policies, and
3023procedures.
30244. System Analysis
3025a. System analysis is the gathering and review of all information from or
3026about the affected IS(s) to further incident analysis and understand the full
3027scope of the incident. The IS information to be analyzed typically includes
3028various logs, files, configuration settings, records of currently logged-on users,
3029past connections (logins), running processes, open files, and changes to files or
3030system settings (access control lists (ACLs), registries, and permissions).
3031b. If the IS has been compromised, care must be taken when using any
3032programs on the suspect IS that may have been modified, or in trusting the
3033validity of logs that may have been tampered with and altered, replaced, or
3034removed. A CND or incident response toolkit, containing trusted copies of
3035system analysis tools, should be used. The toolkit should include appropriate
3036OS tools to examine the suspect IS, including tools to analyze:
3037(1) Files and logs—examine text files, binary/executable files, and
3038archive files.
3039(2) Processes—list processes and list processes that open a socket.CJCSM 6510.01B
304010 July 2012
3041D-8 Enclosure D
3042(3) Connections—list open sockets or ports; list ISs that recently
3043connected.
3044c. As part of the data collection effort, the first responder must determine
3045what has been done to an IS and by whom. This includes not just the
3046attacker, but system and network administrators and IS users. The first
3047responder should have an initial set of questions to ask to those involved and a
3048log book for recording all the information gathered. First responders must
3049document everything they can, including all actions they or anyone else
3050involved take during the investigation or response. A new log must be created
3051for every incident or case. During data collection, the first responder will
3052document the following in the log book:
3053(1) Who is performing the forensic collection.
3054(2) The history of executed analytical tools and commands done during
3055the collection.
3056(3) Any generated tool and command output.
3057(4) The date and time of the executed commands and tools.
3058(5) Expected IS changes or effects (e.g., changed media access control
3059times for specific files) as first responder tools are executed.
3060(6) Any other information pertaining to the response, including artifacts
3061or notes about the IS, its configuration, and its physical location.
3062d. Data obtained for forensics analysis or evidence must be collected using
3063forensically sound methods and tools that capture the relevant data while
3064preventing or minimizing evidence contamination. Forensics methods and
3065tools are specifically designed to enable the following:
3066(1) Collection of volatile data while minimizing the footprint left on
3067the suspect IS. Volatile data is any data stored in IS memory (system registers,
3068cache, and RAM) that will be lost when the IS loses power or is shut down. If
3069the IS is rebooted or shut down, this data may be permanently lost.
3070Examination of volatile data can provide insight into the state of the IS and
3071currently running processes, and potentially help determine a logical timeline
3072identifying the date, time, and/or cause of the incident.
3073(2) Collection of persistent data while preventing data on the suspect
3074IS from being overwritten. Persistent data includes data in the IS’s hard drives
3075and removable storage media that will not be changed when the IS is powered
3076off. This often includes disk imaging, the process of creating an exactCJCSM 6510.01B
307710 July 2012
3078D-9 Enclosure D
3079duplication of the original disk. A disk image includes files as well as hidden
3080files, deleted data, slack space, swap files, and unallocated space.
3081(3) Documentation of the process, typically using a forensic collection
3082log book. The documentation should contain a time-stamped record of all
3083actions taken during collection of the evidence. The purpose of the
3084documentation is to enable the process to be validated and ensure that the
3085digital evidence is an exact representation of the original data.
3086e. Detailed steps for conducting system analysis on various OSs and
3087equipment are beyond the scope of this manual. The analyst who performs
3088such analyses, however, must be knowledgeable and have the necessary tools
3089to access and examine the following types of information on the affected IS(s):
3090(1) Volatile Data. Any data stored in IS memory (system registers,
3091cache, and RAM) that will be lost when the IS loses power or is shut down.
3092(a) Volatile IS data and time examples include:
30931. IS profile.
30942. Current IS data and time.
30953. Command history.
30964. Current IS uptime.
30975. Running processes.
30986. Open files, startup files, and clipboard data.
30997. Logged on users.
31008. Dynamic-linked libraries (DLLs) or shared libraries.
3101(b) Volatile network data examples include:
31021. Open connections.
31032. Open ports and sockets.
31043. Routing information and configuration.
31054. Network interface status and configuration.CJCSM 6510.01B
310610 July 2012
3107D-10 Enclosure D
31085. Address resolution protocol (ARP) cache.
3109(2) Persistent (Non-Volatile) Data. Data in the IS’s hard drives and
3110removable storage media that will not be changed when the IS is powered off.
3111Examples include the following:
31121. IS log files.
31132. Event Viewer files.
31143. Application logs.
31154. Disk image—exact duplicate of the original disk, which
3116includes files as well as hidden files, deleted data, slack space, swap files, and
3117unallocated space.
3118f. While conducting the system analysis, the analyst may need to perform
3119other related tasks. These tasks include looking up hostnames and IP
3120addresses or tracing them back to their sources; searching for hidden or
3121deleted files; checking the integrity of system binaries; checking for
3122unauthorized processes or services; identifying potential malware; or examining
3123other machines on the local network.
3124g. After the system analysis has been completed, new details will emerge,
3125requiring a follow-on report. Information fields in the initial incident report
3126may also need to be updated.
3127h. For a summary of resources useful for investigating incidents, refer to
3128the DOJ “Investigations Involving the Internet and Computer Networks”
3129(reference p).
31305. Malware Analysis
3131a. Malware analysis is the process of analyzing and capturing the
3132capabilities of software artifacts suspected of being malicious code. It is an
3133essential step in determining the full scope of an incident. Malware is defined
3134as software designed and/or deployed by adversaries without the consent or
3135knowledge of the user in support of adversarial missions (e.g., gaining access to
3136resources or information, cyber strikes, C2 operations).
3137b. Uncovering an adversary’s tools, techniques, procedures, and
3138motivations will aid in discovering other affected or vulnerable ISs, establishing
3139a more concrete framework for attribution, and development of additional
3140defensive measures.CJCSM 6510.01B
314110 July 2012
3142D-11 Enclosure D
3143c. Individuals analyzing or otherwise handling malware are expected to:
3144(1) Handle with Care. Adversarial tradecraft is employed by the
3145adversary as a weapon and should be handled as such. It is important when
3146handling a sample suspected of being malicious that proper care is taken to
3147ensure that the sample does not affect any operational DoD information
3148networks or ISs. If possible, once a sample is identified, it should be moved to
3149a separate IS that is completely isolated for analysis. Any physical media used
3150to transport samples should be labeled to indicate that its contents are
3151potentially malicious.
3152(2) Catalog all Software Artifacts. All artifacts suspected of being
3153malware should be safely acquired, preserved, and submitted to the authorized
3154malware catalogs for storage.
3155(3) Manage Capability Effectively. Due to the large volume of artifacts
3156that will likely be gathered as part of system analysis, and because the process
3157of analyzing malware can be extremely time and resource intensive, it is
3158unlikely that a complete, end-to-end analysis of every artifact identified as
3159malicious will be feasible. For this reason, it is important for all DoD CND
3160personnel to understand the analytical resources available to them and to
3161apply a measure of cost-benefit analysis to determine the depth of analysis to
3162be performed on a given artifact. Automated tools should be employed to
3163increase the number of samples that can be processed, where applicable.
3164(4) Perform Analysis in an Isolated Environment. Precautions must be
3165taken when performing analysis to prevent against the execution of code that
3166may adversely affect DoD information networks or ISs. Malware analysis shall
3167be done in a safe and isolated environment segregated from other ISs. In this
3168isolated environment, the intentional or unintentional, execution of the code
3169does not violate the implicit or explicit security policies of the IS. For example,
3170isolated environments may include a malware analysis laboratory,
3171virtualization environment, or an analyst workstation disconnected from the
3172network and intended for malware analysis. This prevents the unintentional
3173compromise of additional ISs or sensitive information.
3174d. Establish Policies Governing Media That Can be Connected to an
3175Analysis Machine. For example, it is relatively common for malware to use
3176universal serial bus (USB) keys to spread, so policy governing the usage of USB
3177keys and other forms of portable storage must be established.
3178e. Preserve the original software artifacts. It is fairly common for malware
3179to attempt to avoid detection by modifying and/or deleting the original
3180malicious file(s). The malware file(s) should be transferred between ISs by a
3181means that avoids accidental execution and preserves evidentiary admissibility.CJCSM 6510.01B
318210 July 2012
3183D-12 Enclosure D
3184Where feasible, technical solutions that physically or electronically prohibit
3185malware distribution should be implemented.
3186f. Levels of Depth for Malware Analysis
3187(1) Malware analysis can be performed at varying degrees of depth.
3188Each successive level requires personnel who possess more sophisticated skills
3189and have access to additional tools or ISs. Depending on the complexity of the
3190malware and depth of analysis required, the time necessary to complete the
3191request can vary from minutes to hours to months. Therefore, when
3192requesting malware analysis, asking specific questions about information of
3193interest to the mission helps expedite results.
3194(2) The diagram (Figure D-2) below illustrates the different degrees of
3195depth for malware analysis. After each stage, the decision must be made as to
3196whether additional information is needed. If additional information is needed,
3197the next successive level of analysis begins. If no additional data is needed,
3198then the analysis should be recorded and appropriately communicated.
3199Figure D-2. Levels of Depth for Malware AnalysisCJCSM 6510.01B
320010 July 2012
3201D-13 Enclosure D
3202(3) Surface Analysis
3203(a) Surface analysis involves quick checks to characterize the
3204sample within the context of the analysis mission.
3205(b) Common surface analysis techniques include file type
3206identification, strings extraction, public source analysis, and comparative
3207analysis with previously analyzed artifacts. The results of this analysis should
3208either produce an actionable result in the context of the request or be used to
3209help direct additional analysis as required
3210(c) Potential information to be gained through surface analysis
3211includes the following:
32121. Basic determination of nature and intent.
32132. Identification of strings in binary files.
32143. Cryptographic hashes.
32154. Antivirus software detection status.
32165. File sizes.
32176. File type identification.
32187. File attribute information.
32198. Packer identification.
32209. Signature-based detection status.
3221(d) While useful for quick malware characterization, surface
3222analysis can produce results based on an incomplete picture of the malware
3223sample. Surface analysis does not accurately determine program functionality.
3224For example, surface analysis may produce useful matches against third-party
3225information, but the third-party information may be incomplete or inaccurate.
3226(e) Analysis missions requiring a high degree of assurance shall not
3227rely solely on surface analysis.
3228(4) Run-time Analysis
3229(a) Run-time analysis is the controlled execution of the malware
3230sample in an isolated environment instrumented to monitor, observe, andCJCSM 6510.01B
323110 July 2012
3232D-14 Enclosure D
3233record run-time behavior without impacting mission-critical systems and
3234infrastructure.
3235(b) Although run-time analysis may provide additional information
3236relative to surface analysis, run-time analysis is generally limited to
3237observation of default execution paths of malware samples. Malware samples
3238may contain unexercised functionality or demonstrate alternate behavior in
3239different run-time environments.
3240(c) Potential information to be gained by performing run-time
3241analysis includes:
32421. Network touch points (addresses, protocols, ports, etc.).
32432. File system and registry activity.
32443. Vulnerabilities or weaknesses in particular run-time
3245environments.
32464. System service daemon interactions.
32475. Dynamic unpacking of packed executable files.
32486. Success of remediation techniques in particular run-time
3249environments.
32507. Suggestions of adversarial intent (low degree of confidence).
3251(d) Note: Subsequent surface analysis of unpacked binaries may
3252yield additional results, and could possibly negate the need for further resource
3253expenditure.
3254(5) Static Analysis
3255(a) Static analysis focuses on examining and interpreting the
3256contents of the malware sample in the context of an analysis mission. Files of
3257many types, particularly text files, Web page scripts, and source code files can
3258be analyzed without malware sample execution or disassembly. In the case of
3259a binary, if a complete understanding of the malware sample is necessary,
3260reverse engineering is required.
3261(b) Potential information to be gained by performing static analysis
3262includes:CJCSM 6510.01B
326310 July 2012
3264D-15 Enclosure D
32651. Static unpacking of packed executables.
32662. Definitive understanding of program source code.
32673. Determination of adversarial intent (high degree of
3268confidence).
32694. Deobfuscation of obfuscated data.
3270(6) Reverse Engineering
3271(a) Reverse engineering, the most in-depth analysis, is highly
3272complex and consists of disassembly of malware sample executable files and
3273interpretation of the assembly language. Reverse engineering is time-intensive
3274and requires extensive technical knowledge and specialized tools. It is the only
3275method of analysis that can produce a definitive or complete understanding of
3276a malware sample. Reverse engineering analysis can range from addressing
3277particular problem scope in order to answer a very few specific questions to
3278extensive reverse engineering all of the code in a malware sample in order to
3279understand complete functionality.
3280(b) Potential information to be gained by performing reverse
3281engineering includes:
32821. Manual unpacking of packed executable files.
32832. Understanding of obfuscation or encryption techniques.
32843. Definitive understanding of malware capabilities.
32854. Characterization of malware sophistication.
32865. Comparison of capabilities across malware samples.
3287g. Cataloging Malicious Code
3288(1) All software artifacts suspected of being malware must be safely
3289acquired, preserved, and cataloged.
3290(2) Cataloging of incident-related artifacts provides structured storage
3291of pertinent malware, logs, and related analysis. Any malware uncovered
3292throughout the incident response process must be cataloged to the JMC.
3293Additional guidance may be found in Enclosure G (Cyber Incident Handling
3294Tools—Joint Malware Catalog). Maintaining a central catalog facilitates and
3295enhances correlation and information sharing within the DoD incident
3296response community.CJCSM 6510.01B
329710 July 2012
3298D-16 Enclosure D
3299(3) Any analytical products that are created should be shared safely,
3300both horizontally and vertically, to the greatest extent possible to ensure that
3301the resources expended can be best utilized to improve the Department of
3302Defense’s overall situational awareness and defensive posture.
3303h. Requesting Malware Analysis
3304(1) Analysis of malware samples is required to accurately characterize
3305the capabilities of the malware. The scope, complexity, and depth of malware
3306analysis requests may differ across DoD and CND organizations. For instance,
3307some components may be tasked with recovering from a compromise and wish
3308to determine the extent of damage done. Intelligence organizations may
3309conduct analysis to gain technical insights to support attribution, or to support
3310counterintelligence activities.
3311(2) When requesting malware analysis, the requestor should specify the
3312questions about the malware requiring an answer and identify any specific
3313information required to support the mission. Malware analysis is resource
3314intensive, and the depth of analysis performed should be no more than is
3315absolutely required. Effective management of analysis requests is critical to
3316managing an effective malware analysis capability.
3317(3) When requesting analysis of a malware sample, Table D-1 should be
3318used to assist in specifying the analysis information required within the context
3319of the mission.
3320Level of Analysis Information Produced from Analysis
3321Surface Analysis
3322Determine basic nature
3323and intent
3324− Identification of strings in binary files
3325− Cryptographic hashes
3326− Antivirus software detection status
3327− File sizes
3328− File type identification
3329− File attribute information
3330− Packer identification
3331− Signature-based detection status
3332Runtime Analysis
3333Determine adversarial
3334intent with low degree of
3335confidence
3336− Network touch points (addresses, protocols, ports, etc.)
3337− File system and registry activity
3338− Vulnerabilities or weaknesses in particular run-time
3339environments
3340− System service daemon interactions
3341− Dynamic unpacking of packed executable files
3342− Success of remediation techniques in particular run-time
3343environments
3344Static Analysis − Static unpacking of packed executablesCJCSM 6510.01B
334510 July 2012
3346D-17 Enclosure D
3347Determine adversarial
3348intent with high degree of
3349confidence
3350− Definitive understanding of some portion of program source
3351− Deobfuscation of obfuscated data
3352Reverse Engineering
3353Definitive understanding of
3354malware analysis
3355capabilities
3356− Manual unpacking of packed executable files
3357− Understanding of obfuscation or encryption techniques
3358− Definitive understanding of malware capabilities
3359− Characterization of malware sophistication
3360− Comparison of capabilities across malware samples
3361Table D-1. Levels of Analysis for Requesting Malware Analysis
33626. Network Analysis
3363a. Network security analysis consists of the collection, examination, and
3364interpretation of network traffic to identify and respond to events that violate
3365the security policy or posture of the resources attached to the network or the
3366network infrastructure.
3367b. Analyzing an adversary’s use of network resources, and uncovering the
3368network interactions that occurred during an intrusion, aid in discovering
3369other affected or vulnerable ISs. It also helps in the development of additional
3370defensive measures.
3371c. Network analysis should be an ongoing activity, with analysts constantly
3372studying and monitoring the normal operation of the network. This should
3373include constructing and updating a baseline of the inventory of hosts and
3374application servers. Because the most serious incidents may not be detected
3375by automated analysis or IDS, analyst understanding of the network provides
3376the best chance of noticing unusual patterns associated with the malicious
3377activity. Once in an incident response situation, this preparatory work will pay
3378significant dividends as the incident response team works through the process
3379described in Enclosure B (Cyber Incident Handling Methodology).
3380d. Network Analysis Capabilities. The network analysis capabilities
3381required for CND analysis across the Department of Defense include the
3382following:
3383(1) I&W. Appropriate use of intelligence information to understand the
3384threats to the DoD information network (both external and internal).
3385(2) AS&W. Detection of known and suspected malicious activity, as
3386well as sharing of such information for improved I&W capability across the
3387Department of Defense.CJCSM 6510.01B
338810 July 2012
3389D-18 Enclosure D
3390(3) Situational Awareness. Situational awareness is understanding the
3391current network security posture, including internal assets and their
3392vulnerabilities, normal and abnormal traffic patterns, and defensive measures
3393in place. These goals are interdependent and none can be fully achieved
3394without the others.
3395e. Network Analysis Technologies
3396(1) Some fundamental technology approaches that form the building
3397blocks of network analysis capabilities include:
3398(a) Wire speed network capture and/or examination.
3399(b) Traffic summarization.
3400(c) Pattern matching.
3401(d) Protocol analysis at all layers of the protocol stack.
3402(e) Behavioral analysis.
3403(f) Statistical anomaly detection.
3404(g) Correlation between data sources.
3405(2) All network monitoring technologies should be provisioned,
3406configured, and evaluated to achieve the following minimum requirements:
3407(a) The ability to operate at the bandwidth levels experienced at the
3408deployment point, up to and including link saturation, while successfully
3409collecting and/or examining all traffic (no packet loss or loss of capability).
3410(b) Pattern matching engines support “regular expressions” or a
3411similarly flexible pattern expression language.
3412(c) Signature engines permit the operator to provide custom
3413signatures, to permit DoD-specific signature development according to timely
3414I&W information.
3415(d) Network sensors perform IP fragment reassembly, to ensure
3416correct parsing of transport layer headers.
3417(e) Network sensors that examine the application layer perform
3418Transmission Control Protocol (TCP) stream reassembly to ensure correct
3419parsing of content data. While there is some difficulty in the emulation of theCJCSM 6510.01B
342010 July 2012
3421D-19 Enclosure D
3422behavior of TCP/IP stacks on destination hosts (e.g., differences in the
3423handling of urgent pointers), a generic reassembly protocol is sufficient to fulfill
3424the requirement.
3425(f) Anomaly detectors achieve acceptable accuracy rates, as defined
3426by the alert consumers, including appropriate or adjustable parameter settings
3427to maximize accuracy in the deployed information network.
3428f. Network Analysis Methodology. Network analysis comprises data
3429sources, data collection, and data analysis.
3430(1) Data Sources. Network traffic consists of event, session, full
3431content, and statistical data.
3432(a) The availability of data sources will vary based on the complexity
3433of the information network and level of network instrumentation in place.
3434(b) Acquiring some data sources may require coordination across
3435DoD elements. This data may reside on the local workstations, network
3436devices, monitoring instrumentation, or other network security mechanisms.
3437(2) Data Collection. The collection of data focuses on gathering
3438network and transport header information (particularly source and destination
3439addresses and ports), content and content-based information (from full packet
3440capture to specific application parameters such as Uniform Resource Locators
3441(URLs) or domain resolution data), traffic summaries, and alerts based on
3442matches on patterns or models of malicious activity (e.g., IDS alerts). Specific
3443technologies that provide this information change over time to address new
3444threats and to incorporate novel approaches to address new and existing
3445threats. However, all DoD entities (or their CNDSPs) must, at a minimum,
3446collect data from the following sources:
3447(a) Network Log Data. This data includes logs of all network
3448connections passing the network boundary at a connection summary level
3449(e.g., network flow records or firewall logs) or better, with a log retention policy
3450that prioritizes data retention. Collecting network logs internally (internal
3451routers or switches) would further enhance this capability. The entity, or its
3452CND service provider, must have an active program of monitoring and
3453analyzing its network log data.
3454(b) Intrusion Detection Data. This must include at least pattern
3455matching capability, with an active signature management program to
3456responsibly address current threat information as available to the incident
3457response organization. In general, vendor-provided signatures would need to
3458be supplemented with DoD-specific signatures to address targeted threats,
3459according to currently available I&W information.CJCSM 6510.01B
346010 July 2012
3461D-20 Enclosure D
3462(3) Enhanced capabilities can be achieved by additionally collecting the
3463following types of data:
3464(a) Full Packet Capture Data. This data can provide complete
3465insight into network transactions that occurred between hosts. It can also
3466allow for the reconstruction of network sessions that can provide a better
3467characterization of the activity. Full packet capturing enhances network
3468logging capability, but must be balanced with the increased cost and analytical
3469overhead due to the much larger data volumes involved. Data retention would
3470typically be much shorter than for summary log data.
3471(b) Statistical and Behavioral Anomaly Detection Data and/or
3472Protocol Analysis. This data can enhance IDS capabilities and contribute to a
3473deeper understanding of network behavior. However, the benefits must be
3474balanced with the uncertainty inherent in these approaches.
3475(c) Intrusion Prevention System Data. This data can be used to
3476identify known malicious activity or attempted intrusions. IPSs may enhance
3477network protection by blocking known malicious traffic, but their benefits must
3478be balanced with the potential for interference with production traffic. These
3479systems must be tuned to minimize false positives; this means that intrusion
3480detection capabilities (which may simply mean non-blocking signatures on the
3481same device) must still be provided to detect intrusions missed by the tighter
3482configuration of the IPS.
3483(4) Data Analysis. Network data analysis helps identify anomalous and
3484potentially malicious activity, enumerate network resources involved in an
3485intrusion, and identify other ISs that may be affected. System and malware
3486analysis will generally also be required to piece together the full event timeline.
3487Many exploits may not be identifiable as such based solely on network activity,
3488for example. Some types of analysis that may be required include the
3489following:
3490(a) Timeline Reconstruction. What did the attacker do? Identify the
3491relevant hosts, network connections, and application events, and place these
3492into an event timeline to organize the information about the incident. This
3493timeline would be used to correlate other event information gained from
3494analysis of system logs, file timestamps, etc.
3495(b) Exploit Analysis. What was exploited and how? Examine all the
3496traffic data sources in order to determine the nature of the exploit and assist in
3497identifying the root cause(s) of the incident. The analyst will have to
3498understand the protocols involved and the network manifestation of the exploit.CJCSM 6510.01B
349910 July 2012
3500D-21 Enclosure D
3501(c) Retrospective Analysis. What else did the attacker do? Use
3502traffic summaries or packet capture data to reconstruct past network events
3503relevant to the intrusion, potentially identifying portions of the malicious
3504activity that were missed by IDS systems. This analysis is part of the process
3505of identifying the full scope of the intrusion event. The analyst will often have
3506to iterate through the other types of analysis, adding new events to the timeline
3507and determining root cause(s) of other exploit activity.
3508g. Analysts must have strong command of the analysis tools at their
3509disposal, and their organizations should support providing the analyst with the
3510specialized training and continuing education to perform well in their role. An
3511automated analysis or alerting tool can only provide the beginning of an
3512understanding of a security incident, and only a skilled analyst provided with
3513appropriate tools can complete the picture.
35147. Analysis and Correlation of Event and Incident Data. Analysis and
3515correlation of event and incident data occur at all levels, as well as within
3516various functional communities (e.g., intelligence, counterintelligence, LE). To
3517conduct this analysis and correlation, it is important that all tiers participate in
3518comprehensive support of the reporting process. Correlation of data enables
3519the CC/S/A/FAs to identify traffic patterns, trends, and other relevant
3520information that is used in determining the defensive operational picture.
35218. Legal Issues. The following is provided as background information on legal
3522issues impacting on incident analysis.
3523a. A number of federal laws7 affect the monitoring and collection of
3524electronic communications and data. These laws cover various topics, such as
3525the searching and seizing of computers and data, privacy, electronic
3526surveillance, and rules of evidence.
3527(1) Laws governing the monitoring of data in transit can be found in 18
3528U.S.C. section 2510 et seq. (reference q) and 18 U.S.C. section 31212 et seq.
3529(reference r) and found in 18 U.S.C. section 2701 et seq. for data in storage
3530(reference s).
3531(2) There may be additional state and local laws (or international laws)
3532that similarly affect forensics activities.
35337 Relevant laws include the U.S. Constitution (4th and 5th amendments), U.S
3534statutory law (18 U.S.C. sections 2510-22, 2701-12, 3121- 27), and Federal
3535Rules of Evidence (hearsay, authentication, and identification). For more
3536information, see http://www.cybercrime.gov/.CJCSM 6510.01B
353710 July 2012
3538D-22 Enclosure D
3539b. Incident handlers and first responders will conduct data acquisition for
3540forensics evidence IAW guidance provided by legal advisors, law enforcement
3541officials, and management.
3542c. For example, computer records are generally admitted as evidence under
3543the Federal Rules of Evidence Exception (803(6)) (reference t) for records of
3544regularly conducted activity. If documented policies and procedures
3545regarding network monitoring and incident response are followed, this will help
3546computer records to be admitted under this Federal Rules of Evidence
3547Exception (reference t), whereas the lack of policies and procedures (or ad hoc
3548procedures) may not.
3549d. The DOJ manual “Searching and Seizing Computers and Obtaining
3550Electronic Evidence in Criminal Investigations”8 (reference u) provides guidance
3551on related topics, including searching and seizing computers with or without a
3552warrant; issues related to the Electronic Communications Privacy Act (ECPA)
3553(reference v); issues related to the electronic surveillance in communications
3554networks (Pen/Trap Statue; Wiretap Statute); and evidence. Although the
3555manual was published to provide guidance to federal law enforcement agents
3556and prosecutors, understanding this guidance will help individuals conducting
3557forensics activities better understand the relevant legal issues that arise and
3558better prepare to interact with law enforcement and prosecutors when needed.
3559e. The DOJ National Institute of Justice provides additional guidance on
3560digital evidence issues in a series of special reports:
3561(1) Electronic Crime Scene Investigation: A Guide for First Responders,
3562Second Edition. This report (reference w) includes additional and more detailed
3563guidance on developing policies and procedures, securing and evaluating the
3564scene, handling evidence at the scene, examining the evidence, and
3565documenting and reporting the results. The report also provides lists of
3566potential evidence by crime category.
3567(2) Forensic Examination of Digital Evidence: A Guide for Law
3568Enforcement. This report (reference x) is intended for law enforcement officers
3569who examine digital evidence. It provides guidance on policy and procedure
3570development; evidence assessment, acquisition, and examination; and
3571documenting and reporting analysis results. Appendices include case
3572examples and sample worksheets.
3573(3) Digital Evidence in the Courtroom: A Guide for Law Enforcement
3574and Prosecutors. This report (reference y) identifies federal laws governing
3575search and seizure issues. It also provides guidance on the handling of digital
3576evidence, courtroom preparation, and presentation of digital evidence.
35778 http://www.justice.gov/criminal/cybercrime/ssmanual/CJCSM 6510.01B
357810 July 2012
3579D-23 Enclosure D
3580f. Collection of Evidence. Data obtained for forensics analysis or evidence
3581must be collected using forensically sound methods and tools that capture the
3582relevant data while preventing or minimizing contamination of the evidence.
3583g. Storage of Evidence
3584(1) Any data or records that might be used as evidence must be
3585documented, maintained, and protected under a chain of custody in
3586accordance with forensics policies and procedures. This avoids allegations of
3587mishandling or tampering with evidence and increases the probability evidence
3588will be entered into a court proceeding.
3589(2) A chain-of-custody log is used to document the integrity of any
3590evidence at every point from the time it is seized until it is presented in court.
3591A chain-of-custody log will typically include the following types of information:
3592(a) Description of the evidence.
3593(b) Details of where (location), when (date and time), and by whom
3594(name, contact information) the evidence was found.
3595(c) Detailed description of the forensic evidence collection method,
3596tools, or procedures
3597(d) Details (who, where, when) of the transfer of evidence to a
3598custodian for safekeeping.
3599(3) A custodian must be designated to control and keep records of any
3600access to the evidence.CJCSM 6510.01B
360110 July 2012
3602D-24 Enclosure D
3603(INTENTIONALLY BLANK)CJCSM 6510.01B
360410 July 2012
3605Appendix A
3606D-A-1 Enclosure D
3607APPENDIX A TO ENCLOSURE D
3608DELIVERY VECTORS
36091. Introduction. A delivery vector is defined as the primary path or method
3610used by the adversary to cause the incident or event to occur. This information
3611is collected as part of the incident report and used to identify trends in the
3612prevalence of various vectors. By understanding the most prevalent vectors,
3613tactical and strategic plans can be developed to improve the defensive posture
3614of DoD information networks. Including the types of delivery vectors in the
3615incident reporting can help USCYBERCOM correlate information across
3616CC/S/A/FAs to identify potential Enterprise Incident Sets.
36172. Delivery Vector Categories
3618a. Delivery vectors are very dynamic but can generally be grouped into
3619several distinct categories. Sub-categories are more specific vectors and may
3620be more dynamic (and therefore require changes over time).
3621b. This annex describes the major categories and sub-categories of delivery
3622vectors. It should be used for assigning delivery vectors to reportable events or
3623incidents. Given the complexity of some attacks, it is not uncommon for more
3624than one delivery vector to be used in an attack. Therefore, a cyber event or
3625incident may be assigned more than one delivery vector.
3626Delivery Vector
3627Category Number Description
36281
3629Sub-category
3630Reconnaissance: Information was accessible and used to characterize
3631ISs, applications, information networks, and users that may be useful in
3632formulating an attack.
3633A Information Gathering and Data Mining: Activity that seeks to gather
3634information from publicly available sources.
3635B Network Scan: Activity that targets multiple IP addresses. This is
3636referred to as a horizontal scan.
3637C System Scan: Activity that targets a single IP address across a range of
3638ports. This is referred to as a vertical scan.
3639Table D-A-1. Delivery Vectors CategoriesCJCSM 6510.01B
364010 July 2012
3641Appendix A
3642D-A-2 Enclosure D
3643Delivery Vector
3644Category Number Description
36452
3646Sub-category Authorized User: A user with authorized access took specific actions
3647that resulted in jeopardizing ISs or data.
3648A Purposeful: An authorized user knowingly took specific actions that
3649jeopardized ISs or data.
3650B Accidental: An authorized user took actions that had consequences over
3651and above the intentions and jeopardized ISs or data.
36523
3653Sub-category Social Engineering: Human interaction (social skills) or deception used
3654to gain access to resources or information.
3655A E-mail: E-mail is the primary vehicle used to deliver a malicious payload
3656or gain access to resources or information.
3657B Web site: A Web site is the primary vehicle used to deliver a malicious
3658payload or gain access to resources or information.
3659C Other: A user was deceived or manipulated in a way that is not covered
3660by the other types of social engineering.
36614
3662Sub-category Configuration Management: Compromise resulting from the inadequate
3663or improper configuration of an IS.
3664A Network: An IS that provides network-based services was improperly or
3665inadequately configured.
3666B OS: An OS was improperly or inadequately configured.
3667C Application: An application was improperly or inadequately configured.
36685
3669Sub-category
3670Software Flaw: A vulnerability in the software that allows for the
3671unauthorized use of or access to an IS in a way that violates the IS’s
3672security policy.
3673A Exploited New Vulnerability: This vulnerability was unknown prior to the
3674event or there was no mechanism available to prevent it.
3675B Exploited Known Vulnerability: This vulnerability was known prior to the
3676event and there was a mechanism available to prevent it.
3677Table D-A-1. Delivery Vectors Categories (continued)CJCSM 6510.01B
367810 July 2012
3679Appendix A
3680D-A-3 Enclosure D
3681Delivery Vector
3682Category Number Description
36836
3684Sub-category Transitive Trust: Compromise resulting from the implicit or explicit
3685trust relationship between security domains.
3686A Other IS Compromise: Compromise resulting from access previously
3687gained on another IS.
3688B
3689Masquerading: Compromise resulting from the unauthorized use of a
3690valid user’s credentials. This may include cryptographic material,
3691account credentials, or other identification information.
36927
3693Sub-category Resource Exhaustion: The consumption of IS resources that prevents
3694legitimate users from accessing a resource, service, or information.
3695A
3696Non-Distributed Network Activity: Activity from a single IP address that
3697overwhelms IS or information network resources. This is generally
3698associated with a DoS incident.
3699B
3700Distributed Network Activity: Activity from multiple IP addresses that
3701overwhelms IS or information network resources. This is generally
3702associated with a DoS incident.
37038
3704Sub-category Physical Access: The unauthorized physical access to resources.
3705A Mishandled or lost resource: Equipment was stolen, lost, or left
3706accessible to unauthorized parties.
3707B Local access to IS: An unauthorized user was provided local physical
3708access to a DoD information network resource.
3709C Abuse of resources: The physical destruction of an information resource
3710by an unauthorized party.
37119
3712Sub-category Other
3713A
3714New Delivery Vector: The delivery vector is not covered by the listed
3715methods. Description of the delivery vector must be included in the
3716incident comments.
371710
3718Sub-category Unknown.
3719A Unable to Determine: Delivery vector could not be determined with the
3720information available.
3721Table D-A-1. Delivery Vectors Categories (continued)
3722c. The delivery vectors above are not exhaustive. Rather, they broadly
3723define the major categories of delivery vectors. To provide a greater degree of
3724granularity, a category may consist of subcategories that further characterize
3725specific delivery vectors. For example, subcategories of the delivery vector
3726“Software Flaw” may include “Exploited a New Vulnerability” or “Exploited an
3727Existing Vulnerability.” This provides a greater degree of control over the type
3728of information being reported.CJCSM 6510.01B
372910 July 2012
3730Appendix A
3731D-A-4 Enclosure D
3732(INTENTIONALLY BLANK)CJCSM 6510.01B
373310 July 2012
3734Appendix B
3735D-B-1 Enclosure D
3736APPENDIX B TO ENCLOSURE D
3737INFORMATION SYSTEM WEAKNESSES
37381. Introduction
3739a. Security controls are safeguards or countermeasures applied to an
3740information system (IS) in order to protect the confidentiality, integrity, and
3741availability of the IS and its information. The catalog of security controls can
3742be found in Committee on National Security Systems Instruction No. 1253,
3743“Security Categorization and Control Selection for National Security Systems”
3744(reference z).
3745b. Information about IS weaknesses is collected as part of the incident
3746report and used to broadly represent gaps or deficiencies in protective and
3747defensive security controls. Security control effectiveness is defined as the
3748extent to which existing controls are implemented correctly, operating as
3749intended, and producing the desired outcome in meeting the security
3750requirements for the IS in its operational environment.
3751c. By collecting this information on an ongoing and consistent basis,
3752management can make more informed decisions based on real data and can
3753provide technical direction that significantly improves the protection of DoD
3754information networks.
37552. Determining Information System Weaknesses
3756a. NIST SP 800-60, “Volume 1: Guide for Mapping Types of Information and
3757Information Systems to Security Categories” (reference aa), can be used to
3758identify the security family and security control(s) that could have been in place
3759to prevent or lessen the impact of the incident. IS weaknesses must be
3760recorded as part of the incident handling process and included in the incident
3761report. It is expected that more than one security control may apply.
3762b. For example, an incident that had a missing patch, poor baseline
3763system configuration, and out-of-date AV signatures as its root causes may
3764have the following IS weaknesses associated with it:
3765(1) Configuration management.
3766(2) System and information integrity.CJCSM 6510.01B
376710 July 2012
3768Appendix B
3769D-B-2 Enclosure D
3770c. IS weaknesses are dynamic and may change over time. Applications,
3771processes, and procedures that independently operate and maintain the
3772security controls must be flexible to allow these controls to be modified as
3773needed while minimizing the effects these changes may have on incident
3774reporting activities.CJCSM 6510.01B
377510 July 2012
3776Appendix C
3777D-C-1 Enclosure D
3778APPENDIX C TO ENCLOSURE D
3779IMPACT ASSESSMENT MATRIX
37801. Impact Assessment
3781a. Impact is assessed based on the degree to which an incident or event
3782adversely affects, or has the potential to affect, the successful accomplishment
3783of operational missions and the confidentiality, integrity, or availability of DoD
3784information networks and ISs.
3785(1) Each cyber event or incident is assessed and assigned an impact as
3786part of the incident handling process.
3787(2) An impact assessment is one of the determining factors when
3788assigning priority to an incident or event.
3789(3) The category and impact guide reporting timelines and response
3790actions should be commensurate with the magnitude of the incident or event.
3791b. In determining the actual impact, consider the current and potential
3792impact of the incident or event on the confidentiality, availability, and integrity
3793of organizational operations, organizational assets, or individuals. The
3794standards and guidelines used below provide a baseline for assessing impact
3795have been adopted and adapted (where necessary) from DoDI 8510.01, “DoD
3796Information Assurance Certification and Accreditation Process (DIACAP)”
3797(reference bb).
37982. Levels of Impact
3799a. Low. The potential impact is low if the loss of confidentiality, integrity,
3800or availability could be expected to have a limited adverse effect on
3801organizational operations, organizational assets, or individuals. Adverse effects
3802on individuals may include, but are not limited to, loss of the privacy to which
3803individuals are entitled under law. A limited adverse effect means that, for
3804example, the loss of confidentiality, integrity, or availability might:
3805(1) Cause degradation in mission capability to an extent and duration
3806that the organization is able to perform its primary functions, but the
3807effectiveness of the functions is noticeably reduced.
3808(2) Result in minor damage to organizational assets.
3809(3) Result in minor financial loss.CJCSM 6510.01B
381010 July 2012
3811Appendix C
3812D-C-2 Enclosure D
3813(4) Result in minor harm to individuals.
3814b. Moderate. The potential impact is moderate if the loss of confidentiality,
3815integrity, or availability could be expected to have a serious adverse effect on
3816organizational operations, organizational assets, or individuals. A serious
3817adverse effect means, for example, that the loss of confidentiality, integrity, or
3818availability might:
3819(1) Cause a significant degradation in mission capability to an extent
3820and duration that the organization is able to perform its primary functions, but
3821the effectiveness of the functions is significantly reduced.
3822(2) Result in significant damage to organizational assets.
3823(3) Result in significant financial loss.
3824(4) Result in significant harm to individuals that does not involve loss
3825of life or serious life threatening injuries.
3826c. High. The potential impact is high if the loss of confidentiality, integrity,
3827or availability could be expected to have a severe or catastrophic adverse effect
3828on organizational operations, organizational assets, or individuals. A severe or
3829catastrophic adverse effect means, for example, that the loss of confidentiality,
3830integrity, or availability might:
3831(1) Cause a severe degradation in or loss of mission capability to an
3832extent and duration that the organization is not able to perform one or more of
3833its primary functions.
3834(2) Result in major damage to organizational assets.
3835(3) Result in major financial loss.
3836(4) Result in severe or catastrophic harm to individuals involving loss of
3837life or serious life-threatening injuries.
38383. Determining Technical and Operational Impact
3839a. The tables below should be used to identify the potential technical
3840impacts (TIs) and operational impacts (OIs) of the incident or reportable event.
3841(1) These impacts should be assessed based on the degree to which an
3842incident or event adversely affects, or has the potential to affect, the successful
3843accomplishment of operational missions and the confidentiality, integrity, or
3844availability of DoD information networks and ISs.CJCSM 6510.01B
384510 July 2012
3846Appendix C
3847D-C-3 Enclosure D
3848(2) These impacts must be recorded as part of the incident handling
3849process and included in the incident report.
3850b. For example, a DoS attack against a local MAC I/II mail server may have
3851the following impacts:
3852(1) Technical Impact
3853(a) Confidentiality—Low.
3854(b) Integrity—Low.
3855(c) Availability—Medium.
3856(d) The potential impact to technical availability is medium because
3857it may degrade day-today business services.
3858(2) Operational Impact
3859(a) Confidentiality—Low.
3860(b) Integrity—Low.
3861(c) Availability—High.
3862(d) The potential impact to operational availability is high because it
3863is targeted at a MAC I/II IS.
38644. Cyber Incident Impact Table. The following table describes the
3865categorization system for assigning impact levels to incidents or events. This
3866table is intended to provide a high-level overview of each security objective and
3867define impact levels across these objectives.
3868POTENTIAL IMPACT
3869Security Objective LOW MODERATE HIGH
3870Confidentiality.
3871Preserving
3872authorized
3873restrictions on
3874information access
3875and disclosure,
3876including means
3877for protecting
3878personal privacy
3879and proprietary
3880The
3881unauthorized
3882disclosure of
3883information
3884could be
3885expected to have
3886a limited
3887adverse effect on
3888organizational
3889operations,
3890The unauthorized
3891disclosure of
3892information could
3893be expected to
3894have a serious
3895adverse effect on
3896organizational
3897operations,
3898organizational
3899assets, or
3900The unauthorized
3901disclosure of
3902information could
3903be expected to
3904have a severe or
3905catastrophic
3906adverse effect on
3907organizational
3908operations,
3909organizationalCJCSM 6510.01B
391010 July 2012
3911Appendix C
3912D-C-4 Enclosure D
3913information. [44
3914U.S.C. 3542].
3915organizational
3916assets, or
3917individuals.
3918individuals. assets, or
3919individuals.
3920Integrity.
3921Guarding against
3922improper
3923information
3924modification or
3925destruction, and
3926includes ensuring
3927information
3928nonrepudiation
3929and authenticity.
3930[44 U.S.C. 3542].
3931The
3932unauthorized
3933modification or
3934destruction of
3935information
3936could be
3937expected to have
3938a limited
3939adverse effect on
3940organizational
3941operations,
3942organizational
3943assets, or
3944individuals.
3945The unauthorized
3946modification or
3947destruction of
3948information could
3949be expected to
3950have a serious
3951adverse effect on
3952organizational
3953operations,
3954organizational
3955assets, or
3956individuals.
3957The unauthorized
3958modification or
3959destruction of
3960information could
3961be expected to
3962have a severe or
3963catastrophic
3964adverse effect on
3965organizational
3966operations,
3967organizational
3968assets, or
3969individuals.
3970Availability
3971Ensuring timely
3972and reliable access
3973to and use of
3974information. [44
3975U.S.C. 3542].
3976The disruption of
3977access to or use
3978of information or
3979an information
3980system could be
3981expected to have
3982a limited
3983adverse effect on
3984organizational
3985operations,
3986organizational
3987assets, or
3988individuals.
3989The disruption of
3990access to or use of
3991information or an
3992information
3993system could be
3994expected to have a
3995serious adverse
3996effect on
3997organizational
3998operations,
3999organizational
4000assets, or
4001individuals.
4002The disruption of
4003access to or use of
4004information or an
4005information
4006system could be
4007expected to have a
4008severe or
4009catastrophic
4010adverse effect on
4011organizational
4012operations,
4013organizational
4014assets, or
4015individuals.
4016Table D-C-1. Cyber Incident Impact Table
40175. Cyber Incident and Event Potential Impact. The following tables provide
4018examples of incidents or events and how they are categorized across each
4019security objective and impact level.
4020a. The tables should be used as a guide to determine the potential impact
4021of an incident or event. Initial assessment should be performed quickly even
4022with limited details and analysis.
4023b. As the investigation continues and a more accurate characterization of
4024the true impact is understood, there is always opportunity to reassess and
4025modify the potential impact.CJCSM 6510.01B
402610 July 2012
4027Appendix C
4028D-C-5 Enclosure D
4029c. Note: “All Security Objectives” is intended to represent examples of
4030incidents or events that may affect any security objective (i.e., confidentiality,
4031integrity, and availability).
4032POTENTIAL TECHNICAL IMPACT
4033Security Objective LOW MODERATE HIGH
4034Confidentiality
4035Reoccurring or
4036automated recon
4037events.
4038Reoccurring or
4039automated
4040unsuccessful
4041activity events.
4042Disclosure of
4043network topology
4044or
4045interconnectivity.
4046Significant recon
4047events.
4048Significant
4049unsuccessful
4050activity events.
4051User credentials
4052Administrative
4053credentials to
4054DoD information
4055networks and ISs
4056are compromised
4057Integrity
4058Malicious logic
4059defeated by
4060defense
4061mechanisms.
4062Exposes limited
4063number of ISs or
4064global network
4065services to risk
4066Propagation of
4067malicious logic
4068that could
4069significantly affect
4070the Department of
4071Defense.
4072Exposes moderate
4073number of ISs or
4074global network
4075services to
4076significant risk.
4077Malicious logic
4078having wellunderstood
4079capabilities and
4080which will not
4081cause significant
4082damage or loss.
4083Inability to verify
4084or known
4085modification to
4086highly sensitive
4087DoD intellectual
4088property.
4089Widespread
4090propagation of
4091malicious logic;
4092could significantly
4093affect DoD.
4094Exposes large
4095number of ISs or
4096global network
4097services to
4098significant risk
4099(e.g., 0-day
4100exploit).
4101Malicious logic
4102capabilities that
4103are unknown or
4104not fully
4105understood.
4106Table D-C-2. Technical Impact ExamplesCJCSM 6510.01B
410710 July 2012
4108Appendix C
4109D-C-6 Enclosure D
4110POTENTIAL TECHNICAL IMPACT
4111Security Objective LOW MODERATE HIGH
4112Availability
4113User workstation
4114is inaccessible.
4115Degradation of
4116services for dayto-day business.
4117A mail server was
4118removed from the
4119network and
4120users were unable
4121to access mail.
4122User Web portals
4123and Web
4124applications are
4125not available
4126Degradation or
4127unavailability of
4128DNS, routing, or
4129PKI
4130infrastructure.
4131All Security
4132Objectives
4133IS was not
4134patched or
4135protected.
4136Exploitation
4137technique used
4138infrequently.
4139Exploitation of the
4140IS can be
4141conducted locally
4142with physical
4143access.
4144IS was partially
4145patched and
4146protected.
4147Exploitation
4148technique used
4149frequently.
4150Exploitation of the
4151IS can be
4152conducted
4153remotely or locally
4154with user
4155interaction.
4156IS was fully
4157patched and
4158protected.
4159Exploitation
4160technique
4161widespread.
4162Exploitation of the
4163IS can be
4164conducted
4165remotely with no
4166user interaction.
4167Table D-C-2. Technical Impact Examples (continued)CJCSM 6510.01B
416810 July 2012
4169Appendix C
4170D-C-7 Enclosure D
4171POTENTIAL OPERATIONAL IMPACT
4172Security Objective LOW MODERATE HIGH
4173Confidentiality
4174A set of
4175configuration
4176information about
4177an obsolete
4178unclassified IS is
4179found on a
4180NIPRNET account.
4181Old duty rosters
4182or schedules are
4183in an accessible
4184directory
4185Unauthorized
4186disclosure of
4187technical
4188reporting
4189structures or TDY
4190assignments.
4191Unauthorized
4192disclosure of highly
4193sensitive DoD
4194Program
4195Information,
4196mission plans or
4197orders, or
4198deployment plans.
4199Integrity
4200Access to
4201deployment
4202records for
4203operations that
4204have been
4205completed are
4206found on
4207compromised
4208machine.
4209Loss of confidence
4210data stored on a
4211MAC II IS for less
4212than 2-3 days.
4213Applying fix to
4214legacy IS based on
4215bulletin or alert
4216leaves application
4217vulnerable to
4218unauthorized
4219access.
4220IS used to manage
4221aircraft
4222maintenance
4223records
4224compromised.
4225Degradation of
4226services on a MAC I
4227IS.
4228Availability
4229Access to files on
4230personnel who are
4231terminated is
4232unavailable.
4233Access to
4234purchasing
4235database for
4236equipment lookups is offline.
4237Unable to process
4238TDY orders.
4239Organization is
4240unable to perform
4241effective C2 with
4242its parent /
4243subordinate
4244organization due
4245to a disabled mail
4246server.
4247Inhibited ability to
4248manage inventory,
4249deliver supplies, or
4250meet deployment
4251timelines.
4252Table D-C-3. Operational Impact ExamplesCJCSM 6510.01B
425310 July 2012
4254Appendix C
4255D-C-8 Enclosure D
4256POTENTIAL OPERATIONAL IMPACT
4257Security Objective LOW MODERATE HIGH
4258All Security
4259Objectives
4260Generates limited
4261if any military
4262action.
4263Causes local
4264adverse publicity.
4265Causes limited or
4266localized coverage
4267in news media.
4268Short-term
4269physical injury or
4270harm.
4271Resources
4272required for
4273response will have
4274limited effects on
4275operations and
4276not significantly
4277reduce the
4278effectiveness of
4279response
4280functions.
4281Affects a MAC III
4282IS, OSD
4283information
4284network, or DoD
4285information
4286network.
4287Generates
4288moderate level of
4289military action.
4290Causes national
4291adverse publicity.
4292Causes moderate
4293coverage in news
4294media.
4295Permanent
4296physical injury or
4297harm.
4298Resources
4299required for
4300response will have
4301moderate effects
4302on operations and
4303may reduce the
4304effectiveness of
4305response
4306functions
4307temporarily.
4308Affects a MAC I/II
4309IS, classified IS,
4310or guard device.
4311Risk to human life
4312or widespread
4313physical injury or
4314harm.
4315Crosses
4316CC/S/A/FAs
4317boundaries.
4318Impacts
4319operational
4320mission of
4321B/P/C/S level or
4322higher
4323information
4324networks.
4325Generates a
4326higher level of
4327military action.
4328Causes a national
4329reaction.
4330Affects national
4331reaction.
4332Causes
4333widespread
4334coverage in news
4335media.
4336Resources
4337required for
4338response will have
4339significant effects
4340on operations and
4341reduce the
4342effectiveness of
4343response
4344functions for a
4345significant period
4346of time.
4347Table D-C-3. Operational Impact Examples (continued)CJCSM 6510.01B
434810 July 2012
4349E-1 Enclosure E
4350ENCLOSURE E
4351CYBER INCIDENT RESPONSE
43521. Introduction
4353a. Incident response is an organized and coordinated series of steps, also
4354known as Response Actions (RAs), to resolve or mitigate a reported incident. It
4355also includes the steps taken to recover affected ISs and return them to a fully
4356operational and secure state.
4357b. Coordination, communication, and documentation actions are also
4358taken during incident response to ensure the right CC/S/A/FAs are involved,
4359notified of the outcomes, and provided any follow-up reports.
4360c. It is also in this phase that incident information and incident response
4361actions are archived and recorded. Once the incident is resolved, it is closed, a
4362final report is submitted, and any postmortem actions are completed.
4363d. This section provides further guidance on incident response and
4364recovery. Further requirements shall be articulated in OPORDs issued by
4365relevant commands.
4366e. The primary objectives for RAs are to:
4367(1) Halt or minimize attack effects or damage while maintaining
4368operational mission continuity.
4369(2) Ensure the effective and timely recovery of ISs in a way that
4370prevents similar incidents from occurring again.
4371(3) Strengthen the Department of Defense’s defensive posture and
4372operational readiness.
4373(4) Ensure that RAs occur in a manner that protects any data
4374according to its level of sensitivity.
4375(5) Support rapid, complete attack characterization.
43762. Types of Responses
4377a. Three types of response activities can occur:CJCSM 6510.01B
437810 July 2012
4379E-2 Enclosure E
4380(1) Technical Response. RAs that involve containment or eradication of
4381any risks or threats associated with the incident, and the rebuilding or
4382restoring of affected ISs to a normal operational state.
4383(2) Management Response. RAs that require some type of
4384administrative, supervisory, or management intervention, notification,
4385interaction, escalation, or approval as part of any response. Administrative or
4386management response steps can include actions taken by human resources,
4387public relations, financial accounting, audits and compliance, and other
4388internal organizational entities.
4389(3) LE/CI and Intel Response. RAs associated with LE/CI; liability;
4390privacy issues; creating or reviewing nondisclosures and service level
4391agreements; and any other legal actions taken in response to an incident.
4392b. RAs across these three areas will be coordinated.
4393c. CC/S/A/FAs must be prepared ahead of time for any RAs. Decisions
4394made in haste while responding to a critical incident are rarely effective.
4395Therefore, response procedures, tools, defined interfaces, and communications
4396channels and mechanisms will be in place and tested beforehand.
4397d. Each CC/S/A/FA will develop response guidance or a response plan.
4398The response plan lists steps to take and specifies who should take them. In
4399this way, when an incident does occur, appropriate personnel will know how to
4400respond. Escalation procedures and criteria must also be in place to ensure
4401effective management engagement in RAs.
4402e. Preparations that will facilitate response activities include:
4403(1) An archive of boot disks and distribution media for all applications
4404and OSs.
4405(2) An archive of security-related patches for applications and OS.
4406(3) Test networks and ISs (to test patches, analyze malicious code, etc.).
4407(4) A resource kit of tools and hardware devices to support analysis or
4408data acquisition.CJCSM 6510.01B
440910 July 2012
4410E-3 Enclosure E
44113. Developing and Implementing Courses of Action
4412a. Courses of action (COAs) include the actions necessary to respond to the
4413reportable cyber event or incident, fix the IS, return the IS to operations, and
4414assess the risk for the IS or information network.
4415b. Those involved in developing COAs will depend on the incident and the
4416affected CC/S/A/FAs. They may be developed by field operations or by
4417CNDSPs, or jointly by both working with any commanders.
4418c. Who will actually execute the COAs will depend on who has
4419responsibility for various infrastructure components.
4420(1) COAs may include CND RAs IAW CJCSI 3121.01, “Standing Rules
4421of Engagement/Standing Rules for the Use of Force for U.S. Forces.” Analysis,
4422comparison, and selection of the best COA should be done at the lowest
4423command possible, consistent with established C2 of Cyberspace Operations.
4424(2) COAs may include the development and issuance of bulletins and
4425other notifications to CC/S/A/FAs to promote awareness, direct actions, and
4426ensure compliance.
4427(3) Those with key roles in responding to an intrusion must be notified
4428and kept informed to fulfill their responsibilities. Executing COAs and
4429information dissemination procedures may include contacting users, security
4430personnel, LE/CI, vendors, Internet service providers (ISPs), other CNDSPs,
4431and other internal or external security organizations.
4432(4) Specific coordination may be required with DoD LE/CI or with
4433external law enforcement organizations when DoD LE/CI support is not
4434available or cannot be obtained due to time or distance factors. Coordination
4435with LE/CI involves helping LE/CI personnel investigate the incident and
4436prosecute the perpetrators, if warranted.
4437(5) International coordination may be needed if attacking hosts reside
4438in a foreign nation or if DoD ISs are attacking networks in that nation.
4439(6) USCYBERCOM reserves the right to direct and assist CC/S/A/FAs
4440with response actions for incidents that fall into a DoD enterprise incident set
4441or when actions otherwise affect multiple theater or Service information
4442networks.
4443d. For more information on coordination and collaboration with LE/CI and
4444international organizations, see Enclosure F (Collaboration with Other Strategic
4445Communities).CJCSM 6510.01B
444610 July 2012
4447E-4 Enclosure E
4448e. NIST SP 800-61, “Computer Security Incident Handling Guide”
4449(reference cc), provides a list of criteria for determining appropriate courses of
4450action or what it calls “strategies.” These criteria include:
4451(1) Potential damage to and theft of resources.
4452(2) Need for evidence preservation.
4453(3) Service availability (e.g., network connectivity, services provided to
4454external parties).
4455(4) Time and resources needed to implement the strategy.
4456(5) Effectiveness of the strategy (e.g., partially contains the incident,
4457fully contains the incident).
4458(6) Duration of the solution (e.g., emergency workaround to be removed
4459in four hours, temporary workaround to be removed in 2 weeks, permanent
4460solution).
4461f. NIST describes COAs and RAs for various attacks such as DoS,
4462malicious code, unauthorized access, and inappropriate usage in NIST SP 800-
446361 (reference cc).
44644. Recovering Without Performing Technical Analysis
4465a. Data from all incidents must be preserved to enable technical analysis.
4466However, under certain circumstances and with approval, technical analysis
4467may not be required prior to IS recovery.
4468(1) For example, it may not be possible to conclusively identify the root
4469cause of an incident through additional analysis. The intruder may have
4470deleted or tampered with logs and files, making them untrustworthy. The
4471existence of multiple unpatched vulnerabilities may make it impossible (or not
4472worth the effort) to try to identify which specific vulnerability was exploited. In
4473such cases, it may be more expedient to begin IS recovery and hardening.
4474(2) Potential technical and operational implications should be assessed
4475carefully prior to recovering an IS without performing technical analysis. Such
4476an assessment will indicate how this may impact mission success. For
4477example, the primary benefit of determining root cause and eradicating it prior
4478to redeploying an IS is to prevent similar system compromises and to share
4479that information with other DoD communities, thereby strengthening the
4480overall security posture of DoD information networks. If a root cause is not
4481identified and eradicated, the IS may once again be compromised and others
4482may lose the valuable information provided by the technical analysis.CJCSM 6510.01B
448310 July 2012
4484E-5 Enclosure E
44855. Containment
4486a. Overview
4487(1) Containment consists of short-term, tactical actions to stop an
4488intruder’s access to a compromised IS, limit the extent of an intrusion, and
4489prevent an intruder from causing further damage.
4490(2) The primary objectives for containment are to:
4491(a) Regain control of the ISs involved in order to further analyze the
4492cyber incident and return the IS to normal operation.
4493(b) Deny an intruder access to prevent him or her from continuing
4494the malicious activity and from affecting other ISs and data.
4495(3) While an intruder has access to an IS, the IS cannot be properly
4496analyzed or restored. Performing containment:
4497(a) Prevents an intruder from accessing or exfiltrating DoD data or
4498other information.
4499(b) Prevents an intruder from destroying valuable evidence and
4500tampering with ISs while they are being analyzed.
4501(c) Prevents an intruder from using DoD ISs to attack other ISs,
4502protecting the CC/S/A/FAs from liability.
4503(4) Containment provides a reasonable security solution until sufficient
4504information has been collected to address the vulnerabilities exploited and the
4505damage sustained.
4506(a) It should be noted that some containment actions can be taken
4507during the preliminary response phase of the incident handling life cycle.
4508(b) More containment steps may be warranted following in-depth
4509analysis, which may identify more affected ISs or malicious activities.
4510Containment steps can be executed iteratively with the steps in the detection
4511and analysis phase.
4512(5) Containment strategies are executed by the CC/S/A/FA responsible
4513for the maintenance and operation of the affected DoD information networks or
4514ISs, this could be a local system administrator or could be the component’s
4515CNDSP. Who executes the strategies will depend on the incident type, affected
4516component, and local policy and procedures.CJCSM 6510.01B
451710 July 2012
4518E-6 Enclosure E
4519b. Containment Strategies. Containment strategies will vary based on the
4520type of incident. Containment activities may include any of the following, or
4521any other strategies determined by the affected CC/S/A/FAs.
4522(1) Blocking. Blocking is the use of network access controls at the
4523perimeter or enclave boundary to prevent the attacker from connecting to other
4524DoD information networks, ISs, or DoD data and services.
4525(a) The decision to block is based on the incident category, the
4526threat to the network, and instruction from CI/LE and USCYBERCOM.
4527(b) Category 1, 2, 3, 4, 6, and critical 7 incidents require immediate
4528blocks at the host and/or gateway level if the risk of further compromise, data
4529exfiltration, and continued threat to the DoD information networks outweighs
4530the benefit of monitoring adversary TTPs for a more comprehensive
4531countermeasure.
4532(c) Other incident categories, such as 5 and 8, may elicit a block if
4533the result reduces risk and exposure to potential delivery vectors.
4534(d) Block requests will include inbound and outbound traffic.
4535(e) Border Gateway Firewall Block. Gateway IP and port blocks are
4536used to prevent the spread of compromise from an identified external IS or
4537delivery vector. Category 1, 2, 3, 4, 6, and 7 incidents could necessitate
4538gateway blocks. Block requests will include inbound and outbound traffic.
4539Sample blocks include:
45401. IP addresses that host malicious code, malware, spyware, or
4541unauthorized software.
45422. Peer-to-peer (P2P) and instant messaging (IM)
4543communication ports.
45443. Mail relays, phishing, and spam originators.
45454. Known hostile IP addresses and hosts.
45465. IP addresses and ports associated with worms, botnets, and
4547trojans.
45486. External hosts that are identified performing scanning,
4549footprinting, or attempting to exploit DoD assets.CJCSM 6510.01B
455010 July 2012
4551E-7 Enclosure E
45527. DoS attacks.
4553(f) Enclave Firewall Block. Enclave firewall blocks follow the same
4554process as gateway blocks depending on the scope of the incident. Enclave
4555blocks are specific to the component behind the firewall. Block requests will
4556include inbound and outbound traffic.
4557(g) Mail and Proxy Block. Mail gateway blocks are required when
4558e-mail is the identified delivery vector. Mail blocks include filtering for
4559attachments, subject lines, and senders. Examples include spam, phishing,
4560worms, and other mail attachments attacks containing malicious code. Proxy
4561blocks are dependent on the content filtering solution of the component
4562managing the proxy application.
4563(2) Network Isolation. Network isolation involves the use of network
4564access controls to logically segment the network and restrict access to the
4565affected hosts. Isolation strategies include the following:
4566(a) Disconnect the IS From Any Local Area Network. This will help
4567prevent further contamination of the affected information network and IS.
4568(b) Disconnect IS From the Internet or Any Other Public Networks.
4569This will help to prevent inbound access or outbound traffic or data exfiltration.
4570(c) Disconnect or Isolate the Affected Network Host and/or Segment
4571from the Rest of the Network. This can help to prevent further contamination
4572or containing malicious activity to an IS or logical network segment. This will
4573allow attached ISs to still function but will not spread malicious activity to the
4574rest of the infrastructure. In some cases, this may be relevant to monitor
4575adversarial activity while limiting the adversary’s ability to attack other ISs.
4576(3) IS, Server, or Service Shutdown. Shutting down an IS, server, or
4577service may help limit damage or prevent further access to the IS by the
4578adversary. However, it will also affect the ability to acquire certain valuable
4579data for the incident analysis. The decision to pursue this containment
4580strategy should be weighed carefully.
4581(a) IS Shutdown. If it is determined that allowing the IS to function
4582will destroy data or applications on the IS, the IS should be shut down with the
4583commander’s approval as a containment measure.
4584(b) Server Shutdown. If it is determined that a particular server,
4585such as an e-mail or Web server, requires shutdown until problems can be
4586eliminated or to contain the spread of malicious code, the specific server
4587should be shut down. Be advised that in addition to destroying non-volatileCJCSM 6510.01B
458810 July 2012
4589E-8 Enclosure E
4590data, shutting down a server may adversely affect multiple users and mission
4591operations. This decision should be made in coordination with the relevant
4592command authority.
4593(c) Service Shutdown. If sufficient analysis has been performed to
4594correctly limit the scope of an intrusion to specific services, these services can
4595be disabled (especially if no patch is available). Be advised that in addition to
4596potentially destroying non-volatile data, shutting down a service may adversely
4597affect multiple users and mission operations. This decision should be made in
4598coordination with the relevant command authority.
4599(4) Other Containment Strategies. Other containment strategies
4600presented by NIST 800-61 (reference cc) include the following:
4601(a) Eliminate the attacker’s route into the environment by
4602preventing attacker from accessing nearby resources that might be targets.
4603(b) Block the transmission mechanisms for the malicious code
4604between infected ISs.
4605(c) Disable user accounts that may have been used in the attack.
4606c. Temporarily Leaving IS Online
4607(1) Under certain circumstances, the commander may decide to leave
4608the affected IS online and accept the risk in operating in and through a
4609compromised environment based on operational requirements. Additionally,
4610the commander may decide to leave the affected IS’s vulnerability accessible in
4611order to monitor the attacker’s activities.
4612(a) CNDSPs will monitor an attacker’s activities at all times
4613regardless of LE/CI involvement. This monitoring for IS protection purposes is
4614conducted in the ordinary course of business and authorized by federal law.
4615The results of monitoring for network defense may be shared with LE/CI
4616organizations 18 U.S.C. 2511(2)(a)(i) (reference dd).
4617(b) CNDSPs are not authorized to conduct monitoring on behalf of
4618LE/CI organizations for purely LE/CI purposes unrelated to CND. LE/CI
4619organizations must consult their servicing Staff Judge Advocate (SJA) about
4620monitoring.
4621(2) If a compromised IS is left running, NIST recommends,
4622“management and legal counsel should ensure there is no liability that can
4623result.” NIST also cautions “not containing malicious activity can cause moreCJCSM 6510.01B
462410 July 2012
4625E-9 Enclosure E
4626malicious activity to occur because malicious code or actions continue which
4627can cause further damage and loss of operations or DoD data.”
4628d. Caveats for Containment
4629(1) Any changes to compromised ISs, including containment actions,
4630may destroy information required to assess the cause of an intrusion. Ensure
4631that all necessary data for analysis is completely collected before making any IS
4632changes. Also, collect and protect all evidence that may be needed in a
4633subsequent investigation before performing any containment actions.
4634(2) CC/S/A/FAs and CNDSPs must define acceptable risks for incident
4635containment and develop strategies and procedures accordingly.
4636(3) Various questions arise when deciding whether to contain malicious
4637or unauthorized activity. Answers to these questions may require discussions
4638with IS and business process owners. Such questions can include:
4639(a) Is it appropriate to shut down or disconnect an IS?
4640(b) Does the CNDSP or local system administrator have the
4641authority to shut down or disconnect an IS?
4642(c) When must an IS stay up and running?
4643(d) What ISs cannot be taken offline or disconnected?
4644(e) Are there investigative or intelligence equities to consider? (See
4645Enclosure F.)
4646(4) Decide appropriate containment strategies for critical assets ahead
4647of time. By preparing in this way, a decision does not have to be made about
4648what is a correct or approved containment strategy during an incident.
4649(5) If the intruder’s actions are rapid and spreading, system
4650administrators and CNDSPs may need to take more immediate action;
4651response and containment policies and procedures should contain guidance for
4652such situations.
46536. Eradication
4654a. Overview
4655(1) Eradication consists of the steps required to eliminate the root
4656cause(s) of an intrusion. All threats and risks should be removed from DoDCJCSM 6510.01B
465710 July 2012
4658E-10 Enclosure E
4659information networks and ISs before returning them to service. If the threat is
4660not removed, then an IS can be easily compromised or breached again.
4661(2) The primary objectives for eradication are to:
4662(a) Ensure the removal of the cause(s) of the malicious activity and
4663any associated files.
4664(b) Ensure the elimination of any access methods used by the
4665intruder, including vulnerabilities, physical security problems, or human error.
4666(3) Execute eradication steps after the first round of containment
4667actions occur and then interactively with any further analysis and containment
4668activities.
4669(4) Sometimes, full eradication can only happen after long-term policy
4670and configuration management changes are put into place. In that case, the
4671threat should be mitigated to the extent possible before rebuilding and
4672reconnecting any affected ISs.
4673(5) Some ISs, due to the nature of the incident, may not need any
4674eradication steps, or the eradication may occur as part of the recovery activities
4675when the infected IS is wiped or erased and rebuilt.
4676(6) Eradication strategies are executed by the CC/S/A/FA responsible
4677for the maintenance and operation of the affected information networks or ISs;
4678this could be a local system administrator or could be the components CNDSP.
4679Who executes the strategies will depend on the incident type, affected
4680component, and local policy and procedures.
4681b. Eradication Strategies. Specific eradication actions depend on the
4682nature of the incident.
4683(1) Remove Malware. Quarantine, delete, replace, or restore the
4684integrity of infected files. In most cases, this will require rebuilding the IS from
4685trusted media. This may also involve updating antivirus signatures.
4686(a) Under most conditions, once an IS is compromised the integrity
4687of that IS cannot be verified until it has been restored from trusted media. If a
4688IS contains malware, keeping it in operation is not recommended unless the
4689complete integrity of that IS can be once again verified, or the IS is left running
4690and monitored closely as part of an ongoing LE/CI case. In the latter case, the
4691decision to leave the IS running must be based on approvals by authorized
4692DoD personnel.CJCSM 6510.01B
469310 July 2012
4694E-11 Enclosure E
4695(b) Any malware uncovered throughout the incident response
4696process must be cataloged in the JMC. Additional guidance may be found in
4697Enclosure G (CND Incident Handling Tools—Joint Malware Catalog).
4698(2) Remediate or Mitigate Vulnerability. Remove vulnerabilities by
4699installing any new operating IS or application patches to vulnerable software to
4700prevent exploitation. If the IS cannot be patched for technical or operational
4701reasons, mitigate the vulnerability by updating IS configurations and defenses
4702to protect or segment the affected host. If a patch is not available, apply
4703workarounds or temporary mitigation strategies.
4704(3) Modify Access Controls. Update user and network access controls.
4705For instance, remove compromised user or administrator accounts; modify
4706network access controls (e.g., IDS/IPS, firewall, content filtering); update
4707baseline configurations; and remove any other access mechanisms used by the
4708adversary.
47097. Recovery
4710a. Overview
4711(1) Recovery consists of the steps necessary to restore the integrity of
4712affected ISs, return the affected data, ISs, and information networks to an
4713operational state, and implement follow-up strategies to prevent the incident
4714from happening again.
4715(2) The main objectives of recovery are to:
4716(a) Restore the integrity of the IS by rebuilding it from trusted
4717media when necessary.
4718(b) Implement proactive and reactive defensive and protective
4719measures to prevent similar incidents from occurring in the future.
4720(c) Ensure all data and ISs are operating in a normal fashion.
4721(d) Ensure the complete resolution and closure of the incident.
4722(3) Data and ISs are fully restored when the necessary patches and
4723fixes applicable to the incident have been installed. If an IS is compromised,
4724the integrity of anything on that IS is suspect. The intruder could have
4725changed the kernel, binaries, data files, running processes, or memory. The
4726only way to be sure an IS is free of malicious code and back doors is to reinstall
4727the trusted media and then install any security patches and upgrades. This
4728includes both OS and application patches.CJCSM 6510.01B
472910 July 2012
4730E-12 Enclosure E
4731(4) Also, as part of the recovery process, any containment activities
4732completed may need to be removed. This can include removing any blocks that
4733are no longer necessary, re-enabling services, and reconnecting ISs and
4734information networks to the LAN or Internet.
4735(5) Recovery strategies can be executed by a variety of DoD personnel
4736based on their roles and responsibilities. Multiple strategies may need to be
4737implemented across the affected component. Who executes the strategies will
4738depend on the incident type, affected component, and local policy and
4739procedures.
4740b. Recovery Strategies. Depending on the nature of the incident, recovery
4741actions can include, but are not limited to the following:
4742(1) Rebuild from Trusted Media. Reinstall the OS and applications
4743from a trusted backup, or from original distribution media.
4744(2) Verify System Data. Review IS data to ensure its integrity.
4745Someone who knows what user or other data was on the IS should review the
4746data to ensure it has not been changed. Alternatively, restore IS data from a
4747trusted backup.
4748(3) Change System Passwords. Change all passwords on the IS and
4749possibly on all ISs that have trust relationships with the victim IS.
4750(4) Improve Network and Host Security
4751(a) Increase host and network monitoring.
4752(b) Enable maximum host logging, auditing, and accounting
4753programs.
4754(c) Disable unnecessary services.
4755(d) Verify there are no weaknesses in configuration files for those
4756services.
4757(e) Install all the latest vendor security patches and upgrades if
4758approved and tested.
4759(f) Update firewall rule-sets.
4760(g) Update boundary router ACLs.CJCSM 6510.01B
476110 July 2012
4762E-13 Enclosure E
4763(h) Update IDS/IPS signatures.
4764(i) Review any DoD guidance, advisories, or bulletins to see if there
4765are other recovery actions or security enhancements that can be enabled or
4766installed.
4767(j) Install new security mechanisms that may help protect ISs or
4768detect malicious activity. This can include programs like file integrity checkers,
4769URL checkers, etc.
4770(k) Implement any needed mail filtering.
4771(l) Update any security policies to reflect or support these security
4772improvements.
4773c. Once all recovery steps have been completed and ISs have been tested to
4774ensure they are operating normally, reconnect any hosts or information
4775networks that were disconnected.
4776(1) All ISs that have a Category 1, Category 2, or Category 7 incident
4777must be erased and rebuilt from trusted media, then patched and updated
4778prior to connecting the IS to the information network. This is necessary to
4779prevent an incident from recurring.
4780(2) Mission impact may require the affected vulnerable component be
4781mitigated temporarily until the mission allows the IS to be rebuilt. For other
4782categories, CC/S/A/FAs have the discretion of rebuilding the IS depending on
4783the impact of the incident.
4784(3) STIGs and technical configuration data are provided as required
4785from DISA Information Assurance Support Environment (http://iase.disa.mil)
4786and NSA security configuration guides (http://www.nsa.gov/snac).
4787(4) CC/S/A report compliance status or directed action of each task or
4788action via Vulnerability Management System (VMS) for their ISs and assets. By
4789doing so, USCYBERCOM and each Combatant Command has visibility of the
4790compliance status of all Service and agency assets that support the Combatant
4791Command.
47928. Post-Incident Activity
4793a. Overview
4794(1) One of the final parts of the incident handling process is learning
4795how to improve operations, processes, and infrastructure defenses by reviewingCJCSM 6510.01B
479610 July 2012
4797E-14 Enclosure E
4798the incident and the response. A postmortem is a review of the incident,
4799including the detection, analysis, and response phases.
4800(2) The primary objectives for performing a postmortem include:
4801(a) Identifying infrastructure problems to be addressed.
4802(b) Identifying ISs and configurations weaknesses or other
4803vulnerabilities to be corrected.
4804(c) Identifying organizational policy and procedural problems to be
4805reviewed and addressed.
4806(d) Identifying technical or operational training needs.
4807(e) Determining unclear or undefined roles, responsibilities,
4808interfaces, and authority.
4809(f) Improving tools required to perform protection, detection,
4810analysis or response actions.
4811(3) The CC/S/A/FA with primary responsibility for handling the
4812incident will normally take the lead in performing the postmortem and
4813collecting and trending any outputs. However, in certain circumstances a
4814management, audit, or other group may coordinate this, as appropriate.
4815b. Post-Incident Activity Strategies
4816(1) Results from a postmortem shall be used to make improvements to
4817the incident management process and methodology along with any
4818improvements to the security posture and defenses of the CC/S/A/FAs critical
4819to achieving the mission of the DoD.
4820(a) CC/S/A/FA HQ will establish a formalized postmortem process
4821and establish criteria defining which incidents require postmortems. Not all
4822incidents may require a postmortem. Incidents that are large in scope,
4823handled poorly, involve law enforcement, or caused severe damage are
4824candidates that require a postmortem. Less severe incidents such as regular
4825scanning require a limited postmortem or no postmortem.
4826(b) All parties involved in the incident should be part of the
4827postmortem. A postmortem shall be held as soon as possible to answer
4828questions such as the following:CJCSM 6510.01B
482910 July 2012
4830E-15 Enclosure E
48311. What were the timeframes for the incident, its detection, and
4832its resolution?
48332. What actions were correctly executed by users, analysts, and
4834management, and what actions were not correctly executed?
48353. Were appropriate procedures available and followed? Were
4836they up-to-date and correct? Were they still applicable?
48374. What would the staff and management do differently the next
4838time a similar incident occurs?
48395. What corrective actions can prevent similar incidents in the
4840future? This should include recommendations for signature updates and/or
4841development and changes to ACLs, filters, and system configurations.
48426. What additional tools or resources are needed to detect,
4843analyze, and mitigate future incidents?
4844(2) Pertinent information resulting from the postmortem should be
4845added as part of the final report for the incident.
4846(3) New or unusual cases can be captured and used as the basis for
4847future training exercises or case studies.
4848(4) After the postmortem is completed, feedback on improvements to be
4849made to policies, procedures, and infrastructure defenses should be passed to
4850the appropriate CC/S/A/FA responsible for making those improvements,
4851provided there is support and approval from commanders and HQ. It is
4852important to implement any changes that can be made based on these lessons
4853learned. This will help provide a more effective defense against recurring or
4854similar incidents. Changes to be implemented can include enterprise or local:
4855(a) Updates to security policies and implementation guides (e.g.,
4856DISA STIGs).
4857(b) Changes to incident management and incident handling
4858processes and procedures.
4859(c) Updates to detection systems.
4860(d) Improvements in IS and information network configurations.CJCSM 6510.01B
486110 July 2012
4862E-16 Enclosure E
4863(e) Changes to configurations and filters on network perimeter
4864devices, such as firewalls, routers, and gateways.
4865(5) The postmortem analysis and lessons learned produce information
4866and incident data that can be collected and used in various ways. This
4867information can be used to create baselines for benchmarking performance,
4868timeliness, and types of incidents seen. It can also be used to generate
4869trending and correlation information for historical purposes to determine
4870whether response actions are actually resolving problems over time.
4871(6) Data to collect and trend can include but is not limited to:
4872(a) Recurring problems and recurring user errors.
4873(b) Incident costs including damage sustained and response and
4874recovery efforts.
4875(c) Incident precursors.
4876(d) Types of incidents seen over time.
4877(e) Types of weaknesses exploited (e.g., certain applications, OSs,
4878social engineering tactics).
4879(7) Output from postmortem analysis and lessons learned can also be
4880used as case studies and training materials for new staff.
4881(CJCSM 6510.01B
488210 July 2012
4883F-1 Enclosure F
4884ENCLOSURE F
4885COLLABORATION WITH OTHER STRATEGIC COMMUNITIES
48861. Introduction
4887a. It is in the long-term interest of the Department of Defense to gain
4888attribution and prosecute malicious individuals attacking DoD ISs. The DoD
4889CND community works hand-in-hand with the DoD LE/CI to investigate and
4890monitor individuals who attack DoD ISs. Information and insights gained from
4891investigations can then be provided back to the DoD community to increase the
4892overall defensive posture of DoD information networks.
4893b. All unauthorized access to information networks or ISs is considered
4894punishable as a crime. The DoD investigative agencies conduct LE/CI
4895investigations and operations in support of CND. In doing so, the DoD
4896investigative agencies obtain and provide relevant threat data for use in
4897mitigating threats to the DoD information networks.
4898c. The success of DoD CND response depends on the Department of
4899Defense’s ability to effectively share and fuse analytical and operational
4900information across and within organizational boundaries, including operational
4901components, service providers, and the LE, CI, and intelligence communities in
4902a timely manner. This enables improved battlefield awareness across the full
4903spectrum of military operations to accurately characterize and understand the
4904effects of network intrusions on DoD information networks and to improve
4905military decision making about response strategies.
49062. Operational Cooperation with LE/CI
4907a. Reporting incidents and sharing information, notifications, and
4908coordinating analysis of security incidents with DoD investigative agencies
4909facilitate criminal attribution in the event U.S. code has been broken. The DoD
4910investigative agencies obtain and provide relevant threat data in a timely
4911manner to mitigate threats to the DoD information networks. The focal point
4912for Net Defense threat data in the Department of Defense is USCYBERCOM.
4913b. Deconflicting Investigative Actions. In some circumstances, LE/CI may
4914request DoD IS providers to allow a potentially compromised DoD IS to remain
4915operational for the purpose of facilitating LE/CI investigations and operations.
4916The commander of the organization shall make every effort to support such
4917requests; however, commanders are still required to maintain and defend theirCJCSM 6510.01B
491810 July 2012
4919F-2 Enclosure F
4920operations and, ultimately, the information networks that facilitate those
4921operations. Additional information can be found in Appendix A to Enclosure F
4922(Coordination and Deconfliction).
4923c. When investigative actions conflict with protective measures, these
4924measures will be coordinated with the affected investigative service ahead of
4925time unless there is an imminent threat.
4926(1) Supporting the Legal Process. Commanders must be careful to
4927balance short-term requirement to conduct operations with the long-term
4928advantage of prosecuting malicious individuals. If a commander is notified of a
4929legal process, such as a subpoena or warrant, has been issued and that their
4930actions may conflict with the intent of that order, the commander will
4931coordinate with LE/CI and the servicing SJA on any actions so that a legal
4932process is not obstructed. Commanders will also promptly inform the
4933USCYBERCOM SJA of any potential conflict.
4934(2) Data and Information Management. Actions required supporting
4935LE/CI investigations may include, but are not limited to, copying device media
4936to facilitate media analysis.
4937(a) Care should be taken in the release of device storage media
4938images or the results of analysis. Media is classified to the highest level of
4939information contained on the media. Additionally, the data on the media may
4940be sensitive but unclassified, such as CUI, limiting its sharing outside the
4941Department of Defense.
4942(b) If the device is evidence in an LE/CI investigation, the media
4943may be LE/CI sensitive, requiring special handling and a law enforcement
4944sensitive (LES) caveat. While this does not forbid CND analysts from
4945performing technical analysis, special care shall be taken to ensure the
4946dissemination of analytical results does not compromise an LE/CI
4947investigation. The commander of the organization shall coordinate with LE/CI
4948when releasing such information.9
4949(c) The operational community and LE/CI organizations must
4950effectively collaborate in order to rapidly disseminate information necessary for
4951network defense while minimizing the potential for compromise of LE/CI
4952operations, sources, and methods. Many times this can be done effectively
4953through the use of “tear lines,” etc.
49549 Where applicable, it may be more convenient to separate these concerns by
4955using two system images: one image for CND purposes and one image for
4956LE/CI purposes.CJCSM 6510.01B
495710 July 2012
4958F-3 Enclosure F
4959(3) Sharing Information. Trust must be established and maintained
4960among the numerous LE/CI agencies. Although there may be no legal
4961restriction on sharing certain information, for instance in regard to an ongoing
4962operation, many agencies may be hesitant to share information that could
4963jeopardize the safety of their sources, methods, and agents. Although
4964information obtained by the LE/CI community is governed by unique
4965restrictions and considerations, if this information is important to the security
4966of DoD ISs, it can be shared with appropriate controls and limitations on
4967distribution. To improve the flow and timeliness of the threat information
4968obtained by the LE/CI community, both the DoD CND organizations and the
4969LE/CI community must ensure formal processes are established to improve
4970mutual understanding of one another’s needs, capabilities, and unique
4971restrictions.
4972d. LE/CI Threat Data
4973(1) From a CND perspective, the principle value of the LE/CI
4974community is the threat information it obtains through investigations and
4975operations. Threat data consists of information that can help lead to increased
4976defense of DoD information networks and the attribution and intent of network
4977intruder(s). It can consist of planned actions that could adversely affect DoD
4978ISs. Threat data also consists of specific methodologies (toolsets, techniques,
4979targeted vulnerabilities) used by network attackers that are discovered through
4980an investigation.
4981(2) Typical sources of data include:
4982(a) Logs and records of ISPs recorded during the course of an
4983intrusion, as well as those ISP records used to store hacking tools, stolen data,
4984e-mails, chat rooms, etc.
4985(b) Information sharing with local, state, federal, and international
4986law enforcement counterparts.
4987(c) Interviews of human sources in support of proactive operations
4988and reactive investigations.
4989(d) Wiretaps, pen trap, and trace, etc.
4990(3) In addition to developing threat data during an investigation or
4991operation, the LE/CI community deters future threats by enforcing various
4992statutes and prosecuting those who violate the law.
4993(4) The CI community offers various capabilities and options when
4994countering the activities of foreign intelligence services and international
4995terrorists.CJCSM 6510.01B
499610 July 2012
4997F-4 Enclosure F
4998(a) Insider Activity. LE/CI authorities and capabilities are typically
4999the best option for addressing suspected and/or known access violations, theft,
5000and damage caused by trusted insiders. Given that “insiders” represent a large
5001population (e.g., U.S. military, government service civilians, contractors, and
5002foreign national coalition partners), reports related to potential insiders will
5003always be handled very cautiously.
5004(b) Unique Restrictions on Law Enforcement Data. As noted above,
5005the network defense can gain very important information from LE/CI
5006investigation and/or operations; however, much of the information may require
5007LES controls.
50083. International Coordination
5009a. International coordination and collaboration are achieved in a number of
5010ways. The Department of Defense has established relationships with many
5011countries through specific bilateral and multinational agreements (for instance,
5012CND information sharing with the 5 Eyes CND community is conducted by
5013USCYBERCOM (J3) under the auspices of the International CND Coordination
5014Working Group). Information is shared routinely, to generate shared
5015situational awareness amongst allied and partner nations, but coordination
5016and collaboration may also occur in response to specific incidents.
5017(1) The USCYBERCOM J3 functions as the focal point for DoD
5018communications with allied military counterparts. USCYBERCOM will
5019coordinate with Geographic Combatant Commands of agreements with allied
5020military counterpart organizations in their AOR.
5021(2) Geographic Combatant Command international CND coordination
5022and collaboration will occur under predefined agreements with military forces,
5023nations, or international organizations in their AOR.
5024b. In extremis, there may be a need to coordinate quickly with other foreign
5025countries in which attacking hosts reside. Existing relationships and
5026arrangements will be used to the greatest extent practicable according to the
5027extent to which they may be beneficial.
5028c. The key questions that may need to be addressed include:
5029(1) What is the state of relations between the United States and the
5030nation in question?
5031(2) Will a request for assistance itself constitute a greater threat to
5032national security than the attack or intrusion itself? This includes an
5033assessment of whether the country is an actual sponsor of the attack or mayCJCSM 6510.01B
503410 July 2012
5035F-5 Enclosure F
5036gain valuable information that could be used to attack the Department of
5037Defense.
5038(3) Does the nation in question have the technical capacity to respond
5039to a request for assistance?
5040(4) How long will it take for the nation to act on the request? Is that too
5041long given the threat to national security?
5042d. The IC has multiple vehicles for working with its counterparts in allied
5043countries. These relationships have a proven history of quickly tipping the
5044allied countries, and vice versa, to threat activity, providing new indications
5045and threat vectors, and increasing information sharing. The USCYBERCOM J2
5046and/or the appropriate GCC J2 DoD Intelligence Agency will act as the focal
5047point for operational intelligence requests to Allied or foreign partner CND
5048intelligence organizations through existing information sharing agreements.
5049e. The LE/CI community has a long history of working with its
5050counterparts in allied and other foreign countries. The LE/CI organizations at
5051USCYBERCOM will serve as the repository for relevant information shared by
5052the LE/CI community, conveying CND organization requests for information to
5053the LE/CI community and providing a focal point for LE/CI coordination with
5054USCYBERCOM.
5055f. In cases where international coordination is required beyond the
5056capabilities of the USCYBERCOM and LE/CI community, USSTRATCOM will
5057forward a request to the Department of State via the Secretary of Defense.
50584. Intelligence Community
5059a. Intelligence support to CND is essential to provide knowledge, reduce
5060uncertainty, and support effective operational decision making. According to
5061the definition of CND found in DoDI O-8530.2 (reference c), CND “ . . . employs
5062intelligence, counterintelligence, law enforcement and other military
5063capabilities to defend DoD information and computer networks.”
5064b. Accurate and timely intelligence analysis of network events and of
5065adversaries’ actions against the Department of Defense’s enterprise is critical to
5066ensuring operations and the future viability of the military’s vital information
5067resources and investments.
5068c. The Intelligence Support to CND offices provides all-source intelligence
5069in support of their respective organizations’ priority intelligence requirements.
5070All source intelligence consists of information that can help lead to increased
5071defense of DoD information networks and attribution and intent of network
5072intruder(s). It can consist of planned actions that could adversely affect DoDCJCSM 6510.01B
507310 July 2012
5074F-6 Enclosure F
5075ISs. All-source intelligence also consists of specific methodologies (toolsets,
5076techniques, targeted vulnerabilities) used by network attackers.
5077d. Each CNDSP is responsible for, and should identify processes for
5078working with, their appropriate Intelligence Support Element. This relationship
5079will vary based on organization and internal authorities and requirements, but
5080can provide a wealth of threat data, indications and warning, and the ability to
5081query the national level IC. Technical reporting between incident handling
5082program and intelligence is maintained in the JIMS. JIMS is the Department of
5083Defense’s new central repository for this key intelligence. The primary objective
5084of the database is to ensure the timely flow of crucial network intelligence
5085across DoD/USG and ally boundaries.
5086e. For additional guidance, see Appendix B to Enclosure F (Intelligence
5087Support to Incident Reporting).
50885. Cyber Unified Coordination Group. The Cyber Unified Coordination Group
5089(CUCG) consists of senior representatives from federal agencies that have roles
5090and responsibilities related to preventing, investigating, defending against,
5091responding to, mitigating, and assisting in the recovery from cyber incidents
5092and attacks.10 The CUCG is responsible for the following:
5093a. Provide input to member agencies and department heads and the
5094Interagency Incident Management Group (IIMG) on cyber security issues,
5095incidents, and threats.
5096b. Assist in reviewing threat assessments and providing strategic
5097situational awareness and decision support across the national cyber incident
5098management spectrum, including prevention, preparedness, response, and
5099recovery.
5100c. Integrate information, frame policy issues, and recommend actions—
5101including use or allocation of federal resources—for agency and department
5102heads, the IIMG, and other appropriate officials.
5103d. Coordinate with the DHS National Operations Center to disseminate
5104critical information to and from government and non-government sources,
5105such as information sharing mechanisms, academia, industry, and the public.
5106e. Support the Executive Office of the President, as appropriate.
510710 The NCRCG is an interagency forum where organizations responsible for a
5108range of activities (technical response and recovery, LE, intelligence, and
5109defensive measures) coordinate for the purpose of preparing for and executing
5110an efficient and effective response to an incident.CJCSM 6510.01B
511110 July 2012
5112Appendix A
5113F-A-1 Enclosure F
5114APPENDIX A TO ENCLOSURE F
5115COORDINATION AND DECONFLICTION
51161. Introduction
5117a. Coordination and deconfliction ensure that incident response COAs are
5118coordinated with all parties potentially affected by the response and in a way
5119that prevents any unnecessary interference or overlap between ongoing
5120activities. These actions must be vetted through all parties potentially affected
5121by the response.
5122b. For the purpose of this guidance, coordination and deconfliction are
5123defined below:
5124(1) Coordination is the act of exchanging information between
5125organizations to provide situational awareness, collaboration on assessments,
5126and synchronized response actions.
5127(2) Deconfliction is a subset of coordination in which information is
5128shared to eliminate overlap or interference between ongoing activities.
51292. Types of Operations
5130a. Time-Sensitive Operations. Time-sensitive operations generally involve
5131network-centric COAs to defend the DoD information networks against
5132imminent or ongoing threats.
5133(1) Time-sensitive operations require coordination inputs from DoD and
5134non-DoD organizations, with the timeliness required based on the threat and
5135the operational situation as determined in the CCIR.
5136(2) As a general rule, inputs for time-sensitive operations will be
5137required from all organizations within 4 hours of notification by
5138USCYBERCOM.
5139(3) USCYBERCOM J2 will manage requests for IC coordination and
5140deconfliction with the appropriate IC members. The LE/CI organizations (at
5141USCYBERCOM) shall conduct LE/CI coordination and deconfliction with
5142appropriate LE/CI organizations.
5143(4) Organizations participating in the coordination and/or deconfliction
5144process will provide POCs capable of responding 24 hours a day to take
5145appropriate action or be able to recall necessary personnel who can complete
5146the actions required within the required timeline in accordance with this
5147manual.CJCSM 6510.01B
514810 July 2012
5149Appendix A
5150F-A-2 Enclosure F
5151b. Non-Time-Sensitive Operations. Non-time-sensitive operations are
5152network-centric and non-network-centric COAs to defeat or mitigate ongoing
5153threats such as a persistent, sophisticated intruder.
5154(1) While coordination and deconfliction are important and all inputs
5155will be considered by USCYBERCOM when deciding to approve or disapprove a
5156particular course of action, non-concurrence from an organization does not
5157constitute a veto over the operation.
5158(2) Non-time-sensitive coordination and deconfliction will use a more
5159deliberative process employing periodic coordination and/or deconfliction
5160meetings, correspondence, teleconferences, and video teleconferences.
5161(3) Non-time-sensitive coordination and deconfliction procedures shall
5162be used when USCYBERCOM contemplates non-network-centric COAs, such
5163as diplomatic initiatives, public affairs campaigns, law enforcement
5164informational exchanges with foreign countries, etc., or when network-centric
5165Tier I incident responses are necessary but not assessed as time sensitive.
5166(4) Coordination and/or deconfliction meetings will be held periodically
5167(e.g., weekly, biweekly) with the IC, appropriate DoD LE/CI organizations, the
5168LE/CI organizations, Combatant Commands, Service components,
5169USCYBERCOM staff, and other government CND organizations as required.
5170c. Operational Practices. Coordination and deconfliction must occur
5171across tiers, between agencies, and with other DoD or external organizations,
5172as appropriate. The following operational practices provide guidance on how
5173this should occur.
5174(1) Establishing Meeting Frequency. Determine how often coordination
5175and deconfliction actions must occur between organizations.
5176(a) For Tier I level incident responses, USCYBERCOM will establish
5177the coordination/deconfliction meeting frequency and ensure meeting
5178notification is provided to appropriate organizations.
5179(b) For Tier II level responses, the respective CC/S/A/FA will
5180establish the coordination/deconfliction meeting frequency and ensure meeting
5181notification is provided to appropriate organizations, keeping USCYBERCOM
5182informed of any planned and executed incident responses.
5183(2) Initial Notifications. Initial notification and request for coordination
5184and deconfliction shall include the following information (at a minimum):CJCSM 6510.01B
518510 July 2012
5186Appendix A
5187F-A-3 Enclosure F
5188(a) A summary of the CND event, to include: threat assessments,
5189damage assessments, technical and operational impacts, and actions taken.
5190(b) Attribution assessment with levels of confidence.
5191(c) COAs under consideration and assessment.
5192(d) Time when inputs must be provided back to the incident
5193response lead agency.
5194d. Managing Concurrence and Alternative COAs. Work with all parties
5195affected by the response to understand their level of concurrence with the
5196recommended COAs and to solicit alternative COAs as needed.
5197(1) Coordination and/or deconfliction inputs from the IC or LE/CI
5198organizations for both time-sensitive and non-time-sensitive operations will
5199include a statement of understanding, where they may concur or nonconcur
5200with proposed COAs.
5201(2) In cases where an organization nonconcurs, the organization will
5202provide supporting technical, operational, or policy information as required so
5203the operational impact of COAs on those organizations can be balanced against
5204the ongoing threat. Nonconcurrence does not equate to a veto.
5205(3) Organizations may recommend alternate COAs in cases where an
5206organization nonconcurs with proposed COA. Organizations may provide
5207assessments of the threat, potential collateral damage, operational impact, and
5208political impact assessment for each COA. Organizations may also recommend
5209no action be taken for DoD, allied, and other forces networks.
5210(4) Organizations should identify data discrepancies and corrected data
5211if they do not concur in that data provided by the incident response lead
5212agency.CJCSM 6510.01B
521310 July 2012
5214Appendix A
5215F-A-4 Enclosure F
5216(INTENTIONALLY BLANK)CJCSM 6510.01B
521710 July 2012
5218Appendix B
5219F-B-1 Enclosure F
5220APPENDIX B TO ENCLOSURE F
5221INTELLIGENCE SUPPORT TO INCIDENT REPORTING
52221. Introduction. Intelligence support to CND is essential in order to provide
5223knowledge, reduce uncertainty, and support effective operational decisionmaking. Accurate and timely intelligence analysis of network events and of
5224adversary’s actions against the Department of Defense’s enterprise is critical to
5225ensuring both operations and the future viability of the military’s vital
5226information resources and investments.
52272. Joint Incident Management System (JIMS)
5228a. The JIMS is the Department of Defense’s central repository for managing
5229event and incident reports. The primary objective of JIMS is to ensure the
5230timely flow of crucial network intelligence across DoD/USG and ally
5231boundaries to reflect the collective reporting of adversary actions, intentions,
5232and capabilities; to assist in shaping tactical, strategic, and military response
5233strategies; and to perform trending analysis, correlation, and fusion.
5234b. The JIMS is used for recording possible foreign activity and domestic
5235initiated threat activity suspected of being foreign in origin and against DoD
5236networks. Use of the JIMS is required by the USCYBERCOM J2 and each
5237Service component CERT/CIRT intelligence support element for the following
5238categories of intrusions:
5239(1) Category 1—Root Level Intrusion.
5240(2) Category 2—User Level Intrusion.
5241(3) Category 4—Denial of Service.
5242c. The JIMS may also be used by Combatant Command Joint Intelligence
5243Centers/Joint Analysis Center/Joint Intelligence Operation Centers
5244(JICs/JAC/JIOCs), DIA, NSA, and DoD Service/agency intelligence centers.
5245d. The JIMS contains incident records based on JIMS entries
5246corresponding to threat activity against DoD computers and information
5247networks. Records include both technical and intelligence data related to the
5248IP addresses conducting activity against DoD ISs.
5249(1) JIMS will be the primary repository of intelligence related to
5250Category 1, Category 2, and Category 4 incidents and database intelligence
5251related to named intrusion sets. USCYBERCOM J3 is responsible for DoDfocused operations, such as official named intrusion sets.CJCSM 6510.01B
525210 July 2012
5253Appendix B
5254F-B-2 Enclosure F
5255(2) During analysis of network events, a serious pattern or series of
5256events may be identified and analytically developed by a Service or other
5257element. For the purposes of analytic collaboration and communication,
5258identifying this activity by a specific name may be warranted. In such a case,
5259the Service that identifies the activity will maintain the criteria and
5260determination of what falls into that “named area of interest” (NAI). If the
5261activity crosses multiple services or organizations, USCYBERCOM J3 may
5262determine the activity warrants being an enterprise event. USCYBERCOM may
5263then use the Service’s criteria to create an official USCYBERCOM Focused
5264Operation.
5265(3) The objective of JIMS intelligence reporting is to share intelligence
5266information and events in support of CND by enabling rapid cross-cueing of
5267threat activity and fusion of all-sources of information on foreign threats to
5268DoD information networks.
52693. Intelligence Reporting Procedures
5270a. CND intelligence reporting on network events focuses on foreign threats
5271to DoD information networks and has been divided into three types of
5272reporting.
5273(1) JIMS. JIMS intelligence reports generated in a timely manner for
5274incidents/events meeting a specified reporting threshold, based on technical
5275event data augmented with all-source intelligence information.
5276(2) Network Intelligence Report (NIR). All-source intelligence reports
5277focused on details of individual activity or a single event, a correlation of
5278several JIMS incident records, entity reporting on a person or organization
5279related.
5280(3) Strategic-Level All-Source Intelligence Analysis and Production.
5281DoD intelligence production will produce CND-related intelligence assessments
5282in response to specific consumer requirements and IAW individual
5283organizational production priorities.
5284b. Initial Intelligence Reporting. Individual incident records in the JIMS
5285are based on threat activity against DoD information networks that might be of
5286foreign origin. Note the JIMS also contains records of domestic IP addresses,
5287but the events associated with this activity are presumed foreign, until proven
5288otherwise.
5289(1) JIMS records are a timely technical summary of an event
5290supplemented with intelligence analysis that is entered into the JIMS.CJCSM 6510.01B
529110 July 2012
5292Appendix B
5293F-B-3 Enclosure F
5294Technical event details are derived from an entry in the JIMS or through other
5295sources. Technical specificity in initial JIMS reports is vital to establishing or
5296ruling out correlation between events during follow-on analysis.
5297(2) A JIMS entry is required for every Category 1—Root Level Intrusion,
52982—User Level Intrusion, 4—DoS, and incidents that appear to be associated
5299with USCYBERCOM-focused operations. A JIMS entry for other incident
5300categories is optional, but it is recommended when associated with focused
5301operations.
5302(3) Input into JIMS of initial analysis is required as soon as information
5303becomes available. Initial analysis on an event should occur as soon as
5304feasible.
5305(4) The USCYBERCOM J2 and the Service component CERT/CIRT
5306intelligence support elements are required to perform initial JIMS intelligence
5307reporting.
5308c. NIRs. NIRs can be based on patterns that emerge from correlation of
5309JIMS reports and/or provide correlated and amplifying intelligence on cyber
5310event(s) or entity(s).
5311(1) There are generally two types of NIRs:
5312(a) Event-Based NIR. Event-based NIRs focus on an incident, group
5313of incidents, or network activity.
5314(b) Entity-Based NIR. Entity-based NIRs focus on an individual,
5315group, or organization identified as a threat or potential threat to DoD
5316information networks.
5317(2) As with initial reports, timeliness for NIRs is important. Upon
5318recognition of a correlation among network incidents, malicious network
5319activity, and analysis on an entity, a NIR should be issued as soon as feasible.
5320(a) NIRs will be disseminated through message traffic, when
5321organizational processes allow, with a URL link to report if appropriate.
5322(b) NIRs will have a standard Title/Subject line. Example:
5323“Service/Organization Network Intelligence Report, Serial Number: Title.”
5324(c) The USCYBERCOM and the Service component command
5325CERT/CIRT intelligence support elements are required to perform follow-on
5326reporting when significant patterns or intelligence is identified associated with
5327events or entity activity. NIR reporting may also be generated by CombatantCJCSM 6510.01B
532810 July 2012
5329Appendix B
5330F-B-4 Enclosure F
5331Command JICs/JAC/JIOCs, DIA, NSA, NGA, and DoD Service/agency
5332intelligence centers.
5333(d) NIRs will be in following format (Table F-B-1):
5334Table F-B-1. NIR Report Format
5335d. Strategic-level, all-source intelligence analysis and production are also
5336used to satisfy CND intelligence requirements.
5337(1) Intelligence reporting to the CND community provides the following
5338benefits:
5339(a) Reports on final attribution.
5340(b) Provides full-scope examinations of events and incidents.
5341(c) Provides assessment of event/entity’s and incident strategic
5342significance.
5343(d) Provides damage assessments.
5344(2) SIRs may omit the detail provided in initial reports or follow-on
5345reports. These reports should attempt to capture the full military and/or
5346SERVICE/ORGANIZATION NETWORK INTELLIGENCE REPORT, SERIAL
5347NUMBER: “TITLE”
5348Summary: Executive overview, key points, and bottom-line.
5349Details: Result of incident, source characterization, target
5350characterization, activity/pattern characterization, and
5351background/entity characterization.
5352Threat Assessment: Analyst comments, recommendations, intelligence
5353impact, OPSEC analysis and significant information from operations.
5354References: Sources used in the report will be included in the Reference
5355section, to include JTID numbers when appropriate.
5356Contact information: Your contact information (organization, e-mail,
5357phone number, etc).
5358Amplifying or Additional Information: When amplifying information
5359exists, it should be included. Examples of this type of information
5360include, but are not limited to, additional technical data, list of hostile
5361IPs, list of victims, signatures, hashes, tools, host names, URLs,
5362intelligence gaps and related collection requirements with appropriate
5363classification markings.CJCSM 6510.01B
536410 July 2012
5365Appendix B
5366F-B-5 Enclosure F
5367political significance of network activity. Strategic reporting is normally
5368generated in response to intelligence consumer production requirements based
5369on organization production priorities and focus.
5370(3) Strategic reports may be based on a wide variety of reporting topics
5371relevant to entities or issues of importance to intelligence support to CND. For
5372example, these reports may provide potential threat information on foreign
5373actors (e.g., governments, sub-national actors, and individuals), technology
5374issues or trends, future projections, case studies, or global characterizations.
5375(4) Timeliness for strategic reporting is an important consideration
5376because it must be relevant to operational needs and other consumer
5377requirements. Although it is not possible to designate a specific time
5378requirement, once a consumer deadline has been established, the intelligence
5379production element must meet that requirement on a timely basis.
5380(5) SIRs may be generated by any CND intelligence provider.
5381(6) Formatting for SIRs is flexible. However, SIRs will generally conform
5382to DoD-wide standards such as the Intelligence Community Assessment.
53834. Product Dissemination
5384a. The Services/Combatant Commands are required to use the primary
5385reporting vehicle (i.e., JIMS). Analysis of network activity will be entered into
5386the JIMS and thus available for the communities use as soon as feasible.
5387Significant cyber events11 should also be disseminated via message traffic to
5388assure that immediate defensive/mitigation actions can be taken.
5389b. When organizational processes allow, all NIRs and strategic-level reports
5390will be disseminated via automated message handling system (AMHS)/M3. It is
5391up to the discretion of each organization to provide other means of
5392dissemination such as posting to a Web page or via e-mail.
5393c. The message format should follow guidelines as stated above or as
5394disseminated by USCYBERCOM.
53955. Writing for Release
5396a. All classified reports will be written for the widest dissemination
5397possible. If appropriate, one report may have multiple versions at different
539811 Cyber events are considered significant if they (1) occur more than one
5399percent of the yearly incident total; (2) affect more than one DoD enclave; and
5400(3) fall under incident handling categories 1, 2, 4, and 7.CJCSM 6510.01B
540110 July 2012
5402Appendix B
5403F-B-6 Enclosure F
5404classification levels (e.g., //REL TO USA, NATO or //REL TO FVEY (i.e.,
5405Australia, Canada, New Zealand, United Kingdom, and United States)).
5406b. All reports will include a “tear-line” or appendix for information, usually
5407technical in nature, which is UNCLASSIFIED//FOR OFFICIAL USE ONLY.
5408Inclusion of such an appendix will reduce ambiguity and provide clarity for the
5409CND community on what information can be used in sensors.
54106. USCYBERCOM “Smart Book”. USCYBERCOM will manage a community
5411“Smart Book.” This book contains background information for the CND IC.
5412Additional information, such as the standard format for Analyst Notebook
5413Charts and organizational missions, will be maintained in this book.
5414Currently, the “Smart Book” can be located on USCYBERCOM’s JWICS Web
5415page.CJCSM 6510.01B
541610 July 2012
5417G-1 Enclosure G
5418ENCLOSURE G
5419COMPUTER NETWORK DEFENSE INCIDENT HANDLING TOOLS
5420This enclosure provides an overview of common tools used by the computer
5421network defense (CND) community to facilitate incident handling.
54221. Joint Incident Management System (JIMS)
5423a. The JIMS is the central repository for managing all reportable events
5424and incidents in the Department of Defense. It serves as the primary reporting
5425mechanism for submitting reportable events and incidents to USCYBERCOM
5426and is the basis for USCYBERCOM support to Combatant Commanders, senior
5427government leaders, and civilian authorities.
5428b. The consistent, complete, and timely reporting of incident data into a
5429single repository is necessary to reflect the collective reporting of adversarial
5430activity. It can also help shape tactical, strategic, and military response
5431strategies, providing local, intermediate, and DoD side situational awareness of
5432CND activities, operations, and their impacts.
5433c. The CC/S/A/FAs provide reportable event and incident reports to the
5434JIMS in the form of database records. These reportable event and incident
5435records are integrated, correlated, and displayed using a variety of visualization
5436applications, the combination of which provide the CND community with a
5437shared situational awareness capability.
5438(1) Lessons Learned. CC/S/A/FAs are required to follow the policy and
5439guidance provided in the Joint Lessons Learned Program (JLLP), CJCSI
54403150.25D. The JLLP will contribute to joint capabilities integration,
5441development, and improvement. The JLLP will enhance the joint operator’s
5442ability to learn from the conduct of operations across all levels of engagement
5443and improve mission effectiveness.
5444(2) The Joint Lessons Learned Information System (JLLIS) is the System
5445of Record for the JLLP and provides a Web-enabled information management
5446system to meet operational needs for reporting lessons learned.
5447d. All organizations participating in the JLLP are to coordinate activities
5448and collaboratively exchange observations, findings, and recommendations to
5449the maximum extent possible.
5450e. CND Analysts use the Enterprise Sensor Grid (ESG) for collecting,
5451processing, and storing the DoD networking sensing environment information
5452(e.g., raw, processed, correlated, alert, etc.), facilitating execution of selected
5453COAs to mitigate and respond to attacks directed at DoD information networks.CJCSM 6510.01B
545410 July 2012
5455G-2 Enclosure G
5456f. USCYBERCOM is the functional owner of the JIMS and maintains and
5457manages it. Access to JIMS can be obtained through USCYBERCOM on
5458SIPRNET.
54592. Joint Malware Catalog (JMC)12
5460a. The JMC is the central repository for storing malware and associated
5461analysis. It serves as the primary reporting mechanism for submitting software
5462artifacts suspected of being adversarial tradecraft (e.g., viruses, rootkits, and
5463worms).
5464b. The JMC is the basis for the Department of Defense’s capability to
5465rapidly analyze malicious code and provide an accurate understanding of its
5466behavior and capabilities. By maintaining a current malware repository, the
5467Department of Defense can leverage previous analytical experience, identify
5468and respond to new attack techniques, and perform applied research to
5469improve analysis capabilities.
5470c. The CC/S/A/FAs submit malware to the JMC. Malware recorded in the
5471JMC can then be analyzed, viewed, correlated, and shared with other DoD
5472organizations. Some analytical results are produced automatically using
5473automated run-time analysis tools. More in-depth analysis may be conducted
5474by technical analysts and recorded in the JMC to share with others.
5475d. The USCYBERCOM is the functional owner of the JMC. The
5476USCYBERCOM maintains and manages the JMC. Access to the JMC can be
5477obtained through USCYBERCOM.
54783. CND Intelligence Analysis Tools
5479a. The primary CND intelligence analysis tool suite used to derive CND
5480intelligence information is JIMS.
5481b. The JIMS analysis environment is available on the SIPRNET network
5482and is intended to fuse intelligence with network incident reports to help shape
5483response strategies and perform trending analysis and correlations.
5484c. JIMS data is comprised of all of the significant foreign-initiated
5485computer intrusion or probe activity noted by incident analysts.
548612 The Joint MALWARE Catalog is currently under development. CND
5487developers interested in participating should contact USCYBERCOM.CJCSM 6510.01B
548810 July 2012
5489G-3 Enclosure G
5490d. Intelligence analysts research the TTPs used by the adversary during
5491each incident to ascertain what adversary may be responsible and if there is
5492any additional associated suspicious activity with this or other DoD hosts.
5493e. Both classified and open source research are used in the analysis, and
5494any derived intelligence is included in the JIMS.
5495f. The information and accompanying intelligence is provided in order to
5496document this activity, and to help determine common methodologies and
5497trends used by threat actors.
54984. DoD Protected Traffic List
5499a. USCYBERCOM maintains the DoD Protected Traffic List at the following
5500URL: http://www.cybercom.smil.mil. This list ensures critical DoD ISs are not
5501affected inadvertently by responses to CND events.
5502b. This list includes Internet-NIPRNET traffic, enclave traffic, and key
5503allied interoperability traffic. This technical data list includes IP addresses and
5504TCP/IP ports, as well as operational impacts if protected traffic is blocked.
5505c. CC/S/A/FAs notify USCYBERCOM of any actions taken that affect the
5506DoD Protected Traffic List. ISs on the DoD Protected Traffic List may be
5507affected under extreme circumstances; therefore, it is imperative to identify the
5508operational impact of actions taken prior to blocking traffic that may be on the
5509protected traffic list.
55105. DoD Enterprise Incident Sets
5511a. Incident sets are groups of related incidents and associated data
5512requiring centralized management at the DoD level.
5513b. Incident sets may span multiple CC/S/A/FAs or merit DoD-level
5514attention based on the scope or implications of the incidents.
5515c. Due to the strategic concern and implications of incident sets,
5516USCYBERCOM notifies STRATJIC IO Division of incidents and actions taken.
5517d. The USCYBERCOM is the central manager for all DoD Enterprise
5518Incident Sets. Incident sets are identified to the network operations
5519community using CTOs, which designate:
5520(1) Incident set unique name.CJCSM 6510.01B
552110 July 2012
5522G-4 Enclosure G
5523(2) Summary description.
5524(3) POC information.
5525(4) Incident set signature indicators.
5526(5) Response action guidance for incidents meeting incident set criteria.
5527(6) Special reporting guidance for both technical reporting and
5528operational reporting.
5529e. Tier II entities develop capabilities to track ongoing incident sets and
5530determines if detected intrusions match criteria for inclusion.
5531f. Intrusions and/or alert data matching a defined incident set signatures
5532are reported immediately to the USCYBERCOM.
5533g. Coordination and deconfliction activities with the LE/CI community for
5534USCYBERCOM managed incident sets occur via the LE/CI organizations (at
5535USCYBERCOM).
55366. DoD Information Network Deception Projects
5537a. DoD entities deploying network deception programs (e.g., honey pots)
5538report the device and/or program to the USCYBERCOM for situational
5539awareness prior to connection to any DoD information network.
5540b. This information is used to deconflict sensor reports of suspicious
5541activities or potentially vulnerable ISs.
5542c. Trusted agents within the USCYBERCOM safeguard system
5543information. Information on deception projects include:
5544(1) Mission, intent, and purpose of the project.
5545(2) Location (Internet address(es) and types of device(s) (must include the
5546WAN routable IP addresses).
5547(3) Type of data to be collected.
5548(4) POC for the device(s), to include telephone, e-mail, and organization.CJCSM 6510.01B
554910 July 2012
5550G-5 Enclosure G
55517. Cyber Condition (CYBERCON)
5552a. The CYBERCON system is a uniform system of five progressive
5553readiness conditions (CYBERCON 5, the least restrictive, through CYBERCON
55541, the most restrictive) with options for offensive and defensive cyberspace
5555operations, to include CND, Computer Network Exploitation (CNE), Computer
5556Network Attack Operational Preparation of the Environment (CNA-OPE), CNDRAs, and CNA as authorized by DoD regulations. CYBERCONs describe
5557graduated levels of readiness and response options that posture DoD
5558components to secure, operate, and defend the DoD Information Network and
5559to deter or defeat adversaries.
5560b. Commanders may raise CYBERCON levels to re-establish the
5561confidence level of systems based on the tradeoff in resources. Alternatively,
5562they may execute tailored readiness options to respond to specific intrusions or
5563threats.
5564c. As component heads or commanders increase their CYBERCON level or
5565implement Tailored Readiness Options (TROs), they will adjust their network
5566footprint and configuration to ensure the availability and control of mission
5567critical resources, and when authorized, conduct or request a CND-RA within
5568the defined bounds of the action under DoD authority.
5569d. Operations in support of CYBERCON implementation will be executed
5570in accordance with CJCSI 3121.01B and any approved supplemental
5571authorities. CDRUSSTRATCOM’s authority to set CYBERCON levels is derived
5572from DoDD O-8530.1 and CJCSI 6510.01, and is consistent with UCP
5573authorities to direct the operations and defense of the DoD Information
5574Network.CJCSM 6510.01B
557510 July 2012
5576G-6 Enclosure G
5577(INTENTIONALLY BLANK)CJCSM 6510.01B
557810 July 2012
5579H-1 Enclosure H
5580ENCLOSURE H
5581REFERENCES
5582a. Federal Information Security Management Act, Title III, Information Security
5583b. OMB Circular No. A-130, “Management of Federal Information Resources”
5584c. DoDI O-8530.2, 9 March 2001, “Support to Computer Network Defense
5585(CND)”
5586d. CJCSI 6510.01 Series, “Information Assurance (IA) and Support to
5587Computer Network Defense (CND)”
5588e. Unified Command Plan (UCP), 6 April 2011
5589f. DoDI O-3600.02, 28 November 2005, “Information Operation (IO) Security
5590Classification Guidance”
5591g. DoDI 5505.3, 21 June 2002, “Initiation of Investigation by Military Criminal
5592Investigative Organizations”
5593h. CJCSI 3121.01 Series, “Standing Rules of Engagement/Standing Rules for
5594the Use of Force for U.S. Forces”
5595i. CJCSM 3150.03 Series, “Joint Reporting Structure Event and Incident
5596Reports”
5597j. DoD 5400.11-R, 14 May 2007, “Department of Defense Privacy Program”
5598k. Privacy Act of 1974, 5 U.S.C. 552a
5599l. OMB memorandum M-07-16, 22 May 2007, “Safeguarding Against and
5600Responding to the Breach of Personally Identifiable Information”
5601m. OMB memorandum M-06-16, 23 June 2006, “Protection of Sensitive
5602Agency Information”
5603n. OMB memorandum M-06-19, 12 July 2006, “Reporting Incidents Involving
5604Personally Identifiable Information and Incorporating the Cost for Security in
5605Agency Information Technology Investments.”CJCSM 6510.01B
560610 July 2012
5607H-2 Enclosure H
5608o. NIST Special Publication 800-86, August 2006, “Guide to Integrating
5609Forensic Techniques into Incident Response”
5610p. “Investigations Involving the Internet and Computer Networks,” NCJ
5611210798. National Institute of Justice. Department of Justice (DOJ). January
56122007. Web. 17 July 2009. http://www.ojp.usdoj.gov/nij/pubssum/210798.htm.
5613q. 18 U.S.C. 2510 et seq.
5614r. 18 U.S.C. 31212 et seq.
5615s. 18 U.S.C. 2701 et seq.
5616t. Federal Rules of Evidence Exception (803(6))
5617u. “Searching and Seizing Computers and Obtaining Electronic Evidence in
5618Criminal Investigations,” July 2002, Computer Crime and Intellectual Property
5619Section, Criminal Division, U.S. Department of Justice. Web:
562015 July 2009, http://www.cybercrime.gov/s&smanual/
5621v. Electronic Communications Privacy Act (ECPA)
5622w. “Electronic Crime Scene Investigation: A Guide for First Responders,
5623Second Edition,” April 2008, National Institute of Justice, Department of
5624Justice. Web: 17 July 2009, http://www.ojp.usdoj.gov/nij/pubssum/219941.htm
5625x. “Forensic Examination of Digital Evidence: A Guide for Law Enforcement,”
5626April 2004, National Institute of Justice, Department of Justice. Web:
562717 July 2009, http://www.ojp.usdoj.gov/nij/pubs-sum/199408.htm
5628y. “Digital Evidence in the Courtroom: A Guide for Law Enforcement and
5629Prosecutors,” January 2007, National Institute of Justice, Department of
5630Justice. Web: 17 July 2009, http://www.ojp.usdoj.gov/nij/pubssum/211314.htm
5631z. CNSSI No. 1253, October 2009, “Security Categorization and Control
5632Selection for National Security Systems”
5633aa. NIST SP 800-60, “Volume 1: Guide for Mapping Types of Information and
5634Information Systems to Security Categories”CJCSM 6510.01B
563510 July 2012
5636H-3 Enclosure H
5637bb. DoDI 8510.01, 28 November 2007, “DoD Information Assurance
5638Certification and Accreditation Process (DIACAP)”
5639cc.NIST SP 800-61, March 2008, “Computer Security Incident Handling Guide”
5640dd. 18 U.S.C. 2511(2)(a)(i)
5641ee.CJCSI 3150.25D, “Joint Lessons Learned Program”
5642ff. Joint Publication 1-02 Series, “Department of Defense Dictionary of Military
5643and Associated Terms”
5644gg.CNSSI No. 4009, “National Information Assurance (IA) Glossary”
5645hh.DoD O-8530.1-M, 17 December 2003, “Department of Defense Computer
5646Network Defense (CND) Service Provider Certification and Accreditation
5647Process”
5648ii. DoDD 8100.1, 19 September 2002, “Global Information Grid (GIG)
5649Overarching Policy”
5650jj. DoDD 8500.01E, 24 October 2002, “Information Assurance (IA)”
5651kk. “Joint Concept of Operations for Global Information Grid Network
5652Operations”
5653ll. DoDI 8552.01, 23 October 2006, “Use of Mobile Code Technologies in DoD
5654Information Systems”
5655mm. CJCSI 3150.25, “The Joint Lessons Learned Program”
5656nn.Joint Publication 5-0 Series, “Joint Operation Planning”
5657oo. CNDSP Evaluator’s Scoring Metrics, “Certification and Accreditation”, Ver.
56588.0, 1 June 2011
5659pp. NIST SP 800-53, “Recommended Security Controls for Federal Information
5660Systems and Organizations, Revision 3”CJCSM 6510.01B
566110 July 2012
5662H-4 Enclosure H
5663(INTENTIONALLY BLANK)CJCSM 6510.01B
566410 July 2012
5665GL-1 Glossary
5666GLOSSARY
5667GLOSSARY PART I—ABBREVIATIONS AND ACRONYMS
5668ACL access control list
5669AO Authorizing Official
5670AOR area of responsibility
5671ARP address resolution protocol
5672AS&W attack sensing and warning
5673AV antivirus
5674B
5675B/P/C/S base/post/camp/station
5676BDA battlefield damage assessment
5677C
5678C2 command and control
5679CAT category
5680CCC C4 Control Center
5681CC/S/A/FA Combatant Command/Service/Agency/Field Activity
5682CCIR Commander’s Critical Information Requirement
5683CERT computer emergency readiness team
5684CI counterintelligence
5685CIO chief information officer
5686CIRT computer incident response team
5687CND Computer Network Defense
5688CNDRA Computer Network Defense Response Actions
5689CNDSP Computer Network Defense Service Provider
5690COA course of action
5691CTO communications tasking order
5692CUI Controlled Unclassified Information
5693CYBERCON cyber condition
5694D
5695DAA Designated Accrediting Authority, now known as the
5696Authorizing Official
5697DHS Department of Homeland Security
5698DIA Defense Intelligence Agency
5699DIB Defense Industrial Base
5700DISA Defense Information Systems Agency
5701DLL Dynamic-Link Library
5702DNC DISA NetOps Center
5703DoD Department of Defense
5704DoDI Department of Defense instruction
5705DOJ Department of JusticeCJCSM 6510.01B
570610 July 2012
5707GL-2 Glossary
5708DOS Department of State
5709DoS denial of service
5710DSN Defense Switch Network
5711DTG date-time group
5712E
5713ECPA Electronic Communications Privacy Act
5714ESG Enterprise Sensor Grid
5715F
5716FISMA Federal Information Security Management Act
5717FRAGORD fragmentary order
5718G
5719GNCC Global Network Operations Control Center
5720GNSC Global Network Support Center
5721H
5722HQ headquarters
5723I
5724I&W indications and warning
5725IA information assurance
5726IAPC Information Assurance Protection Center
5727IAVM information assurance vulnerability management
5728IAW in accordance with
5729IC Intelligence Community
5730ICCWG International CND Coordination Working Group
5731IC-IRC Intelligence Community–Incident Response Center
5732IDS intrusion detection system
5733IIMG Interagency Incident Management Group
5734IM instant messaging
5735IO information operations
5736IP Internet Protocol
5737IPS intrusion prevention system
5738IS information system
5739ISAC Information Sharing and Analysis Center
5740ISP Internet service provider
5741IT information technology
5742J
5743JEL Joint Electronic Library
5744JIMS Joint Incident Management System
5745JMC Joint Malware Catalog
5746JLLIS Joint Lessons Learned Information SystemCJCSM 6510.01B
574710 July 2012
5748GL-3 Glossary
5749JLLP Joint Lessons Learned Program
5750JTIP Joint Threat Intelligence Portal
5751JWICS Joint Worldwide Intelligence Communications System
5752L
5753LAN local area network
5754LE law enforcement
5755LE/CI law enforcement and counterintelligence
5756LES law enforcement sensitive
5757M
5758MAC mission assurance category
5759MB megabyte
5760N
5761NAI named area of interest
5762NCRCG National Cyber Response Coordination Group
5763NIPRNET Non-Secure Internet Protocol Router Network
5764NIR Network Intelligence Report
5765NIST National Institute of Standards and Technology
5766NGA National Geospatial-Intelligence Agency
5767NOSC Network Operations Security Center
5768NRO National Reconnaissance Office
5769NSA National Security Agency
5770NSC Network Service Centers
5771NTOC National Security Agency/Central Security Service Threat
5772Operations Center
5773O
5774OI operational impact
5775OMB Office of Management and Budget
5776OPORD operation order
5777OPREP operational report
5778OPSEC operations security
5779OS operating system
5780OSD Office of the Secretary of Defense
5781P
5782P2P peer-to-peer
5783PII personally identifiable information
5784POC point of contact
5785R
5786RA Response Actions
5787RAM random-access memoryCJCSM 6510.01B
578810 July 2012
5789GL-4 Glossary
5790S
5791SA situational awareness
5792SCI sensitive compartmented information
5793SIPRNET Secret Internet Protocol Router Network
5794SIR Strategic Intelligence Report
5795SJA Staff Judge Advocate
5796STIG Security Technical Implementation Guides
5797STRATJIC USSTRATCOM Joint Intelligence Center
5798T
5799TASKORD tasking order
5800TCCC Theater C4I Control Center
5801TCP Transmission Control Protocol
5802TDY temporary duty
5803TI technical impact
5804TID Threat Identification Database
5805TNC Theater NetOps Center
5806TNCC Theater Network Control Center
5807TPFDD time-phased force deployment data
5808TRO tailored readiness option
5809TS Top Secret
5810TTP tactics, techniques, and procedures
5811U
5812URL Uniform Resource Locator
5813USB universal serial bus
5814US-CERT United States–Computer Emergency Readiness Team
5815USCYBERCOM U.S. Cyber Command
5816USSTRATCOM U.S. Strategic Command
5817W
5818WAN wide area network
5819WARNORD warning orderCJCSM 6510.01B
582010 July 2012
5821GL-5 Glossary
5822GLOSSARY PART II—DEFINITIONS
5823Unless otherwise stated, the terms and definitions contained in this glossary
5824are for the purposes of this manual only. Unless indicated by a parenthetic
5825phrase after the definition that indicates the source publication or document,
5826these terms have not been standardized for general, DoD-wide use and
5827inclusion in the Department of Defense Dictionary of Military and Associated
5828Terms (JP 1-02) (reference ff). In some cases, JP 1-02 may have a general,
5829DoD-wide definition for a term used here with a specialized definition for this
5830instruction.
5831accreditation decision. See CNSSI No. 4009, “National Information Assurance
5832(IA) Glossary” (reference gg).
5833attack sensing and warning (AS&W). See CNSSI No. 4009 (reference gg).
5834availability. See CNSSI No. 4009 (reference gg).
5835blue team. See CNSSI No. 4009 (reference gg).
5836command authority. See CNSSI No. 4009 (reference gg).
5837Commander’s Critical Information Requirement (CCIR). An information
5838requirement identified by the commander as being critical to facilitating timely
5839decision making.
5840component CND authority. See reference hh.
5841computer network defense (CND). Actions taken to protect, monitor, analyze,
5842detect, and respond to unauthorized activity within the Department of Defense
5843information systems and computer networks.
5844computer network defense (CND) operational hierarchy. See reference hh.
5845computer network defense response actions (CND RAs). CJCSI 3121.01 Series,
5846“Standing Rules of Engagement/Standing Rules for the Use of Force for U.S.
5847Forces”
5848computer network defense (CND) services. See reference hh.
5849computer network defense service provider (CNDSP). See reference hh.CJCSM 6510.01B
585010 July 2012
5851GL-6 Glossary
5852confidentiality. See CNSSI No. 4009 (reference gg).
5853counterintelligence. Information gathered and activities conducted to identify,
5854deceive, exploit, disrupt, or protect against espionage, other intelligence
5855activities, sabotage, or assassinations conducted for or on behalf of foreign
5856powers, organizations or persons or their agents, or international terrorist
5857organizations or activities.
5858counterintelligence activities. The four functions of counterintelligence are
5859operations; investigations; collection and reporting; and analysis, production,
5860and dissemination.
5861counterintelligence investigation. An official, systematic search for facts to
5862determine whether a person is engaged in activities that may be injurious to
5863U.S. national security or advantageous to a foreign power.
5864cyber incident. Actions taken through the use of computer networks that
5865result in an actual or potentially adverse effect on an information system
5866and/or the information residing therein.
5867enclave. See CNSSI No. 4009 (reference gg).
5868enterprise CND sensor grid. A coordinated constellation of independently
5869owned and implemented intrusion and anomaly detection systems deployed
5870throughout DoD information systems and computer networks. The CND
5871sensor grid supports sensing capabilities for NetOps.
5872event. Any observable occurrence in a system and/or network. Events
5873sometimes provide indication that an incident is occurring. See CNSSI No.
58744009 (reference gg).
5875fragmentary order. An abbreviated form of an operation order issued as
5876needed after an operation order to change or modify that order or to execute a
5877branch or sequel to that order (reference ff).
5878General Service Network or System (GENSER). See reference hh.
5879Global Information Grid. See CNSSI No. 4009 (reference gg).
5880incident handling. The detection, analysis, and response to any cyber event or
5881incident for the purpose of mitigating any adverse operational or technical
5882impact.
5883indications and warning (I&W). See reference hh.CJCSM 6510.01B
588410 July 2012
5885GL-7 Glossary
5886information assurance (IA). Actions taken through the use of computer
5887networks that result in an actual or potentially adverse effect on an information
5888system and/or the information residing therein (reference gg).
5889information assurance vulnerability management (IAVM). The comprehensive
5890distribution process for notifying CC/S/A/FAs about vulnerability alerts,
5891bulletins, technical advisories, and countermeasures information. The IAVM
5892program requires CC/S/A/FA receipt acknowledgment and provides specific
5893time parameters for implementing appropriate countermeasures depending on
5894the criticality of the vulnerability.
5895Information Sharing and Analysis Center (ISAC). Mission is to advance the
5896physical and cyber security of the critical infrastructures by establishing and
5897maintaining a framework for valuable interaction between and among ISACs
5898and with government (http://www.isaccouncil.org).
5899integrity. See CNSSI No. 4009 (reference gg).
5900Joint Malware Catalog. The Joint Malware Catalog is the central DoD
5901repository for storing malware and associated analysis. It serves as the
5902primary reporting mechanism for submitting software artifacts suspected of
5903being adversarial tradecraft (e.g., viruses, rootkits, and worms).
5904Joint Incident Management System (JIMS). JIMS is the central catalog for
5905managing event and incident reports. The primary objective of JIMS is to
5906ensure the timely flow of crucial network intelligence across DoD/USG and ally
5907boundaries; to reflect the collective reporting of adversarial activity; to assist in
5908shaping tactical, strategic, and military response strategies; and to perform
5909trending analysis, correlation, and fusion.
5910Joint Lessons Learned Program (JLLP). Establishes policy, guidance and
5911responsibilities for the CJCS Joint Lessons Learned Program (JLLP) and
5912codifies the Joint Lessons Learned Information System (JLLIS) as the DoD
5913system of record for the JLLP.
5914Mission Assurance Category. See reference jj.
5915network operations (NetOps). NetOps is defined as the operational construct
5916consisting of the essential tasks (DoD Information Networks Network Defense,
5917DoD Information Networks Enterprise Services, and content staging/
5918information dissemination management), situational awareness (SA), and C2
5919that USSTRATCOM will use to operate and defend DoD Information Networks.
5920The three desired effects of NetOps are assured system and network
5921availability, assured information protection, and assured information delivery
5922(reference kk).CJCSM 6510.01B
592310 July 2012
5924GL-8 Glossary
5925operation order (OPORD). A directive issued by a commander to subordinate
5926commanders for the purpose of effecting the coordinated execution of an
5927operation (reference ff).
5928red team. See CNSSI No. 4009 (reference gg).
5929reportable event. An event that may, or may not, result in an incident, but is
5930required to be reported in accordance with this manual or other DoD reporting
5931guidelines (e.g., OPREP 3 reporting).
5932special enclave. DoD information systems and/or computer networks with
5933special security requirements (e.g., special access programs, special access
5934requirements).
5935system. See CNSSI No. 4009 (reference gg).
5936tasking order (TASKORD). A method used to task and to disseminate to
5937components, subordinate units, and command and control agencies projected
5938targets and specific missions (reference ff).
5939trusted media. Media provided by a trusted source that is adjudged to provide
5940reliable software code and/or information and whose identity can be verified by
5941authentication.
5942trusted source. A software and/or information source that is adjudged to
5943provide reliable software code and/or information and whose identity can be
5944verified by authentication (reference ll).
5945trusted toolkit. Tools provided by a trusted source that are adjudged to provide
5946reliable software code and/or information and whose identity can be verified by
5947authentication.
5948vulnerability assessment. See CNSSI No. 4009 (reference gg).
5949warning order (WARNORD). A WARNORD is a planning directive that initiates
5950the development and evaluation of military COAs by a supported commander
5951and requests that the supported commander submit a commander’s estimate
5952(reference ff).