Networks - Incident Handling

Incident Handling Guide

1. Definition of Adverse Event and Computer Security Incident

An event is any observable occurrence in a system or network. Adverse Events are events with a negative consequence, such as system crashes, network packet floods, unauthorized use of system privileges, defacement of a Web page, and execution of malicious code that destroys data. Computer Security Incident, hereafter referred to as incident, can be thought of as a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. Examples of incidents are:

• Denial of Service
• Malicious Code
• Unathorized Access
• Inappropriate Usage
• Multiple Component

2. Need for Incident Response

Incident Response has become necessary because attacks frequently cause the compromise of personal and business data. These events make the case daily for responding quickly and efficiently when computer security defenses are breached. The benefits of having an incident response capability:

• Responding to incidents systematically so that the appropriate steps are taken
• Helping personnel to recover quickly and efficiently from security incidents, minimizing loss or theft of informatin and disruption of services
• Using information gained during incident handling to better prepare for handling future incidents and to provide stronger protection for systems and data
• Dealing properly with legal issues that may arise during incidents

3. Handling an Incident - Preparation and Prevention

The preparation phase involves establishing and training an incident response team and acquiring the necessary tools and resources. During preparation, CWU also attempts to prevent incidents that will occur by using industry standard recommended practices for securing networks, systems and applications such as:

• Patch Management for all systems
• Host-based Security
  • Perform regular vulnerability assessments to identify serious risks and mitigate the risks to an acceptable level
  • Disable all unneeded services on hosts
  • Run services with the least privileges possible to reduce the immediate impact of successful exploits
  • Use host-based firewall software
  • Limit unauthorized physical access to logged-in systems by requiring hosts to lock idle screens automatically
  • Regularly verify the permission settings for critical resources, including password files, sensitive databases and public Web pages
• Web Server Security
• Network Security (Internal and External Firewalling)
  • Configure network perimeter to deny all incoming and outgoing traffic that is not expressly permitted:
    • Blocking the usage of services that no longer serve a legitimate purpose and are used in DoS attacks
    • Perform egress and ingress filtering
    • Blocking traffic from unassigned IP address ranges, known as bogon lists
    • Writing and sequencing firewall rules and router ACLs to block traffic
    • Configuring border routers not to forward directed broadcasts
    • Limiting incoming and outgoing ICMP traffic to only the necessary types and codes
    • Blocking outgoing connections to common IRC, peer-to-peer service and instant messaging where needed
  • Implement rate limiting for certain protocols so they can only consume a designated percentage of total bandwith
  • On Internet-accessible hosts, disable all unneeded services and restrict the use of services that may be used DoS attacks
  • Implement DoS prevention software such as Mazu Networks' Enforcer
  • Implement redundancy for key functions (e.g., multiple firewalls, Web servers)
  • Ensure that networks and systems are not running near maximum capacity or it could be easy for a minor DoS attack to take up the remaining resources
  • Properly secure all remote access methods, including modems and VPNs
  • Put all publicly accessible services on secured DMZ network
  • Use private IP addresses for all hosts on internal networks.
• Malicious Code Prevention
  • Read antivirus bulletins
  • Eliminate open Windows shares
• User Awareness Training
• Configure email servers so they cannot be used for mail relaying
• Implement spam filtering on all email servers
• Run antivirus software and keep it updated
• Use intrusion detection software
• Configure all hosts to use centralized logging and event correlation software
• Establish password policy that requires users change passwords, complexity level, reuse, etc.
• Use outages distribution lists, outages notifications on Intranets, and CVS for change management information (e.g., system shutdowns, configuration changes, routine system administrative tasks)

Some tools and resources available for incident handling:

4. Handling an Incident - Detection and Analysis

Incident Categories. Incidents can occur in countless ways so it is impractical to develop comprehensive procedures with step-by-step instructions for handling every incident. The best we can do is to prepare generally to handle any type of incident and more specifically to handle common incident types:

• Denial of Service - an attack that prevents or impairs the authorized use of networks, systems or applications by exhausting resources
  • Reflector Attack: a host sends many requests with a spoofed source address to a service on an intermediate host. (The service used is typically UDP based.)
  • Amplifier Attack: like a reflector attack only the goal is to use a whole network of intermediate hosts. (The service sends an ICMP or UDP request to an expected broadcase address hoping that many hosts will receive the broadcast and respond to it.)
  • Distributed Denial of Service Attacks: Coordinated attack among many computers.
  • Synfloods: The attacker initiates many TCP connections in a short time (by sending SYN packets) but does not complete the TCP three-way handshakes necessary to complete the connection.
• Malicious Code - a virus, worm, Trojan horse or other code-based malicious entity that infects a host
  • File Infector Viruses: attach themselves to executable programs such as word processors, spreadsheets, then propagate to infect other programs on the system. (Jerusalem and Cascade are two of the best- known file infector viruses.)
  • Boot Sector Viruses: Infects the master boot record of a hard drive or the boot sector of removable media. Symptoms include an error message during boot or cannot boot. (Form, Michelangelo and Stoned are boot sector viruses.)
  • Macro Viruses: The most prevalent and successful type of virus. They attach themselves to documents such as word processing files and spreadsheets. A macro virus uses an application's macro programming language to execute and propagate. (Concept, Marker and Melissa are well-know macro viruses.)
  • Virus Hoaxes: False virus warnings. Typically circulated by innocent end users who believe they are helping by distributing to the Internet community. (Good Times and Bud Frogs are widely distributed hoaxes.)
  • Trojan Horses: Programs that appear to be benign but actually have a hidden malicious purpose. They tend to fit into one of three models:
    1. Continuing to perform the function of the original program and additinally performing a separate malicious activity.
    2. Continuing to perform the function of the original program but modifying the function to perform malicious activity.
    3. Performing a malicious function that completely replaces the function of the original program.
  • Worms: Self-replicating programs that are completely self-contained, they do not require a host program to infect a victim. (Blaster and SQL Slammer are popular worms.)
  • Mobile Code: software that is transmitted from a remote system to a local system and then executed on the local system without the user's explicit instruction. Often acts as a mechanism for a virus, worm or Trojan horse to be transmitted to the user's workstation. Popular vehicles for mobile code are Java applets, ActiveX, JavaScript and VBScript.
  • Blended Attack: An instance of malicious code that uses multiple methods to spread. The well-known Nimda "worm" used email, windows shares, web servers and web clients to distribute itself.
• Unauthorized Access - a person gains logical or physical access without permission to a network, system, application, data or other resource. Some examples include:
  • Performing a remote root compromise of an email server
  • Defacing a Web server
  • Guessing and cracking passwords
  • Copying a database containing credit card numbers
  • Viewing sensitive data such as payroll records or medical information, without authorization
  • Running a packet sniffer on a workstation to capture usernames and passwords
  • Using a permission error on an anonymous FTP server to distribute pirated software and music files
  • Dialing into an unsecured modem and gaining internal network access
  • Posing as an executive, calling the helpdesk, resetting th4e executive's email password and learning the new password
  • Using an unattended, logged-in workstation without permission
• Inappropriate Usage - a person violates acceptable use policies. examples of inappropriate use include users who:
  • Download password cracking tools or pornography
  • Send spam promoting a personal business
  • Email harassing messages to coworkers
  • Use file or music sharing services to acquire or distribute pirated materials
  • Set up an unauthorized Web site on one of the organization's computers
  • Transfer sensitive materials from the organization to external locations
• Multiple Component - a single incident that encompases two or more incidents

Detection. Signs of an incident fall into two categories: indications and precursors. A precursor is a sign that an incident may occur in the future. An indication is a sign that an incident may have occurred or may be occurring now. Some precursor or indication sources:

• Network and host-based IDS
• Antivirus software
• File integrity checking software
• Third-party monitoring service
• Operating system, service and application logs
• Network device logs
• Information on new vulnerabilities and exploits
• Information on incidents at other organizations
• People from within the organization
• People from other organizations

DoS attacks can be detected through particular precursors and indications, primarily those listed in the table below:

Malicious code attacks can be detected through particular precursors and indications, primarily those listed in the table below:

Unauthorized Access Indications:

Some Inappropriate Usage Indications are listed in the table below:

Incident analysis is difficult to do as not every precursor or indication is guaranteed to be accurate. The following recommendations for making incident analysis easier and more effective:

• Profile Networks and Systems
• Understand Normal Behaviors
• Use Centralized Logging and Create a Log Retention Policy
• Perform Event Correlation
• Keep All Host Clocks Synchronized
• Maintain and Use a Knowledge Base of Information
  • Links to malicious code and hoax information; the most comprehensive and up-to-date sources are typically the major antivirus software vendors
  • Links to lists of domains that hav been blacklisted for sending spam
  • Explanations of significance and validity of precursors and indications, such as intrusions detection alerts, OS log entries and application error codes
• Use Internet Search Engines for Research
• Run Packet Sniffers to Collect Additional Data
• Consider Filtering the Data
• Consider Experience as Being Irreplaceable
• Seek Assistance From Others

Incident Documentation. As soon as the incident response team suspects that an incident is occurring or has occurred, it is important to start recording all facts regarding an incident into a logbook. Document system events, telephone conversations, observed changes in files can lead to more efficient, more systematic and less error-prone handling of the problem. Every step taken from the time the incident was detected to its final resolution should be dated and signed by the handler.

The team will maintain records about the status of incidents along with other pertinent information:

• The current status of the incident
• A summary of the incident
• Actions taken by all incident handlers on the incident
• Contact information for other involved parties (e.g. system owners, sysadmins)
• A list of evidence gathered during the investigation
• Comments from handlers
• Next steps to be taken (e.g. waiting for a sysadmin to patch an application)

Incident Prioritization. Incidents should not be handled on a first-come, first-served basis. Handling will be prioritized on two factors:

• Current and Potential Technical Effect of the Incident
• Criticality of the Affected Resources

Incident Notification. After the incident has been analyzed and prioritized, the team will notify the appropriate individuals within the organization and perhaps other organizations.

• President of the University
• Director of ITS
• System owner
• Legal Department
• Public Affairs (for incidents that may generate publicity)

5. Handling an Incident - Containment, Eradiation, and Recovery

Containment strategies vary based on the type of incident. Criteria for determining the appropriate strategy include:

• Potential damage to and theft of resources
• Need for evidence preservation
• Service availability (e.g., network connectivity, services provided to external parties)
• Time and resources needed to implement the strategy
• Effectiveness of the strategy (e.g., partially contains the incident, fully contains the incident)
• Duration of the solution (e.g., emergency workaround to be removed in four hours, temporary workaround to be removed in two weeks, permanent solution)

In certain cases, delaying the containment of an incident may be done so monitoring the activity can be done to gather evidence. The team should discuss the delayed containment with the legal team to determine if it is feasible. If a system has been compromised and allows the compromise to continue, it may be liable if the attacker uses the compromised system to attack other systems.

The primary reason for gathering evidence during an incident is to resolve the incident, however, the evidence may be used for legal proceedings. It is important to clearly document how all evidence, including compromised systems, has been preserved. A detailed log should be kept for all evidence, including the following:

• Identify information (e.g., the location, serial number, model number, hostname, MAC address, and IP address of the computer)
• Name, title, and phone number of each individual who collected or handled the evidence during the investigation
• Time and date (including time zone) of each occurrence of evidence handling
• Locations where the evidence was stored

Computer forensic software is valuable not only for acquiring disk images, but also for automating much of the analysis process, such as:

• Identifying and recovering file fragments and hidden and deleted files and directories from any location (e.g., used space, free space, slack space)
• Examining file structures, headers and other characteristics to determine what typoe of data each file contains and not relying on file extensions (e.g.,.doc, .jpg, .mp3)
• Displaying the contents of all graphics files
• Performing complex serches
• Graphically displaying the drive's directory structure
• Generating reports

During evidence acquisition, it is prudent to acquire copies of supporting log files from other resources- for example, firewall logs that show what IP address an attacker used. Logs should be copied to sanitized write-protectable or write-once media.

During incident handling, system owners typically want to identify the attacker. Although this information can be important, the incident handlers should stay focused on containment, eradication and recovery. Identifying the attacker can be time consuming and futile. The following items are the most commonly performed activities for attacker identification:

• Validating the Attacker's IP Address
• Scanning the Attacker's System
• Researching the Attacker Through Search Engines
• Using Incident Databases
• Monitoring Possible Attacker Communication Channels

Eradication and Recovery. After an incident has been contained, eradication may be necessary to eliminate components of the incident, such as deleting malicious code and disabling breached user accounts. See tables below for possible eradication and recovery strategies.

6. Checklists for handling incidents.

The following checklist provides major steps to be performed in handling a Denial of Service incident.

The following checklist provides major steps to be performed in handling a Malicious Code incident.

The following checklist provides major steps to be performed in handling an Unauthorized Access incident.

The following checklist provides major steps to be performed in handling an Inappropriate Usage incident.