Computer Security Incident Response Plan (CSIRP)
Date
1.0 Introduction
2.0 Incident Response Policy
2.1 Purpose and Objectives
2.2 Scope
2.3 Computer Security Incident
2.4 Organizational structure
2.4.1 Incident Response Team (IRT) Roles and Responsibilities
2.4.1.1 Executive Staff
2.4.1.2 Team Lead
2.4.1.3 Tech Lead
2.4.1.4 Incident Recorder
2.4.1.5 User Representatives
2.4.2 Support Staff
2.4.2.1 Legal
2.4.2.2 Public Relations
2.4.2.3 Human Resources
2.5 Incident severity ratings
2.6 Enforcement
3.0 Incident Response Plan
3.1 Prevention
3.1.1 Host Security
3.1.2 Network Security
3.1.3 Malware Prevention
3.1.3 User Awareness and IT Training
3.2 Preparation
3.3 Detection and Analysis
3.3.1 Attack Vectors
3.3.2 Signs of an Incident
3.3.3 Sources of Precursors and Indicators
3.3.4 Incident Analysis
3.3.5 Incident Documentation
3.3.6 Incident Prioritization
3.3.7 Incident Notification
3.4 Containment, Eradication, and Recovery
3.4.1 Choosing a Containment Strategy
3.4.2 Evidence Gathering and Handling
3.4.2.1 Sources of Data
3.4.3 Identifying the Attacking Hosts
3.4.4 Eradication and Recovery
3.5 Post-Incident Activity
3.5.1 Lessons Learned
3.5.2 Using collected Incident Data
3.5.2.1 Number of Incidents Handled
3.5.2.2 Time Per Incident
3.5.2.3 Objective Assessment of Each Incident
3.5.3 Evidence Retention
4.0 Incident Response Procedures
4.1 Incident Handling Checklist
5.0 Attachments/Forms/Checklists
Computer Security Incident Reporting Form
Detection and Analysis Form
Major Incident Report - Executive Summary
Evidence/Property Chain of Custody
Evidence Gathering
Lessons Learned Form
Attachment 1
Attachment 2
6.0 Contacts
Works Cited
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 proceduresensuring 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 ComputerSecurity Incident
The National Institute of Standards and Technology (NIST) defines the following terms related to computer security:
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 and Technology, 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 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 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 Staff
2.4.2.1 Legal
Makes recommendation to IRTbased 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
DirectsIRT regarding evidence collection and handling
2.4.2.2 Public Relations
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.6Enforcement
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.1Prevention
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 devicesare configured to deny all activity not expressly permitted. Internal security devices are configured to detect and defend against installation and propagation of known threats.
3.1.2 User Awareness and IT Training
All [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 madeavailable 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
3.3.2 Signs of an Incident
The 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
Source / ResponseAlerts
An Intrusion Prevention Systemindicates 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.
TheIntrusion 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 AntiVirusclients 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.
Logs
Operating 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 Information
Information 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.
People
Users 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 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.