Introduction

Computer systems and technology are inseparable parts of corporate landscapes not just within organizations but also while connecting with the outside world through suppliers, customers, business partners and the internet. Data compromise at such times will spell devastation for your organization.

What is a security incident?

A security incident includes an event related to information systems that involves violation of a law or an organizational security policy, an event that causes significant disruption to the confidentiality, integrity or availability to information assets or any event that negatively impacts employees, customers, business partners or stockholders.

What is incident response planning?

Incident response is an expedited reaction to a security incident. An incident response plan is a plan that allows you to function appropriately during an incident so that you can resolve issues, contain the incident, and get running. Incident response planning should be a part of every organization’s contingency planning program. In the face of a security incident, proper planning can avoid bad publicity and focus media attention on the quick response time of the organization in dealing with the security incident.

An incident response plan contains policies and procedures for handling a security incident by laying down objectives and steps to be followed while ensuring that the critical business processes work uninterrupted. A periodic assessment of the organization’s IT inventory, system requirements, policies and procedures is necessary as systems undergo frequent change to support ever-changing business needs. New IT assets must be documented and contingency measures revised if required. Certain items, such as contact lists might require more frequent reviews. In order to be effective, an incident response plan thus needs to be frequently reviewed and updated.

Incident Response Team

Incidence response planning is done by the Incidence Response Team (IRT). An IRT always needs to be well-prepared for any kind of incident. A well-oiled IRT will enable a much better chance of minimizing any potential damage. An IRT is also involved in determining incident trends that can help increase the understanding of how incidents relevant to the organization can be better responded to in the future. Investing in a good IRT proves cost-effective considering the direct and indirect costs organizations would have to incur in case of leakage or destruction of sensitive information, such as loss of reputation, interruption in the critical business cycles, etc.

To be effective, an IRT needs to have a mission: a set of objectives to focus on at all times so that the team members don’t lose track of what they have set out to achieve. There needs to be a single point of contact in the team who communicates with the organization, the team and any external entities. The team members, apart from being highly technical need to be fully aware of the critical business functions of the organization to serve the best interests of the organization.

The team can have a team in-house or it can contract with an outside IRT. Contracting would be beneficial in terms of special expertise, as security incidents are becoming increasingly complex, and also in terms of productivity as contracted teams would work only when required as against employees who would be waiting around even when there are no incidents.

Incident Response Policies and Procedures

Policies should be formulated before forming an IRT so that the members of the IRT have a known path to tread on when they assume incident response responsibilities. The policies should be designed along the lines of the overall organizational security policy and the documented policy should find place in the organizational security policy handbook.

It is wise to have an operational guide containing staff information with names of contacts, phone numbers, fax numbers, procedures for sending and receiving information to the organization, information related to incident reports like the types of reports and content, procedures for information handling including information logging and incident summaries, configuration, administrative policies and configurations of the computer equipment, contacts with investigating agencies, procedures on dealing with media, priorities in response efforts, vendor contacts, etc.

Although the word ‘Incident Response’ suggests responding to an incident, the team also needs to be engaged in proactive prevention activities like conducting regular network security audits, checking log files, patching holes, etc. Prevention of anticipated incidents requires a lot of planning and resources in terms of finance, personnel and network. For e.g., in case a vulnerability is identified, the IRT seeks answers to the following questions:

♦ Is this vulnerability easy to reproduce?
♦ Does this vulnerability affect only this version or all versions of this software?
♦ Does this vulnerability affect versions of other vendors?
♦ Is this vulnerability being exploited time and again?
♦ What is the prior level of access required to exploit this vulnerability?
♦ Does this vulnerability grant any privileged access?
♦ Can this vulnerability be further exploited to gain privileged access?

Incident Response Methodology

The primary goals of incident response are to limit, mitigate, prevent and protect. The IRT mainly collects and analyses data related to an incident. Before that, it needs to identify and confirm the incident so that mere errors or false alarms don’t create panic in the organization.

Detection and Analysis:

The Chief Incident Response Coordinator (CIRC) is responsible for managing and coordinating incident response efforts. Incident logs should be maintained, include time stamps and be treated as evidence. The team is responsible for identifying the extent of the incident and the IT systems affected by the incident. Attempts need to be made to identify the type of the incident (e.g. network probe/scan, Virus/Worm attack, Denial of Service etc.) and the source of the incident (e.g. internal, external, third-party, etc.). If required, forensic examinations with formal procedures (chain of custody, evidence handling procedures, etc.) need to be carried out either at a host level or a network level or both. Forensic tools aid in analysis by creating bit-image copies of media, correlating events and processes, and recovering deleted files.

Containment:

Upon confirmation of incident(s) the team needs to initiate containment efforts in the form of isolation of IT system(s) and/or networked device(s). This may include methods such as manual disconnection from a network(s), logical isolation of a host, etc. In the event that the physical disconnection or logical isolation methods are not possible or not helpful, the local network to which a system or networked device is attached is isolated. Sometimes all it takes is simply unplugging one network cable to physically isolate a system. Routers and firewalls can also isolate the system. If a substantial loss of data appears imminent because of a malicious attack, the team should be prepared to completely disconnect the system from its power source.

Eradication:

As a first step in eradication, the team needs to identify and implement measures to curb the continuation and propagation of an incident. These efforts may include complete rebuilding of IT systems or networked devices that have been affected by an incident, not limited to machine/device compromise alone. Additionally, the team also needs to analyze any digital evidence, gathered from forensic efforts or otherwise, to identify the source of the incident and the cause, including the exact vulnerability that was exploited.

Recovery:

Once eradication efforts have been successfully carried out, the team needs to test the affected IT systems or networked devices for traces of the vulnerability that was identified as exploited. Once a safety confirmation is obtained, they can be reconnected to the network and restored into the operational function that they initially performed.

Post-Incident Analysis:

Finally, the team creates a detailed report on the incident and submits it to the Chief Incident Response Coordinator (CIRC). The report should include timestamps, details of each step undertaken during the incident, issues identified, changes implemented, and any further recommendations based on incident understanding. The CIRC then presents the report to senior management, who then further identify and assess the larger impact of the incident on the organization. Senior management then identify if a public statement is required to be issued based on whether the incident is likely to have after-effects that could be noticed outside the organization.

Plans need to be tested time and again by staging emergencies and measuring response times. Such tests will lead to improved plans that will foster speed and accuracy.

Sharing information with outside parties

From time to time, organizations may deal with incidents that require communication with outside parties such as regulatory agencies, law enforcement entities, media entities, Internet Service Providers (ISP), vendor(s) of software deemed as having vulnerabilities during containment/eradication efforts, etc.

Conclusion

Given enough time and resources, even the most secure and hardened system can be compromised. It will not be an exaggeration to say that the level of preparedness of an organization in dealing with a security incident will determine if it will remain in business. Incident response planning is therefore inevitable.