Incedent handling

I have been writing a report on Incifent handling for my school assignment its kinds short right now i have to submit about 10-15 pages what do you guys think i should add to it . is the format okay or doe's dos the format needs to be changed. it's bacically on detecting a incident after completing this i have to write another one on Recovering from a incident and the Post Incident Measures

What is a Incident

An incedent refers to a situation in which the occurrence of an event either damages or has the potential to damage a resource. In a computer related environment it refrs to an event that has an impact on the security of a network. an incedent can result in different consequences, such as fraud, information leakage, or destruction of network resources. An incedent can occur because of various reasons. Some of the common incedents that effect the security of the network are:

* Attack from a malicious code, such as a virus and Trojan.
* Intrusion by employee.
* Intrusion by people from outside the organization

all such incedents can be a serious threat to system and networks of an organization. althogh the actual damage caused by these incidents cannot be predicted, it can range from disrupting work on a computer to harming the computing capability of large networks.

Need for Incident Handling

in the current technological scenario, there are an incresing number of people who have the knowledge to break into a network illegaly for either $ or fun. Yhe organization that rely heavily on Internet are especially susceptible to hacking attacks. It is almost impossible to predict the number and types of hacking incedents that can occur. therefore, an organization needs to prepare itself to handle incedents with minium effort and cost. a list of reasons in support of the need for incedent handling:

• It equips the organisation with the procedure that can be followed if incidents occur
• It saves the time and effort required to fix the incident at the time when the
  organization network has been affected due to the occurrence of an incident.
• It he;ps the organization to derive lessons that helps prevent similar incedents in
  future.
• It helps an organization to assess, in advance, the skills requited and to equip the
  organization to handle all types of incidents.
• It provides the data that can be used by the organization to fix any incidents that
  might occur in the future.

Types of Incidents

various types of Incidents can occur to a network or a computer. These incidents can be classified into various categories based on their type and extent of damage they can do. Some common types incidents are:

• Intrusion
• Malicious Code
• Fraud and Theft
• Errors and omissions
• Denial-of-Service attacks
• Defaced pages
• Quite Intrusion.

Phases of Incident handling

The importantpahses of incident handking are:

• Preparation
• Identification
• Reporting and Communication
• Eradication
• Recovery
• follow Up

Preparing for Incident Handling

The steps that need to be implementsd to minimize the impact of an incident needs to be defined in advance. A lot of foresight is required by the organization to initiate the fixing methodology at the earliest to handle the incident. The organization needs to prepare a plicy that guides the administrators to handle incidents. This planning includes the identification of people who have the skills to fix issues generated by inidents. The planner needs to consider all possible situations and their remedies. The preparation phase includes the following actions.

• Formulation of a incident handling policy
• Formulation of a incident handling team.

Formulation of an Incident-Handling Policy

An organization needs to devise a formal incident-handling plicy as a guideline document, which can be used in the case of incidents. This policy needs to define the lillowing.

• Purpose: The purpose defines the areas in which this policy may be used as a guideline document.
• Coverage: Coverage defines the people who are affected by the policy and who meed to offer skills in the case of an incident.
• Network and System Details: In this section of te policy, details regarding the technology used needs to be provided. the policy makers may also add the details regarding the possible known vulnerabilities in the existing system and the patches that have been added to the loopholes for which a solution has been identified. As possible list of incidents is avalible in this section the administrator might be able to identify the problem quickly.
• Procedure: This section is the most important section and needs to include all the intricate details of the steps that an incident handler needs to take. this saction defines all the possible incidents and the methods to fix these incidents.
• history documents: A location of the document detailing the history of incident and the technoques used to fix that incisdent meeds to be mentioned here. This helps an incident handler to locate the refrence focument to identify the best practices in relation to fixing problems.
  
  
  Identifying Incidents
  
  The first step in incident handling is to identify wether or not an incident has occured. An error or bur on the network need not necessarily be an incident. it can be simply an event that has occured by mistake or coincidence. Considiring such events as incidents can resultin confusion and loss of effort and $. the experts need to perform various steps ansd use certain techniques to identify the type of incident. these steps and techniques include:
  
  
• System and network logging function.
• Detection tools.

System and network logging function.

this step includes checking the various log files in order to estain the type of incident that has occured. the first check needs to be made on the network data, network data refers to the file generated to record the data regarding the applications, user activities, and network traffic. These log files can reveal data regarding any suspicious or unusual activities on the network. these log files provide evidence that can be used to trace the cracker. the data in the log files can also provide information om the extent of harm that might have been caused by the incident. there are various log files that can be viewed to collect the required information. Some example of the log files in Unix and Windows NT are:

UNIX

• Sulog: The su command is used to obtain superuser privileges. the sulog command log records the detail about each user using this command.
• System Logs: The various log files in a system includes syslog message, mail information and warnings. a check must be made to identify any unauthorized access. For example, checking for segment fault message indicates that the incident is of the Buffer Overflow type.
• Sniffer logs: Check for the presence of any sniffer files. the presence of any sniffer files indicats intrusion on the network

WindowsNT

• Event Viewer: This contains three logs system, security and application logs. this tool can be viewed from the Administrator Tools options in WindowsNT.
• Web Server Logs: these logs contains information rgarding the connections to applications such as Cold Fusion, IIS, and Microsoft FrontPage.

Detection Tools

Various detection tools are needed to be installed on the network to ensure that the incident can be detected in early stages before it harms the network resources. therefore the network must be constantly monitored for possible incidents. A list of few tools is given below:

[list=1]
[1] System Monitoring Tools:

• The Computer Oracle and Password System (COPS) package from Purdue University. Examines a system for a number of known weaknesses and alerts the system administrator to them; in some cases it can automatically correct these problems
• Check Promicious Mode(cpm): The cpm program from Carnegie Mellon University. Checks a system for any network interfaces in promiscuous mode; this may indicate that an attacker has broken in and started a packet snooping program
• Watcher: The Watcher package by Kenneth Ingham. A configurable and extensible system monitoring tool that issues a number of user-specified commands, parses the output, checks for items of significance, and reports them to the system administrator
• RIACS Intelligent Auditing and Categorizing System

[2] Network analysis Tools:

• Dummynet
• Ethereal
• Intrusion Detection - LANguard

[3] Log Analysis Tools

• LogSite
• NetIntellect, Linkbot
• Sawmill
• WebTracker

Assessing the Severity of an Incident
This is a very critical step in incident handling because it determines the steps that needs to be taken to resolve the incident. Severity refers to the level and type of harm an incident can cause to the network. The severity level is determined on the basis of the amount of loss the incident can bear on the network in relation to money, goodwill and effort. there are certain criteria that help determine the level of severiry:

• Type of attack:
• Number of Computer Affected
• Replication Factor[/b]: there can be attacks that might have the capability of replicating itself. for example a Virusthat can replicate itself through e-mail. this kind of attack makes it difficult to determine the number of computers that might be affected.
• Intentins of the incident:

Looks good. If I might add, might want to put something in about people not panicking after they discover/detect an attack. No IDS for detection? What about contact lists for preparation? If you haven't looked at it, you might want to look at The Process of Network Security by Thomas Wadlow. It actually details the necessary steps quite well and might give you some idears. :D

You could also write up something on the use of call lists etc... who's in charge when you actually have an incident in place, (can someone pull the plug on the router?). CERT and SANS both have some good stuff on this.

I`d break the IDS section down into NIDS and HIDS, dicuss the pros and cons of each and give some product examples. You could also add something about IDS outsourcing in this.

Talk about evidence handling, i.e what do you do with all these logs you have???

Also, one thing to add is that many organizations are now required to have policies on this kind of thing, the SEC and FDIC both assess this now in their audits (this is one of the reasons you use to persuade your boss you need this stuff - no policy = possible fine, a nice practical reason)

Looks like a good start though. The IDS books by Stephen Northcutt provide good coverage as does the Cybersecutity Operations Handbook by Rittinghouse and Hancock.

The one thing I didn't see was a section regarding the Incident Response Team. There was a one-liner, but i think it deserves more attention.

Identifying the Team is a critical step in Incident Handling. Best to not wait until you have an incident occurring to decide who you want to respond.

The team should include more than just hardcore security admins as well. I think the biggest part most forget about it is someone to interface with senior mgmt. Trust me, the last thing you need when your trying to collect volatile data or perform a live response is the CEO standing on your ass asking questions :)

Also, the team doesn't have to be filled w/ dedicated personnel. It is quite normal for people who have non-incident response full-time duties to be members of the IR team.

Cheers,
<0

Swordfish, just to nitpick on a few things, better check your spelling, use of spacing between words and capatalize beginning paragraphs. Spell out dollar not $. I know this is not your final report, just trying to help.

You might want to check here:

http://www.sans.org/rr/catindex.php?cat_id=27

SANS has very good stuff on Incident Handling...

Most important in your IR team is the company's legal representation and the PR unit of the company too. Some states, California comes to mind, now have a law that states that you _must_ inform the potentially damaged "customers". The last thing you want is your overzealous employee, (read geek), emailing them all himself.... It needs to be crafted by the legal beagles and the party planners, (PR).... ;)

The other people are pretty obvious but these two are often overlooked. The protocols should also be worked out ahead of time. For example, the CEO should _not_ be part of the IR team but _must_ be in the line of communication, (they need to know all that goes on but do not need input). It needs to be made quite clear that the senior IT/Information Security person, (depending on the setup of your organization), needs to control the IT based actions and that no suspect computers should be touched without the prior permission from him/her.... It's too easy for someone to be "helpful" and mess up the whole investigation which can be the difference between a sucessful prosecution and the authorities laughing and telling you to come back next time.......