Computer Security Incident Response Plan (CSIRP)

Date

1

1.0 INTRODUCTION................................................................................................................. 4

2.0 INCIDENT RESPONSE POLICY.......................................................................................4

2.1 Purpose and Objectives.................................................................................................................... 4

2.2 Scope............................................................................................................................................... 4

2.3 Computer Security Incident.............................................................................................................. 4

2.4 Organizational structure.................................................................................................................. 52.4.1 Incident Response Team (IRT) Roles and Responsibilities................................................................5

2.4.1.1 Executive Staff..........................................................................................................................52.4.1.2 Team Lead................................................................................................................................52.4.1.3 Tech Lead..................................................................................................................................62.4.1.4 Incident Recorder.....................................................................................................................62.4.1.5 User Representatives................................................................................................................6

2.4.2 Support Staff....................................................................................................................................72.4.2.1 Legal.........................................................................................................................................72.4.2.2 Public Relations........................................................................................................................72.4.2.3 Human Resources.....................................................................................................................7

2.5 Incident severity ratings................................................................................................................... 7

2.6 Enforcement.................................................................................................................................... 7

3.0 INCIDENT RESPONSE PLAN........................................................................................... 8

3.1 Prevention....................................................................................................................................... 83.1.1 Host Security....................................................................................................................................83.1.2 Network Security..............................................................................................................................83.1.3 Malware Prevention.........................................................................................................................83.1.3 User Awareness and IT Training.......................................................................................................8

3.2 Preparation...................................................................................................................................... 8

3.3 Detection and Analysis..................................................................................................................... 93.3.1 Attack Vectors..................................................................................................................................93.3.2 Signs of an Incident..........................................................................................................................93.3.3 Sources of Precursors and Indicators...............................................................................................93.3.4 Incident Analysis............................................................................................................................113.3.5 Incident Documentation................................................................................................................123.3.6 Incident Prioritization.....................................................................................................................123.3.7 Incident Notification.......................................................................................................................12

3.4 Containment, Eradication, and Recovery........................................................................................123.4.1 Choosing a Containment Strategy..................................................................................................123.4.2 Evidence Gathering and Handling..................................................................................................13

3.4.2.1 Sources of Data.......................................................................................................................143.4.3 Identifying the Attacking Hosts......................................................................................................14

2

3.4.4 Eradication and Recovery...............................................................................................................15

3.5 Post-Incident Activity..................................................................................................................... 153.5.1 Lessons Learned.............................................................................................................................153.5.2 Using collected Incident Data.........................................................................................................16

3.5.2.1 Number of Incidents Handled.................................................................................................163.5.2.2 Time Per Incident....................................................................................................................163.5.2.3 Objective Assessment of Each Incident..................................................................................16

3.5.3 Evidence Retention........................................................................................................................16

4.0 INCIDENT RESPONSE PROCEDURES.........................................................................16

4.1 Incident Handling Checklist............................................................................................................ 17

5.0 ATTACHMENTS/FORMS/CHECKLISTS....................................................................18Computer Security Incident Reporting Form..........................................................................................19Detection and Analysis Form..................................................................................................................20Major Incident Report - Executive Summary..........................................................................................22Evidence/Property Chain of Custody......................................................................................................25Evidence Gathering................................................................................................................................27Lessons Learned Form............................................................................................................................30Attachment 1..........................................................................................................................................34Attachment 2..........................................................................................................................................36

6.0 CONTACTS........................................................................................................................ 37

WORKS CITED........................................................................................................................ 38

3

1.0 Introduction

An incident response plan brings together and organizes the resources for dealing with any event that harms or threatens the security of information assets. Such an event may be a malicious code attack, an unauthorized access to information or systems, the illegal use of services, a denial of service attack, or a hoax. The goal is to facilitate quick and efficient response to incidents, and to limit their impact while protecting information assets. [COMPANY] must plan with the expectation that security incidents will almost certainly occur in the future as additional technologies with differing demands are brought into the environment to service the information technology needs of the company. This Incident Response Plan is approved to assist in incident identification, response, and notification.

2.0 Incident Response Policy

2.1 Purpose and Objectives

The purpose of this computer security incident response plan is to facilitate the effective response and handling of cyber security incidents affecting the confidentiality, integrity, or availability of [COMPANY] information assets. In addition, this policy will define guidelines and procedures ensuring security events, incidents and vulnerabilities associated with information systems are communicated in a timely manner to facilitate expedient corrective action and to minimize negative impact.

2.2 Scope

This plan encompasses all information systems that access the [COMPANY] domain either internally or externally. This plan will apply to all employees regardless of status who perform work for or have access to company data.

2.3 Computer Security Incident

The National Institute of Standards and Technology (NIST) defines the following terms related to computer security:

4

An event is any observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a web page, a user sending email, and a firewall blocking a connection attempt.

Adverse events are events with a negative consequence, such as system crashes, packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malware that destroys data. This policy addresses only adverse events that are computer security-related, not those caused by natural disasters, power failures, etc.

A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices (National Institute of Standards andTechnology, 2012). Examples of incidents are:

Users open a link in an email from a known source that is actually malware. Clicking the link infects their computer and initiates a connection to an external source unbeknownst to the users.

An attacker obtains sensitive business data and threatens to release it publicly or sell it unless the victim pays a fee.

A user introduces a virus to the network by plugging in an infected thumb drive without scanning it. The user doesn’t report it out of fear or embarrassment causing the propagation of the virus and loss of data.

An attacker identifies a vulnerable service on the internal network through a port scan and exploits it through a denial of service attack that causes systems to crash.

2.4 Organizational structure This section describes the various roles and responsibilities of the Incident Response Team. While there are a number of roles performed by the team, it may be advantageous given the size of the company to have more than one role performed by a given individual. This is reflected in the Contacts matrix in Section 6.0.

2.4.1 Incident Response Team (IRT) Roles and Responsibilities

2.4.1.1 Executive Staff Directs adherence to the policies/processes/procedures of

the Incident Response Plan (IRP) Oversees IRT activities through frequent updates and

recommendations from the Team Lead Provides authority for escalation decision based on

5

recommendation from Team Lead Ensures necessary resources are available to the team

facilitating optimal response to any incident Final authority for any voluntary core system or critical

service shutdown for incident containment/recovery on recommendation from Team Lead

Manages communication between [COMPANY], public, media and potentially local, state, and/or federal agencies.

Directs company-wide incident response dry-run or table-top exercise at least annually

2.4.1.2 Team Lead Serves as the primary liaison to Executive Staff on all

matters of incident response Responsible for administration and implementation of the

IRP Ensures the IRP is continually updated, available to each

team member and reviewed every 6 months Determines validity of an incident based on prompt

aggregation of current data and notifies Executive Staff Upon official declaration of an incident, recommends IRT

activation to Executive Staff and determines initial course of action

Acts as central point of contact directing incident response overseeing each phase and providing frequent updates to Executive Staff

Ensures clear and consistent communication gathered and shared among IRT and to Executive Staff throughout incident response

Advises Executive Staff if activation of support staff becomes necessary due to legal, public relations, or employee concerns.

Responsible for the confidentiality and release of all data gathered – discussed - recorded during the IR lifecycle to only authorized personnel until method and content of post-incident notifications are determined

Conducts the annual incident response dry-run or table-top exercise and provides results to Executive Staff

2.4.1.3 Tech Lead Serves as the primary point of contact point of contact for

procedural implementation of the IRP as directed by the team lead

Go-to person who knows the passwords, where the logs are, how the network interacts, how to block ports/IPs,

Ensures collaboration with other team/support members

6

based on direction from Team Lead Sole voice to Team Lead on progress of tech team through

each phase of an incident. Provides updates regularly and confidentially

Advises Team Lead on proposed remediation activities to include potential impact/executes plan as directed

In collaboration with an incident recorder, ensures all data is being captured frequently

Provides critical insight to Team Lead during post-incident phase

2.4.1.4 Incident Recorder Ensures all data gathered/steps taken/discoveries made

are promptly captured and legibly recorded for analysis and post-incident review

Provides recorded information to Tech Lead/Team Lead/Executive Staff only, unless otherwise directed by any of those individuals

Keeps recorded data in possession at all times until transferred to an authorized location or scanned/shredded as directed.

2.4.1.5 User Representatives Liaison to Team Lead on user concerns/impact/requests

throughout the IRT lifecycle Ensures users are adhering to direction from IRT during

an incident and reporting violations immediately to Team Lead

Provides information and/or updates to user community as directed from the Team Lead

Contributes to post-incident phase by voicing observations on the incident and recovery impact as well as offering potential efficiencies

2.4.2 Support Staff2.4.2.1 Legal

Makes recommendation to IRT based on any legal implications of incident cause and/or response as requested

Provides insight in the event an employee caused the incident whether through negligence or intent

Drafts necessary legal documents as required Can advise team on how to interpret and apply contractual

compliance requirements Directs IRT regarding evidence collection and handling

2.4.2.2 Public Relations

7

Makes recommendations to IRT on any issues affecting the company from a public relations standpoint

Coordinates communications and response to media as directed

Prepares official communications as requested Interact with the shareholders if necessary and update

them on the process, what is being done, what they should know, and any steps they may need to take as directed by the IRT

2.4.2.3 Human Resources Makes recommendations to team on issues affecting

[COMPANY] employees Coordinates necessary employee actions as decided by

Executive Staff

2.5 Incident severity ratings

Critical to the determination of a computer security incident is evaluating an event in scope, impact, and systems affected against pre-determined factors. An event does not become a computer security incident until it is classified under a particular severity. The [COMPANY] Severity Matrix will be used as a tool to assist in making such a judgment.

2.6 Enforcement

Violations of this policy, including failure to comply, may result in loss of user privileges, suspension, or termination of employment. Civil and/or criminal penalties may also apply.

3.0 Incident Response Plan

3.1 Prevention

3.1.1 Host Security All hosts will be configured and deployed in compliance with

approved procedures. Antivirus and endpoint protection software serve as a layered measure of defense against intrusion attempts and malicious software.

3.1.2 Network Security

Network boundary devices are configured to deny all activity not expressly permitted. Internal security devices are configured to detect and defend against installation and propagation of known

8

threats.

3.1.2 User Awareness and IT TrainingAll [COMPANY] employees will receive both initial and quarterly

security training and will be accountable regarding their personal responsibility and compliance. Users will also complete and acknowledge user training as it is made available and comply with scheduled deadlines. All incidents must be reported to the the Manager, IT and Infrastructure immediately upon discovery. The system affected will in no way be used to report an incident.

3.2 Preparation

The following products should be updated and/or readily available:

Organizational chart Floor Map Phone numbers for emergency personnel IRT member roster Establish a baseline of system parameters through

frequent review of logs Network/hardware architecture drawings Forensic and analysis utilities Backup device to capture data Blank media Evidence handling supplies (Evidence storage bags/tags,

evidence tape, digital cameras) Hardware/Software warranty information Software image to restore a system Hardware spares if possible Password reset disk Backup/Restoration Plan and Procedures Credentials for all systems and who the people are that

have those credentials

3.3 Detection and Analysis

3.3.1 Attack Vectors Method or source of attack:

External/Removable Media (An attack executed from removable media)

Denial of Service and Brute-Force Attacks Web (browser hijacking, cross scripting) Email (malicious attachment/links) Impersonation (attacker uses an employee’s credentials) Improper Usage (violations of policy by company user) Loss or theft of equipment

9

3.3.2 Signs of an IncidentThe following examples point to signs that an incident may be occurring or could be occurring soon

User clicked a link or provided information in a phishing email

Link redirects to unexpected website Extreme system and/or network slowness Multiple pop up windows that can’t be closed Unknown loss of data Unable to access system resources Intrusion Detection System begins registering sharp

increase in incoming activity AntiVirus alerts that a host is infected User notices email is being automatically sent from their

email

10

11

12

Source ResponseAlerts

An Intrusion Prevention System indicates an abnormally high number of blocks or attempts to access a particular IP from multiple locations.

Look for distinct changes in the attack surface. If a particular port is being targeted, verify the port is needed or research to determine if it presents a newly discovered vulnerability. Either block the attackers IPs or mitigate the vulnerability.

The Intrusion Detection system indicates increased suspicious traffic against a host or broadcast.

Traffic within the firewall is being monitored by an Intrusion Detection System. If it alerts to broadcast traffic or attempts to make external connections to unknown IPs, the source system may be infected with malware. Verify AntiVirus clients are both updating and running scheduled scans. Check security logs for access errors.

Antivirus detects and successfully disinfects or quarantines a file.

Don’t be satisfied that AntiVirus is doing its job. Determine how malicious code entered the system and what vulnerability/weakness it was attempting to exploit.

LogsOperating system, service and application logs

Logs from operating security systems, services, and applications (particularly audit-related data) should be checked from wherever they are being captured. These logs are critical to building the puzzle on what might be an ongoing intrusion.

Network Device Logs Valuable in identifying network trends and in correlating events detected by other devices. Oftentimes DOS attacks are preceded by reconnaissance activities. If firewall logs indicate a port scan may be happening, block originating IP to thwart the attack.

Publicly Available InformationInformation on new vulnerabilities warns of potential malicious exploit

Simply being informed about new vulnerabilities and exploits can prevent some incidents from occurring and assist in detecting and analyzing new attacks.

PeopleUsers report social engineering attempts or observe someone attempting to gain physical access to a sensitive area

Notify all employees of the attempted access and remind them to report suspicious activity. Determine what the person(s) were attempting to gain access to/find information to narrow down what may be vulnerable to an attack.

Business partners report their network has been hacked or infected with malware.

External reports must be taken seriously as well. Reports of increased network activity coming to or from [COMPANY] could be an indicator. Notify employees to be particularly diligent in observing anomalous behavior and keep a close watch on network activity. Anything out of the ordinary should be quickly dealt with. Consider blocking the domain until resolved.

3.3.3 Sources of Precursors and Indicators

3.3.4 Incident Analysis

Symptom Matrix - Refer to the Symptom Matrix for possible causes

Analyze Log Activity - Determine if system changes are different than prepared baseline. Check the system logs to identify activity that is not common to the organization compared to previous log reviews. Are programs loaded that were not approved or not part of the build?

Analyze Network Activity - Determine if the network activity is unusually high when compared to the performance baseline for the organization.

Perform Log Review - When reviewing the current logs, refer back to older logs to identify trends consistent with the current incident. This may help create a profile for this attack and how long it has been occurring.

Perform Event Correlation - A firewall log may have the source IP address that was used, whereas an application log may contain a username. An Intrusion Prevention System may detect that an attack was launched against a particular host, but it may not know if the attack was successful. Alerts from host security applications may provide that information. Correlating events among multiple indicator sources can be invaluable in validating whether an incident occurred.

Use Internet Search Engines for Research - Internet search engines can help analysts find information on unusual activity. For example, an analyst may see some unusual connection attempts targeting TCP port 22912. Performing a search on the terms “TCP,” “port,” and “22912” may return some hits that contain logs of similar activity or even an explanation of the significance of the port number. Note that separate workstations should be used for research to minimize the risk to the organization from conducting these searches.

Filter the Data - There is simply not enough time to review and analyze all the indicators; at minimum the most

13

suspicious activity should be investigated. One effective strategy is to filter out categories of indicators that tend to be insignificant. Another filtering strategy is to show only the categories of indicators that are of the highest significance; however, this approach carries substantial risk because new malicious activity may not fall into one of the chosen indicator categories.

Seek Assistance from Others - Occasionally, the team will be unable to determine the full cause and nature of an incident. If the team lacks sufficient information to contain and eradicate the incident, then it should consult with internal resources (e.g., information security staff) and external resources (e.g., US-CERT, other Computer Security Incident Response Teams, contractors with incident response expertise). It is important to accurately determine the cause of each incident so that it can be fully contained, and the exploited vulnerabilities can be mitigated to prevent similar incidents from occurring.

If more than 1 incident is occurring and the root cause isn’t readily obvious, try and collect as much information as possible before proceeding to containment. Oftentimes an intruder or malicious actor will spend days observing and collecting information before any real damage is done. Try and gather as much data as possible about the incident to make an informed decision thus creating an optimal pathway in developing a strategy to deal with the root cause of the problem.

3.3.5 Incident Documentation

As mentioned in the roles and responsibilities, documentation is critical through every phase of incident handling. From incident identification to post-incident review, every decision, action, discovery, and response must be clearly documented and centrally stored in a secure location. To help with incident classification and determination, refer to the Detection and Analysis Form.

3.3.6 Incident Prioritization

Make determination based on the Severity Matrix at Attachment 1. Data and/or systems with a higher sensitivity that are most vulnerable with regard to the current incident should drive prioritization.

3.3.7 Incident Notification

14

Activate the IRT. Using the IRT roster notify each team member to meet in a room that can provide some level of privacy and security. If after hours, determine whether the whole team needs to report in or if some can provide benefit remotely. If users need to be notified right away, prepare a statement for the user representatives to notify all users. If criticality of the incident or affected systems demands an early notification to shareholders/business partners, the IRT team lead and Support Staff will assist the Executive Staff in preparing a statement to be issued to relevant parties. Executive Staff will deliver the statement to impacted business partners as soon as reasonably practicable. This statement will provide an overview of the type and severity of the incident and next steps as it relates to notifying shareholders and/or others impacted by such incident.

3.4 Containment, Eradication, and Recovery

3.4.1 Choosing a Containment StrategyDetermine an initial containment strategy that strikes a balance

between business need and containment. For instance, while it may be ideal to shut down the network to prevent further spread of a virus the implication to losing connectivity for an entire day may result in a more damaging result. Financial and operational implications must be considered in developing the containment strategy. The Executive Staff must approve the shutting down of networks, servers, or anything that impacts the customer. Containment strategy should be based on the following:

Potential damage to and theft of resources Need for evidence preservation Service availability (e.g., network connectivity, services

provided to external customers) Time and resources needed to implement the strategy Effectiveness of the strategy (e.g., partial containment, full containment) Duration of the solution (e.g., emergency workaround to

be removed in four hours, temporary workaround to be removed in two weeks, permanent solution).

Determine Cost – Outage cost/benefit analysis of each system

Consider using the Containment, Eradication and Recovery Form to document this phase.

3.4.2 Evidence Gathering and HandlingEvidence Gathering and Handling is an important activity but

may not be required in every circumstance. [COMPANY] currently has a vendor relationship with Dell SecureWorks. The

15

recommendation is to contract Dell SecureWorks to perform Containment, Eradication and Recovery for incidents that fall outside [COMPANY] CSIRT capabilities as determined by the team lead. The following lists remedial steps that can be taken to secure hardware and capture data by [COMPANY] employees.

According to the NIST 800-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 organization’s 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.” (National Institute of Standards andTechnology, 2006)

Use the Chain of Custody Form to capture all relevant information as specified above.

It is important to secure the perimeter around a computer and limit access to authorized personnel during the collection process to ensure that the evidence is not altered. Record the time and date the incident responder entered the scene, the floor plan of the scene documenting the location of devices and surrounding objects, personnel present in the scene, photographs of the scene to include all digital evidence in its original place. All digital evidence must be secured ensuring that no unauthorized individuals interact with the collected information. Disconnect network cables and/or disable Wi-Fi to remove the item from the network only after all data has been captured and only after written approval from Executive Staff. If devices can be segregated from the main network into an isolated network that should be considered first before premature disconnect. Some malicious software incorporates a “keep alive” ping to other hosts. If they are not able to ping other hosts the malicious software will begin encrypting or deleting the data on the system.

3.4.2.1 Sources of Data - A critical step in evidence gathering

16

is to identify potential sources of data. Consider the systems impacted may be broader than the ones reflecting signs of intrusion/malicious software. Removable media on affected systems will also be collected. When acquiring data, the analyst should create a plan that prioritizes sources. Use the Evidence Gathering Form as a guide. The following are important factors for prioritizing data:

Likely Value – Based on experience and previous knowledge the analyst should be able to at least estimate the relative likely value of each potential source.

Volatility – This should be given priority over the gathering of non-volatile data. Volatile data should be collected in the following order:

1. Network connections2. Login sessions3. Contents of memory4. Running processes5. Open files6. Network configuration7. Operating system time (National Institute of Standards

and Technology, 2006) Amount of Effort Required – This can vary widely. Resources

and manpower available should help make a prioritization determination. Acquiring system logs would require much less effort than acquiring data from an ISP.

Now it is time to acquire the data. This involves collecting the data through security tools, analysis tools, and/or forensic tools to collect volatile/non-volatile data. The data must be copied in a manner that verifies the integrity of the file after copying. Tools are available on the forensic toolkit-DVD/Thumb drive to perform data validation should you choose to use them. Analysts should examine copies of files, not the originals.

3.4.3 Identifying the Attacking HostsIt may be feasible or necessary to identify the attacking host(s).

Although consideration should be given to the resources and time commitment that may require. Containment, eradication, and recovery should be priority as identifying an attacking host can be time-consuming and potentially provide little information. It can also take away from the primary goal of limiting the scope of the incident and recovering resources. The best practice here is to do a simple search of the source IP on any open threat exchange website which will provide information about the IP such as whether it is a known malicious host. The IP may be part of a known blacklist of IPs that should always be blocked. In this case source IP should be blocked on the network incoming and outgoing. Network and security devices

17

active on the network should be analyzed for volume of activity to determine the scope of the attack.

3.4.4 Eradication and RecoveryOnce contained, eradication may be necessary to remove

components of the incident. This can range anywhere from blocking an IP, disabling a user account, deleting malware, to a variety of possibilities based on the incident. It is important to identify all infected hosts to be remediated. This step removes every remnant of the attack to prevent recurrence post-incident. In some instances, eradication is performed during recovery or not required.

Recovery involves restoring systems to normal operation, confirm the systems are functioning properly and remove vulnerabilities if applicable. This step involves reformatting systems, restoring from backup, replacing files, installing patches, changing passwords, and tightening firewalls and access control lists. (National Institute ofStandards and Technology, 2006)

Eradication and recovery should be done in a well-planned phased approach that restores critical systems as quickly and safely as possible without opening the door to further risk. There may be large-scale incidents that take much longer to recover from that affect policy, configuration, or network changes.

3.5 Post-Incident Activity

3.5.1 Lessons LearnedThis step is often overlooked but is equally as important as

every other phase of incident response. Without learning from each incident, the company makes itself vulnerable to repeating inefficiencies and/or missing critical opportunities for improvement. This is the final phase of incident response and officially closes out the process. The following should be covered:

Review of the how, what, when, where of the incident Timeline of the incident

o Elapsed time from beginning of the incident to discovery and through each phase of the process if available

o Time it took for an IRT member to respond to the initial report of the incident

o How long it took to report the incident to management and external entities if necessary

How did each team member perform in dealing with the incident?

18

Were procedures followed? Are there procedural improvements to be considered?

What steps inhibited the recovery? Is there anything that would be done differently the next

time to improve the process? Did any corrective actions come out of this incident that

could prevent recurrence? What should the company watch out for in the future to

identify an incident like this earlier? Are additional tools or resources needed to detect,

analyze, and mitigate future incidents? Did the incident cause damage before it was detected?

Why or why not? How effectively was the incident logged and identified? Is remedial or additional training needed for our

users/team members? Is this a recurrence of a previous incident? Was there monetary damage to [COMPANY] or its

shareholders? How did the initial impact assessment compare to the

actual impact? Was communication adequate?

Ensure everyone coming to the meeting understands the intent and comes prepared with information that will benefit the discussion. In other words, every member that has collected input or been a part of the process in any way should have detailed input about these topics to contribute. Not every question above can be answered within the context of a single meeting, but should be addressed as soon as the information becomes available to adequately evaluate performance.

3.5.2 Using collected Incident Data3.5.2.1 Number of Incidents HandledAs incidents increase an effective practice is to evaluate the

frequency and types that have occurred to determine effectiveness of policies and plans. This may also prompt for stronger background checks on employees or stronger network security controls.

3.5.2.2 Time Per IncidentAs recorded after each incident, a profile of time required to

overcome different types of incidents will become clearer comparatively.

3.5.2.3 Objective Assessment of Each IncidentBased on aggregated answers from previous incidents,

determine how effective historically the IRP has been to minimize or mitigate those incidents. This will help in identifying patterns that

19

have carried over from one incident to another where a single post-incident evaluation may be insufficient in highlighting useful information on its own.

3.5.3 Evidence RetentionData from all incidents will be retained for a period not less than

180 days. In the event collected data bears legal significance, it will be retained until the termination of legal proceedings.

4.0 Incident Response Procedures

The below checklist provides a general overview of steps to be completed. It does not include or require every step in every incident but should be used as a guide.

20

4.1 Incident Handling Checklist

Incident Handling ChecklistAction Complet

edDetection and Analysis

3.3.13.3.2

Identify method or source of attack/signs of an incident

3.3.3 Investigate sources of precursors and indicators

3.3.4 Perform incident analysis

3.3.5 Document list of systems affected

3.3.6 Determine severity based on Severity Matrix

3.3.7Using the Major Incident Report, brief the incident to Executive staff, internal personnel, and report the incident on https://dibnet.dod.mil/ within 72 hours of incident discovery

Containment, Eradication, and Recovery3.4.1 Choose containment strategy

3.4.2 Acquire, preserve, secure, and document evidence using the Chain of Custody and Evidence Gathering forms

The following steps can be completed using the Containment, Eradication and Recovery form.

Contain the incident

3.4.4 Eradicate the incident

Identify and mitigate all vulnerabilities that were exploited

Remove malware, inappropriate materials, and other components

If more affected hosts are discovered (e.g., new malware infections), repeat the Detection and Analysis steps to identify all other affected hosts, then contain and eradicate the new incidents

Recover from the incident

21

Return affected systems to an operationally ready state

Confirm that the affected systems are functioning normally

If necessary, implement additional monitoring for related activity

Post-Incident Activity

3.5.1Using the Lessons Learned form, hold a lessons learned meeting (mandatory for major incidents, optional otherwise)

Create Follow-Up Report

5.0 Attachments/Forms/Checklists

22

Computer Security Incident Reporting Form

Note: To formally report an incident, first call [IT/Security Manager] at (xxx) xxx-xxxx

Print, complete form, and hand-carry to [IT/Security Manager]

1. Name of person reporting incident: ________________________________________

Division: ________________________ Phone #: ________________________

E-mail address: ___________________ Username: _______________________

Incident was detected: date)___________ time)___________

Incident was reported: date)___________ time)___________

2. Please describe the incident (who, what, when, where, how, etc.): __________________

________________________________________________________________________

________________________________________________________________________3. Please describe what actions were taken, if any, prior to reporting

the incident:

________________________________________________________________________

________________________________________________________________________

4. List all systems involved or affected: _________________________________________

5. Other companies involved (if any): __________________________________________

6. Any other relevant information: ____________________________________________

23

________________________________________________________________________

________________________________________________________________________

Received by: __________________ Date/Time:

__________________

Assigned Incident ID#: CP - ________

Detection and Analysis FormIncident Handler Name:____________________ Phone#:____________________

Date/Time Date: _______________ Time: ________________Threat Name

Incident ID# CP - __________

Incident Severity

Attack Vector

Removable Media Denial of Service and Brute-Force Attacks Web (Browser hijacking, cross scripting) Email (Malicious attachment/links) Impersonation (Attacker uses an employee’s credentials) Improper Usage (Violations of policy by [COMPANY] user) Loss or theft of equipment Other: _____________________________________________ Unknown

Signs of an

Incident

What signs currently exist? Build list as new discoveries are made.

_______________________________________________________

_______________________________________________________

Incident Analysis Computer Security Incident Reporting Form

System Logs

24

Firewall Logs AntiVirus Network Monitoring SIEM Symptom Matrix Internet Researchhttps://www.us-cert.gov/ncas/alertshttps://www.f-secure.com/en/web/labs_global/threat-descriptionshttp://www.trendmicro.com/vinfo/us/threat-encyclopedia/

Systems Affected

Interior, how many? _______ Exterior, type? ______________ How many? _______ Critical Systems? ____________________________________ Core Systems? ______________________________________

Detection and Analysis Form (cont.)Notes

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

25

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

_______________________________________________________

Major Incident Report - Executive SummaryDate and Time Major Incident OccurredDate: Time: Incident ID#: CP - __________

Summary of the IncidentSummary: (Who, What, When, Where)

Root Cause:

Systems AffectedCore Systems (Email/Internet/Active Directory/Citrix)

Important Systems

26

Critical Systems

Other? How Many?

Customers/Shareholders Affected

Who?

Notification Required?

Major Incident Report - Executive Summary (cont.)

Proposed RemediationPlan to contain/eradicate incident:

Systems that must be shutdown/disconnected to contain/eradicate incident:

For how long?

Impact to [COMPANY] /customer/shareholder:

Alternative solution, if any?

27

Other considerationsLegal?

Public Image?

Federal?

Validations

______________________________________

______________________________________

[NAME]IRT Team Leader

28

Evidence/Property Chain of CustodyDescription

Incident ID#: CP - __________Item # Qty Description of Articles (For physical devices

include manufacturer, model, and serial #

Date/Time

From(Name-Org-Signature)

To(Name-Org-Signature)

Purpose of Change of Custody

_____________ _____________Date/Time

From(Name-Org-Signature)

To(Name-Org-Signature)

Purpose of Change of Custody

29

_____________ _____________Evidence/Property Chain of Custody (cont.)

Date/Time

From(Name-Org-Signature)

To(Name-Org-Signature)

Purpose of Change of Custody

_____________ _____________Date/Time

From(Name-Org-Signature)

To(Name-Org-Signature)

Purpose of Change of Custody

_____________ _____________Date/Time

From(Name-Org-Signature)

To(Name-Org-Signature)

Purpose of Change of Custody

_____________ _____________Date/Time

From(Name-Org-Signature)

To(Name-Org-Signature)

Purpose of Change of Custody

30

_____________ _____________Date/Time

From(Name-Org-Signature)

To(Name-Org-Signature)

Purpose of Change of Custody

_____________ _____________

31

Evidence Gathering

Name: ________________________________ Title: ________________________________

Email: _____________________________

Phone: ____________

Incident ID#: CP - _________

Date/Time Scene Entered: ____________________ ____________Secure the perimeter around compromised system(s)

Floor plan of the scene documenting devices and surrounding objects:

Personnel present at the scene:_________________________ _________________________ __________________________________________________ _________________________ __________________________________________________ _________________________ _________________________Photographs of the scene

Capture data (either backup or use forensic toolkit if necessary)

Non-Volatile capture sequence

1. Network Connections 2. Login sessions 3. Contents of

memory

4. Running Processes 5. Open Files 6. Network configs

7. OS system time

Methods/tools used to capture data:_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________Segment network/Disconnect network cables/disable Wi-Fi

Wrap, tag, and secure items in evidence storage bags

32

Containment, Eradication and Recovery FormIncident Handler Name:____________________ Phone#:____________________

Date/Time Date: _______________ Time: ________________

Threat Name:

Incident ID# CP - ___________

Containment Strategy

Proposed solution:

Estimated time to completion:

Will evidence need to be preserved?

Systems/Services/networks to be shutdown: For how long?

Estimated cost/impact to customer:

Duration of the Solution:

Containment Log _____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

33

_____________________________________________________________

Eradication steps

Identify and mitigate all vulnerabilities

Remove malware, inappropriate materials, other components

Eradication Log

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

Recovery steps

Return affected systems to an operationally ready state

Confirm all systems functioning normally Implement additional monitoring to look for related activity

Recovery Log

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

_____________________________________________________________

34

35

Lessons Learned FormThreat Name:

Incident ID#

CP - _________

Date: __________Time: __________

IRT Members

who participate

d

Name: _______________________ IRT Role: _______________________Name: _______________________ IRT Role: _______________________Name: _______________________ IRT Role: _______________________Name: _______________________ IRT Role: _______________________Name: _______________________ IRT Role: _______________________Name: _______________________ IRT Role: _______________________Name: _______________________ IRT Role: _______________________

Review of the how, what, when, where of the incident

____________________________________________________________________________________________

____________________________________________________________________________________________

____________________________________________________________________________________________

Timeline of the incident – total time from discovery to completion:

____________________________________________________________________________________________

Time it took for an IRT member to respond to the initial report of the incident

____________________________________________________________________________________________

How long it took to report the incident to management and external entities if necessary

36

____________________________________________________________________________________________

How did the team perform in dealing with the incident?

____________________________________________________________________________________________

____________________________________________________________________________________________

Lessons Learned Form (cont.)Were procedures followed? Are there procedural improvements to be considered?

____________________________________________________________________________________________

____________________________________________________________________________________________

What steps inhibited the recovery?

____________________________________________________________________________________________

____________________________________________________________________________________________

Is there anything that would be done differently the next time to improve the process?

____________________________________________________________________________________________

____________________________________________________________________________________________

Did any corrective actions come out of this incident that could prevent recurrence?

____________________________________________________________________________________________

____________________________________________________________________________________________

What should the company watch out for in the future to identify an incident like this earlier?

____________________________________________________________________________________________

37

____________________________________________________________________________________________

Are additional tools or resources needed to detect, analyze, and mitigate future incidents?

____________________________________________________________________________________________

Did the incident cause damage before it was detected? Why or why not?

____________________________________________________________________________________________

____________________________________________________________________________________________

Lessons Learned Form (cont.)How effectively was the incident logged and identified?

____________________________________________________________________________________________

Is remedial or additional training needed for our users/team members?

____________________________________________________________________________________________

Is this a recurrence of a previous incident?

____________________________________________________________________________________________

Was there monetary damage to [COMPANY] or its shareholders?

____________________________________________________________________________________________

____________________________________________________________________________________________

How did the initial impact assessment compare to the actual impact?

____________________________________________________________________________________________

Was communication adequate?

____________________________________________________________________________________________

38

____________________________________________________________________________________________

Notes

____________________________________________________________________________________________

____________________________________________________________________________________________

____________________________________________________________________________________________

____________________________________________________________________________________________

39

Attachment 1 Severity Matrix

ddddddPlandf

40

Category Incident Severity 3Low

Severity 2Medium

Severity 1High

Virus/Malware 1 or more Ext 1 Int but quarantined

Quarantined on: Less than 10% Int

Any successful attempt on: Core service Critical system More than 1 Int

Hacking/Malicious Activity 1 or more Ext Int but stopped by

IPS/AV

Stopped on: Less than 10% Int

Any successful attempt on: Core service Critical system More than 1 Int

Phishing Unsuccessful Immediately contained Unreported Not immediately contained

Systems Impacted 1 or more Ext Less than 10% Int Core Service Critical System More than 10% Int

Data Loss/Compromise User data on 1 Int or Ext/recoverable

User data on less than 10% Int or Ext

Loss of company data

High/High/High Privacy Act HIPAA Secondary system

AD Loss/Theft any system Loss Shareholder Data

Key:IPS – Intrusion Prevention ServiceAV – AntivirusAD – Active Directory

Attachment 1 (Cont.)

ddddddPlandf

SEVERITY RESPONSESeverity Response

Severity 3 Minimal response necessary. Incidents should be documented for future analysis. Cause should be determined to prevent recurrence. User remedial training should be considered.

Severity 2 Same as Severity 3, but with increased monitoring and data analysis. Run full system scan of security tools. Review security and network logs. Activate IRT only if further review reveals more widespread impact than originally thought.

Severity 1 Activating IRT may be required. Isolate affected systems at a minimum and propose shutdowns of a greater scope to prevent spread. Make notifications to potentially impacted customers. May also have to include emergency services and/or federal agencies depending on the incident.

SYSTEMSAbbreviation CIA Definition

Int High-Mod-Mod Internal networked systems not including core service or critical systemsExt Mod-Low-Low External systems accessing internal resources (laptops, cell phones, PCs, etc)Core Service High-High-High Critical Systems High-High-High Secondary Systems High-High-High

41

Attachment 2Symptom Matrix

Indication

Malware Type Attacker Tool Type

Mul

tipar

tite

Viru

s

Mac

ro V

irus

Net

Ser

vice

Wor

m

Mas

s Mai

ling

Wor

m

Troj

an H

orse

Mal

icio

us M

obile

C

ode

Bac

kdoo

r

Key

stro

ke L

ogge

r

Roo

tkit

Mal

icio

us B

row

ser

Plug

_Ins

Emai

l Gen

erat

ors

Security Tools Antivirus software alerts Spyware detection and removal utility alerts Network-based intrusion prevention alerts Host-based intrusion detection alerts for changes to files Firewall and router log entries Observed Host Activity System cannot boot Error message displayed during system boot System instability and crashes occur Programs start slowly, run slowly, or do not run at all Unknown processes are run at system startup Unusual and unexpected ports open Sudden increase occurs in the number of e-mails being sent and received Changes are made in templates for word processing documents, spreadsheets, etc. Web browser configuration is changed, such as different home page and new toolbars Files are deleted, corrupted, or inaccessible Unusual items appear on the screen, such as odd messages, graphics, and overlapping or overlaid message boxes Unexpected dialog boxes appear, requesting permission to do something Observed Network Activity Significantly increased network usage Port scans and failed connection attempts targeted at the vulnerable service (e.g., open Windows shares, HTTP) Network connections between the host and unknown remote systems

GUIDE TO MALWARE INCIDENT PREVENTION AND HANDLING (National Institute of Standards and Technology, 2005) Reflect the Indication meets the malware or attack type

ddddddPlandf

42

ddddddPlandf

43

6.0 Contacts

IRT RosterIRT Role Name Phone Email

Executive StaffExecutive StaffTeam LeadTech LeadIncident RecorderUser RepUser RepUser RepUser RepLegalPublic RelationsHuman RelationsSecurity Consultant

Shawn Walker 937-751-4047

Shawn.walker@secdefllc.com

Security Consultant

Shawn Waldman 937-802-7521

Shawn.waldman@secdefllc.com

Emergency ResponseFire and RescueAdministrative number – County Dispatch - or 911

Police Services DepartmentAdministrative number – County Dispatch – or 911

Works Cited

National Institute of Standards and Technology. (2006). Guide to Integrating Forensic Techniques into Incident Response. Computer Security Division. Gaithersburg: US Department of Commerce.

National Insittute of Standards and Technology. (2004). Standards for Security Categorization of Federal Information and Information Systems. Information Technology Laboratory. Gaithersburg: US Department of Commerce.

National Institute of Standards and Technology. (2012). Computer Security Incident Handling Guide. Information Technology laboratory. US Department of Commerce.

National Institute of Standards and Technology. (2005). Guide to Malware Incident Prevention and Handling. Computer Security Division. Gaithersburg: US Department of Commerce.