Incident Response Plan

profilesepola
bd_ch_10_sect_02_04.html
Home>Computer Science homework help>Incident Response Plan

Detecting Incidents

The challenge for every IR team is determining whether an event is the product of routine systems use or an actual incident. Incident classification The process of examining an adverse event or incident candidate and determining whether it constitutes an actual incident. is the process of examining an adverse event that has the potential to escalate into an incident and determining whether it constitutes an actual incident. Classifying an incident is the responsibility of the IR team. Initial reports from end users, intrusion detection systems, host- and network-based virus detection software, and systems administrators are all ways to track and detect adverse events. Careful training in the reporting of an adverse event allows end users, help desk staff, and all security personnel to relay vital information to the IR team. Once an actual incident is properly identified and classified, members of the IR team can effectively execute the corresponding procedures from the IR plan. This is the primary purpose of the first phase of IR: incident detection The identification and classification of an adverse event as an incident, accompanied by the CSIRT’s notification and the implementation of the IR reaction phase. .

A number of occurrences signal the presence of an incident. Unfortunately, these same events can result from an overloaded network, computer, or server, and some are similar to the normal operation of these information assets. Other incidents mimic the actions of a misbehaving computing system, software package, or other less serious threat. To help make incident detection more reliable, Donald Pipkin has identified three categories of incident indicators: possible, probable, and definite.*

Pipkin, D. Information Security: Protecting the Global Enterprise. Upper Saddle River, NJ: Prentice Hall PTR, 2000: 285.

Possible Indicators

The following types of incident candidates are considered possible indicators of actual incidents:

  • Presence of Unfamiliar Files—Users might discover unfamiliar files in their home directories or on their office computers. Administrators might also find unexplained files that do not seem to be in a logical location or owned by an authorized user.

  • Presence or Execution of Unknown Programs or Processes—Users or administrators might detect unfamiliar programs running, or processes executing, on office machines or network servers.

  • Unusual Consumption of Computing Resources—An example of this would be a sudden spike or fall in consumption of memory or hard disk space. Many computer operating systems, including Windows, Linux, and UNIX variants, allow users and administrators to monitor CPU and memory consumption. Most computers also have the ability to monitor hard drive space. In addition, servers maintain logs of file creation and storage.

  • Unusual System Crashes—Computer systems can crash. Older operating systems running newer programs are notorious for locking up or spontaneously rebooting whenever the operating system is unable to execute a requested process or service. You are probably familiar with systems error messages such as “Unrecoverable Application Error,” “General Protection Fault,” and the infamous Windows “Blue Screen of Death.” However, if a computer system seems to be crashing, hanging, rebooting, or freezing more frequently than usual, the cause could be an incident candidate.

Probable Indicators

The following types of incident candidates are considered probable indicators of actual incidents:

  • Activities at Unexpected Times—If traffic levels on the organization’s network exceed the measured baseline values, an incident candidate is probably present. If this activity surge occurs when few members of the organization are at work, this probability becomes much higher. Similarly, if systems are accessing drives, such as floppy and CD-ROM drives, when the end user is not using them, an incident may also be occurring.

  • Presence of New Accounts—Periodic review of user accounts can reveal an account (or accounts) that the administrator does not remember creating or that is not logged in the administrator’s journal. Even one unlogged new account is an incident candidate. An unlogged new account with root or other special privileges has an even higher probability of being an actual incident.

  • Reported Attacks—If users of the system report a suspected attack, there is a high probability that an attack has occurred, which constitutes an incident. The technical sophistication of the person making the report should be considered.

  • Notification from IDPS—If the organization has installed and correctly configured a host or network-based Intrusion Detection and Prevention System (IDPS), then notification from the IDPS indicates that an incident might be in progress. However, IDPSs are difficult to configure optimally, and even when they are, they tend to issue many false positives or false alarms. The administrator must then determine whether the notification is real or the result of a routine operation by a user or other administrator.

Definite Indicators

The following five types of incident candidates are definite indicators of an actual incident. That is, they clearly signal that an incident is in progress or has occurred. In these cases, the corresponding IR must be activated immediately.

  • Use of Dormant Accounts—Many network servers maintain default accounts, and there often exist accounts from former employees, employees on a leave of absence or sabbatical without remote access privileges, or dummy accounts set up to support system testing. If any of these accounts begins accessing system resources, querying servers, or engaging in other activities, an incident is certain to have occurred.

  • Changes to Logs—Smart systems administrators back up system logs as well as system data. As part of a routine incident scan, systems administrators can compare these logs to the online versions to determine whether they have been modified. If they have and the systems administrator cannot determine explicitly that an authorized individual modified them, an incident has occurred.

  • Presence of Hacker Tools—Network administrators sometimes use system vulnerability and network evaluation tools to scan internal computers and networks to determine what a hacker can see. These tools are also used to support research into attack profiles. All too often, however, they are used by employees, contractors, or outsiders with local network access to hack into systems. To combat this problem, many organizations explicitly prohibit the use of these tools without written permission from the CISO, making any unauthorized installation a policy violation. Most organizations that engage in penetration-testing operations require that all tools in this category be confined to specific systems, and that they not be used on the general network unless active penetration testing is under way. Finding hacker tools, or even legal security tools, in places they shouldn’t be is an indicator an incident has occurred.

  • Notifications by Partner or Peer—If a business partner or another connected organization reports an attack from your computing systems, then an incident has occurred.

  • Notification by Hacker—Some hackers enjoy taunting their victims. If an organization’s Web pages are defaced, it is an incident. If an organization receives an extortion request for money in exchange for its customers’ credit card files, an incident is in progress. Note that even if an actual attack has not occurred—for example, the hacker is just making an empty threat—the reputational risk is real and should be treated as such.

Potential Incident Results

The situations described in the following list may simply be caused by the abnormal performance of a misbehaving IT system. However, because accidental and intentional incidents both can lead to the following results, organizations should err on the side of caution and treat every adverse event as if it could evolve into an actual incident:

  • Loss of Availability—Information or information systems become unavailable.

  • Loss of Integrity—Users report corrupt data files, garbage where data should be, or data that just looks wrong.

  • Loss of Confidentiality—There is a notification of a sensitive information leak, or information that was thought to be protected has been disclosed.

  • Violation of Policy—There is a violation of organizational policies addressing information or InfoSec.

  • Violation of Law or Regulation—The law has been broken and the organization’s information assets are involved.

Listen webReader by ReadSpeaker Open/close toolbar