27. DRAFT - Template_Information System_Incident Response Plan.docx

information system name INCIDENT Response Plan for [eMASS System Name]

[eMASS SYSTEM ACRONYM] [System Version 1.2.0.0]

November 2017

Use the date of the Authorizing Official (AO) signature in the placeholder above.

Include only the month and year.

Site/Program Office Information System (IS) Name Incident Response Plan Artifact 2

MMM YYYY

Add appropriate classification marking iii

DOCUMENT REVISION AND HISTORY PAGE

This document will be reviewed at a minimum annually.

OF CHANGE

SECTION/

PARAGRAPH

PAGE

Global

i

Table of Contents

List of Tables

Information System Name Incident Response Plan Month YYYY

Information System Name Incident Response Plan Month YYYY i

Introduction This Incident Response Plan (IRP) document applies to Information System (IS) Name (ACRONYM) 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.

Incident Response Controls The following Incident Response (IR) controls are from NIST SP 800-53, Rev. 4.

Control No.

Control Name Security Controls and Enhancements

Table 1-1: Summary of NIST SP 800-53 Incident Response Controls for Low-, Moderate-, and High- Impact Systems Purpose [IR-8] The purpose of the IRP 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. This facility maintains an incident handling program in accordance with Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01B “Cyber Incident Handling Program.”, 10 July 2012.

Provide the organization’s mission, strategies and goals for incident response. Refer to Section 2.3.2 of the NIST SP 800-61, “Computer Incident Handling Guide” for additional guidance.

Applicable Provisions and Directives [IR-1] 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 (P.L.) No. 93-579 “Health Insurance Portability and Accountability Act (HIPAA)” 1996. P.L. 104-191. , 21 August 1996 Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01B “Cyber Incident Handling Program.”, 10 July 2012 Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6510.01F “Information Assurance and Support of Computer Network Defense.”, 09 February 2011 DoD Directive 8570.01, “Information Assurance Training, Certification, and Workforce Management.”, 15 August 2004; Certfied current 23 April 2007 DoD Directive O-8530.1, “Computer Network Defense (CND).”, 01 January 2001 DoD Instruction 8500.01, “Cybersecurity”, 14 March 2014 DoD Instruction 8510.01, “Risk Management Framework (RMF) for DoD Information Technology (IT)”, 12 March 2014 DoD Instruction O-8530.2, “Support to Computer Network Defense (CND). 09 March 2001 NIST Special Publication 800-53 “Security and Privacy Controls for Federal Information Systems and Organizations”, Rev 4, April 2013 NIST Special Publication 800-61 “Computer Security Incident Handling Guide”, Rev 2, August 2012 NIST Special Publication 800-86 “Guide to Integrating Forensic Techniques into Incident Response”, August 2006 Defense Health Agency Administrative Instruction 071, “Incident Response Team (IRT) and Breach Response Requirements”, 15 September 2015.

Computer Incident Response Program The IS’s Computer Incident Response Program includes processes and procedures to ensure:

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 Event An "event" is any observable occurrence, not yet assessed, that may affect the performance or security of an IS. Detection of an event is the continuous process of identifying any usual network or system activity, user behavior, or organizational practices and procedures with potential to adversely affect systems, networks, or operational missions. The primary objectives for detecting events include ensuring all suspicious activity is detected and reported so that further analysis can take place to determine if it is a reportable event or incident, that suspicious activity is reported in a timely manner consistent with required reporting timelines. 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.

Incident An “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 or manipulates 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.

Types of Incidents 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, self-replicating malicious code can replicate rapidly, thereby making containment an especially difficult problem.

Cracker/Hacker Attacks 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.

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.

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.

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.

Misuse Misuse occurs when someone uses a computing system for other than authorized purposes.

Espionage Espionage is the stealing of information to subvert the interests of a corporation or government.

Hoaxes Hoaxes are the proliferation of false information about incidents or vulnerabilities.

Roles, responsibilities & reporting requirements [IR-1], [IR-4] 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 System Security Manager (ISSM), 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.

Upon receipt of confirmation of an incident, the Computer Incident Response Team (CIRT) must be activated. [Insert Applicable Computer Network Defense Service Provider (CNDSP)/Cyber Security Service Provider (CSSP) Agreement.] Information System Name Personnel User/Operator If a computer security incident is detected, it should be reported immediately to the Information System Security Officer (ISSO). 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 ISSO.

Information System Security Officer The ISSO is responsible for all security matters related to the IS.

The ISSO has the responsibility to report incident information in a timely fashion. In addition, the ISSO is prepared to advise the ISSM 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.

It is also the ISSO’s responsibility to coordinate incoming information, advise users on handling security incidents, and disseminate information to the ISSM and end users, as appropriate.

Information System Security Manager The ISSM has the responsibility to report incident information in a timely fashion. In addition, the ISSM receives the information, coordinates a response with the assistance of the ISSO and passes it to the Director of the ACRONYM IS. If criminal activity is suspected or is immediately evident, the ISSM will cooperate with external authorities.

Information System Name 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:

Paragraph below is for Government IS only; remove if not applicable Incidents that occur with the ACRONYM IS the Director/PM of the IS must notify the Office of the Chief Information Officer (OCIO)/Cyber Security (CS) Director and the DHA Privacy and Civil Liberties 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/CS and DHA Privacy and Civil Liberties Office, and complete the Information Assurance Computer Incident Reporting Form found in Appendix C: Table B-1, Cyber Security (CS) Computer Incident Reporting Form.

Technical support for an active attack will be directed to the DoD Computer Emergency Response Team (CERT), by the Government Information System Office Name Information System (IS).

Information System Name Computer Incident Response Team In the event of an incident, the affected ACRONYM IS CIRT will notify the responsible IS/Data Owners. Additionally, Government ISs will also need to notify the DoD CERT and affected service CIRT. Last statement is for Government IS only, remove if not applicable.

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 ISSM, ACRONYM management will activate the CIRT Have a plan of action in place, in the event of an incident Maintain proper chain of custody for confiscated data and devices 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.

As per NIST SP800-86, Guide to Integrating Forensic Techniques into Incident Response, before the analyst begins to collect any data, a decision should be made by the analyst or management (in accordance with the organizations policies and legal advisors) on the need to collect and preserve evidence in a way that supports its use in future legal or internal disciplinary proceedings. In such situations, a clearly defined chain of custody should be followed to avoid allegations of mishandling or tampering of evidence. This involves keeping a log of every person who had physical custody of the evidence, documenting the actions that they performed on the evidence and at what time, storing the evidence in a secure location when it is not being used, making a copy of the evidence and performing examination and analysis using only the copied evidence, and verifying the integrity of the original and copied evidence. If it is unclear whether or not evidence needs to be preserved, by default it generally should be preserved.

Department of Defense Computer Emergency Response Team [IR-6] The DoD CERT is a component of the United States Cyber Command (USCYBERCOM). The DoD CERT provides CS Incident Response Support to the Defense Information Infrastructure Community Support of CS.

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 http://www.us-cert.gov/.

[CCI-000836]

Conducting Training [IR-2] Training is an important part of protection. All DHA personnel are compliant with the requirement based on DoDD 8570.01 requirements for IA awareness training. Incident Response training is required for information system users with an incident response role or responsibility. A major incident is not the time to discover that preparations and procedures are incomplete.

incident response process [IR-4] As discussed in NIST SP 800-61, Computer Security Incident Handling Guide, the incident response process has several phases. The first step is Preparation, not only by establishing the capability, but also in preventing incidents. The next step is Detection and Analysis of incidents to rapidly minimize the number of infected hosts and amount of damage the site sustains. The impact can be mitigated by containing it and ultimately recovery from it during the Containment, Eradication and Recovery steps. In the last step, Post-Incident Activity, a robust assessment of lessons learned to prevent similar incidents from occurring must be performed.

[CCI-000822, CCI-000823, CCI-000825]

[Discuss the documented procedures for handling of incidents until they are transferred to the responsibility of the CNDSP/CSSP. Describe how the incident handling activities are coordinated with contingency plan activities to maintain confidentiality and integrity of the contingency assets. For additional guidance, refer to NIST SP 800-61 and the CJCSM 6510.01B.] 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 further damage by ensuring that response actions are known and coordinated.

NOTE: The following actions must be addressed in the Incident Response Plan The ISSO 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.

Add/revise steps as necessary.

Detection and Analysis 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 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/DHA 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 DHA 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 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.

[Summarize the process for actions taken upon discovery of suspicious activity; discuss procedures in place for detection and analysis of incidents. Describe process for documenting actions taken and resolution and describe procedures in place.] Reporting of Incidents [IR-6] Reporting is an ongoing process throughout the incident handling lifecycle.

In the event the incident involves PII, it must be reported to the US-CERT and the DHA Privacy Office within 1 hour and the DoD Defense Privacy and Civil Liberties Division and Director within 48 hours. To report the incident involving PII, use http://www.us-cert.gov/. For further information, refer to Appendix G of this document and DHA Administrative Instruction-071.

If PHI is involved, refer to DHA Privacy Office guidance for additional breach reporting and notification actions as required by the Health and Human Services (HHS) Final Omnibus Rule and Title 45, CFR, Parts 160 and 164.

[Describe the process for reporting of incidents to the CNDSP/CSSP, USCYBERCOM and senior leadership.] Incident reporting guidelines are outlined in the CJCSM 6510.01B. Incidents reported are categorized according to Appendix A to Enclosure B: Cyber Incident and Reportable Cyber Event Categorization. Reporting timelines are described in Section 5of this document and will vary according to activity category.

Analysis of Incidents [Provide Analysis of Incidents details. Incident analysis determines if an event is a reportable event and what occurred during the incident. Describe how action(s) taken and analysis of results are documented. Reference applicable procedures.] Determination of Incident [Provide the Determination of Incident details. Initial analysis of a detected event aids in the determination of an incident. This includes determining whether it is a reportable incident, preventing further damage, maintaining control of the system(s) affected and the surrounding environment, collection of information, and updating of the incident report. Who will determine both the operational impact and technical impact of the incident?] Coordination for Incident [Identify the stakeholders involved. Describe the process for to ensure that effective coordination of an incident and communication with other agencies and organizations are conducted through appropriate channels. Who will coordinate with other agencies and components as necessary?] Notification by the United States Cyber Command In the event the USCYBERCOM 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/CSSP for incident handling execution in accordance with Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01.

Involvement for Critical Incidents The Flag/General Officer will be involved for critical incidents. 24 hours after the release of an NDTM, if the USCYBERCOM 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 USCYBERCOM Deputy Commander for escalation to the DHA CIO.

48 hours after the release of an NDTM, if USCYBERCOM 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 USCYBERCOM Commander for escalation to the DHA Privacy and Civil Liberties Office Director.

Add appropriate classification marking Add appropriate classification marking

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 sensitive information 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 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).

[Describe the process for containing the incident and necessary mitigating actions. Identify procedures for containment. Describe existing guidance regarding containment requirements. For example, determine if the compromised information should be left on the current system or if the system should be taken offline and the information transferred to alternative media.] 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 includes legal action against the perpetrator, when possible.

[Describe the process for eradication of incidents and identify eradication procedures.] Malicious Code Attacks and Cracker/Hacker ATTACKS and Responses Malicious Code Attacks and Appropriate Response Malicious code attacks include attacks by programs such as viruses, Trojan horse programs, worms, and scripts used by cracker/hackers to gain privileges, capture passwords, and /or modify audit logs to exclude unauthorized activity.

Computer Viruses A virus is a variation of a Trojan horse. It is propagated via a triggering mechanism (e.g., even time) with a mission (e.g. delete files, send data).

Description 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 commonly shared as attached files via e-mail and the Internet, macro viruses circulate very rapidly and can re-infect an installation overnight.

Actions Obtain the anti-virus tools needed and start using them as soon as possible. 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 compact disc (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 CIRT/CERT team 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.

Worms A computer worm is an unwanted, self-replicating autonomous process, or set of processes, that penetrates computers using automated hacking techniques.

Description 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.

Actions If a worm is noticed, inform the ISSO, 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.

Trojan Horses A Trojan horse is a useful and innocent program containing additional hidden code that allows unauthorized computer network exploitation, falsification, or destruction of data.

Description 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, have a technical support specialist analyze it to determine whether or not the program contains any Trojan horse code.

Actions 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 the IS CIRT before the program is deleted from the system.

Cracker/Hacker Attacks and Appropriate Responses Crackers and hackers are unauthorized users who attempt to obtain unauthorized access to IS. Modem dial-in is a favorite way to crack systems.

Cracking Utilities 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 5.1.2.2, Worms, for protective measures.

Description 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) Actions To protect against a cracker/hacker attack, users must 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 easy-to-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 ongoing monitoring of the IS with host- and network-based intrusion detection systems (IDSs), implementation of Information Assurance Vulnerability Alerts (IAVAs) and patches, as well as audit log reviews. Additional defenses include: firewall/Access Control Lists (ACLs), on-going 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 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/crypto-checksum 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 Appendix D: Cracker/Hacker Report.

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.

[Describe the process for restoring data and systems and making the necessary changes to network configuration and identify procedures for incident recovery.]

Post-Incident Activity 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.

[CCI-000824]

[Are after action reviews from incidents conducted? Describe how lessons learned from ongoing incident handling activities are incorporated into incident response procedures, training, and testing/exercises. ] 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?

Reporting formats, included in appendices 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 conducted at least on an annual basis.

[CCI-000848]

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.

The VAA reviews will follow three phases:

· Phase I – A Vulnerability Assessment Team (VAT) will examine ISs, networks, workstations, and CS 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 DHA 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.

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 Appendix F, Vulnerability Report, have another technical support specialist verify that the vulnerability exists. Once the technical vulnerability has been validated notify the IS ACRONYM ISSO who is responsible for all security matters related to the IS.

Legal Procedures This section is not intended to provide detailed legal guidance. Any legal questions should be forwarded to DHA legal counsel. The DHA legal counsel provides advice and counsel also coordinates with the DHA Privacy Office regarding breaches.

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.

Category and Title See Appendix C, Table B-2: Incident Category Definitions

Root Level Intrusion (Incident)

User Level Intrusion (Incident)

Unsuccessful Activity Attempt (Event)

Denial of Service (Incident)

Non-Compliance Activity (Event) All Non- Compliance Events

Reconnaissance (Event)

Malicious Logic (Incident)

Investigating (Event)

notification

Explained Anomaly (Event)

hours Within 72 hours

Table 7-1: Reporting Timelines

INCIDENT RESPONSE TESTING [IR-3]

<Site/facility> tests the incident response capability for ACRONYM at least every 6 months for high availability / annually for low/moderate availability. Results must be documented and reviewed by the incident response team.

[CCI-000818, CCI-000821, CCI-001624]

[Define the tests for incident response. For further guidance, refer to Appendix A of the NIST SP 800-61. For systems with moderate and high watermark, incident response testing must be coordinated with organizational elements responsible for related plans.

List the necessary support from all responsible organizational elements for incident response testing responsible for related plans.]

APPENDIX A: INFORMATION SYSTEM SECURITY INCIDENT FORMS

Use this DHA Information Assurance Computer Incident Reporting Form to report incidents to the OCIO/CS Director and/or the DHA Privacy and Civil Liberties Office Director. Follow up the initial contact with an electronic copy of this form or fax it to 703.681.8814.

DHA Contractor information system (IS) Only

Incident Number: _____________________ (See Table B-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: _________________________________________________

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

Date Supervisor Notified: ________________________________________________________

Network Administrator:

Firewall Administrator:

LAN Administrator:

Network Security:

Virus Section:

Information Systems Security Officer:

Federal Computer Incident Response Team:

Data Owner:

Law Enforcement Agency:

Breach Requires Reporting to the Department of Health and Human Services (HHS): Y/N

Date DHA Privacy Office Notified:_________________________________________________

6. Additional Details (Please include here any information not detailed above)

For Government IS only APPENDIX B: INCIDENT RESPONSE CHAIN OF NOTIFICATION Contact Information

IS Name (ACRONYM) ISSO Name:

Address:

City, State, Zip:

(xxx) xxx-xxxx (Work)

(xxx) xxx-xxxx (Cell/Pager) E-mail:

ACRONYM Alternate ISSO Name:

Address:

City, State, Zip:

(xxx) xxx-xxxx (Work)

(xxx) xxx-xxxx (Cell/Pager) E-mail:

ACRONYM ISSM

Name:

Address:

City, State, Zip:

(xxx) xxx-xxxx (Work)

(xxx) xxx-xxxx (Cell/Pager) E-mail:

ACRONYM Alternate ISSM Name:

Address:

City, State, Zip:

(xxx) xxx-xxxx (Work)

(xxx) xxx-xxxx (Cell/Pager) E-mail:

ACRONYM Director/Program Manager Name:

Address:

City, State, Zip:

(xxx) xxx-xxxx (Work)

(xxx) xxx-xxxx (Blackberry) E-mail:

Director,…