Menu
s
0 Comments

-483235520065Office of the Inspector General (OIG)
Incident Response Plan
As of April 28, 2018
00Office of the Inspector General (OIG)
Incident Response Plan
As of April 28, 2018

Table of Contents TOC o “1-3” h z u
Introduction PAGEREF _Toc512718393 h 3Background PAGEREF _Toc512718394 h 3Types of Incidents PAGEREF _Toc512718395 h 4Incident Classification PAGEREF _Toc512718396 h 6Incident Response Team PAGEREF _Toc512718397 h 7Incident Response Processes PAGEREF _Toc512718398 h 8Coordination and Communication PAGEREF _Toc512718399 h 10Appendices PAGEREF _Toc512718400 h 11References PAGEREF _Toc512718401 h 18

IntroductionIncident Response Plan: The incident response plan, hereafter, IRP outlines actions to follow in the event of a security incident, while describing the roles and responsibilities of the Incident Response Team.
Office of the Inspector’s (OIG) Mission: The OIG’s mission is to “promote effective, efficient, and economically sound intelligence activities and detect and deter fraud, waste, abuse, and mismanagement for all DIA elements, programs, functions, and operations. We accomplish this by conducting independent audits, inspections, and investigations and managing the DIA Hotline program” (DIA, 2017).

Purpose and Scope: The purpose of this plan is to provide an organized approach to addressing, handling, responding, and managing security incidents in an effective and efficient manner. The goal of the plan is to execute in such a way to minimize damage to the organization while reducing recovery time and costs. The IRP will be reviewed, assessed, and tested annually and updated accordingly.

BackgroundThe OIG has access to sensitive and classified data that is used as evidence to support claims of fraud, waste, and/or abuse. Therefore, confidentiality, integrity, and availability of data are extremely important and a risk for the office. The OIG also support the agency’s efforts in becoming more efficient and effective in operations to meet the mission (DIA OIG Website, 2017). As a result, the office has several risks to be aware of and assessed.

Strategic Risks Internal and external sources that could prevent the OIG accomplishing its mission.

Reputational Risks The risk that the behavior exhibited and actions taken do not align with the OIG’s core values, which could impact trust of stakeholders; this also includes questions of independence and objectivity.

Political Risks Most Inspector Generals (IGs) are politically appointed. Political events could impact the OIG from being able to meet its mission.

Management Risks OIG’s management practices could prevent them from meeting its mission.

Operational Risks Risks arising from inadequate or failed internal processes (independence, objectivity, competence), systems, people management or other internal or external events.
IT Risks Constant changes in IT could impact the OIG’s ability to do its job.

Resource Management Risks Being able to hire, develop and retain sufficient resources to support meeting the mission.

Hazard Risks The risk that the employee’s lack of awareness or improper behavior could impact the OIG’s ability to meet its mission.

Reporting Risks Reliability of OIG’s reporting, which includes accuracy and timeliness of end products. The reports must meet standards, regulations and stakeholder expectations.
Compliance Risks The risk of not complying with applicable laws and regulations as well as not detecting or reporting activities, not in compliance with statutory, regulatory, organizational requirements.

(OIG, Department of Labor, 2016)
Types of IncidentsIncident Categories
Assigning categories to incidents allow for easy classification especially when reporting incidents to the Computer Security Incident Response Team (CSIRT). There are numerous incident categories the OIG could consider, specifically because the organization is part of the Department of Defense as well as the Intelligence Community.
Categories Details
Breach of Personal Identifiable Information (PII) Incidents involving the discovery or access of personal information (SS#, financial information, driver’s license, home and email addresses). That could result in harm or inconvenience to the organization of individual.

Access Control and Identity Verification Denial of service attacks or unwanted system disruptions.

Unauthorized Use of a System Using systems for purposes other than work-related could cause an incident related to compromising sensitive data.

Email Abuse Unsolicited email on the unclassified system or spam. Phishing emails requesting network credentials and/or personal information.
Network Configuration Changes to the system, be it hardware or software without authorization.
Incident Examples and Operations
Within the OIG, there are several examples that are likely to fall within the incident categories listed above. Given the organization uses the secured system for most of its processing due to the excessive amounts of sensitive data, incidents could arise from negligence in handling, processing and storing information on the unclassified system. The examples presented below are more than likely to occur as a result of employee activity on the unclassified system, impacting the OIG’s operations.
Incident Categories Examples Operations Impacted
Breach of PII Transferring sensitive information from secured network to unclassified network and then sending information to another user without properly encrypting the data.
Sending PII to personal email.

Not properly storing sensitive documentation and someone without a need to know gets access to it.

Taking sensitive information out of the building and an unauthorized person gets a hold of it.

Plugging in a USB into the secured system and downloading PII data.

Providing personal information on unsecured websites. OIG’s investigations and the legal group would be impacted because they would need to work with CSIRT to determine the severity of the incident and whether fraud or malicious intent is involved. Impact high.

Access Control and Identity Verification System shutdown while working on documents in the unclassified system.

The system continually asking for login authentication and signing into the network. OIG would work on the secured network until CSIRT is able to resolve the issue. If the incident is on the unclassified network there would be little impact on operations since most of our work is on the secured network. Impact medium to high.

Unauthorized Use of System Accessing improper websites.

Not adhering to system controls in place.
Finding ways to bypass firewalls.

Downloading unauthorized software.

Not adhering to ethics policy when accessing and using systems. OIG’s investigations and the legal group would be impacted because they would need to work with CSIRT to determine the severity of the incident and whether fraud or malicious intent is involved. Impact high.

Email Abuse Excessive and improper use of the unclassified email.
Negligence in encrypting sensitive data on the unclassified system.

Responding to emails when the system provides a warning not to.
Responding to spam and unknown email addresses instead of reaching out to information security for verification.
Opening unknown emails and downloading links. OIG would work on the secured network until CSIRT is able to resolve the issue. Investigations and the legal group would be impacted because they would need to work with CSIRT to determine the severity of the incident and whether fraud or malicious intent is involved. Impact high.

Network Configuration Changes to hardware and software without notification from the network administrator.

Communications on the unclassified system indicating that changes need to be made to the system but asking for network verification from the employee for changes to be made.

Malicious code viruses infecting the network. OIG IT technical specialist will work with CSIRT to determine the cause of the changes to the hardware and software. If this occurred on the secured network, this would cause a work stoppage, greatly impacting OIG’s ability to meet its mission. If it occurred on the unclassified network then we would not use the unclassified network until the issue was resolved. Impact high.
Incident Classification
Potential Impact Definitions
Classification Low Medium High
Confidentiality – Protection of information access and disclosure restrictions. Unauthorized access or disclosure of information but has limited effect on an organization or individual. Unauthorized access or disclosure of information that has a serious effect on an organization or individual. Unauthorized access to disclosure of information that has a critical effect on an organization or individual.

Integrity – Protecting against unauthorized modifications or changes to information. Unauthorized modifications have a limited effect on an organization or individual. Unauthorized modifications have a serious effect on an organization or individual. Unauthorized modifications have a critical effect on an organization or individual.

Availability – Making sure information is timely and reliable when needed. Lack of access to timely and reliable information has a limited effect on an organization or individual. Lack of access to timely and reliable information has a serious effect on an organization or individual. Lack of access to timely and reliable information has a critical effect on an organization or individual.
(Source: FIPS Publication 199, VT IRP, 2015)
Incident Criticality
When it comes to incident response, it is important to prioritize especially if multiple incidents occur simultaneously. Therefore, the incident criticality table helps the organization to address the most severe or high-risk incidents first. When partnering with an external incident response vendor, timely response is essential. Timeliness and collaboration with our internal CSIRT minimize the impact of the incident to the organization. Additionally, timeliness is a metric the organization tracks to assess performance and identify needed improvements.
Classification Level (4 most severe) Typical Characteristics Activate CSIRT Incident Response Internal/External
4 Network attacks that impact operations, national security and endanger lives Yes Response from internal and external immediately. External onsite within 4-8 hours.

3 Threats to sensitive data with a serious impact on the organization and individuals. Yes/Advise Response from internal immediately. Discuss with the external team to determine if onsite is needed. If so external onsite response within 8-12.
2 Threats to non-sensitive data with little to no impact on the organization and individuals. No Inform OIG IT internal network specialist to document and monitor activity and perform some testing if necessary.

1 Minor issues with no impact and no follow up required. No Inform OIG IT internal network specialist. Maintain reports and periodically check activity.

(VT IRP, 2015)
Incident Response Team
The incident response team consists of stakeholders of the OIG as well as across the agency. Depending upon the complexity and type of breach, the team members listed below will execute tasks and provide proper oversight to address the incident. The team’s mission is to prevent loss of life, exposure of sensitive data from information systems, networks or databases, and maintain public confidence.

The primary incident response team members are:
Chief Information Officer (CIO)/Deputy Chief Information Officer (DCIO): The executive lead that activates incident response team, monitors mitigation efforts, and reports to Director and Deputy Director the incident and actions taken.
CIO Security Specialists: Monitors systems and collects data that appear suspicious. Reports the data to CIO/DCIO and provides advice on the mitigation actions to take.
CIO Helpdesk Network Analysts: Serves as the central point of contact for all incidents and informs CIO and DCIO of security incidents.

OIG IT Specialist: Serves as the IT representative for the OIG and works directly with the CIO Security Specialists.

The supporting incident response team members are:
Inspector General (IG)/Deputy Inspector General (DIG): Provides support services in forensic investigation, audits, and inspection of incidents.

Chief Financial Officer (CFO): Supports CIO efforts particularly if sensitive financial data is compromised.

Human Resources: Supports CIO efforts regarding breach of sensitive employee information (e.g. payroll, ssno, addresses, etc.)
OIG Legal Counsel: Supports CIO efforts and determines the legal ramifications (if any) to the OIG and agency due to the incident.

OIG Audits and Inspections Divisons: Conducts audit and inspections to ensure the agency’s information security is in compliance with applicable laws and regulations.

Incident Response Processes
The incident response process has four phases; preparation, detection and analysis, containment, eradication, and recovery and post-incident activity. The figure below represents the incident life cycle according to NIST Special Publication 800-61 revision 2.

Preparation: The most important phase when it comes to incident response. Organizations should not wait until an incident occurs to try and execute incident response processes because it could cause more damage than expected or critical steps will be overlooked. Preparation not only involves establishing an incident response capability but ensures the organization is ready to respond to incidents, but also preventing incidents by ensuring that systems, networks, and applications are sufficiently secure.

Detection and Analysis: Different types of incidents require different responses. During the detection and analysis phase, it is important to assess the incident, its criticality and risk to the organization to determine the proper courses of action.

Containment, Eradication, and Recovery: Containment is important because the actions help minimize the potential damage the organization as a result of the incident. Eradication is the process of destroying or eliminating the components of the incident and recovery is the process of restoring the organization’s systems back to normal.

Post-incident Activity: The essential actions associated with post-incident activity should be to assess what went well, what went wrong, and how the organization incident response process can be improved (NIST 800-61, revision 2)
Incident Triage
According to Tech Target triage for IT, “is the procedure of assigning levels of priority to tasks or individuals to determine the most effective order in which to deal with them”. As the potential for incidents increases, it is essential that “IT operations continually triage issues to decide which problems are most urgent to the organization. For example, top-priority issues are dealt with as they arise and medium-priority issues attended to when there are no top-priority issues remaining. If there are no medium-priority issues outstanding, low-priority issues may be addressed” (2016).
For the OIG triage and analysis are vital in the event of an incident, because properly assigning priority levels can mean the difference between life and death. For example, exposure of classified intelligence on the whereabouts of an intelligence agent on assignment can put the agent’s life at risk. So to ensure no tasks or processes are overlooked, a checklist is a convenient tool to verify and validate that procedures have been properly executed. The NIST Special Publication 800-61 revision 2 Checklist for Incident Response and Handling (2012) was used as the foundation for the checklist below. Additional information/procedures were added to obtain data relevant to the OIG.
Incident Response Checklist for Triage and Analysis
Detection and Analysis Completed
1.0 Determine whether an incident has occurred 1.1 Analyze the precursors and indicators
1. User identified issues with the system.

2. Analyze activity to determine if it is a potential incident. 1.2 Look for correlating information
1. User installed software.

2. User noticed a change in the computer’s performance.

3. User was on social media.

4. Downloaded a link and warned by the antivirus software. 1.3 Perform research (e.g., search engines, knowledge base)
1. Identify the timing of the notification and who sent the notification.

2. Identify the user’s activity with the intrusion occurred. 1.4 As soon as IT personnel believe an incident has occurred, begin documenting the investigation and gathering evidence
1. Obtain and review log files.

2. Find out if a ticket was created and who created it.

3. Identify the system impacted by the incident. 2.0 Prioritize handling of the incident based on the relevant factors (functional impact, information impact, recoverability effort, etc.) 3.0 Report the incident to the appropriate internal personnel and external organizations.

1. Address incidents in the order of priority, high then medium and if time allows low risks.

2. Activate IRP if an incident has occurred. Be onsite in 8 hours in high risk 3. Reach out to shareholders to inform those impacted by the incident.

4. Use IRP to determine who to inform based on triage and analysis.

5. Inform internal and external shareholders. Containment, Eradication, and Recovery 4.0 Acquire, preserve, secure, and document evidence
1. Obtain data log files from the operating system.

2. Identify the data impacted by the incident.

3. Back up documentary evidence. 5.0 Contain the incident
1. Shut down the network, if needed.

2. Disable necessary devices. 6.0 Eradicate the incident 6.1 Identify and mitigate all vulnerabilities that were exploited
1. Run patches and system fixes.

2. Develop corrective action plans.

3. Implement corrective action plans.

4. Run test to ensure that vulnerabilities identified have been mitigated. If not develop another corrective action plan and retest until resolved. 6.2 Remove malware, inappropriate materials, and other components
1. Run antivirus software
2. Make sure firewalls are functioning properly. 6.3 If more affected hosts are discovered (e.g., new malware infections), repeat the Detection and Analysis steps (1.1, 1.2) to identify all other affected hosts, contain (5), and then eradicate (6) the incident for them 7.0 Recover from the incident 7.1 Return affected systems to an operationally ready state
1. Restore network functionality and operations and go back to business as soon as possible. 7.2 Confirm that the affected systems are functioning normally
1. Run test to ensure systems are functioning properly. 7.3 If necessary, implement additional monitoring to look for future related activity
1. Obtain, incorporate, and assess monitoring tools to identify future potential incidents. Post-Incident Activity 8.0 Create a follow-up report 8.1 Hold lessons learned meeting (mandatory for major incidents, otherwise optional)
1. Ensure the meeting is held with the proper stakeholders based on the severity of the incident. Source: NIST Special Publication 800-61 revision (2012)
Coordination and CommunicationIn the event of an incident, the OIG may need to interact with different internal and external organizations in the course of executing incident response activities. Some of which include other incident response teams, law enforcement agencies, Internet service providers, and Congress. Coordination and communication with the internal and external parties should be outlined and documented prior to an incident occurring. This is so all parties are aware of their roles and responsibilities and effective lines of communication have been established. The coordination and communication between the parties should be reviewed and assessed annually.

Appendices
Appendix A – Recovery Cheat Sheet
In the event of an incident, to ensure that proper actions are taken to bring the organization back to normal operation, the list below is a cheat sheet of items needed to assist with proper recovery.

Items Organization Needs to Maintain for Recovery Parties Responsible for Collecting, Maintaining and Safeguarding the Items Retain for Regulatory and Other Requirements
Listing of identified and prioritized critical assets – to determine what would cause the organization to suffer heavy losses if stolen or damaged. In the event of an incident, must be protected. 1 Organization Stakeholders (to include department heads, legal, HR responsible for collecting. IT team responsible for maintaining and safeguarding items. Yes
Risk assessment of all systems and applications – to determine what risks are posed by combinations of threats and vulnerabilities and focus monitoring efforts based on a level of risk. 2 Organization Stakeholders for collecting and IT team responsible for maintaining and safeguarding items. Yes
Listing of all applications – to know what is on the network in order to better determine what has been impacted by an incident. 3 CIO and IT team. Yes
Network diagram of the entire network and recovery site, if at a different location – allows the team to get the network up and running to normal if recovery is at a different location. 3 CIO and IT team. Yes
Copies of vendor contact and insurance policy information – just in case the organization needs to contact the vendor and its insurance company, it will not need to spend time searching for information. 3 Legal and finance department head. Yes
Documented incident response policies and procedures – reviewed annually and updated annually and provided to the appropriate parties. Stakeholders and response team. Yes
Listing of the response team. Stakeholders. Yes
Emergency contact/communications listing, on-call information – for team members and others within and outside the organization (primary and backup contacts). 2 Stakeholders and response team. Yes
Incident Recovery Plan, that provides guidance in the event of an incident and defines stakeholders roles and responsibilities. The plan should be tested, assessed and updated annually. 3 Stakeholders, and response team. Yes
Copies of service level agreement with 3rd party service providers – if part of the CSIRT team is external, need to know what was agreed upon by both parties so it can be clearly executed. 3rd party service providers, IT team and legal if necessary. Yes
Incident report mechanisms – phone numbers, email addresses, online forms, and secure instant messaging systems that users can use to report suspected incidents. 2 Stakeholders, and response team. Yes
Issue tracking system for tracking incident status, etc. 2 Response team. Yes
War room if necessary, for central communication and coordination. 2 Response team. No
Encryption software – to be used for communications among team members, within the organization, and with external parties; and for Federal agencies. 2 IT, IS and response team. Yes
Storage Facility – for storing evidence and sensitive information. 2 Response team. Yes
Implement appropriate technology to protect critical assets: This is the software and hardware that is needed to respond to a cyber incident. 2 Stakeholders, IT, and IS teams. Yes
Documented legal authorization to monitor internal user activity: the corporate legal counsel needs to be familiar with the company’s cyber incident posture, policies, and procedures. Legal, IS team. Yes
Digital forensic workstations and/or backup devices – to create disk images, preserve log files, and save other relevant incident data. 2 Response team. Yes
Laptops and portable printers to analyze data, write and print reports, logs, and other evidence. 2 Response team. Yes
Spare workstations, servers, and networking equipment, or the virtualized equivalents – used to test before and during an incident. 2 Response team. Yes
Black removable media – to gather evidence from systems. 2 IT, IS, and response team. Yes
Evidence gathering accessories, including hard-bound notebooks, digital cameras, audio recorders, chain of custody forms, evidence storage bags and tags, and evidence tape, to preserve evidence for possible legal actions. 2 IT, IS, and response team. Yes
Report of user passwords maintained queried by the network’s database. Maintained in the database. IT and IS teams. Yes
Implement software to detect and stop malware throughout the organization. 2 IT and IS teams. Yes
Ensure network host is properly configured and maintain system and application configuration checklists – this will come in handy in the recovery efforts. 2 IT and IS teams. Yes
Maintain documentation of user awareness and training. 2 Stakeholders, IT, and IS teams. Yes
Network device, operating systems, and application logs. 2 IT and IS teams. Yes
Maintain backup copies of the configuration of the SIEM products and logs. IT and IS teams. Yes
Requirements for forensic analysis and evidence. 2 Stakeholders, IT, and IS teams. Yes
Documented Jump Bag list – for grab-and-go responses (i.e., when you need to respond to a breach quickly). This list should include overall responses and actions employees need to take immediately after a breach. Helping to keep the plan organized and prevents mistakes caused by panic. 1 Stakeholders, IT, and IS teams. Yes
Listing of 24 hour supply delivery and restaurants near the site – just in case the incident requires additional supplies and the team is working around the clock either testing or in the event of an incident. 3 Stakeholders, IT, and IS teams. Yes
Appendix B – Post-incident Activity
One of the steps for post-incident activity is to create and complete a follow-up report on the incident. The form should be completed as soon as possible following the detection or reporting of an IT security incident. All items completed should be based on information that is currently available. The form may be updated and modified if necessary. The security incident response report form below was developed by the Journal of American Health Information Management Association (AHIMA) in 2008 and was used to report all IT security related incidents.

Security Incident Response Report Form

Privileged and Confidential Attorney

Client Communication/Work Product

EVALUATION

How Well Did Work Force Members Respond?

Were the Documented Procedures Followed? Were They
Adequate?

What Information Was Needed Sooner?

Were Any Steps or Actions Taken That Might Have Inhibited the Recovery?

What Could Work Force Members Do Differently the Next Time an Incident Occurs?

What Corrective Actions Can Prevent Similar Inc
idents in the Future?

What Additional Resources Are Needed to Detect, Analyze, and Mitigate Future Incidents?

Other Conclusions or Recommendations:

FOLLOW

UP

Reviewed By:

?

Security Officer

?

IS Department/Team

?

Privacy Officer

?

Other

Recommended Actions Carried Out:

Initial Report Completed By:

Follow

Up Completed By:

This form has been developed as a working tool for assessment and improvement activities; it is intended for
internal use only.

70

Security Incident Response Report Form

Privileged and Confidential Attorney

Client Communication/Work Product

EVALUATION

How Well Did Work Force Members Respond?

Were the Documented Procedures Followed? Were They
Adequate?

What Information Was Needed Sooner?

Were Any Steps or Actions Taken That Might Have Inhibited the Recovery?

What Could Work Force Members Do Differently the Next Time an Incident Occurs?

What Corrective Actions Can Prevent Similar Inc
idents in the Future?

What Additional Resources Are Needed to Detect, Analyze, and Mitigate Future Incidents?

Other Conclusions or Recommendations:

FOLLOW

UP

Reviewed By:

?

Security Officer

?

IS Department/Team

?

Privacy Officer

?

Other

Recommended Actions Carried Out:

Initial Report Completed By:

Follow

Up Completed By:

This form has been developed as a working tool for assessment and improvement activities; it is intended for
internal use only.

70

Appendix C – After Action Review (AAR)
As part of the post-incident activity, an AAR is a review or debrief to document what happened with the incident, why it happened, how it happened and what can be done better the next the time. The review is used to capture lessons learned (successes and failures) from incident response process, in an effort to improve future processes. An AAR template is listed below.

ReferencesAfter Action Review, (2018). Retrieved April 28, 2018, from After Action Review Template.pdf.

Betan, H. (2010). Ten things that must be included in IT disaster recovery plans.Tech
Target. Retrieved April 22, 2018, from
https://searchdisasterrecovery.techtarget.com/tip/Ten-things-that-must-be-included-in-IT-disaster-recovery-plans.

Cichonski, P., Millar, T., Grance, T., and Scarfone, K. (2012). Computer Incident
Handling Guide. (2012). NIST Special Publication 800-61 Revision 2. Retrieved April 8, 2018, from https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.

DIA OIG Website (2017). Retrieved March 11, 2018, from
http://www.dia.mil/About/Office-of-the-Inspector-General/.

How to Make and Implement a Successful Incident Response Plan. (2017). Security
Metrics. Retrieved April 18, 2018, from https://www.ffifs.org/pdf/How%20to%20Make%20and%20Implement%20a%20Successful%20Incident%20Response%20Plan.pdfIT Security Incident Reporting Form (2018). Retrieved April 8, 2018, from
www.dhs.pa.gov/cs/groups/webcontent/documents/form/p_031584.doc.

Office of the Inspector General, Department of Labor Framework for Enterprise Risk
Management. (2016). Retrieved March 11, 2018, from https://www.oig.dol.gov/public/OIG%20DOL%20ERM%20Framework.pdf.

Security Incident Response Form. (2008). Journal of American Health Information Management
Association (AHIMA). Retrieved April 28, 2018, from https://www.AHIMA.org.

Virginia Tech Guide for Cyber Security Incident Response. (2015). Retrieved March 25, 2018
from Virginia Tech IRP (1).pdf.

What is Triage? (2016). Tech Target. Retrieved April 8, 2018, from
https://whatis.techtarget.com/definition/triage.