Download 3 Responding to Incidents

ARTIFACT 2
STRAGEGIC SITUATIONAL AWARENESS (SSAW)
INCIDENT RESPONSE PLAN
Version 1.0
April 2013
Include the month and year only on the cover page when completing this Artifact.
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
TABLE OF CONTENTS
1
INTRODUCTION..............................................................................................................1
1.1 Scope ....................................................................................................................................1
1.2 Purpose.................................................................................................................................1
1.3 Applicable Provisions and Directives ..................................................................................1
1.4 Computer Incident Response Program ................................................................................2
1.5 Definitions............................................................................................................................2
1.5.1
Event ............................................................................................................................2
1.5.2
Incident ........................................................................................................................2
1.6 Types of Incidents ................................................................................................................2
2
1.6.1
Malicious Code Attacks ...............................................................................................2
1.6.2
Unauthorized Access ...................................................................................................3
1.6.3
Unauthorized Utilization of Resources ........................................................................3
1.6.4
Disruption of Denial of Services..................................................................................3
1.6.5
Misuse ..........................................................................................................................3
1.6.6
Espionage .....................................................................................................................3
1.6.7
Hoaxes..........................................................................................................................3
ROLES, RESPONSIBILITIES, AND REPORTING REQUIREMENTS...................4
2.1 Introduction ..........................................................................................................................4
2.2 Information System Name Personnel ..................................................................................4
2.2.1
User/Operator ...............................................................................................................4
2.2.2
Information Assurance Officer ....................................................................................4
2.2.3
Information Assurance Manager..................................................................................4
2.2.4
Information System Name Director/Program Manager ...............................................4
2.2.5
Information System Name Computer Incident Response Team..................................5
2.3 Department of Defense Computer Emergency Response Team ..........................................6
3
RESPONDING TO INCIDENTS .....................................................................................7
3.1 Response Procedures ...........................................................................................................7
3.1.1
Preparation for Incident Response ...............................................................................7
3.1.1.1
Warning Banners .....................................................................................................7
3.1.1.2
Audit Data ................................................................................................................8
i
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
3.1.2
Identification for Incident Response ............................................................................8
3.1.3
Containment of Incidents .............................................................................................9
3.1.4
Eradication of Incidents .............................................................................................10
3.1.5
Recovery of Systems..................................................................................................10
3.1.6
Follow-up to an Incident ............................................................................................10
3.2 Government Information System Response Procedures ...................................................11
3.2.1
Identification for Incident Response ..........................................................................11
3.2.2
Containment of Incidents ...........................................................................................11
3.2.3
Reporting of Incidents................................................................................................11
3.2.4
Analysis of Incidents..................................................................................................11
3.2.5
Determination of Incident ..........................................................................................12
3.2.6
Coordination for Incident ...........................................................................................12
3.2.6.1
Notification by the Joint Task Force Global Network Operations ........................12
3.2.6.2
Involvement for Critical Incidents .........................................................................12
3.2.7
Eradication of Incident ...............................................................................................12
3.2.8
Follow-up to an Incident ............................................................................................12
3.2.9
Recover from Incident ...............................................................................................12
3.2.10
Vulnerability Assessment Activity ........................................................................13
3.3 Malicious Code Attacks and Appropriate Response .........................................................13
3.3.1
Computer Viruses ......................................................................................................13
3.3.1.1
Description .............................................................................................................13
3.3.1.2
Actions ...................................................................................................................14
3.3.2
Worms ........................................................................................................................14
3.3.2.1
Description .............................................................................................................14
3.3.2.2
Actions ...................................................................................................................14
3.3.3
Trojan Horses .............................................................................................................14
3.3.3.1
Description .............................................................................................................14
3.3.3.2
Actions ...................................................................................................................15
3.3.4
Cracking Utilities .......................................................................................................15
3.4 Cracker/Hacker Attacks and Appropriate Responses ........................................................15
3.4.1
Description .................................................................................................................15
ii
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
3.4.2
Actions .......................................................................................................................15
3.5 Technical Vulnerabilities ...................................................................................................16
3.6 Legal Procedures ................................................................................................................16
3.6.1
Evidence .....................................................................................................................16
4
REPORTING TIMELINE ..............................................................................................17
5
INFORMATION SYSTEM SECURITY INCIDENT FORMS ..................................18
6
VIRUS REPORT .............................................................................................................23
7
CRACKER/HACKER REPORT ...................................................................................24
8
VULNERABILITY REPORT ........................................................................................25
9
INCIDENT RESPONSE CHAIN OF NOTIFICATION CONTACT
INFORMATION ..........................................................................................................................27
APPENDIX A
SSAW LIST ..................................................................................................31
List of Tables
Table 4-1: Reporting Timelines ....................................................................................................17
Table 5-1: Information Assurance Computer Incident Reporting Form ......................................22
Table 5-2: Incident Category Definitions .....................................................................................22
iii
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
1 INTRODUCTION
1.1
Scope
This document applies to Strategic Situational Awareness (SSAW) system activities processing
Department of Defense (DoD) information and information protected under the Privacy Act of
1974.
The guidelines contained herein include fundamental information about responding to security
incidents. They are to be used independent of particular hardware platforms or operating
systems. As such, this document does not contain technically detailed information. Instead, it
provides a practical source of guidance and incident response.
1.2
Purpose
The purpose of the Incident Response Plan is to protect the information system (IS), data, and
personnel, taking into consideration costs and other practical constraints. A systematic approach
uses resources more efficiently, in terms of both personnel and time.
1.3
Applicable Provisions and Directives
NOTE: The reference, Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01A,
highlighted in GREEN, is applicable to the Government IS only and can be deleted for the
AFMS Contractor IS Incident Response Plan.
STANDARD REFERENCES:







Office of Management and Budget (OMB) Memorandum M-06-19, “Reporting Incidents
Involving Personally Identifiable Information and Incorporating the Cost for Security in
Agency Information Technology Investments.” 12 July 2006.
OMB Memorandum M-07-16, “Safeguarding Against and Responding to the Breach of
Personally Identifiable Information.” 22 May 2007.
“Privacy Act of 1974.” 5 (U.S. Code) U.S.C. § 552a, Public Law No. 93-579.
“Health Insurance Portability and Accountability Act (HIPAA)” 1996.
Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01A, “Information
Assurance (IA) and Computer Network Defense (CND).” Volume I (Incident Handling
Program). 24 June 2009.
DoD Directive 8500.01E, “Information Assurance (IA).” 24 October 2002. Certified
current as of 23 April 2007.
DoD Instruction 8500.2, “Information Assurance (IA) Implementation.” 6 February
2003.
1
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
1.4
Computer Incident Response Program
The IS’s Computer Incident Response Program includes processes and procedures to ensure:







1.5
Quick and efficient recovery through proven response measures
Minimal loss or theft of information or disruption of critical computing services
Systematic response by outlining the recommended response times
Protection of IS and data through quick detection and recovery
Protection of personnel through sound incident response practices
Efficient use of resources through quick resolution of incidents
Coordinated annual exercise of the Incident Response Plan
Definitions
1.5.1 Event
An "event" is any observable occurrence, not yet assessed, that may affect the performance of an
IS. Examples of events include the system boot sequence, a system crash, and packet flooding
within a network. Events sometimes indicate that an incident is occurring.
1.5.2 Incident
“Incident” refers to an adverse event in an IS, or the threat of such an event’s occurrence.
Examples of incidents include the unauthorized use of another user's account or system
privileges, and the execution of malicious code that destroys data.
Other adverse events that cause system crashes include natural disasters and power-related
disruptions (e.g., floods, fires, electrical outages, and excessive heat). For the purpose of this
program, the term "incident" refers to an intentional and/or unintentional adverse event that is
related to IS security.
1.6
Types of Incidents
1.6.1 Malicious Code Attacks
Malicious code attacks include attacks by programs such as viruses, Trojan horse programs,
worms, and scripts used by crackers/hackers to gain privileges, capture passwords, and/or
modify audit logs to exclude unauthorized activity. Malicious code is particularly troublesome
because it is typically written to conceal its presence, making it difficult to detect. Also, selfreplicating malicious code can replicate rapidly, thereby making containment an especially
difficult problem.
2
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
1.6.2 Unauthorized Access
Unauthorized access encompasses a range of incidents, from improperly logging onto a user's
account (e.g., when a hacker logs on to a legitimate user's account) to obtaining elevated
privileges for unauthorized access to data. Unauthorized access could also entail access to
network data obtained by planting an unauthorized "sniffer" program or devices to capture all
packets traversing the network.
1.6.3 Unauthorized Utilization of Resources
It is not always necessary to access another user's account in order to attack an IS. An intruder
can access information or plant Trojan horse programs simply by misusing available services or
via social engineering.
1.6.4 Disruption of Denial of Services
Perpetrators and malicious code can disrupt or deny network and computing services in many
ways, including erasing a critical program, "mail spamming" (flooding a user account with
electronic mail), and modifying system functionality by installing a Trojan horse program.
1.6.5 Misuse
Misuse occurs when someone uses a computing system for other than authorized purposes.
1.6.6 Espionage
Espionage is the stealing of information to subvert the interests of a corporation or government.
1.6.7 Hoaxes
Hoaxes are the proliferation of false information about incidents or vulnerabilities.
3
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
2 ROLES, RESPONSIBILITIES, AND REPORTING REQUIREMENTS
2.1
Introduction
This section describes the roles and responsibilities of different individuals within the IS security
organizational hierarchy. Each individual, from end users to the Information Assurance Manager
(IAM), has responsibilities related to the security of the IS. It is important therefore that all
personnel understand their roles and responsibilities in relation to computer incidents affecting
the organization. The following is a list of personnel who will be notified (i.e., the reporting
chain) in the event of a suspected or actual IS incident:
Upon receipt of confirmation of an incident, the Computer Incident Response Team (CIRT) must
be activated.
2.2 SSAW Personnel
2.2.1 User/Operator
If a computer security incident is detected, it should be reported immediately to the Information
Assurance Officer (IAO). Any end user noticing anomalous or suspicious activity (incident or
reportable event) must report the situation immediately to their network helpdesk. The helpdesk
will report the activity to the respective IAO.
2.2.2 Information Assurance Officer
The IAO is responsible for all security matters related to the IS.
The IAO has the responsibility to report incident information in a timely fashion. In addition, the
IAO is prepared to advise the IAM on immediate response decisions in the event of a serious
breach of security or the compromising of Protected Health Information (PHI), Personally
Identifiable Information (PII), or sensitive information (SI), as in the case of an attacker gaining
access via the Internet.
It is also the IAO’s responsibility to coordinate incoming information, advise users on handling
security incidents, and disseminate information to the IAM and end users, as appropriate.
2.2.3 Information Assurance Manager
The IAM has the responsibility to report incident information in a timely fashion. In addition,
the IAM receives the information, coordinates a response with the assistance of the IAO and
passes it to the Director of the SSAW IS. If criminal activity is suspected or is immediately
evident, the IAM will cooperate with external authorities.
2.2.4 Strategic Situational Awareness Director/Program Manager
The Director/Program Manager (PM) will begin the notification process once a security incident
has been identified. Any event with the potential to adversely affect an IS through unauthorized
access, destruction, disclosure, modification of data, and/or denial of service is a threat. Such
events are considered computer security incidents.
Choose the appropriate scenario:
For AFMS Contractors IS only
4
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
Incidents that occur with SSAW IS, the Director must notify the AFMS Privacy Office Director
via telephone. Immediately afterwards, the IS Director will follow up with an e-mail to the
AFMS Privacy Office, and complete the AFMS Information Assurance Computer Incident
Reporting Form found in Section 5, Information System Security Incident Forms.
For Government IS only
Incidents that occur with the SSAW IS the Director/PM of the IS must notify the Office of the
Chief Information Officer (OCIO)/Information Assurance (IA) Director and the AFMS Privacy
Office Director within an hour of the potential or confirmed breach via telephone. Immediately
afterwards, the Director/PM will follow up with an e-mail to the OCIO/IA and AFMS Privacy
Office, and complete the Information Assurance Computer Incident Reporting Form found in
Section 5, Table 5-1, Information Assurance Computer Incident Reporting Form.
Technical support for an active attack will be directed to the DoD Computer Emergency
Response Team (CERT), by the SSAW Program Office (PO).
2.2.5 Strategic Situational Awareness Computer Incident Response Team
In the event of an incident, the affected SSAW IS CIRT will notify the responsible PO/Data
Owners. Additionally, Government sites will also need to notify DoD CERT and affected
service CIRT.
In order to support incident response, the following steps are incorporated into this plan:













Review their overall security policies to ensure that incident response is properly
addressed
Upon receipt of confirmation of the computer incident from the IAM, SSAW
management will activate the CIRT
Have a plan of action in place, in the event of an incident
Maintain audits of security-related events and audit log protection
Report security incidents
Back-up audit data
Secure backups
Ensure appropriate markings
Encrypt backups when passwords may be compromised, if the media is lost
Never configure systems to overwrite audit or security logs
Force security logs to be manually cleared and require administrative intervention
Assign a technically-competent individual to review audit data for potential security
violations
Ensure a reporting cycle for security related events-specify who is notified and how they
are notified
After the event, it may be necessary to provide evidence of the intrusion for legal action. This
procedure should also be addressed. This phase would require an individual(s) with sufficient
knowledge to reconstruct the intrusion and explain its significance in terms of the risk or damage
that has occurred. This is where computer forensics is initiated.
5
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
2.3
Department of Defense Computer Emergency Response Team
The DoD CERT is a component of the Joint Task Force on Global Network Operations (JTFGNO). The DoD CERT provides IA Incident Response Support to the Defense Information
Infrastructure Community Support of IA.
On the DoD CERT Website, users can report an incident, review technical tips and best
practices, and download the latest Information Assurance Vulnerability Management (IAVM)
notifications. Details regarding the DoD CERT can be found at the DoD CERT Website, located
at https://www.cert.mil.
6
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
3 RESPONDING TO INCIDENTS
This section and related subsections should go into detail on the internal processes that are in
place and implemented in response to an information system (IS) incident.
3.1 Response Procedures
3.1.1 Preparation for Incident Response
One of the most critical facets of responding to incidents is preparation before an incident occurs.
Preparation limits the potential for damage by ensuring that response actions are known and
coordinated. Preparatory actions to be taken include the following:

The IAO is registered to receive IAVM notifications.
 Document the IS baseline of protection with the required security controls. This will
allow the security professional to easily identify unauthorized modifications to the IS if
an incident should occur.
 Create written incident response procedures and make them widely available. They are
widely distributed in case key personnel are absent. This ensures that a critical
complement of personnel with the necessary knowledge will be available if and when an
incident occurs.
 Plan communications needs. Prepare and distribute contact lists with work, cell, and
home phone numbers and other contact information of personnel to be notified during
incidents. Inform users whom they should contact in case of an incident. Also, it is
recommended that all key personnel have pagers/cell phones in case they are needed
immediately.
 First, determine what is done with critical information and/or computing services.
Determine whether SI should be left on the IS, or copied to media and taken off-line.
Alternatively, critical computing services can be moved to a system on another network
that has less chance of interruption.
 Establish and employ standard backup, shutdown, and recovery procedures to ensure
operational continuity. This practice enables personnel to check the integrity of the
systems and data to verify whether unauthorized changes have occurred by comparing
files to the corresponding backup. Also, to ensure a standard method of backing up,
shutting down, and recovery procedures to allow a systematic process in the event an
incident occurs.
 Provide training to personnel. Personnel receive training on responding to incidents and
also are required to participate in periodic simulated incidents in which written incident
response procedures are followed.
 Obtain and implement incident response support tools. Examples include: virus detection
and eradication tools, tools to restore mainframes and workstations, and incident
detection tools.
3.1.1.1 Warning Banners
Every screen displayable device should show a warning banner visible to all users who attempt to
login to the system. The warning banner should advise users that: The system is for official use
only and any unauthorized use may result in criminal prosecution. Remove any login banners
7
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
that welcome users to a system, as perpetrators may argue in a court of law that they were not
warned about unauthorized usage, but were instead encouraged to use a system that welcomed
them.
Also include a statement in the login banner to the effect that use of a system constitutes
voluntary consent to have one's computing-related activity monitored. The login banner needs to
be consistent with AFMS Guidance and include the Privacy Act of 1974. The content and
verbiage of the warning banner must have the approval of the SSAW’s legal department prior to
the banner’s being displayed and used on the system.
3.1.1.2 Audit Data
A similar legal issue concerns monitoring of systems and networks. Reading audit logs is not
considered an invasion of privacy. Using monitoring tools that determine what type of packet
was sent, its source and destination, etc. is an acceptable audit mechanism.
The United States (U.S.) Department of Justice (DoJ) advises, however, that capturing packets
that are transmitted over networks, then reading those packets verbatim, constitutes a possible
violation of the Electronic Privacy Act. One should not, therefore, use sniffer devices or sniffer
programs to monitor the content of messages transmitted over networks, nor should one use an
intrusion detection tool that does the same.
3.1.2 Identification for Incident Response
Identification is determining whether or not an incident has occurred, and if so, the nature of the
incident. System and network audit logs can also provide information on unauthorized activity.
It normally begins after someone has noticed an anomaly in the IS. Determining whether or not
that anomaly is symptomatic of an incident is often difficult because apparent evidence of
security incidents often turns out to indicate something else – e.g., errors in system configuration
or an application program, hardware failures, or, most commonly, user errors.
Although no symptom of a security incident is conclusive by itself, observing one or more of
these symptoms should prompt an investigation by the appropriate technical and computer
security personnel.
Typical indications of security incidents include, but are not limited to, any or all of the
following:










Any intrusion into a network with a perceived unauthorized result
Any loss or suspected loss of PHI, PII, or DoD information
Any unauthorized access or suspected unauthorized access to PHI, PII, or DoD
information
Suspicious entries in IS accounting
Accounting discrepancies
Unsuccessful login attempts
Unexplained new user accounts
Unexplained new files or unfamiliar file names
Unexplained modifications to file lengths or dates, especially in system executable files
Unexplained attempts to write to system files or changes in system files
8
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013












Unexplained modification or deletion of data
Any indications of Denial of Service or Distributed Denial of Service attacks
System crashes
Poor system performance
Unauthorized operation of a program or sniffer device to capture network traffic
“Door knob rattling” (e.g., use of attack scanners, remote requests for information about
systems and/or users, or social engineering attempts)
Unusual time of usage (note: more security incidents occur during non-working hours
than any other time)
An indicated last time of usage of a user account that does not correspond to the actual
last time of usage for that user
Any incident involving a Web server
Any unauthorized privileged user, administrator, or root level access of a DoD IS/AFMS
Contractor
Any new virus or worm for which no published countermeasure exists, any new virus
whose propagation could likely outrun containment capabilities, or any new virus that
affects network services (e.g., e-mail and domain name system services)
Any root level access on a system using new methods that exploit significant
vulnerabilities shared by DoD IS and AFMS Contractors connected to a DoD IS
It is extremely important to immediately obtain a full image of the system, once suspicious
events have been observed. Perpetrators of computer crimes are becoming increasingly
proficient at destroying evidence of their illegal activity. Unless it is immediately captured,
evidence may be destroyed before it can be evaluated. The image will also provide a basis for
comparison later on, in case any additional unauthorized activity is observed. Be sure to safely
store all evidence using chain of custody procedures to prevent loss or theft.
Record the nature of suspicious events observed in a logbook. Identify the system, time and
other details, even if they may not appear to be relevant at the time. Also record the names of
those with whom the incident or possible incident was discussed. Careful recording of these
details can assist in identifying the nature of an incident, developing effective solutions, and
prosecuting those who are responsible. Also, the logbook is safely stored.
In the event the incident involves PII, it must be reported to the United States Computer
Emergency Readiness Team (U.S. CERT) within 1 hour and the AFMS Privacy Office Director
within 24 hours. To report the incident involving PII, use http://www.us-cert.gov/.
3.1.3 Containment of Incidents
Containment aims to limit the magnitude and damage of an incident. Determine if the system
should be: shut down entirely; disconnected from the network; or allowed to continue to run in
its normal operational status to monitor the activity. The answer depends on the type and
magnitude of the incident. In the case of a simple virus incident, it is almost certainly best to
quickly eradicate any viruses without shutting down the infected system.
If SI and critical programs may be at risk, it is generally best to shut down the system, or at least
temporarily disconnect it from the network. It may be advisable to let a system continue to run
9
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
normally, risking some damage, disruption or compromise of data, if there is a reasonable chance
that a perpetrator can be identified. Continue to follow proper reporting procedures during this
phase, by keeping others informed of the status of the effort(s).
3.1.4 Eradication of Incidents
Eradication entails the removal of the cause of the incident. In the case of a virus incident, it
simply requires removing the virus from all systems and media, usually through virus eradication
software. Full eradication of intrusions should, however, include legal action against the
perpetrator, when possible.
3.1.5 Recovery of Systems
Recovery means restoring a system to its normal mission status. Some incident recoveries
require only the assurance that the incident did not in any way affect the system software or the
data. Other incident recoveries may require a complete restore of operation from backups, after
determining the integrity of the backup itself. Once the restore procedures have been performed,
verify that it was successful and that the system is back to its normal condition.
3.1.6 Follow-up to an Incident
Follow-up activity is one of the most critical activities in incident response. It helps
organizations improve their incident handling procedures and to incorporate lessons learned into
their standardized operating procedures.
Analyze what has occurred and what was done to intervene. For instance, ask the following
questions:







Was preparation sufficient?
Did detection occur promptly or, if not, why not?
Could additional tools have helped the detection and eradication process?
Was the incident sufficiently contained?
Was communication adequate, or could it have been better?
What practical difficulties were encountered?
What processes and procedures need to be improved and how?
Work with all stakeholders to validate or update the amount of man-hours required to respond to
the incident, including the time necessary to restore the systems.
Identify a financial cost associated with the incident, to ensure the availability of required
funding.
Be prepared to answer the following questions:





What was the associated monetary cost and was it higher than projections?
How much did the incident disrupt ongoing operations and what can be done to lessen the
impact in the future?
Was any data irrecoverably lost, and, if so, what was the value of the data?
If so, how can we prevent the loss of data in the future?
Was any hardware/software damaged or replaced?
10
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
Reporting formats, included in Sections 5 through 9 of this document, depend on the type of
incident. Answer the questions above and include a "lessons learned" section in the report. The
report will be disseminated to stakeholders to ensure the distribution of “lessons learned”
throughout the enterprise.
"Lessons learned" contained in the report will be used as the basis for modifying incident
response policies and procedures.
3.2
Government Information System Response Procedures
The following IS security incident response procedures are provided as baseline requirements for
incident management by Government ISs/Program Offices.
3.2.1 Identification for Incident Response
If a system user or administrator discovers suspicious activity, he or she must report it to the
network helpdesk. Network administrators will notify their Network Operations Director (NOD)
and Director, OCIO/IA. The Director, OCIO/IA and the NOD will assess the event and label it
as either a reportable event or confirmed incident:


A reportable event is any occurrence, not yet assessed, that may affect the performance of an
information system
A confirmed incident is any information system-assessed occurrence resulting in actual or
potentially adverse effects on an information system
The Director, OCIO/IA and the NOD will assign reportable events or confirmed incidents to one
of the categories (re-categorize, if applicable) listed in Table 5-2, Incident Category Definitions.
The Director, OCIO/IA and NOD will document the potential incident and all actions taken for
resolution of the incident.
3.2.2 Containment of Incidents
The NOD, in consultation with the Director, OCIO/IA and Computer Network Defense Service
Provider (CNDSP), will take all necessary mitigating actions to contain the incident.
3.2.3 Reporting of Incidents
The NOD will submit an initial report to the CNDSP and JTF-GNO. Reporting timelines will
vary according to activity category and system Mission Assurance Category (MAC), Section 4,
Reporting Timeline. In the event the incident involves PII, it must be reported to the U.S. CERT
within 1 hour, the AFMS Privacy Office Director and CNDSP within 24 hours, and the Defense
Senior Privacy Official within 24 hours.
The Director, OCIO/IA and the NOD will brief the AFMS Chief Information Officer (CIO) on
the incident.
The NOD will submit final reports (including impact assessments) within 24 hours of the
incident’s resolution.
3.2.4 Analysis of Incidents
The NOD will collect all data about the incident including the following:


Logs
Personal accounts
11
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013

Inventory of the systems
The NOD will validate circumstances surrounding the incident by confirming the following data
points:



3.2.5
Type
Intrusion method used
Vulnerabilities
Determination of Incident
The NOD, CNDSP, and the Director, OCIO/IA will determine both the operational impact and
technical impact of the incident.
3.2.6 Coordination for Incident
The Director, OCIO/IA will coordinate with other agencies and components as necessary.
3.2.6.1 Notification by the Joint Task Force Global Network Operations
In the event the JTF-GNO determines a critical incident poses a near term threat to the integrity
of Global Information Grid (GIG), a Network Defense Tasking Message (NDTM) will be issued.
The NDTM will task the CNDSP for incident handling execution in accordance with Chairman
of the Joint Chiefs of Staff Manual (CJCSM) 6510.01.
3.2.6.2 Involvement for Critical Incidents
The Flag/General Officer will be involved for critical incidents. 24 hours after the release of an
NDTM, if JTF-GNO determines the incident response, analysis, and reporting processes do not
demonstrate sufficient progress, resolution, or command level involvement, the issue will be
elevated to the JTF-GNO Deputy Commander (07-Level) for escalation to the AFMS CIO.
48 hours after the release of an NDTM, if JTF-GNO determines the incident response, analysis,
and reporting processes still do not demonstrate sufficient progress, resolution, or command level
involvement, the issue will be elevated to the JTF-GNO Commander (09-Level) for escalation to
the AFMS Privacy Office Director.
3.2.7 Eradication of Incident
The Network Operations Manager, in consultation with the CNDSP, will develop Courses of
Action.
3.2.8 Follow-up to an Incident
The NOD will submit updated information on the incident to the CNDSP. Absent direction to
the contrary, submitted reports are due within 8 hours of new data. The NOD will submit final
reports (including impact assessments) within 24 hours of the incident’s resolution.
3.2.9 Recover from Incident
The NOD, in consultation with the CNDSP, will fully restore data and systems and execute the
necessary changes to network configuration.
12
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
3.2.10 Vulnerability Assessment Activity
Following a systemic event or as a precursor to accreditation, information owners may request a
baseline review, known as a Vulnerability Assessment Activity (VAA), of its enclaves and
network systems. Requests for such resources must follow a specific chain of authority.
a. The DAA will notify the AFMS Privacy Office Director regarding the need for a
baseline review.
b. The AFMS Privacy Office Director must formally request that the CNDSP begin a
VAA.
The VAA reviews will follow three phases:
3.3

Phase I – A Vulnerability Assessment Team (VAT) will examine ISs, networks,
workstations, and IA policies to determine the adequacy of existing security measures
and identify security deficiencies.

Phase II – Once the VAT has identified vulnerabilities, the “Blue Team” will provide
guidance on areas of concern. The team will function as a “friendly assist” to
expeditiously remedy deficiencies and enhance policy and procedures.

Phase III – After the VAT and Blue Team (a team of knowledgeable personnel normally
form by Defense Information Systems Agency (DISA) to assist in vulnerability
mitigation) have addressed all deficiencies, the “Red Team” (A team of personnel
knowledgeable in adversaries' and offensive attacks) attacks the AFMS Information
Technology (IT) information infrastructure and attempts to discover additional
weaknesses and vulnerabilities. These teams will work closely with system/network
owners to demonstrate how future attacks might occur. Team leaders also will submit to
system/network owner’s recommendations for protecting their systems.
Malicious Code Attacks and Appropriate Response
Respond to malicious code attacks using the incident response procedures outlined in Section
3.1, Response Procedures. Keep in mind that there are also numerous special considerations for
dealing with malicious code: A virus report outline is enclosed as Section 6, Virus Report.
3.3.1 Computer Viruses
3.3.1.1 Description
STANDARD LANGUAGE (DO NOT MODIFY): A computer virus is a self-replicating code
that operates and spreads by modifying executable files, and is usually user-initiated. Therefore,
all users must receive training on how to detect viruses and on procedures for limiting virus
propagation.
Macro viruses are a type of virus that uses an application's own macro programming language to
convert documents into templates and rapidly distribute themselves. These viruses reside on an
application that typically uses macros, such as word processing software applications and
spreadsheets. Macro viruses are the most common and rapidly growing type of virus. Macro
viruses can also "auto-execute" when an infected e-mail attachment is opened, and can infect
files on the recipient's hard drive or file server. Since word processing and spreadsheet files are
13
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
commonly shared as attached files via e-mail and the Internet, macro viruses circulate very
rapidly and can re-infect an installation overnight.
3.3.1.2 Actions
STANDARD LANGUAGE (DO NOT MODIFY): Obtain the anti-virus tools needed and start
using them as soon as possible. Effective virus detection and eradication tools are available from
the DoD CERT. A simple (but not always effective) way to detect viruses is to look for
unexplained increases in the length of executable files. Since viruses work by modifying
applications and system executables, a growth in the length of these files typically indicates the
presence of a virus. Remember that saboteurs and malicious code can modify any program to
which they have write access; therefore, security professional should ensure the integrity of any
anti-virus tool. A good technique is to keep at least one known good copy of anti-virus software
on a write-protected CD or other removable magnetic media.
Immediately discontinue use of any computer that is infected by a virus. Leave the infected
computer on, and call for technical support. Leave a sign on the computer screen to warn others not
to use the computer. Do not attempt to eradicate the virus and restore the system without the
assistance of a qualified security professional. Make a copy of any virus that has infected a
computer before it is eradicated, so that the IS CIRT and/or DoD CERT can analyze the virus.
Also, be sure that the virus is eradicated from all backup disks. Failure to clean backup disks is a
major cause of re-infection.
3.3.2 Worms
3.3.2.1 Description
STANDARD LANGUAGE (DO NOT MODIFY): Worms are usually user-initiated and
generally propagate themselves over networks and spread rapidly. They are detectable through
system processes. Look for an unfamiliar process (usually with an unusual name) that is running
and consuming a large proportion of a system's processing capacity. Worms may indicate their
presence by writing unusual messages to a user’s display. Messages from unknown users that
ask one to copy an e-mail message to a file may also propagate worms.
3.3.2.2 Actions
STANDARD LANGUAGE (DO NOT MODIFY): If a worm is noticed, inform the IAO,
system administrator or security professionals immediately. Saving a copy of any worm code
found on a system can considerably accelerate efforts to analyze and deal with the worm.
Prompt termination of any rogue processes created by the worm code, minimizes the potential
for damage.
3.3.3 Trojan Horses
3.3.3.1 Description
STANDARD LANGUAGE (DO NOT MODIFY): Trojan horse programs are hidden
programs. They are often designed to trick users into copying and executing them. To avoid
Trojan horse programs, one must use discretion when using any new software. Be especially
suspicious of electronic bulletin board services, some of which may contain Trojan horse
programs. If there is any doubt about the authenticity or functionality of a software program,
14
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
have a technical support specialist analyze it to determine whether or not the program contains
any Trojan horse code.
3.3.3.2 Actions
STANDARD LANGUAGE (DO NOT MODIFY): The best way to avoid Trojan horse
programs is to be discriminating about using any new software. If it is discovered that a Trojan
horse program has damaged or otherwise infected a system, leave the system alone and contact
the system administrator or security professional. Also, leave a sign on the system warning
others not to use it. Save a copy of the Trojan horse program on a specially marked CD used
only for this purpose, and give it to IS CIRT before the program is deleted from the system.
3.3.4 Cracking Utilities
STANDARD LANGUAGE (DO NOT MODIFY): Cracking utilities are programs planted in
systems by attackers for a variety of purposes such as elevating privileges, obtaining passwords,
disguising the attacker’s presence, and others. See Section 3.3.2, Worms, for protective
measures.
3.4 Cracker/Hacker Attacks and Appropriate Responses
3.4.1 Description
STANDARD LANGUAGE (DO NOT MODIFY): Crackers and hackers are unauthorized
users who attempt to obtain unauthorized access to IS. Modem dial-in is a favorite way to crack
systems. Crackers/hackers may sit at a terminal, enter commands, wait to see what happens, and
then enter more commands; however, most cracking attacks are automated and take only a few
seconds. This makes identifying and responding to the intrusion more difficult.
Symptoms of a compromise by a cracker/hacker include the following:

Changes to directories and files
 A displayed last time of login that is not the actual time of last login
 Discover that someone else is logged into an individual's account from another computer,
when an authorized user is unable to log in to their account (often because someone has
changed the password)
3.4.2 Actions
STANDARD LANGUAGE (DO NOT MODIFY): To protect against a cracker/hacker attack,
users should always use a good and strong (difficult-to-guess) password and set file access
permissions conservatively (e.g., to prevent unauthorized access to the home directory). System
administrators should install tools such as password filters that prevent users from adopting easyto-guess passwords and tools that check file integrity. The password generator tool provides a
‘one time use’ password and prevents this password from being used successfully more than
once.
Defense-in-depth is the best “defense” against attacks with on going monitoring of the IS with hostand network-based intrusion detection systems (IDSs), implementation of IAVAs and patches, as
well as audit log reviews. Additional defenses include: firewall/Access Control Lists (ACLs), ongoing training, and the use of two-factor authentication. Crackers generally use cracking utilities as
a means to obtain unauthorized access to systems. Cracking utilities usually are different from
conventional malicious code attacks, in that most cracking utilities do not disrupt systems or destroy
15
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
code. They are typically "a means to an end," obtaining elevated access, modifying audit logs, etc.
Checksum or crypto-checksum tools are effective in spotting changes in files and are, therefore,
effective in detecting cracking utilities.
To use these tools, one needs to compute a checksum or crypto-checksum baseline, and then
compare the result to the currently obtained result. If there is a difference with no readily available
explanation, the integrity of the examined file may have been compromised. However, saboteurs
can modify a program to which they have access, therefore, be sure to store the checksum/cryptochecksum programs offline and securely (e.g., on a write-locked disk, stored in a safe) when not in
use/running.
See the Cracker/Hacker Report outline within Section 7, Cracker/Hacker Report.
3.5
Technical Vulnerabilities
Most of the currently known technical vulnerabilities in applications and operating systems have
been discovered by users, often as they attempted to run a program or change a configuration. If
a technical vulnerability is discovered, immediately document that vulnerability and include the
following information:




What is the vulnerability?
How can the vulnerability defeat security mechanisms?
How can the vulnerability be exploited (including special conditions under which the
vulnerability occurs)?
How can we fix/mitigate the vulnerability?
After documenting the vulnerability, using the Vulnerability Report outline, found in Section 8,
Vulnerability Report, have another technical support specialist verify that the vulnerability
exists. Attempt to fix (after going through the proper configuration management plan) or
mitigate with Defense-in-Depth strategies and documenting in the Mitigation Strategy Report.
3.6
Legal Procedures
This section is not intended to provide detailed legal guidance. Legal precedent dictates,
however, that one should adhere to the following procedures to avoid compromising the eventual
prosecution of perpetrators of computer crimes.
3.6.1 Evidence
Anything related to an incident or possible incident is potentially a piece of evidence. As such,
notes, audit logs and backups, copies of malicious code, and so forth are critical. Soon after
(e.g., daily, if following an incident) new information is recorded in the logbook, take it to
someone who is responsible for handling such evidence. This person should copy each new page
of the logbook, store the copy in a locked container, and provide a signed and dated receipt.
Audit logs and other physical entities are handled in a similar manner. If these procedures are
not followed, trial attorneys for the perpetrator may be able to successfully argue that the
evidence was fabricated.
16
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
4 REPORTING TIMELINE
Category and Title
Impact
Initial Notification
to CNDSP
Initial Report to
CNDSP
Initial submission
to JCD
1
Root Level Intrusion*
(Incident)
High
Within 15 minutes
Within 4 hours
Within 6 hours
Moderate
Within 2 hours
Within 8 hours
Within 12 hours
Low
Within 4 hours
Within 12 hours
Within 24 hours
High
Within 15 minutes
Within 4 hours
Within 6 hours
Moderate
Within 2 hours
Within 8 hours
Within 12 hours
Low
Within 4 hours
Within 12 hours
Within 24 hours
3
Unsuccessful Activity
Attempt (Event)
Any
Within 4 hours
Within 12 hours
Within 24 hours
4
Denial of Service*
(Incident)
High
Within 15 minutes
Within 4 hours
Within 6 hours
Moderate
Within 15 minutes
Within 4 hours
Within 6 hours of
discovery
Low
Within 30 minutes
Within 6 hours
Within 8 hours
5
Non-Compliance
Activity (Event)
All NonCompliance
Events
Within 4 hours
Within 12 hours
Within 48 hours
6
Reconnaissance
(Event)
Any
Within 4 hours
Within 12 hours
Within 24 hours
7
Malicious Logic*
(Incident)
High
Within 15 minutes
Within 4 hours
Within 6 hours
Moderate
Within 2 minutes
Within 8 hours
Within 12 hours
Low
Within 4 hours
Within 10 hours
Within 18 hours
8
Investigating
(Event)
N/A
Within 2 hours of
notification**
Within 4 hours of
notification
Within 24 hours
9
Explained Anomaly
(Event)
N/A
N/A
Within 24
hours
Within 72 hours
2
User Level Intrusion*
(Incident)
Table 4-1: Reporting Timelines
17
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
5 INFORMATION SYSTEM SECURITY INCIDENT FORMS
Use this AFMS Information Assurance Computer Incident Reporting Form to report incidents to
the Office of the Chief Information Officer/Information Assurance (OCIO/IA) Director and/or
the AFMS Privacy Office Director. Follow up the initial contact with an electronic copy of this
form or fax it to 703.681.8814.
AFMS Contractor information system (IS) Only
Incident Number: _____________________ (See Table 5-2, Incident Category Definitions, 1-9)
Date of Incident: ______________________ Time of Incident:_____________________
1. Reporting Organization Information
Organization: ____________________________________________________________
Name: __________________________________________________________________
Section:_________________________________________________________________
Telephone #:_____________________________________________________________
E-mail Address: __________________________________________________________
2. Target Host Information
Host IP: ________________________________________________________________
Host Machine Name:______________________________________________________
Classification Levels:
Classified __________/Sensitive But Unclassified _________ /Non-Sensitive _________
System Mission:__________________________________________________________
Operating System:_________________________________________________________
3. Source(s) Information
Source(s) IP: _____________________________________________________________
Source Host Name: _______________________________________________________
Source Name and Address: _________________________________________________
18
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
4. When Detected
Type of Incident or Attack:
How Detected:
Description of Incident:
Was System Compromised? Yes _______ No ________
Database/Files Compromised:
# of Individuals Affected:
# of Servers/Workstations Affected:
Impact on Operation:
Countermeasure(s):
5. Notification
Network Administrator:
Firewall Administrator:
LAN Administrator:
Network Security:
Virus Section:
Information Systems Security Officer:
Federal Computer Incident Response Team:
Data Owner:
Law Enforcement Agency:
6. Additional Details (Please include here any information not detailed above)
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
19
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
For Government IS only
Information Assurance Computer Incident Reporting Form
Use this form to transmit initial and follow-on reports to the Computer Network Defense Service
Provider (CNDSP) and Joint Task Force – Global Network Operations (JTF-GNO).
NOTE: Incidents that may be classified in multiple categories are reported at the most severe
category.
Field
Description
CERT/CIRT Incident Number
Identify the reporting CERT/CIRT’s reference number for tracking the
incident.
Primary Incident Category
Identify access level gained as per Table 5-2, Incident Category
Definitions.
Secondary Incident Category
Identify any sub access level gained, if more than one category applies, as
per Table 5-2, Incident Category Definitions.
Attack Vector
Identify attack vector.
Weakness
Identify system weakness.
Last Update
ZULU date time group (DTG) (DTG Example: 141615Z AUG 06) of the
last time the report was updated. Provide Year/Month/Day/Hour/Minute
/Seconds.
Incident Start Date
ZULU DTG of the earliest event that was incorporated into the incident.
Provide Year/Month/Day/Hour/Minute /Seconds.
Incident End Date
ZULU DTG that incident actually ended. Provide
Year/Month/Day/Hour/Minute /Seconds.
Status
Status of the incident (“OPEN” or “CLOSED”).
System Classification
Classification of the system under attack. “UNCLASSIFIED,”
“CONFIDENTIAL,” “SECRET,” “TOP SECRET.”
Detecting Unit or Organization
Name of reporting Unit or Organization.
Affected Unit or Organization
Name of reporting affected Unit or Organization.
Action Taken
Indicates what action has been taken in response to the incident. Include
notifications and associated reports. Include whether a copy of a medium
was taken (image hard drives), or logs collected and disposition of
mediums and logs).
Organization Tracking
AFMS
CERT Date Reported
ZULU DTG of when the incident was first reported to the CNDSP/JTFGNO. Provide Year/Month/Day/Hour/Minute/Seconds.
Operational Impact
Identify any detrimental effects on ability to perform mission.
Major Command
AFMS
System Impact
This is a subjective field, but it is critical to get a general sense of the
impact on operations of an incident.
20
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
Field
Description
Systems Affected
Number of systems affected by the incident.
Staff Hours Lost
This is reported as an update record and may cause the Impact field to be
updated. Amount of time your technical support required to identify,
isolate, mitigate, resolve and recover from the attack and repair the
attacked system (do not include analyst time spent analyzing the incident).
Exercise Name
Name of the exercise, if applicable.
Event Description
Provide a detailed description of the event, including what happened, how
it occurred and the current action taken to mitigate the event.
Source IP and port
Provide source IP with resolution data identifying owner and country of
source IP machine. If the intruder is known, provide all identifying
information to include objective of intruder, if known. (Source IP is not
necessarily indicative of true origin). Footnote the source of
resolution/attribution data – i.e., ARIN.org.
Intruder(s) (if known)
Identify the intruder or group that is responsible for the incident, if
known.
Origin (country) (if known)
Identify the Source IPs country of origin.
Target IP(s) and port
Provide target IP with resolution identifying responsible command and
physical location of target IP machine. Footnote the source of
resolution/attribution data – i.e., DoD NIC, NSLOOKUP, WHOIS. If
machine is behind a NAT’ed (network address translation enabled) router
or firewall then also provide the wide area network (WAN) routable
address (i.e., the Internet/SIPRNet routable IP address).
Technical Details
Provide a narrative description of the incident with technical details.
Include DTGs of significant events (start, stop, or change of activity).
State the use of the targeted system and whether the system is online or
off-line. Indicate whether the incident is ongoing.
Physical Location (base, camp, post or
station)
Identify the facility that is affected by the intrusion and/or owns the
Target IP and where the physical system resides:
Provide the address for the facility.
Technique, tool or exploit used
Identify the technique, tool, or exploit that was used to exploit the
vulnerability.
OS and version of OS
Record the operating system and version number of the operating system
(OS) where the incident occurred.
Use of target (e.g., web server, file
server, host)
If applicable, for what the intruder/attacker used the target system for
after it was exploited, if applicable.
DoD Network
Identifies network on which the incident occurred:
 NIPR
 SIPR
Comments
Provide any amplifying information about the incident.
Synopsis
Provide an executive summary of the incident.
Contact Information:
Name:
Organization:
21
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
Field
Description
Telephone:
Fax:
E-mail:
Table 5-1: Information Assurance Computer Incident Reporting Form
Category
Description
1
Root Level Intrusion (Incident): Unauthorized privileged access (administrative or root access) to
a DoD system.
2
User Level Intrusion (Incident): Unauthorized non-privileged access (user level permissions) to a
DoD system. Automated tools, targeted exploits, or self-propagating malicious logic may also attain
these privileges.
3
Unsuccessful Activity Attempt (Event)**: Attempt to gain unauthorized access to the system,
which is defeated by normal defensive mechanisms. Attempt fails to gain access to the system (i.e.,
attacker attempt valid or potentially valid username and password combinations) and the activity
cannot be characterized as exploratory scanning. Can include reporting of quarantined malicious
code.
4
Denial of Service (Incident): Activity that impairs, impedes, or halts normal functionality of a
system or network
5
Non-Compliance Activity (Event): This category is used for activity that due to DoD actions
(either configuration or usage) makes DoD systems potentially vulnerable (e.g., missing security
patches, connections across security domains, installation of vulnerable applications, etc). In all
cases, this category is not used if an actual compromise has occurred. Information that fits this
category is the result of non-compliant or improper configuration changes or handling by authorized
users.
6
Reconnaissance (Event): An activity (scan/probe) that seeks to identify a computer, an open port,
an open service, or any combination for later exploit. This activity does not directly result in a
compromise.
7
Malicious Logic (Incident): Installation of malicious software (e.g., Trojan, backdoor, virus, or
worm).
8
Investigating (Event): Events that are potentially malicious or anomalous activity deemed
suspicious and warrants, or is undergoing, further review. No event will be closed out as a category
8. Category 8 will be re-categorized to appropriate Category 1-7 prior to closure.
9
Explained Anomaly/Activity (Event): Events that are initially suspected as being malicious but
after investigation are determined not to fit the criteria for any of the other categories (e.g., social
engineering).
Table 5-2: Incident Category Definitions
22
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
6 VIRUS REPORT
EXAMPLE TEXT:
Date/Time: __________________________
Name of Reporting Associate: _____________________________________________
Organization: ___________________________________________________________
Phone: _______________________________
Location: _______________________________________________________________
Provide the following information to your Information Assurance Officer.
1. Name of the infecting virus: __________________________________________
2. Source of the virus:
____________________________________________________________________
3. Other locations within or outside of your office that could possibly be infected as a result
of this virus:
____________________________________________________________________
4. Number and types of systems infected (i.e., hard disks and servers), along with the
number of CDs/media infected:
____________________________________________________________________
5. Method of clean-up:
____________________________________________________________________
6. Number of man-hours required in effort: _________________________________
7. Damage or observations resulting from the virus triggering:
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
23
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
7 CRACKER/HACKER REPORT
EXAMPLE TEXT:
Date/Time:
Name of Reporting Associate:
Organization:
Phone:
Location:
1. Reporting Date:
2. Incident Date:
3. Type of Incident:
4. Individuals Involved (name/office):
5. Cost of Incident (downtime, actual costs incurred, etc.):
6. Summary of Incident and Investigation Results (e.g., number of hosts attacked, how
access was obtained, how attack was identified, was an Incident Response Organization
contacted prior to submission of report, etc.)
7. Supervisor’s Recommendations/Comments:
8. Investigating Official’s Name:
9. Local Action to Prevent Re-occurrence:
10. Recommended Action by Incident Official:
11. Attack Address:
12. Physical location of system:
13. Hardware Configuration:
14. Operating System:
15. Security Software installed:
16. Highest level of data residing on system:
17. Damage or observations resulting from attack:
18. Other affected hosts/sites:
24
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
8 VULNERABILITY REPORT
EXAMPLE TEXT:
Date/Time: __________________________
Name of Reporting Associate: _____________________________________________
Organization: ___________________________________________________________
Phone:
Location: _______________________________________________________________
A. Required Information
1. Date Vulnerability was reported:
2. Contact person:
a. Name:
b. Organization:
c. Phone Number:
d. Position:
3. Hardware/Software:
a. List hardware and system configuration:
b. Software Description:
i.
Operating system (include release number)
ii.
Describe any unique attributes - i.e., locally modified special security
properties
4. Executive Summary of Vulnerability: A description of the nature and effect of the
vulnerability, in general terms.
5. Description of Technical Vulnerability: A scenario that describes specific conditions
to demonstrate the weakness or design deficiency. The description should
sufficiently describe the conditions so that the weakness or design deficiency can be
“reconstructed” without further information. This scenario may include source code
or object code.
6. Describe the specific impact or effect of the weakness or design deficiency in terms
of:
a. Denial of service
b. Alteration of information, and/or
c. Compromising of data. Cite specific examples as appropriate.
7. Indicate whether or not the “affected” vendor has been notified.
8. Suggested Fixes - Describe any code or procedures you may have discovered that,
when implemented, may reduce the impact of the defined technical vulnerability.
9. Additional Information
25
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
9.1. System Specifics:
a. Location:
b. Owner:
c. Network connections:
9.2. Security attributes:
9.3. Additional clarifying information.
26
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
9 INCIDENT RESPONSE CHAIN OF NOTIFICATION CONTACT INFORMATION
EXAMPLE TEXT:
Strategic Situational Awareness (SSAW) IAO
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
(xxx) xxx-xxxx (Cell/Pager)
E-mail:
SSAW Alternate IAO
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
(xxx) xxx-xxxx (Cell/Pager)
E-mail:
SSAW IAM
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
(xxx) xxx-xxxx (Cell/Pager)
E-mail:
SSAW Alternate IAM
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
27
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
(xxx) xxx-xxxx (Cell/Pager)
E-mail:
SSAW Director/Program Manager
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
(xxx) xxx-xxxx (Blackberry)
E-mail:
Director, AFMS Privacy Office
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
(xxx) xxx-xxxx (Blackberry)
E-mail:
Director, OCIO/IA
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
(xxx) xxx-xxxx (Blackberry)
E-mail:
SSAW CIRT
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
28
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
(xxx) xxx-xxxx (Cell/Pager)
E-mail:
SSAW Data Owner
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
(xxx) xxx-xxxx (Cell/Pager)
E-mail:
AFMS Certifying Authority
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
(xxx) xxx-xxxx (Blackberry)
E-mail:
Network Operations Director (Government IS Only)
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
(xxx) xxx-xxxx (Blackberry)
E-mail:
Designated Accrediting Authority
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
29
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
(xxx) xxx-xxxx (Blackberry)
E-mail:
AFMS CIO
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
(xxx) xxx-xxxx (Blackberry)
E-mail:
Director, AFMS
Name:
Address:
City, State, Zip:
(xxx) xxx-xxxx (Work)
(xxx) xxx-xxxx (Blackberry)
E-mail:
30
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
Appendix A
SSAW LIST
SSAWs used specifically in this Artifact are to be listed in this appendix.
SSAW
TERM
ACL
Access Control List
AFMS
Air Force Medical Service
AIS
Automated Information System
C&A
Certification and Accreditation
CD
Compact Disc
CERT
Computer Emergency Response Team
CIO
Chief Information Officer
CIRT
Computer Incident Response Team
CJCSM
Chairman of the Joint Chiefs of Staff Manual
CND
Computer Network Defense
CNDSP
Computer Network Defense Service Provider
DIACAP
DoD Information Assurance Certification and Accreditation Process
DAA
Designated Accrediting Authority
DISA
Defense Information Systems Agency
DoD
Department of Defense
DoJ
Department of Justice
DTG
Date Time Group
GIG
Global Information Grid
IA
Information Assurance
IAM
Information Assurance Manager
IAO
Information Assurance Officer
IAVA
Vulnerability Assessment Alerts
IAVM
Vulnerability Assessment Management
IDS
Intrusion Detection System
IS
Information System
IT
Information Technology
JTF-GNO
Joint Task Force – Global Network Operations
LAN
Local Area Network
31
UNCLASSIFIED
Strategic Situational Awareness Incident Response Plan
Artifact 2
April 2013
SSAW
TERM
MAC
Mission Assurance Category
NDTM
Network Defense Tasking Message
NOD
Network Operations Director
OCIO
Office of the Chief Information Officer
OMB
Office of Management and Budget
OS
Operating System
PHI
Protected Health Information
PII
Personally Identifiable Information
PO
Program Office
POC
Point of Contact
PM
Program Manager
PPS
Ports, Protocols, and Services
PPSM
Ports, Protocols, and Services Management
SI
Sensitive Information
VAA
Vulnerability Assessment Activity
VAT
Vulnerability Assessment Team
32
UNCLASSIFIED