Task 2 RMF_Incident Response Plan.docx

{COMMAND}

{SYSTEM NAME} {ACRONYM}

System Version: {VERSION} eMASS# {EMASS#}

Confidentiality: {CONFIDENTIALITY} Integrity: {INTEGRITY} Availability: {AVAILABILITY}

Department of the {SERVICE}

{LOGO}

Incident Response Plan Document Version: 1.0.0

{DATE}

Prepared by: {ORGANIZATION}

DISTRIBUTION IS LIMITED TO U.S. GOVERNMENT AGENCIES AND THEIR CONTRACTORS.

OTHER REQUESTS FOR THIS DOCUMENT MUST BE REFERRED TO: {ORGANIZATION}

Change Record

Amplifying Guidance

i. Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01B, "Cyber Incident Handling Program"

ii. NIST Special Publication 800-61 Revision 2, "Computer Security Incident Handling Guide"

iii. United States Cyber Command

iv. United States Computer Emergency Readiness Team

Table of Contents

FOR OFFICIAL USE ONLY

{ACRONYM}

INCIDENT RESPONSE PLAN {DATE}

Template developed by:

http://www.i-assure.com FOR OFFICIAL USE ONLY

1.0 OVERVIEW

A Cyber Incident is defined as, “An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.

Guidance contained herein will cover the high-level procedures related to the Protect, Monitor, Analyze, Detect, and Respond phases of the Computer Network Defense (CND) life cycle. It will describe the policies and processes required to operate a comprehensive DoD cyber incident-handling program. More specific guidance tailored for the individual requirements of CC/S/A/FAs will be provided through operation orders (OPORDs), warning orders (WARNORDs), fragmentary orders (FRAGOs), tasking orders (TASKORDs), or similar command authority orders and directives. This document is a framework that will be used by {ACRONYM} and individuals to provide a unified approach to cyber incident handling to enable effective collaboration between and across DoD distributed organizations in a way that improves the {ACRONYM}’s ability to protect and defend DoD information networks and information.

This document complies with the following requirements from NIST Special Publication 800-53 Revision 4, "Security and Privacy Controls for Federal Information Systems and Organizations". A detailed compliance matrix can be found in Appendix I, “Detailed Compliance Matrix”.

Table 1 - SP-800-53v4 Compliance Matrix

1.1 Applicability

This IRP contains information that is required to present the full incident lifecycle and reporting requirements. The {ACRONYM} role within this process is Tier III, which initiates local operational reporting and receives support from and responds to direction from a designated Tier II Computer Network Defense Service Provider (CNDSP). The {ACRONYM} CNDSPs are:

DELETE N/A CNDSP

https://www.ncdoc.navy.mil http://www.ncdoc.navy.smil.mil

DSN: (312) 537-4024 Com: (757) 417-4024 Toll: (888) 628-2362

STE: (312) 537-7952

STE: (757) 417-7952

ncdoc@ncdoc.navy.mil cndwo@ncdoc.navy.smil.mil Plain Language Address: NCDOC NORFOLK VA

https://www.ncdoc.navy.mil http://www.ncdoc.navy.smil.mil

DSN: (312) 537-4024 Com: (757) 417-4024 Toll: (888) 628-2362

STE: (312) 537-7952

STE: (757) 417-7952

ncdoc@ncdoc.navy.mil

https://www.ncdoc.navy.mil http://www.ncdoc.navy.smil.mil

DSN: (312) 537-4024 Com: (757) 417-4024 Toll: (888) 628-2362

STE: (312) 537-7952

STE: (757) 417-7952

ncdoc@ncdoc.navy.mil

https://www.hpc.mil

https://www.hpc.mil

Table 2 - Computer Network Defense Service Providers

1.2 Internal Roles and Points of Contact

A single incident response team has been created to handle incidents throughout {ACRONYM}. The team has only part-time incident response team members, serving as more of a virtual incident response team. When an emergency occurs, the team members are contacted rapidly, and those who can assist do so. The IT help desk acts as a first point of contact for incident reporting. The help desk members are trained to perform the initial investigation and data gathering and then alert the incident response team if it appears that a serious incident has occurred. The following roles have been established for the {ACRONYM} Incident Response Team:

{PHONE}

{EMAIL}

{PHONE}

{EMAIL}

{PHONE}

{EMAIL}

{PHONE}

{EMAIL}

Table 3 - Internal Roles and Points of Contact

2.0 INTRODUCTION

The methodology described in this section provides a general, standardized process that establishes the intent and requirements for detecting, analyzing, and responding to information or technology events or cyber incidents for the purpose of mitigating any adverse operational or technical impact on DoD data, ISs, and information networks.

An effective cyber incident handling capability relies on disciplined processes, procedures, and ISs. These must communicate timely, accurate, and accessible information about the cyber incident’s cause, impact, and current situation to incident responders, command authorities, and others involved in directing incident response actions. The primary objectives of this cyber incident handling process is to:

1) Maintain a robust detection capability to ensure all suspicious activity is detected and reported so that further analysis can take place to determine if it is a reportable cyber event or incident.

2) Ensure the timely reporting of cyber incidents through appropriate technical and operational channels in a way that promotes an accurate, meaningful, and comprehensive understanding of the cyber incident throughout its life cycle.

3) Effectively contain events and incidents and isolate ISs to minimize any damage or impact to DoD information networks, ISs, data, and services.

4) Safely acquire and preserve the integrity of data required for cyber incident analysis to help determine the technical/operational impact, root cause(s), scope, and nature of the cyber event or incident.

5) Ensure the effective coordination and communication of cyber incident information through appropriate channels and with appropriate stakeholders, higher CND organizations, and/or CC/S/A/FAs’ headquarters (HQ).

6) Provide an effective and comprehensive response that includes the recovery of any affected ISs and the return to a fully functioning, secure, operational state for all services and ISs.

7) Identify lessons learned to help improve infrastructure component protection strategies and cyber incident handling procedures to prevent a recurrence of the cyber event or incident. Observations should be entered into the Joint Lessons Learned Information System (JLLIS) at http://www.jllis.smil.mil. JLLIS is the DoD system of record for lessons learned. Use of JLLIS allows for the dissemination of lessons learned throughout the Joint Force.

8) Understand patterns of activity and trends to characterize the threat and direct protective and defensive strategies.

3.0 CYBER INCIDENT HANDLING PROCESS AND LIFE CYCLE

The basic process for DoD cyber incident handling can be grouped into the following processes or phases:

1) Detection of events.

2) Preliminary analysis and identification of incidents.

3) Preliminary response actions.

4) Incident analysis.

5) Response and recovery.

6) Post-incident analysis.

Figure 1 - Cyber Incident Lifecycle

What is learned throughout the process can be leveraged to improve the state of the practice in defending against future attacks.

3.1 Detection of Events

Detection of cyber events is the continuous process of identifying any unusual network or IS activity that has the potential to adversely affect DoD information networks, ISs, or operational missions. The primary objectives of detecting cyber events include:

a) Ensuring all suspicious activity is detected and reported so that further analysis can take place to determine if it is a reportable cyber event or incident.

b) Ensuring suspicious activity is reported in a timely manner consistent with required reporting timelines.

c) Effectively coordinating with command channels and other DoD organizations.

As part of this process, information about potential incidents, vulnerabilities, or other security or incident information is gathered and reported to the appropriate area for analysis and response. This process is important because it is the point where an anomalous or unusual cyber event is first noticed and identified as something that must be reviewed. It may also be the first point at which a cyber event is reported. Detection starts the reporting process Detection of a cyber event may occur in various ways, including by:

1) An automated detection system or sensor.

2) A report from an individual or user.

3) An incident report or situational awareness update from other internal or external organizational components, such as other CNDSPs, USCYBERCOM, US-CERT, IC, LE/CI, or other external Computer Security Incident Response Team entities.

3.2 Preliminary Analysis and Identification

Performing preliminary analysis and identifying incidents is the process of performing initial analysis of a detected cyber event to determine if it is a reportable cyber event or incident. The primary objectives for this phase include the following:

a) Determining whether a detected event is a reportable cyber event or incident.

b) Ensuring all appropriate DoD organizations are notified through technical and operational reporting channels.

c) Ensuring the timely submission of an initial incident report that contains as much complete and useful information as is available (or possible).

A standardized benchmark is used for defining a reportable cyber event or incident. If an event does not meet the incident criteria, it can be removed from consideration. If the proper preliminary analysis is not done, some incidents may not be identified and therefore never be reported. Such a failure can impact the global security posture of the DoD information networks, resulting in an inaccurate operational picture and potentially allowing an incident to continue, thereby increasing the damage and loss resulting from the unidentified and unreported malicious activity. During this phase of the incident life cycle, the incident handler or automated detection systems will review the incoming event data, identify what type of activity is occurring, and determine if an anomalous event shall be treated as a reportable cyber event or incident. Initial information to be reviewed will include, where available:

a) General description of the problem, event, or activity.

b) Status (ongoing or ended; successful or unsuccessful).

c) Number of ISs affected.

d) Source and destination Internet Protocol (IP) addresses.

e) Source and destination ports.

f) Hostname(s).

g) IS location.

h) User information.

i) Timestamps.

j) IDS alert and payload data (if relevant).

An event can be declared an incident at various points in the incident handling process, including during the preliminary analysis phase or the more detailed incident analysis phase. Sometimes, if an automated detection system is used, the criteria used to benchmark network traffic or IS activity may flag an event as an incident at the time it is detected.

3.2.1 Preliminary Analysis and Identification Methodology

The following methodology will ensure a consistent approach to preliminary analysis and identification:

Figure 2 - Preliminary Analysis and Identification Methodology Assess and Categorize. Assess the event against the incident criteria to determine if it is a reportable cyber event or incident. Confirmed reportable events or incidents shall be categorized using Appendix A to Enclosure B (Cyber Incident and Reportable Cyber Event Categorization). In cases where more than one category applies, the category of highest precedence is used as outlined in the appendix. The security classification of the incident is determined at this stage in accordance with DoDI O-3600.02, “Information Operations (IO) Security Classification Guidance”, or local CC/S/A/FA original classification authority approved classification guidance. Based on the incident’s category, nature, and impact, determine if the computer forensics process should be initiated.

Perform Preliminary Impact Assessment. Determine the potential damage of the reportable cyber event or incident. This preliminary impact assessment should be conducted in accordance with Appendix E, “Impact Assessment Matrix”. The initial assessment shall be performed quickly, even with limited details and analysis. As the investigation continues and a more accurate characterization of the true impact is understood, the report is reassessed and modified. To make an accurate impact assessment, the analyst performing the preliminary assessment must have access to personnel with a good understanding of the function and criticality of the IS, information network, or data in question and its role in fulfilling the CC/S/A/FA mission (or ensure that those who do have that knowledge are informed).

Begin or Continue Documentation. Begin to document the incident if documentation has not already begun. If it has been determined that computer forensics are required (e.g., LE investigation), then begin to document the chain of custody. Documentation should include:

a. All known information about the cyber event or incident.

b. All actions taken during the preliminary analysis activities and the results of that analysis.

c. A chain of custody record initiation determination made by LE/CI if forensic evidence is collected and further prosecutorial investigation may be a consideration.

Submit Initial Report. Prepare and submit the initial report to the appropriate organizations and commands and through the appropriate reporting mechanisms. Incident reporting procedures identified in Attachment B, “Cyber Incident Reporting” will be followed. Timelines for reporting are outlined in Table 7, “Reporting Timelines”. Additional guidance on reporting timeframes are provided by command authority OPORDs or other specific guidance. Incidents and reportable events shall be reported at the appropriate classification level using the appropriate means (i.e., Non-secure Internet Protocol Router Network (NIPRNET) e-mail or normal telephone for unclassified incidents and Secret Internet Protocol Router Network (SIPRNET) or secure telephone for Secret incidents). E-mails reporting an incident must be digitally signed at a minimum. Incident reporting will be conducted out of band from the involved network. Do not use assets on an information network that is (or potentially has been) compromised because an attacker may be monitoring the compromised network and could be warned of detection.

3.3 Preliminary Response Actions

Preliminary response includes the coordinated and initial action(s) taken to protect the information network or IS from any further malicious activity and to acquire the data required for further analysis. Preliminary response actions are the immediate steps taken once an incident has been detected and declared. These actions are important as they provide information to help protect the ISs and information network from more damage while more detailed analysis is completed. More detailed response steps may be taken after a more thorough analysis is performed. These will be based on the nature, scope, and potential impact of the incident. The primary objectives of preliminary response include:

1) Preventing a reportable cyber event or incident from causing further damage.

2) Maintaining control of the affected IS(s) and the surrounding environment.

3) Ensuring forensically sound acquisition of data necessary

4) Maintaining and updating the incident report and actively communicating updates through the appropriate technical and operational command channels.

3.3.1 Preliminary Response Action Methodology

The following methodology will ensure a consistent approach to preliminary response and action:

Figure 3 - Preliminary Response Actions Contain the Incident. Contain any potential threat to protect the affected IS or information network and prevent any further contamination, intrusion, or malicious activity. Containment can be done by an automated detection system or by incident handling staff working in conjunction with technical and management staff. Containment will be coordinated with the supporting CNDSP. The commander and supporting CNDSP will coordinate with LE/CI as required. Containment actions that may affect the ability to acquire and preserve data about the incident must be decided on carefully. When making these decisions, it is important to assess the relative value of ensuring mission success by preventing further damage against the potential for containment actions to hinder further analysis.

Acquire and Preserve Data. Safely acquire and preserve the integrity of all data (as directed) to allow for further incident analysis. All incidents require that as much data as possible be acquired and its integrity preserved. This includes volatile data (system registers, cache, and Random- Access Memory (RAM)), persistent data (system images, log files, and malware), and environmental data (environment, location, and configuration around the system). This data is necessary to support LE/CI investigations and to conduct incident analysis to fully understand the scope and impact of the incident. The IS will not be shut down or disconnected from the information network prior to acquiring and preserving the data (e.g., making a system image) unless authorized by the CNDSP or command authority. However, an exception to this requirement should be made if the machine begins to perform destructive tasks such as deleting files or formatting drives. In that case, the computer should be shut down quickly. Data from related systems or devices (e.g., routers, IDS/intrusion prevention system (IPS), domain controllers, and AV servers) that potentially aid in incident analysis will be acquired and preserved.

If an incident affects a large number of ISs, it may be impractical to acquire and preserve the data from each IS. An example would be an incident involving 100 user workstations containing no sensitive data that were compromised using the same delivery vector. In such cases, data must be acquired and preserved to the extent that the data provides new and/or additional information that could help in the technical analysis required to understand the nature, scope, and potential impact of the incident. Therefore, each IS may not require data acquisition and preservation (e.g., system images). However, prior to invoking this COA, the relevant CNDSP or command authority must approve that such data acquisition and preservation is not required.

Extenuating circumstances may prohibit the acquisition of data. For instance, there may be insufficient tools and/or resources. Alternatively, the acquisition may jeopardize mission-critical responsibilities or cause major operational mission degradation. In all cases, the CNDSP or command authority must approve that such data acquisition is not to be done.

Continue Documentation. Update the incident report with any actions taken during the preliminary response step and other useful information that may help to better characterize the incident. Any steps taken by first responders that potentially change the status or state of the affected IS must be documented. For example, actions such as taking the IS offline or touching any files on the IS will change the state of the information to be collected—including file access times, running processes, and memory contents. If this information is changed and not documented, it can potentially corrupt the admissibility of the forensic evidence collected in an investigation. For this reason, it is important to document any actions taken on the affected IS or service.

3.4 Incident Analysis

Cyber incident analysis is a series of analytical steps taken to find out what happened in an incident. The purpose of this analysis is to understand the technical details, root cause(s), and potential impact of the incident. This understanding will help in determining what additional information to gather, coordinating information sharing with others, and developing a COA for response. The primary objectives of this phase include:

1) Ensuring the accuracy and completeness of incident reports.

2) Characterizing and communicating the potential impact of the incident.

3) Systematically capturing the methods used in the attack and the security controls that could prevent future occurrences.

4) Researching actions that can be taken to respond to and eradicate the risk and/or threat.

5) Understanding patterns of activity to characterize the threat and direct protective and defensive strategies.

6) Identifying the root cause(s) of the incident through technical analysis.

It is important to understand the different types of incident analysis. For most incidents, the CNDSP incident handlers will conduct (or coordinate) a system analysis to gather any necessary information from or about the affected IS(s). Depending on the type of incident (or reportable event) activity, if network or malware information is also available, then the CNDSP will also conduct (or coordinate) a network analysis and/or malware analysis, as appropriate. If there is a chance the incident might meet the criteria for reporting an incident to LE/CI for the purposes of pursuing a disciplinary, criminal, or CND investigation, then computer forensics evidence collection and analysis must be performed.

3.4.1 Incident Analysis Methodology

The following methodology will ensure a consistent approach to incident analysis:

Figure 4 - Incident Analysis Methodology Gather Information. Identify and collect all relevant information about the incident for use in incident analysis. Information gathered may include data previously acquired and preserved, external logs, personal accounts, all-source intelligence, technical information, or the current operational situation. Any software artifacts suspected of being malware should be submitted to the Joint Malware Catalog (JMC).

Validate the Incident. Review, corroborate, and update (if applicable) the reported incident to ensure all information is accurate as reported. Reports should be reviewed and updated to maintain situational awareness, to add to incomplete information, or to correct erroneous information contained in the report. Report validation may require the review of trusted network and system logs or affected ISs to determine if the suspected activities happened as reported. Verify that the incident is categorized properly, in accordance with Appendix A, “Cyber Incident and Reportable Event Categorization”.

Determine Delivery Vector(s). Analyze the information to determine the delivery vector(s) used by the threat actor. The delivery vector is the primary path or method used by the adversary to cause the incident or event to occur. Delivery vectors are used to systematically record major classes of delivery vectors used by adversaries. They do not identify the system specific root cause(s) of an incident. If more than one delivery vector is identified, distinguish between the primary and secondary delivery vectors used by the threat actor. For example, use of socially engineered e-mail delivering a malicious payload exploiting a known vulnerability that was preventable. Delivery vectors should be assessed in accordance with Appendix D, “Delivery Vectors”.

Determine System Weaknesses. Analyze the information to determine any underlying system weaknesses, vulnerabilities, or security controls that could have prevented or mitigated the impact of the incident. Identification of system weaknesses is a process used to systematically record and categorize major classes of security controls that could prevent similar incidents from occurring in the future. They cannot identify the system-specific root cause(s) of an incident.

Identify Root Cause(s). Analyze the information to determine the system-specific cause(s) of the incident. Root cause identification expands upon the identified delivery vector(s) and system weaknesses by precisely identifying the sets of conditions allowing the incident to occur. For example, a delivery vector may identify an unpatched system. This is useful for correlation and trending but is insufficient in identifying the specific cause of the incident and preventing against future occurrences. Root cause identification would determine missing patches or system configurations that allowed the incident to occur. The root cause(s) of an incident should (unless not practical) be determined prior to the recovery and reconstitution of any system, unless otherwise approved by your command authority. The decision to restore a system without identifying the root cause(s) of an incident must be weighed carefully as it may leave the system vulnerable. For example, if the root cause of an incident stemmed from a missing patch in the baseline configuration, a system restoration using the same baseline configuration would leave the IS open to future compromise. A risk assumed by one is potentially a risk shared by many. Failing to identify the root cause of an incident may expose multiple commands and organizations to increased risk, especially in situations where they share similar configurations or defensive measures.

Determine Impact. Analyze the information gathered to validate and expand on the original impact assessment done during the preliminary analysis. Impact should be assessed in accordance with Appendix E, “Impact Assessment Matrix”. The impacts to be determined are as follows:

a) Technical Impact (TI). TI refers to an incident’s detrimental impact on the technical capabilities of the organization. TI typically refers to impacts on the information network or IS machines directly or indirectly affected by the incident.

b) Operational Impact (OI). OI refers to a detrimental impact on an organization’s ability to perform its mission. This may include direct and/or indirect effects that diminish or incapacitate IS or information network capabilities, the compromise and/or loss of DoD data, or the temporary or permanent loss of mission-critical applications or ISs.

Research and Develop COAs. Identify actions necessary to respond to the reportable cyber event or incident, fix the IS, and assess the risk for the IS or information network. Analysis, comparison, and selection of the best COA could be done at the lowest command possible. For instance, a commander could be the approving authority for an incident response COA for his or her base. USSTRATCOM, through USCYBERCOM, reserves the right to redirect all response actions for incidents that fall into a DoD Enterprise Incident Set. In some cases, in coordination with the Tier II CNDSP, AO (DAA), and USSTRATCOM, the commander may decide to leave the IS vulnerable and accessible in order to monitor the attacker’s activities. This may be done to assist an LE/CI investigation or for network defense and operational purposes. COA may include CND Response Actions (CND RAs) as outlined in CJCSI 3121.01, “Standing Rules of Engagement/Standing Rules for the Use of Force for U.S. Forces.” Actions that potentially affect traffic on the DoD Protected Traffic List must be coordinated with USCYBERCOM.

Coordinate with Others. Work with other appropriate parties to collect additional information, obtain assistance and additional expertise or guidance, and notify appropriate operational and technical channels regarding changes in the status of reportable events, incidents, and incident handling activities. Timely interagency coordination and de-confliction of operations are crucial to conducting an effective incident response. For additional guidance, refer to Appendix F, “Coordination and De-confliction”. Coordination ensures that the identification and de-confliction of response is vetted through all the parties that may be affected by the response.

Coordination may include the following:

1) Reporting vertically to alert higher HQ and other CND organizations.

2) Reporting horizontally to other peer organizations that have ISs that may be affected.

3) Researching and planning response strategy and COA

Perform Correlation and Trending. This involves analyzing and identifying relationships and trends between incidents in the short term and patterns across incidents in the long term. Effective and complete reporting throughout the incident handling life cycle ensures that the Department of Defense has the ability to conduct and identify these trends and patterns. Trending analysis involves understanding and accurately characterizing the relationship of incidents reported and providing awareness of the cyber security trends as observed by the affected parties. It includes analysis based on incident information that has been reported to the constituent, incidents identified by the constituent, and public/private sector information identified when correlating and analyzing the data.

3.5 Response and Recovery

Response and recovery include the detailed response steps performed to prevent further damage, restore the integrity of affected ISs, and implement follow-up strategies to prevent the incident from happening again. The primary objectives for performing response and recovery include:

1) Resolving the incident according to policy, procedures, and quality requirements.

2) Mitigating the risk or threat.

3) Restoring the integrity of the IS and returning it to an operational state.

4) Implementing proactive and reactive defensive and protective measures to prevent similar incidents from occurring in the future.

5) Completing a battlefield damage assessment (BDA) IAW Appendix E, “Impact Assessment Matrix”.

Response and recovery may require a combination of technical, management, and/or LE/CI actions. Technical actions include changes in the network and IS infrastructure to remove the risk or threat. Management steps can include administrative, human resources, public relations, or policy creation and management activities. LE/CI actions can include further investigation or criminal prosecution. Other management issues may involve legal actions to handle liability, service level agreements, or contracting issues.

3.5.1 Response and Recovery Methodology

The following methodology will ensure a consistent approach response and recovery:

Figure 5 - Response and Recovery Methodology Implement Containment. Implement (if applicable) additional containment actions to regain control of or isolate the system and prevent further malicious activity. Determine the appropriate containment strategy based on the type of incident. Examples of strategies might include modifying network access controls (e.g., firewalls), installing new AV or IDS/IPS signatures, or making physical changes to the infrastructure. Collaborate with partners since investigative or intelligence equities may need to be considered before certain containment measures are taken. See Enclosure F for a full discussion of collaboration.

Eradicate Risk. Eradicate the risk and take actions that remove the cause of the incident from the IS/network. No system should be rebuilt until system data has been adequately preserved and the vulnerability has been mitigated. ISs having a Category (CAT) 1, 2, and 7 cyber incidents must be rebuilt from trusted media and have up-to-date AV software loaded and configured IAW Security Technical Implementation Guides (STIGs) and warning and tactical directives/orders (e.g., WARNORDs, FRAGOs, TASKORDs, etc.) prior to connecting the IS to the information network. Mission impact may require patching the affected component and instituting temporary vulnerability mitigation until the mission allows the IS to be rebuilt.

Recover from Incident. Fully restore affected data and ISs to normal operation (if applicable). Harden ISs to prevent similar incidents and monitor them to ensure the IS is completely free from the original IS weakness. For some incidents, eradication is either not necessary or is performed during recovery. Preventing similar incidents may involve changing baseline configurations, tightening network perimeter security, updating AV and scanning tool signature files, rebuilding the system from trusted media, conducting user training, or implementing countermeasures that mitigate the risk.

Coordinate with Others. Work with appropriate parties to implement COAs and resolve cyber events or incidents.

Notify Others. Notify any relevant stakeholders or participants of actions they need to take. Notify involved parties (as appropriate) of the status of the incident and progress of the response. Submit updated information on the incident and the progress of the response to keep higher CND organizations and/or HQ updated on the status of the incident response. CC/S/A/FAs must ensure that program managers for centrally managed programs are notified of CAT 1, 2, 4, 5, or 7 cyber incidents impacting their programs (Appendix A to Enclosure B).

Continue Documentation. Update the incident record in JIMS with information on any response and recovery steps that were taken. Each update to the JIMS report provides a more complete understanding of the incident. Consistent and frequent updates provide a platform to broadly characterize adversarial activity and enable USCYBERCOM to direct appropriate defensive actions for all DoD information networks.

Update Response Actions and Battlefield Damage Assessment (BDA) and Close Incident. Update the incident record in JIMS that closes out the incident. Ensure all parties have completed the necessary actions for the response. The BDA documents the technical and operational impact (i.e.,OPSEC assessment) of the incident on the organization. It should be determined IAW Appendix E, “Impact Assessment Matrix”. Update the JIMS incident record with the BDA within 24 hours after the incident is resolved. Declare the incident closed, change the status in the JIMS to closed, and perform any other actions to close the incident. Incidents cannot be closed as a CAT 8—Investigating. An incident might be closed for the CC/S/A/FA or the CNDSP but still remain open for LE/CI investigation. CNDSPs are responsible for closing an incident. Incidents may be reopened by USCYBERCOM if necessary, in which case the affected CNDSP would be contacted and given direction as to what additional actions should be taken.

3.6 Post-Incident Analysis

Post-incident analysis involves a postmortem on an incident to review the effectiveness and efficiency of incident handling. Data captured in the postmortem includes lessons learned, initial root cause, problems with executing COAs, missing policies and procedures, and inadequate infrastructure defenses. Postmortem results should be used to improve the incident management process and methodology and the security posture and defenses of the CC/S/A/FAs.

One of the most important parts of incident handling is learning how to improve operations, processes, and infrastructure defenses by reviewing how an incident happened and how the response was handled. The primary objectives for post-incident analysis include:

1) Identifying infrastructure problems to address.

2) Identifying organizational policy and procedural problems to be addressed.

3) Identifying technical or operational training needs.

4) Determining unclear or undefined roles, responsibilities, interfaces, and authority.

5) Improving tools required to perform protection, detection, analysis, or response actions.

Not all incidents require a postmortem. Usually, incidents that are large in scope, handled poorly, involved LE, or caused severe damage require a postmortem. Incidents that do require a postmortem will be sent to USCYBERCOM.

4.0 INFORMATION SPILLS

Classified (or sensitive) data spills occur when classified data is introduced onto an unclassified information system, to an information system with a lower level of classification, or to a system not accredited to process data of that restrictive category. Although it is possible that no actual unauthorized disclosure occurred, classified data spills are considered and handled as a possible compromise of classified information involving information systems, networks and computer equipment until the inquiry determines whether an unauthorized disclosure did or did not occur.

The following personnel are responsible for responding to information spills:

The process for responding to information spills is contained within DODM NUMBER 5200.01, Volume 3, "DoD Information Security Program: Protection of Classified Information" and local policies. Guidance requires After Actions Report (AAR) creation to ensure that organizational personnel impacted by information spills can continue to carry out assigned tasks while contaminated systems are undergoing corrective actions.

APPENDIX A – CYBER INCIDENT AND REPORTABLE CYBER EVENT CATEGORIZATION

A Cyber Incident or Reportable Cyber Event Category is a collection of events or incidents sharing a common underlying cause for which an incident or event is reported. Each cyber event or incident is associated with one or more categories as part of the incident handling process. In cases where more than one category applies, the category assigned should be determined using the following precedence. The following table describes the category precedence for incidents.

Table 4 - Category Precedence

Investigating (Category 8) reports will include an initial assessed incident category (Categories 1-7 or 9) and be re-categorized based on continued investigation. No reports will be closed as a Category 8. The following table provides incident and reportable event categories.

privileges granted to the user. This includes unauthorized access to information or unauthorized access to account credentials that could be used to perform user functions such as accessing Web applications, Web portals, or other similar information resources. If the IS is compromised with malicious code that provides remote interactive control, it will be reported in this category.

Note the above CAT 3 explanation does not cover the “run-of-the- mill” virus that isdefeated/deleted by AV software. “Run-of-the- mill” viruses that are defeated/deleted by AV software are not reportable events or incidents and should not be annotated in JIMS.

Table 5 - Cyber Incident and Reportable Cyber Event Categories

APPENDIX B – CYBER INCIDENT REPORTING

Incident reporting comprises a well-defined framework for the timely reporting of any reportable cyber event or incident. It ensures the report provides an accurate, meaningful, and complete understanding of the incident, from initial detection through analysis to resolution and closure. This section provides guidance on the reporting requirements for reportable cyber events and incidents. There are two primary reporting structures, which are described below.

1) Technical Reporting Structure. This structure consists primarily of global USCYBERCOM (Tier I), regional/theater/CC/S/A/FAs (Tier II) CNDSPs, and local (Tier III) organizations and describes the interactions between each of the tier levels and how reporting, notification, and communications shall occur.

2) Additional Reporting Structures. This group includes other reporting structures that may be required in support of the IC, LE/CI, and operational and any other external organizations as appropriate.

The following table summarizes reporting vehicles available in order of preference. Other mechanisms should only be used when the JIMS cannot be accessed or when circumstances require the use of other reporting channels. Regardless of how initial reporting is done, information regarding the report must be added to the JIMS:

Data

Fax/Voice

Table 6 - Incident Report Vehicles Technical Reporting is designed to assist with the handling of incidents and provide fixes to mitigate the operational and/or technical impact of an incident.

Tier I Reporting. Tier I receives reports from Tier II and external entities. It is positioned for centralized coordination and control in a way that allows it to broadly characterize attacks occurring across the Department of Defense. This vantage point allows it to provide tactical and strategic direction to subordinate levels and determine defensive and/or protective strategies that help improve the overall security posture of the DoD Information Networks. Tier I includes USCYBERCOM and supporting entities Tier II Reporting. Tier II receives reports from the subordinate levels (Tier III). This information can also be shared (if applicable) with other Tier II entities to provide insight into activity that can potentially affect its region or theater of operations. Tier II organizations report incidents to USCYBERCOM. All incident reports should be submitted through the JIMS unless prevented by extenuating circumstances (e.g., no access to JIMS). All organizations must report through their CNDSP. The CNDSP enters the report into the JIMS. Lateral reporting may be required by their operational or administrative chain of command.

Tier III Reporting. Tier III initiates local operational reporting and receives support…