Log in / Register
Home arrow Computer Science arrow The InfoSec Handbook
< Prev   CONTENTS   Next >

Incident Response Policy, Plan, and Processes

Incident Response Policy should be put in place by management of the organization demonstrating its commitment to the Incident Response. This policy directs and provides guidance to the entire organization and provides the base for the Incident Response Plan and related processes.

Incident Response Policy

Incident Response Policy provides management direction towards Incident Response and also emphasizes the management's commitment to the same and highlights the “musts” as far as Incident Response is concerned. Incident Response Policy covers the following areas.

Purpose and Scope of the Policy

This should clearly define the purpose of incident response, namely, what the organization wants to achieve through incident response. This should also describe the scope of incident response in the organization. The scope can be the entire organization or a particular unit or a specific group of units and the type of incidents and circumstances.2

It highlights management's commitment and addresses what the management feels as mandatory to be followed with regard to incident response.

Definition of Information Security Incidents and Related Terms2

From organization to organization, the definition of information security incidents can differ. It is necessary that the organization clearly defines what it means by an incident and related terms like incident response, incident recovery, and incident response team.

Organizational Structure, Roles, Responsibilities, and Authorities

Any policy cannot be implemented effectively and efficiently unless there is a proper structure to support it in the organization. The structure should be composed of clear roles with clear responsibilities. For an incident response, many times somebody needs to act expeditiously without any bureaucratic approval cycle in order to carry out immediate containment or control activities. Therefore it is necessary that some of the roles have to be provided with authorities which may be beyond their normal authorities. An organization's structure, roles, responsibilities, and designated authorities have to be clearly defined and described so that there is no ambiguity, and that no confusing actions are taken.

All the people in the organization have to be clearly informed of the organization structure, roles, and responsibilities as the incident response has to be quick and requires coordination between various functions and personnel of the organization and cannot happen without this clarity across the organization. Otherwise, egos and organizational bureaucratic setups can create hurdles during an incident response which can delay the response significantly leading to a higher level of disruption or damage or theft. The roles, responsibilities, and authorities should provide the authority to the incident response team even to confiscate the equipment or disconnect the equipment and to monitor and investigate suspicious activities.2 This also should make it clear what and which types of communications to the outside world or to the related agencies are permitted and who is permitted to carry out the same.

Incident Response Teams constitute personnel with complementary skills, experience, and capabilities. Head of the Incident Response Team is normally vested with significant authority to make decisions at times of need to effectively contain and recover from incidents.

Ratings of Incidents

All incidents do not require the same level of attention. Some of the incidents may be localized incidents and may have a local impact. Some may be organization-wide incidents with organization-wide impact. Some incidents may impact critical business areas and others may impact non-critical business areas. Some incidents may be easy to be responded to while some others may be very complex which can be responded to only by experts. Some incidents may have high impacts and some incidents may have low impacts on the organization. In order that the organizational personnel and the incident response team do not get confused, clear guidelines have to be provided as to the severity of various types of incidents. Speed of action required to be taken and the priority depends upon the severity rating of the incident.


Any critical activity in the organization has to be measured to understand either its effectiveness or efficiency or both of these. The measurements provide us with the clear view of where we stand with respect to performance and bring out the opportunities for improvement. But, measurements to be made should be appropriate and should be defined in clear terms so that the measurements actually provide us the information as per the intended objectives of these measurements.

Incident Response Plan

The Incident Response Plan should clearly define what is considered as an incident in the organization. Second it should clearly identify the potential types of incidents the organization is exposed to based on the infrastructure of the organization, IT architecture of the organization, types of operating systems, and tools and utilities used by the organization. Third, it has to clearly describe what needs to be done if a new and unanticipated incident is faced by the organization. This may include who needs to be notified, and who will make a final call as to what needs to be done. The Incident Response Plan also has to specify external agencies or forums if any need to be informed or consulted with.

The Incident Response Plan covers the following areas.

Purpose and Scope

Purpose of the Incident Response Plan and the scope as to which type of incidents, pertaining to which location and which functions is made clear in this section.

Strategies, Goals, and Approach to Incident Response

Incident response strategies, goals, and approaches including the incident monitoring strategies, incident response strategies, strategies related to organization to effectively handle incidents including the team composition, internal and external coordination, and total or partial outsourcing of the incident response need to be clearly planned for and appropriate responsibilities are to be assigned to named personnel with appropriate backups so that there is a guarantee that in case of any incidents, they are handled effectively.

Internal and External Communication Plan

The communication for identifying the incidents, declaring the incidents, and responding to the incidents needs to be clear and should come from the persons authorized to carry out such communications. The communications should be within the defined boundaries and the communications should be appropriately worded. The clarity as to how internal communications need to be handled and how the external communications need to be restricted are to be clearly planned for.

Plan for the Incident Response Capability2

An organization requires adequate, suitable incident response capability in order to be effective and efficient in incident response. Any organization has to assess its current incident response capability in terms of availability of techniques, tools, and utilities and the resource competence including the skills to handle incidents. If it does not have the internal capability either the option to outsource or to acquire the capability through new recruitments has to be looked into. Plans to have appropriate, adequate, and suitable incident response capability have to be clearly delineated with action responsibility and target dates clearly assigned.

Measurement of Incident Response Capability and its Effectiveness

It is necessary to measure the incident response capability of the organization including that of the outsourced portion of the incident response capability. Periodic assessment of the same will close up the gaps between the expectations and the current realities. Organizations are not static. People with expertise and assigned key responsibilities may leave the organization. The same holds true for outsourced organizations.

At the time of outsourcing, the particular organization may have excellent capabilities but over a period of time it is possible that it would have lost the capability or would have had its capability reduced because of the attrition of key people. Further, the new technologies being implemented or changes to the technologies being implemented

can make the requisite incident response capability differ from what was originally planned. Further, we also need to measure the effectiveness of the implemented capability. These may be possible to be measured by the responses that have been provided to the incidents which have occurred. Similarly, it may be possible to test some of the incident response through mock scenarios and testing of the possible incidents.

It is important to consider the various types of incidents possible and how they have to be handled so that there is no ambiguity. At least processes have to be clearly defined in respect to high impact incidents. These may be based on the common attack vectors.

Integration with the Other Plans of the Organization

An organization may have other plans like Risk Management, Disaster Recovery, and Business Continuity Plans. It is necessary that all these plans are integrated in such a way that each plan complements the other plans and does not contradict the other plans.

Incident Response Processes

Incident response processes are the important elements for the success of the incident responses. Various possible incidents from virus infection to malware infection to server crashes to denial of service attacks to bomb threats to many such possible incidents have to be thoroughly planned. Where the possibility of these incidents is high, the incident responses have to be discussed and planned for by having appropriate incident response processes.

These processes have to be detailed enough with various possible scenarios and appropriate responses. These processes have to detail how these incidents are identified and analyzed. These need to be supported additionally by templates, forms, and checklists as relevant so that it is easy to implement the expectations of these incident response processes effectively.

Incident Response Teams

Incident Response Team(s) is/are an important component and highly influence the success or failure of the effectiveness and efficiency of the incident response. This team requires the knowledge, experience, and skills to ensure that the incident detection, incident containment, and incident eradication are carried out effectively and efficiently.

Incident Response Team(s) can be dedicated teams or may be “on call” teams depending upon the criticality of the business, exposure of the organization to the incidents, competence of the IT resources, and resilience of the information security infrastructure.

Incident Response Team structuring based on distribution of the Responsibilities

Incident Response Teams are normally structured based on best fit distribution of the responsibilities among various centers.

Centralized Incident Response Teams2

Centralized Incident Response Teams are usually suitable for smaller organizations with less geographical spread. In big organizations such a structure can lead to lack of effective coordination due to various reasons like cultural reasons, internal political reasons, and bureaucratic decision making.

Distributed Incident Response Teams2

Distributed Incident Response Teams are suitable for multi-business, multi-locational organizations with distributed IT infrastructure. Each of these centers or group of centers may have their own Incident Response Team. In today's world, where each center is connected to the other centers and where the same business is carried out in various geographies and where the IT infrastructure is distributed based on efficiency and competency, it is necessary to have a person or group coordinating the efforts of these various Incident Response Teams as the same incident may affect multiple locations or an incident at one center may impact the business carried out at other centers.

Hybrid Incident Response Teams

It is possible that the expertise to handle the incidents in not uniformly distributed across various locations of an organization. In such a case it is possible to constitute a Central Incident Response Team at the prime location of the organization or technological hub of the organization with Incident Response Teams at the other centers as required. Incident response for some of the smaller centers or the centers which may lack the requisite expertise may be directly taken care of by a Central Incident Response Team. In such a model, it is possible to authorize the individual Incident Response Teams at various centers to act independently in case of local incidents and keep such incidents reported

to the Central Incident Response Team. But, in case of purely local incidents the Central Incident Response Team assumes the advisory role if any support is required by the local Incident Response Teams. All the incidents which have impact across the businesses or locations or of higher impact are handled by the Central Incident Response Team. Necessary actions are directly taken by the Central Incident Response Team or as per the directions of the Central Incident Response Team by the distributed Incident Response Teams.

Incident Response Team Structuring Based on who Constitutes the Teams

The teams have to be constituted with appropriate competent resources. This depends upon the business, technology infrastructure, tools, and utilities used. If the team is not composed of competent resources it is possible that incidents may not be recognized sufficiently early or incident response may be delayed or incident response may not be effective. All organizations may not have in-house competence for effective and efficient incident response. They may have to complement internal competence with external expertise to effectively deal with incident response. Again the Incident Response Team can be constituted with full-time members or part time “on call” members. This depends upon the business criticality as well as IT infrastructure robustness, probable incidents, and IT resilience. The pros and cons of each of these structures have to be evaluated in the context of the organization and then an appropriate decision has to be made based on the well-evaluated and well-considered trade-off 3.

Fully Employee Constituted Incident Response Teams

If the organization has adequate internal competence then the Incident Response Team can be constituted internally. But, if the Incident Response Team is required to be available 24x7 and required to be deployed as it is, it is better to constitute a separate Incident Response Team with the experts specifically recruited by the organization. However, if it is enough to constitute an “on call” Incident Response Team then it is more effective to constitute the team internally with the expertise already available in-house.

Fully Outsourced Incident Response Teams

Here, the organization arranges for the entire team to be constituted by outside experts. Usually this may be through a single outsourced entity. However, it may be a group of organizations to which the outsourcing is done with complementary expertise, even though such a scenario is seen less in practice. This type of team constitution is usually found in smaller organizations for which it is difficult to internally source the requisite expertise. It is possible that such teams may have a tough time providing for effective and efficient Incident Response sometimes because of bureaucratic responses or hindrances or because of lack of effective authority delegated to them.

Hybrid Teams: Partially Constituted by Employees and Partially Constituted by Outsourced Contractors

Here, the organization constitutes its Incident Response Team with chosen internal employees and chosen outsourced contractors. This model is likely to work the best because the internal expert resources are complemented through other rare / non-available skills from the outsourced contractors. As the internal employees constitute a good portion of the team bureaucratic hindrances or lack of authority impeding effectiveness and efficiency of the incident response may not be an issue in this case.

Ensuring Effectiveness of Incident Response

As discussed earlier, incident response is not always easy for the following reasons:

• The actual incident may be the one that was not anticipated

• Key members of the incident response team and their backups may not be available when the incident actually happens

• Incident response plan is beautifully drafted but the stakeholders are not trained effectively on the plan

• Incident response teams are not staffed suitably or adequately

• Incident response plan was not updated for a long time and has become non-useful because of the changes to the infrastructure and systems over a period of time

• Incident Response Processes are outdated and are not in sync with the currently deployed technology

For effective incident response execution the following steps have become essential:


Any battle is half won before it begins if the preparations are done well. Similarly, preparation is very important to ensure the effectiveness of the incident response. Following are the important aspects of the preparation:2

• Risk assessment and identification of the risk mitigation steps to overcome the non-acceptable risks including the threats likely to lead to incidents

• Training the resources on the possible incidents and providing them the awareness and knowledge to enable them to effectively prevent the incidents, such as virus prevention programs, strong password, or encryption training

• Effective formulation of the Incident Response Team constituting suitable and appropriate structure and members with the requisite capability

• Well thought out and preventive IT infrastructure and physical security infrastructure

• Effective Incident Response Policy, Incident Response Plan, and supporting Incident Response Processes

• Validation of the Incident Response Plans and Incident Response Processes to ensure that they work when required

• Training on the execution of the Incident Response Plans

• Regular update to the Incident Response Policy, Incident Response Plan, and Incident Response Processes in tune with the changes to or at the organization

• Configuring the setup including those of tools / utilities used by the organization appropriately

Important aspects to be considered during the preparation are:2

• Internal and external contact details including those of on-call members, Incident Response Team members, and external agencies.

• Incident Reporting Mechanisms including the e-mail ids, contact phone numbers, or tools / utilities through which incidents can be reported.

• Incident Response War Room: This is the place designated for the Incident Response Team to operate. Primarily the Incident Response Team Leader directs and guides the team from here and can be contacted here. This room is provided with multiple telephone lines and other accessories to ensure effective communication in and out of this War Room.

• Incident Tracking Tool/Utility: Incidents need to be tracked including the status of the incidents and various actions taken at various places to ensure that the actions are executed as proposed. This is the incident repository which needs to be kept updated and which provides the Incident Response Team Leader to provide accurate and correct information related to incident status to internal and external stakeholders, as relevant.

• Readily available or accessible Incident Response Plan and Processes

• Secure Storage Facility: This is provided to store and preserve the evidence obtained during incident investigation.

• Mobiles or Tablets: These enable effective communication during the incident among internal and external stakeholders.

• Incident Analysis Hardware and Software such as Forensic Workstations, Backup Devices, Laptops and/or desktops, Servers, Portable Printers, Forensic Software, Digital Cameras, Video / Audio Recorders, Blank Media and other tools / utilities as relevant which help out in effectively analyzing the incidents; analyzing, collecting, and preserving the evidence.2

• Incident Analysis Resources including List of Ports, Network Diagrams / Maps, Configuration Management Database, Operating System and Database and Application related documentation.2

• Incident Mitigation Software which enables restoration and recovery of Operating Systems, Applications enabling IRT to create clean OS and application images.

Incident Detection2

Incident detection2 is the next important step. All the incidents are not possible to be anticipated. However, there are some common threads among certain groups of incidents and these are normally known as Common Attack Vectors. These Common Attack Vectors enable us to understand and use the possibility of providing more specific responses. Table 5-7 lists the Common Attack Vectors.2

Table 5-7. Common Attack Vectors2

Common Attack Vector Description

External / Removable Media An attack executed from removable media or a peripheral device—for example,

malicious code spreading onto a system from an infected USB flash drive

Attrition An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services (e.g., a DDoS intended to impair or deny access to a service or application; a brute force attack against an authentication mechanism, such as passwords, CAPTCHAS, or digital signatures)

Web An attack executed from a website or web-based application—for example, a cross-site scripting attack used to steal credentials or a redirect to a site that exploits a browser vulnerability and installs malware


Common Attack Vector Description

Email An attack executed via an email message or attachment—for example, exploit code disguised as an attached document or a link to a malicious website in the body of an email message

Impersonation An attack involving replacement of something benign with something malicious— for example, spoofing, man in the middle attacks, rogue wireless access points, and SQL injection attacks all involve impersonation

Improper Usage Any incident resulting from violation of an organization's acceptable usage

policies by an authorized user, excluding the above categories; for example, a user installs file sharing software, leading to the loss of sensitive data; or a user performs illegal activities on a system

Loss or Theft of Equipment The loss or theft of a computing device or media used by the organization, such as a laptop, smartphone, or authentication token

Other An attack that does not fit into any of the other categories

Precursors and Indicators of Incidents2

It is most difficult to understand whether the incident is occurring or has already occurred and the type, extent, and

/ or magnitude of the incident. Precursors provide an indication that there is a possibility of an incident happening, such as if there is an email or telephonic threat to the organization, a terrorist attack, or there have been failed attempts made to break into a critical system.

Indicators provide the signals that the incident is either occurring at this point of time or has already occurred, such as file checksums do not match, some data is leaked and published on a public website, somebody has already defaced the website, an increased number of files are getting corrupted day by day, or higher than normal utilization of the traffic is observed. It is possible that some of these indicators may be false positives and would have happened because of an employee's unintended mistake which was not even observed by the employee concerned or because of a wrong restoration by oversight or a wrong update. We may not have either a precursor or an indicator in case of some of the incidents, such as a new exploit of a new vulnerability just uncovered by a hacker or a misconfiguration newly exploited by an internal knowledgeable employee.

However, these precursors and indicators, when available, provide us an opportunity to speed up our responses and many times provide us the opportunity to either stop an incident from happening or reduce the impact of the incident.

Sources of Precursors and Indicators

Some of the sources of the precursors and indicators are described in Table 5-8.2

Table 5-8. Common Sources of Precursors and Indicators2

Source Description


IDPSs IDPS products identify suspicious events and record pertinent data regarding them, including the date and time the attack was detected, the type of attack, the source and destination IP addresses, and the username (if applicable

and known). Most IDPS products use attack signatures to identify malicious activity; the signatures must be kept up to date so that the newest attacks can be detected. IDPS software often produces false positives—alerts that indicate malicious activity is occurring, when in fact there has been none. Analysts should manually validate IDPS alerts either by closely reviewing the recorded supporting data or by getting related data from other sources.

SIEMs Security Information and Event Management (SIEM) products are similar to IDPS products, but they generate alerts based on analysis of log data

(see below).

Antivirus and antispam software Antivirus software detects various forms of malware, generates alerts, and

prevents the malware from infecting hosts. Current antivirus products are effective at stopping many instances of malware if their signatures are kept up to date. Antispam software is used to detect spam and prevent it from reaching users' mailboxes. Spam may contain malware, phishing attacks, and

other malicious content, so alerts from antispam software may indicate attack attempts.

File integrity checking software File integrity checking software can detect changes made to important files

during incidents. It uses a hashing algorithm to obtain a cryptographic checksum for each designated file. If the file is altered and the checksum is recalculated, an extremely high probability exists that the new checksum will not match the old checksum. By regularly recalculating checksums and comparing them with previous values, changes to files can be detected.

Third-party monitoring services Third parties offer a variety of subscription-based and free monitoring

services. An example is fraud detection services that will notify an organization if its IP addresses, domain names, etc. are associated with current incident activity involving other organizations. There are also free real-time blacklists with similar information. Another example of a third-party monitoring service is a CSIRC notification list; these lists are often available only to other incident response teams.


Operating system, service and application logs

Logs from operating systems, services, and applications (particularly auditrelated data) are frequently of great value when an incident occurs, such as recording which accounts were accessed and what actions were performed. Organizations should require a baseline level of logging on all systems and a higher baseline level on critical systems. Logs can be used for analysis by correlating event information. Depending on the event information, an alert can be generated to indicate an incident.


Table 5-8. (continued)

Source Description

Network device logs Logs from network devices such as firewalls and routers are not typically a primary source of precursors or indicators. Although these devices are usually configured to log blocked connection attempts, they provide little information about the nature of the activity. Still, they can be valuable in identifying network trends and in correlating events detected by other devices.

Network flows A network flow is a particular communication session occurring between hosts. Routers and other networking devices can provide network flow information, which can be used to find anomalous network activity caused by malware, data exfiltration, and other malicious acts. There are many standards for flow data formats, including NetFlow, sFlow, and IPFIX.

Publicly Available Information

Information on new vulnerabilities and exploits


People from within the organization

Keeping up with new vulnerabilities and exploits can prevent some incidents from occurring and assist in detecting and analyzing new attacks. The National Vulnerability Database (NVD) contains information on vulnerabilities.

Organizations such as US-CERT33 and CERT®/CC periodically provide threat update information through briefings, web postings, and mailing lists.

Users, system administrators, network administrators, security staff, and others from within the organization may report signs of incidents. It is important

to validate all such reports. One approach is to ask people who provide such information how confident they are of the accuracy of the information.

Recording this estimate along with the information provided can help considerably during incident analysis, particularly when conflicting data is discovered.

People from other organizations Reports of incidents that originate externally should be taken seriously. For

example, the organization might be contacted by a party claiming a system at the organization is attacking its systems. External users may also report other indicators, such as a defaced web page or an unavailable service. Other incident response teams also may report incidents. It is important to have mechanisms in place for external parties to report indicators and for trained staff to monitor those mechanisms carefully; this may be as simple as setting

up a phone number and e-mail address, configured to forward messages to the help desk.

Analysis of the Incidents:2

As discussed earlier, all the indicators at all times may not provide accurate information and may lead to false positives. Hence, the mere presence of an indicator is not sufficient to presume that an incident has occurred or is occurring. A suspected incident has to be analyzed based on the indicators and other related information and then the analysis has to be confirmed. At the same time, it is necessary to understand the cause of the incident (may be an intentional attack, may be a misconfigured system, may be an employee mistake, may be unintentional violation of a policy impacting the system, etc.) to effectively deal with the incident. Many a time, experts may have to be involved in the analysis of the incidents to understand the correct causes and to arrive at effective solutions. Sometimes it may be too late to do anything as the confidential information is already released to the public. Sometimes only partial containment is possible. However, corrective action should be identified to either remove the possibility of such an incident happening or the possibility of root cause(s) from happening.

Table 5-9 details actions that may help in simplifying incident analysis, or making incident analysis relatively easy.2

Table 5-9. Actions that may help in analyzing incidents effectively.2

Action Description

Profiling of Networks and Systems Profiling is measuring the characteristics of expected activity so that changes

to it can be more easily identified. Changes possibly indicate an incident even though sometimes these may be false positives.

Understanding Normal Behaviors Study of networks, systems, and applications to understand their normal

behavior will provide us sufficient clues to understand and identify abnormal behavior.

Creating a Log Retention Policy Log information is critical information. This will provide leads into possible

threads from earlier activities like reconnaissance activities. Having the logs for sufficient lengths of time ensures that there is a traceability to the thread of related activities as some of the incidents may be uncovered after substantial time of its occurrence.

Performing Event Correlation Events can be correlated from different sources of information e.g. firewall logs

to server logs to the application logs.

Clock Synchronization Clock synchronization across all the physical and logical systems ensures that

the incidents and evidences can be correlated easily. This provides adequate strength to the evidence collected from the legal stand point.

Maintaining and Using a Knowledge Base

Using Internet Search Engines for Research

This knowledge base acts as a quick reference source for the incident handlers. It should be easily searchable database. This knowledge base needs to be maintained updated with changes to the same in tune with the changes to the organizational scenario.

In today's world, Internet acts as a very important source of quick reference and useful information. We should be careful to ensure that the information is authentic, useful and relevant in the context of the incident faced by us.

Using tools / utilities as relevant Use utilities like packet sniffers as relevant to collect more data to provide

adequate information on the incident so that the action to be taken can be understood clearly.

Filtering the data Various tools and utilities like SIEM, IDPSs etc. collect huge amount of data.

It is not possible to go through each of these data. Data need to be filtered suitably and appropriately to identify possible patterns and possible indicators.

Seeking assistance from others Various governmental and non-governmental sources can provide us

information as to the current incident scenarios which may be applicable to us also. Keeping in touch with other Incident Response Teams from other companies or governmental and non-governmental agencies / forums can provide us crucial inputs on recognizing the incidents as well as analyzing the

incidents effectively. However, caution should be exercised as to when we need to share the information.

Incident Impact Analysis and Prioritization of the Actions2

An incident may have impact on the functional aspects or on the CIA (Confidentiality, Integrity, and Availability) aspect of information security or both on the functional aspects as well as the CIA aspect of information security. Higher the impact, higher shall be the prioritization related to the actions to contain or to recover from them.

Recoverability effort is also one of the important aspects which drive the prioritization of the actions. It is possible to recover from some of the incidents very easily with low effort, such as an isolated breach of one of the non-critical servers. It may be very difficult to recover from some of the other incidents and it may take weeks to recover e.g. a major security glitch in the application which is deployed across multiple systems in the organization. Further, in some cases if the information is already compromised, such as confidential information stolen already made public, there is no way you can recover from the situation for that particular instance.

Incident Documentation and Incident Notification2

Complete details of the incidents have to be captured including the analysis details, causes identified, containment actions identified and taken, and corrective actions identified and taken. These details can be tracked through an online system wherein the incident handlers need to update the details as they proceed with the analysis and take appropriate actions. It is important to document online or through paper based records various information related to the incidents. These not only come in handy later come in the evidence to be produced before legal authorities but also as future knowledge base as to what were the indicators, what were the analysis details, what were the causes, what actions were identified, which actions worked and which did not, whether the containment was effective, and

if so to what extent, what was the magnitude or impact of the incident, whether the recovery actions worked or not, etc. These are crucial knowledge from the future perspective. Hence, the documentation cannot be ignored. Similarly, updating the status of the incident regularly on the online system should not be forgotten as the Incident Response Team Leaders as well as other key stakeholders like CIO, Chief Information Security Officer, or Owner of the data or system compromised, may be reviewing the status online or Incident Response Team Leaders may use the status for internal and external communication. Any wrong communication gives the wrong impression about the organization.

All the relevant and identified stakeholders (i.e., internal as well as external), depending upon the incident and corresponding incident response plans and processes, have to be communicated with regularly on the incident and its status. Typical stakeholders for the incident reporting are Chief Information Security Officer, Chief Information Officer, Business / Data / System Owner, Other internal and external Incident Response Teams, Human Resources (in case of breaches by employees), Public Affairs department (incidents of public concern where the status need

to be informed to the public or where the incident attracts adverse publicity), Legal Department (where there are legal implications of the incident or where the incident has to be dealt with legally), and other governmental agencies / departments as relevant.

Incident Containment, Eradication, and Recovery2

Incident containment is very important to limit the impact on the business. The containment actions may be disconnecting or isolating the infected system from the network so that it does not infect other systems. Subsequent to the containment or in conjunction with the containment eradication of the cause(s) of the incident has to be done by identifying appropriate corrective actions. If mistake proofing of the systems is possible, like reconfiguring the system and thus avoiding recurrence of the same incidents in the future, the mistake proofing has to be attempted. However, you may have to weigh the costs of actions against the benefits from the actions and the residual risks. Further, recovery has to be attempted to ensure that the systems are restored effectively to their original positions at the time of the incident, such as if the data integrity is impacted because of the incident, then the data has to be restored to the accurate data by either nullifying the impact of the incident or to the last known state of data with the integrity intact and further transactions have to be re-applied. If the availability of the data is impacted the system has to be restored so that the legitimate users can access the same, such as after a DDoS the access to the server / system is restored

to the legitimate users. In case of impact on confidentiality, possible eradication may be removal of the published data from those sites which had published the same (possibly nothing much could be done if somebody had already copied the data from there). All of the three aspects are important to ensure the effectiveness of the incident response.

Containment Strategy2

Early containment is important to the success of effective Incident Response. Containment reduces the actual damage or inhibits the resources from being exhausted, such as delinking an infected machine limits the spread of infection

to other machines or diverting the attacking traffic to a sandbox, which avoids a denial of service attack. Containment strategy shall be spelt out clearly so that the incident handlers do not get confused but have absolute clarity on what prioritizes the containment. Sometimes it may be dangerous to carry out the containment if the containment action may make malicious software to act differently or severely. Hence, containment action should be well thought out by the experts. Some of the criteria for containment strategy are:

• Possible damage if the containment action is not carried out

• Whether the damage is likely to be increased if the containment is not carried out

• Services assured to the customers

• Time and resources needed to implement the containment strategy

• Type of the containment solution (temporary, permanent, etc.)

• Likely effectiveness of the containment strategy

• Evidence preservation requirement (NIST's SP 800-61 Rev 2)

The containment strategy should be kicked in as early as possible if the damage is likely to escalate because of further compromises possible or is likely to spread significantly impacting other business areas. However, the downsides of a containment action, if any, have to be understood before applying the containment actions.

Evidence Gathering and Handling2

Evidence needs to be gathered from two perspectives: first to understand how the attack is happening and where the attack is happening, second is to capture and preserve the evidence if legal ramifications are there or a legal battle has to be waged against the incident subsequently. If the evidence has to be used for legal purposes, then the evidence has to be collected as per the legal requirements, according to the prior consultation and understanding from the legal experts. It is also necessary to document how and when the evidence was collected and how it is preserved, how it is protected. A chain of custody for the evidence with clearly documented handover should be preserved. It is also necessary to take a snapshot of evidence as early as possible before application of any containment action so that the evidence is of value during the legal proceedings.

Eradication and Recovery2

Eradication is carried out as soon as possible. Eradication is getting rid of the vulnerabilities exploited or infection, such as a virus that infected being deleted, the misconfiguration of the system which was exploited is corrected, the defect in the application which was exploited is fixed, the operating system weakness which was exploited is appropriately patched, and changing the compromised passwords. Understanding the cause(s) of the incident is very important to do effectively.

Recovery is restoring the system back to normalcy, that is, undoing the adverse effects of the incident by restoring back the crashed operating system, correcting the integrity of the database, restoring back the correct data if the integrity of the data was impacted, or setting right the parameters altered by the incident.

Also, it may be useful to ensure from the learning of the incident that better logging, auditing, and monitoring are built into the systems so that the future detection of such incidents is easy. Effective eradication and recovery is often not easy and takes time. Some of them require infrastructural changes which may need budgeting, proper impact study, evaluation of alternative tools, and a plan for implementation of the selected tool.

Once the eradication and recovery is completed, the compromised system(s) need to be monitored to ensure that the eradication and recovery are effective. This gives the assurance that the incident is either possible to be detected easily in the future if it repeats or such incidents are possible to be prevented.

Post Incident Analysis and Activities2

Every incident and the way it was handled, provides significant learning which cannot be lost. The learnings from each incident need to be captured and analyzed so that the learning can be applied to future incidents as applicable. Also, in case legal actions are to be pursued then the evidence has to be organized and submitted to the appropriate authorities so that the legal actions can be initiated and pursued effectively.

Analysis of Learnings

Analysis of the learnings has to be carried out at least in the case of major or critical incidents. Periodic analysis meetings can be carried out in respect of collation of the learnings from other incidents. Ideally all the stakeholders who were involved in the incident detection, incident handling, and incident response should be involved in the meeting. The entire incident has to be deliberated upon and the results have to be collated:

• What had happened and when?

• Whether all the contacts could be contacted or were there issues in reaching the contacts like wrong e-mail ids or wrong / old contact numbers or the resources had already left the organization?

• Whether the incident response processes were effective or had to be modified on the fly to handle the incident effectively?

• Whether the incident handling led to any side-effects or adverse impacts and if so, what were they and how could they have been avoided?

• Was there a better way to respond to the incident than the way it was handled?

• Was there a better way to organize the response team?

• What information was needed but was not available on time?

• What learning from this incident can be applied to avoid probable similar incidents?

• What precursors and / or indicators were useful in identifying the incident and which of these will be helpful for future?

• Was the internal communication and external communication effective? Were they useful? Are there possibilities to improve upon these?

• What utilities / tools are required to better identify, prevent, analyze, or handle such incidents?

• Data related to the incident like duration of the incident, efforts spent on various phases of incident handling, types of incidents and their categorization based on various aspects like attack vectors used, external / internal attacks, etc.

Many more such questions can be asked to understand what went right, what went wrong, what could be done differently or better going ahead, and how these learnings will be useful for the future.

Use of Incident Data2

After analyzing these learnings, the improvement activities based on these learnings have to be initiated which may lead to the update of the Incident Response Plan and Incident Response Processes. Also, awareness and trainings may have to be improved based on these learnings.

Further, where legal actions have to be initiated, the details of the evidence collected have to be submitted to the legal department so that they can arrange for the legal recourse.

Data collected during the incident analysis has to be retained for a sufficiently long period for the following reasons [3]:

• Some of these may be useful at a later period of time, as some of the impacts of the incidents which are not identified now, may be identified later

• Some traces of future incidents may be found or some activities which are precursor activities for future incidents may be possible to be correlated to at a later date

Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >
Business & Finance
Computer Science
Language & Literature
Political science