Free Research Paper On Computer Incident Response Plan

1.0 Introduction

Authority

This document is developed by the Central IT service team in Greiblock Credit Union (GCU) in Chicago, Illinois. The Central IT Service team is responsible for developing a framework for service standards and guidelines for minimum IT security requirements for all the banking operations and assets. This framework will be used by the central office of GCU in Chicago as well as all its branches.

Purpose and Scope

This document seeks to help GCU in mitigating the risk from computer related security breach issues by providing guidelines for an effective and efficient response to incidents. It includes policies and procedures on establishing incident response program, but the main focus of the document is laid on handling, detecting, analyzing and prioritizing computer related incidents. Central offices as well as the branches are encouraged to tailor the guidelines and solutions recommended to enhance their security requirements, but it is strongly recommended that they follow the minimum requirements at least.

Audience

This document is created for the information technology security response teams, network and system administrators, computer security staff, and chief information security officer at GCU, Chief Information Officer, system security program managers and technical support staff responsible for responding to security incidents.

Document Structure

The structure of the document is outlined below:
Section 2 discusses the need for incidence response, incident response team structure and highlights the groups who will participate in the incident handling process.
Section 3 discusses the incident handling steps with special in-depth policies and procedures in the areas of dynamic vulnerability analysis, intrusion detection, and incident response.

Section 4 examines the need for coordination and information sharing to tackle the incident response process effectively.

2.0 Computer Security Incidents Requirement Capability
An incident response team is required in GCU to bring required resources together in a collaborative and organized manner to deal with an adverse event related to security and safety breaches of GCU’s computer and information technology assets and resources. This adverse event may include unauthorized access to GCU’s systems, malicious code attack, hoaxes, general misuse of the system, and the denial of service (Horne, 2014).

Incident Response Policy Definition and Responsibilities

The first thing involved in a computer incident response plan is to identify what can be or cannot be categorized as an incident. Incidents in GCU’s are defined as

Loss of confidential data (data theft)

Compromise of data integrity ( Modification of data without authorization)
Theft of physical IT assets.
Damage of physical IT asset.
Denial of service.
Misuse of information and assets.
Infection of computer systems by unauthorized software.
Attempt at gaining unauthorized access.
Unauthorized changes to GCU’s hardware, software or IT configuration.
Unusual system behavior (Killcrece, 2014)
The purpose of the incident response team is to
Provide a central department in GCU to handle such incidents
Protect GCU’s information assets
Prevent the use of GCU’s systems in attack against other systems.
Comply with requirements.
Minimize the possibility of exposure to malicious attacks (Horne, 2014).
The objective of the GCU’s central incident response team includes
Limit immediate incident impact for employees, management partners and customers of GCU.
Determine the cause of the incident
Recover from the incident
Find out ways to avoid further exploitation of GCU’s information system.
Avoid escalations
Assess the impact and damage after the incident.
Update policies and procedures, if required.
The Organizational Structure of roles and responsibilities and authorization in GCU is centralized. The Computer System Incident Response Team (CSIRT), based out of GCU head office in Chicago, Illinois, operates centrally. This team will be the single point of contact for any incident. CSIRT will be responsible for detection, prevention and analysis of incidents across the organization and its 100 branches. This team will be 100% dedicated to the task. The team will have incident response team informer in each of the branch offices whose primary responsibility may be different, but in the case of an incident in the branches, they are fully responsible for reporting the incident at the earliest to the central team. They will help the central CSIRT team only on the basis of urgency. Unless otherwise mentioned, branch heads will act as the CSIRT point of contact for the respective branches (Horne, 2014).
Prioritization of incidents is important. In case of capacity constraints of the CSIRT team, incidents will be addressed based on the priority ratings. Higher priority incidents will be addressed first and escalated quickly than lower priority incidents. Prioritization of incidents is done based on the impact on GCU systems and on the customers (Horne, 2014). The prioritization table is as shown below:

Time spent per incident (average time per incident)

Labor time on incident
Total tie from the beginning to the end of incident
Response time for the CSIRT team
Time to report to the management (Killcrece, 2014).
Objective assessment of Logs
Adherence to incident response policies/procedures
Damage calculation procedure followed for % of incidents
Subjective assessment of each assessment
Handling an Incident
Figure 1: Incident Management Life Cycle (The U.S Department of Commerce, 2015)
The incident response entails several processes and phases. The initial phase called the preparation and training phase is the one when the system is prepared to handle most of the attacks on its own, and the organization tries to implement a set of controls that will reduce the number of incidents. Subsequent phases involve detection and analysis, contamination- eradication and recovery, and post incident activity (Killcrece, 2014).

Dynamic Vulnerability Analysis

It is important for the CSIRT team to establish controls and checks that will help prevent the attacks. In order to do that, understanding the system vulnerabilities and implementing fixed or dynamic vulnerability analysis software are important. It is highly recommended for the CSIRT to use dynamic methods so that it can get into the core of the code used by the attackers and can analyze the intrusion properly. Dynamic vulnerability analysis will collect traces from the incoming and outgoing traffic of the executed web application modules. This trace will contain a sequence of events. Dynamic vulnerability analyzer like Python Interpreter can be implemented (Philips and Swiler, 2011). Traces are saved as XML files that can then be read by the Python Analyzer as a sequence of events. Based on the controls setup by the CSIRT team, the analyzer can filter, block, contaminate and copy the information, and generate system alerts.
Configuration Files: The analyzer analyses and categorizes vulnerabilities into four types of nodes; input, critical, other, and filter. It also categorizes the data based on the following criteria:

Machine Class (workstation, router, server, printer etc.)

Hardware Type
Operating System
Users (root, normal or privileged)
Configuration – (Ports enabled/disabled, special privilege)
Type of network (Ethernet, ATM, Wi-Fi)
Physical Link – communication media
The analyzer also provides a topology and a graph of the network where the intrusion or breach has taken place or someone tried to breach the network (Philips and Swiler, 2011).
Attacker Profile: It is impossible for a dynamic vulnerability analyzer tool to actually profile a human behavior. However, an analyzer maps the attacker capability (like possession of hacking software, automated toolkit, password cracking program, physical access) depending on the method of attack. The attacker file is then kept alongside with the configuration files provided to the CSIRT team for analysis (Philips and Swiler, 2011). If any pattern of attack is found by the CSIRT, then they will put a new control in place to prevent it.
Attack Templates: Attack templates are nothing, but generic steps used in known types of attacks. This is already configured in the system by the CSIRT team, but as new ways of attacks are developed, dynamic vulnerability analysis provides information as regards whether or not the given control or attack template was used for the same kind of attack or the attacker has used a new template (Philips and Swiler, 2011). If a new template was used, then the CSIRT will document a new attack profile in its control and check procedures. Attack templates should be decided based on the following nodes:

User Level – None, guest, normal, privileged, root or administrator

Machine – server, user machine, ATM, router printer etc.
Vulnerabilities: This filed provides information as regards any change to the attack template from the existing ones. In the case of dynamic vulnerabilities, new attack templates should automatically get added to the configuration file.
Capabilities: This finds out the capabilities of the attacker. Dynamic vulnerability analysis tool will automatically update the attacker profile if a new profile is traced.
The CSIRT should implement dynamic analysis algorithm together with penetration testing for preventing and reducing the number of incidents as the dynamic application knows the web application from inside that helps in the generation of more accurate penetration test cases (Killcrece, 2014).

Dynamic Analysis softwares/hardware to be used is as follows:

Digital Forensic Workstations and backup devices – to create disk images, save relevant incident data and preserve log files.
Laptops/tablets for analyzing sniffing packets and writing reports
Spare workstations, servers etc for backup, restoration and penetration and malware testing.
Blank removal media
Portable printer for printing log files and other evidences from an isolated system
Dynamic vulnerability analyzer software
Digital forensic software to analyze disk images
Port lists
Network diagrams – soft and hard copy.
Cryptographic hashes of critical files
Current baseline and backup (Philips and Swiler, 2011).
Intrusion Detection Plan/ Policy
This policy provides procedures to establish intrusion detection to protect assets and data on the GCU network. It provides guidelines on the implementation of intrusion detection in GCU underlining the roles and responsibilities. The policy is designed to protect the GCU network from being infested by hostile software/malware or unintended use of data. The policy covers all the hosts in the network across the organization, even those systems not on the internet.

Objective: the objective of an intrusion detection policy is already discussed in the previous section.

Requirements: Below are underscored the minimum requirements that the employees and management should fulfill to facilitate the CSIRT team in the implementation of the intrusion detection plan easily:
All the systems accessible by customers from the internet or by public must use IT approved intrusion detection software (Philips and Swiler, 2011).

All individual computers of the employees should have IT approved intrusion detection software installed.

All host based and network based intrusion detection logs and systems should be checked daily by the central team, and proper action should be taken in the case of an anomaly.

All intrusion detection logs should be retained for a minimum period of 180 days.

All suspicious activity, suspected intrusion or erratic behavior by the system should be reported to the CSIRT team in Chicago within an hour.
Roles: The intrusion detection team play the following role in the whole process of monitoring, prevention and recovery process during and after an incident.

Intrusion detection team will be responsible for monitoring detection systems, hosts, networks logs on a regular basis.

The team will also be responsible for selecting and implementing detection system and software.
The team is responsible for reporting incidents to the proper stakeholders, including the management, HR, PR team, media, the government and police, if required.
The team is also responsible for acting on incidents, taking appropriate action, minimizing damage, removing any hostile software/malware and recommending and implementing changes if approved by the management (Killcrece, 2014).

Source and Indicator Matrix

This matrix defines the source to be used to detect the type of alerts. This matrix should be used to detect intrusion and should be updated as and when new things come up.

Incident Analysis and Response

After the intrusion detection is done in accordance with the previous step, intrusion analysis starts. The following steps should be followed by the CSIRT team in Chicago.

Profiling of the Networks and Systems and identification of exact location of the problem system.

Incident prioritization: Once detected, the CSIRT should quickly prioritize the incident and act upon it based on the priority report.
Incident Analysis: Identify normal state and the deviation occurred due to the incident. Analysis of the log is also important to arrive at the final decision about the cause of the incident.
Vulnerability Analysis: Once the cause is identified, vulnerability of the system to this new incident is known. The CSIRT should suggest to the management and then implement procedures and policies so that it does not happen in the future.

Documentation: Update the policy and procedure documentation, if required.

Communication/Notification: Once the incident analysis and the future course of actions are finalized, the CSIRT should work with the HR and PR team to communicate to the users about the new changes or policy updates, if required (Killcrece, 2014).
4.0 Collaboration and Information Sharing
The threat to the computer security of the present day makes it important for organizations to collaborate in the case of an incident response. GCU should ensure effective coordination and quick response of different vendors with the CSIRT team in the event of an incident. The most important aspect of an incident response plan is collaboration and coordination in information sharing where GCU will share crucial information related to threat, attack and vulnerability with its software and hardware vendors as and when required and also derive knowledge from their experience. Incident information sharing is mostly mutually beneficial. It is often seen that the same type of attacks and threats affect multiple organizations simultaneously.

Coordination

Figure 2: Incident Collaboration Framework (The U.S Department of Commerce, 2015)
As discussed above, GCU should coordinate with other incident response teams. If GCU can form incident response coordination with other banks or credit union and financial institutions, then they will not only benefit from each other’s security process, but will gain valuable knowledge of how to tackle an intrusion or prevent new types of intrusions. Incident response team within an organization may enter into many types of coordination process. For example, GCU’s technical team may coordinate with the operational team of another company to share strategies on mitigating an intrusion that is affecting multiple organizations simultaneously. The manager of the CSIRT team should be responsible for creating coordination relationships and scope of relationships. He should define information sharing process for the three types of setup shown below:

Team to Team

Team to Coordinating team
Coordinating team to Coordinating team (U.S Department of Commerce, 2015).

Information Sharing

Ad Hoc: Most of the information sharing is done through ad hoc means like email, messaging, and phone on a need basis (Horne, 2014). This information sharing depends on the mutual relationship between two employees or individual trust on each other. This may be the most cost effective way. If enough budgets are not available, this method can be used.
Partially Automated: GCU should try to automate as much information sharing as possible once it agrees to a process with its collaboration partner (Horne, 2014). This makes the process cost effective and efficient. In reality, it is not possible to fully automate and it is not desirable also. The CSIRT team of GCU should decide what and what not to automate.

References

Killcrece, G. Kossakowski , K., Ruefle, R. and Zajicek, M. (2003). Organizational Models for Computer Security Incident Response Teams (CSIRTs). Carnegie Mellon University. Retrieved on 13th Feb, 2015 from <http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=6295>
Philips, S. and Swiler, L. (2011). Uncertain-Graph Based Method for Network Vulnerability Analysis. Journal Of Software, 22(6), 1398-1412. doi:10.3724/sp.j.1001.2011.03819.
Putukov, A. (2015). Detecting Security Vulnerabilities in Web Applications Using Dynamic Analysis with Penetration Testing. OWASP. Retrieved on 13th Feb, 2015 from <https://www.owasp.org/images/3/3e/OWASP-AppSecEU08-Petukhov.pdf>
The U.S Department of Commerce. (2015). Computer Security Incident Handling Guide. National Institute of Standards and Technology. Retrieved on 13th Feb, 2015 from <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf>
The U.S Department of Homeland Security. (2015). National Cyber Incident Response Plan. Retrieved on 13th Feb, 2015 from <http://www.federalnewsradio.com/pdfs/NCIRP_Interim_Version_September_2010.pdf>
Horne, B. (2014). On Computer Security Incident Response Teams. IEEE Secur. Privacy, 12(5), 13-15. doi:10.1109/msp.2014.96.