ABC company incident response plan

ABC company incident response plan

1.0 Scope

This incident response plan applies to ABC Corporation (ABCC), a software company consisting of 200 workstations, a primary and backup data center housing 6 Sun Solaris servers acting as application servers, 2 Windows 2003 Servers acting as file servers and the related networking hardware. ABCC creates financial software applications for fortune 100 companies in the US and Asia. ABCC provides ASP and Help Desk services to their clients through dedicated T1 lines. The ABCC primary office and data center is located in Jersey City, NJ in a building with state of the art security and redundancy.

The plan will include ABCC response procedures to the computer security threats defined in section 2.2.

2.0 Executive Summary

2.1 Purpose

The purpose of the ABC Company Incident Response Plan is to provide ABC Company with a plan that addresses computer security incidents. The computer security incidents addressed in this plan are ones that impact the confidentiality, integrity or availability of ABC Company's data and computer resources. This plan will cover when an incident is declared, escalated and how ABC Company's incident response team members will respond.

The incident response plan is to be used simultaneously with the Disaster Recovery and Business Continuity Plans where applicable.

2.2 Types of Computer Security Incidents (Goel)

Malicious Threats

Virus - Malicious software that attaches itself to other software. Typically replicates itself to every software application.

Worm - Malicious stand alone software designed to propagate throughout a network.

Spoofing - a program masquerading as another by falsifying data and thereby gaining an illegitimate advantage

Eavesdropping - Electronic monitoring of a network to collect passwords or other data.

Spamming- over loading a system with incoming messages or other traffic to cause a system crash.

Unintentional Threats

Equipment malfunctions - hardware or software that functions abnormally or is in conflict with the intended behavior.

Human Error - inadvertent alteration or destruction of programs, data or hardware. This may also include inadvertent exposure of confidential data.

3.0 Computer Security Incident Response Team (CSIRT)

The Incident Response Team is to provide an effective and orderly response to computer security incidents defined in section 2.2. The main goal of the CSIRT is to prevent serious loss of the company's assets, profit and to protect the company's reputation by providing effective and skillful response to any unexpected event involving the company's computer information system, proprietary source code, network and database.

The CSIRT is authorized to take any necessary actions to mitigate or resolve an incident, report and document its findings to management and authorities if necessary under the direction of the Information Security Officer. (Carnagie Mellon University, 2010)

Contact information of the CSIRT can be found on the company wiki page. Incidents should be recorded in the company's PEEL (Problem Enhancements Electronic Log) database.

3.1 Roles and Responsibilities

Alf Newlin,------------------------------Provides authority to the CSIRT

Chief Information Officer (CIO)----------Approves business decisions based on input from the CSIRT.

-----------------------------------------Determines the nature and scope of the incident

-----------------------------------------Contacts members of the CSIRT

-----------------------------------------Coordinates CSIRT activity

Robert Haufe,----------------------------Provides proper training on incident handling

Information Security Officer (ISO)-------Escalates to the CIO as appropriate

-----------------------------------------Monitors progress of the investigation

-----------------------------------------Ensures evidence gathering, chain of custody, and preservation is appropriate

-----------------------------------------Prepares a written summary of the incident and corrective action taken

-----------------------------------------Analyzes network traffic for signs of denial of service, distributed denial of service, or other external attacks

-----------------------------------------Runs tracing tools such as sniffers, Transmission Control Protocol (TCP) port monitors, and event loggers

David Quinn,-----------------------------Looks for signs of a firewall breach

Network Operations-----------------------Contacts external Internet service provider for assistance in handling the incident

-----------------------------------------Takes action necessary to block traffic from suspected intruder

-----------------------------------------Coordinates activities with the Information Security Office

-----------------------------------------Documents the types of personal information that may have been breached

Paul Pollock,----------------------------Provides guidance throughout the investigation on issues relating to privacy of customer and employee personal information

Human Resources--------------------------Assists in developing appropriate communication to impacted parties

-----------------------------------------Assesses the need to change privacy policies, procedures, and/or practices as a result of the breach

-----------------------------------------Provides advice in situations involving employees

-----------------------------------------Ensures all service packs and patches are current on mission-critical computers

-----------------------------------------Ensures backups are in place for all critical systems

Sagar Mugar,-----------------------------Examines system logs of critical systems for unusual activity

System Administrator---------------------Reviews audit logs of mission-critical servers for signs of suspicious activity

-----------------------------------------Contacts the Information Technology Security Office with any information relating to a suspected breach

-----------------------------------------Collects pertinent information regarding the incident at the request of the Information Security Office

-----------------------------------------Ensures the usability of any evidence collected during an investigation if the company chooses to take legal action

Art Spellman,----------------------------Provides advice regarding liability issues in the event the incident affects

General Counsel--------------------------patients, associates of the university, employees, and the general public

-----------------------------------------Submits requests for investigations

-----------------------------------------Communicates necessary information to clients

Terri Lim,-------------------------------Monitors business applications and services for signs of attack

Client Relationship Manager--------------Preserve any evidence

-----------------------------------------Cooperate with investigative personnel during investigation if needed

4.0 Procedures

4.1 Process Flow Diagram (Haufe, 2010)

The following process flow diagram is a general guide on handling computer security incidents.

4.2 Detailed Response Procedures

First response to all incidents is to notify CSIRT immediately.

4.2.1 Virus

4.2.1.1 Detection

  • Changes in file sizes or date/time stamps
  • Computer is slow starting or slow running
  • Unexpected or frequent system failures
  • Change of system date/time
  • Low computer memory or increased bad blocks on disks

4.2.1.2 Response

  • Evaluate the situation
  • Identify infected system(s)
  • Isolate and contain infected system(s)
  • Analyze the infected system(s) using up to date standard tools - anti-virus scanners
  • Attempt to determine source of infection
  • Issue alert
  • Save the system state to preserve evidence if possible

4.2.1.3 Post Incident Tasks

  • Review security policies
  • Adjust policies as needed
  • Update security tools as needed
  • Conduct Lessons Learned
  • Close PEEL ticket

4.2.2 Worm

4.2.2.1 Detection

  • Computer is slow starting or slow running
  • Unexpected or frequent system failures

4.2.2.2 Response

  • Evaluate the situation
  • Identify infected system(s)
  • Isolate and contain infected system(s)
  • Analyze the infected system(s) using up to date standard tools
  • Attempt to determine source of infection
  • Issue alert
  • Save the system state to preserve evidence if possible

4.2.2.3 Post Incident Tasks

  • Review security policies
  • Adjust policies as needed
  • Update security tools as needed
  • Conduct Lessons Learned
  • Close PEEL ticket

4.2.3 Spoofing

4.2.3.1 Detection

  • Increased dropped packets
  • Outgoing packets that do not have the network address of the interface it is coming from
  • Monitor transaction logs of automation services, scanning for unusual behaviors
  • Correlate user identification with shift times or increased frequency of access
  • Correlate user command logs with administrator command functions

4.2.3.2 Response

  • Evaluate the situation
  • Identify compromised system(s)
  • Disconnect automation services until patched or monitor automation access points, such as network sockets, scanning for next spoof, in attempt to trace back to perpetrator
  • Change user password or use standard administrator functions to determine access point, then trace back to perpetrator
  • Attempt to determine source of attack
  • Issue alert
  • Save the system state to preserve evidence if possible

4.2.3.3 Post Incident Tasks

  • Review security policies
  • Adjust policies as needed
  • Update security tools as needed
  • Conduct Lessons Learned
  • Close PEEL ticket

4.2.4 Hacker Attack

4.2.4.1 Detection

  • Changes to directories and files
  • A displayed last time of login that was not the actual time of last login
  • Finding that someone else is logged into an individual's account from another terminal
  • Inability to login to an account (often because someone has changed the password).

4.2.4.2 Response

  • Lock attacker out of the system
  • Kill all processes started by attacker
  • Attempt to determine source of attack
  • Issue alert
  • Save the system state to preserve evidence if possible
  • Contact law enforcement

4.2.4.3 Post Incident Tasks

  • Review security policies
  • Adjust policies as needed
  • Update security tools as needed
  • Conduct Lessons Learned
  • Close PEEL ticket

4.2.5 Eavesdropping

4.2.5.1 Detection

  • Correlate user identification with shift times or increased frequency of access
  • Correlate user problem reports.
  • Monitor network performance
  • Correlate user command logs with administrator command functions

4.2.5.2 Response

  • Change user password or use standard administrator functions to determine access point
  • Trace back to perpetrator

4.2.5.3 Post Incident Tasks

  • Review security policies
  • Adjust policies as needed
  • Update security tools as needed
  • Conduct Lessons Learned
  • Close PEEL ticket

4.2.6 Spamming

4.2.6.1 Detection

  • Monitor disk partitions, network sockets, etc. for overfull conditions

4.2.6.2 Response

  • Analyze message headers to attempt trace back to perpetrator

4.2.6.3 Post Incident Tasks

  • Review security policies
  • Adjust policies as needed
  • Update security tools as needed
  • Conduct Lessons Learned
  • Close PEEL ticket

4.2.7 Equipment malfunctions

4.2.7.1 Detection

  • Hardware diagnostic systems report issues
  • Software diagnostic tools report issues

4.2.7.2 Response

  • Restore backup copies of software and data as needed
  • Initiate switch to DR site if necessary

4.2.7.3 Post Incident Tasks

  • Review security policies
  • Adjust policies as needed
  • Update security tools as needed
  • Conduct Lessons Learned
  • Close PEEL ticket

4.2.8 Human Error

4.2.8.1 Detection

  • Audit trails of system usage, especially user identification logs
  • Audit trails of system transactions

4.2.8.2 Response

  • Review audit trails of system transactions
  • Restore backup copies of software and data as needed
  • Initiate switch to DR site if necessary

4.2.8.3 Post Incident Tasks

  • Review security policies
  • Adjust policies as needed
  • Conduct retraining
  • Conduct Lessons Learned
  • Close PEEL ticket

5.0 Summary

ABC Company is the alias for my current employer. The company is actually a small one that has less than 20 employees. The company's products and services however are accurately described herein. An Information Security department does not exist. The Operations team consists of three people. The company does not currently have an incident response plan. At best the company has a Disaster Recovery site, a Business Continuity Plan and an Emergency contact waterfall document. Needless to say I believe this project serves well to provide the company with a foundation to build on in regards to having a sound incident response plan.

6.0 Works Sited

Carnagie Mellon University. (2010). CSIRT Development. Retrieved March 5, 2010, from CERT: http://www.cert.org/csirts/

Goel, S. (n.d.). UofA Center of Information Forensics and Assurance. Retrieved March 1, 2010, from University of Albany: http://www.albany.edu/~goel/classes/spring2006/itm604/resources.shtml

Haufe, R. (2010, March 5). Information Security Officer. (T. Lim, Interviewer)

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!