The Stages of Incident

Response
Stages for incident response

METHODOLOGY #1 METHODOLOGY #2
• Preparation • Preparation
• Identification • Detection and Analysis
• Containment • Containment, Eradication, and
Recovery
• Investigation
• POST-INCIDENT ACTIVITY[Secure
• Eradication and Evaluate the Scene, Document
• Recovery the Scene, Perform Evidence
Collection, Package, Transport, and
• Follow-Up Store the Collected Digital Evidence]
Preparation
• Preparation is critical to the successful identification, handling, and
recovery for any computer incident.

• Preparation includes identifying the start of the incident, identifying

how to recover from the incident, and how to get back to normal
business operations sooner.
Preparation 1
• First part of preparation includes
• Creation and approval of well-established corporate security policies
Including warning banners, user privacy expectations, established
incident notification process, the development of an incident
containment policy, creation of incident handling checklists, insuring
the corporate disaster recovery plan is up to date, and making sure the
security risk assessment process is functioning and active.
Preparation 2
• Another important part of preparation is training: training for the
incident responders (SIRT team members) and training for the
organization’s system administrators.
• Types of training include operating system support, specialize
investigative techniques, incident response tools usage, and corporate
environmental procedure requirements.
• An additional focus of specialized training includes decision-making
efforts to determine if and when local law enforcement authorities
should be contacted during investigations.
Preparation 3
• Pre deployed incident handling assets
• Sensors, probes, and monitors on critical systems—these automated
mechanisms allow monitoring of:
1. System applications with a service and network monitoring program
2. CPU utilization, disk space, processes, and other pertinent metrics and
investigating any unusual activity;
3. Access to the application (allows and denies)
• Tracking data bases on core systems based upon minimum security
baselines (snapshots of the systems or networks during normal operations)
and the corporate Configuration Management Data Base (CMDB).
• Active audit logs for all server and network components—where the logs
are retained, how often the logs are updated, who controls them, etc
Preparation
• One final thing to understand about preparation is a few questions you
always need to present to your users so they know what is expected.
■ What action are they to take or not take at identification of incident?
■ Who do they call?
■ When do they call?
■ What information do they provide when calling?
■ Who should they notify or not notify about the possible incident?
Providing a basic response template for users to fill in when reporting an
event or incident is a good way to ensure the right information is provided in
a timely manner
Group Activity 2
• Assume you all part of SIRT team ,Prepare check list for pre incident
preparation activities which will ensure effective IR implementation .
Identification
• The second stage of Incident Response is proper Identification of the
incident.
Is the event simply an unusual activity, or can you identify it as
suspicious?
If so, what are the surrounding activities? Are there multiple reports
of issues on the network, or is it confined to one machine or location?
 Some of the areas to check include……

Unfamiliar File Names

• The modern malware event today often loads files onto a system hardrive
with files which are not normally found in a modern operating system. These
files can be identified and evaluated quickly once discovered.
Modifications to file names and/or dates, especially in system executable files
• “Hackers” often rename malicious executable files with names of normal
files and then place them into the expected directories of the operating system.
Intrusion Detection System (IDS) Alerts or Alarms
• Network- and host-based Intrusion Detection Systems can often provide the
responder indications of potential malicious or harmful activity so they should
be reviewed and examined during initial response efforts to gain a possible
path of attack and/or access of the malicious incident.
Some of the areas to check include…
• E-mail flood
• E-mail flooding, often an indicator of a worm event, can provide a
responder with indications of access methods and techniques used to
gain a method of ingress into the network and should be used to
instigate a response
Some of the areas to check include:
Suspicious Entries in System or Network Accounting
• The accounting logs for each location should provide indicators of unusual actions
in the system or network activities
Excessive Unsuccessful Login Attempts (>3 per user)
• Usual security controls are designed to deny access once three unsuccessful logins
are attempted in a row. This is an indicator of potentially malicious attackers trying
to access systems or networks without having compromised credentials
Unexplained New User Accounts
• Compromised administrative accounts often will indicate the creation of new
accounts for the purposes of creating malicious user access to systems and
networks
• All of these potential incident indicators can allow you to determine if this event
really is an incident or just an unusual event
Computer incident report form
• The reporting person, the end user or the system administrator, should fill
out a standardized computer incident report.
• This report should contain multiple fields wherein the reporting person
identifies the time and date of occurrence, location of occurrence,
machine/system/network involved and activity active when the event
occurred.
• This form provides valuable initial identification data for ensuring
the proper handling of the event. For example if system/computer has
an apparent identifiable virus/malware then this could be reflected on the
reporting form by the type of end-user interaction and response reported.
Incident Categories by Type of Incident[NIST
&US- CERT ]
CATEGORY NAME DESCRIPTION

LEVEL1 Unauthorized In this category an individual gains logical or physical access without permission
access to a department/agency/corporate network, system, application, data, or other
resource (e.g., physical documents). This category includes any breach of
Personal Identifiable Information (PII) or Privacy data. This type of incident
should be reported to the responsible corporate or organizational office as soon
as the incident is identified
LEVEL2 Denial of An attack that successfully prevents or impairs the normal authorized
service (DoS) functionality of networks, systems, or applications by exhausting resources. This
activity includes being the victim of or participating in the DoS. The DoS attack is
focused on not allowing users to access the needed computing resources to
accomplish their tasks. Most current router devices have mitigation techniques
built-in to their operating systems, so this type of incident is either based
against older equipment, or focused on large-scale attacks from multiple
sources
LEVEL3 Malicious Successful installation of malicious software (e.g., virus, worm, Trojan horse,
code or other code-based malicious entity) that infects an operating system or
application. This level is, today, by far and away has the largest number of
incidents reported. Most all of the antivirus and malware security vendors are
reporting large increases in the number and deployment of malware across the
Incident Categories by Type of Incident[NIST
&US- CERT ]
NAME DESCRIPTION
CATEGORIES
LEVEL 4 Improper A person violates acceptable computing use policies. This is the typical
usage classification for an insider threat or disgruntled employee incident within the
organization. This type of incident typically causes large-scale losses but is
often isolated to one network or location and carries the potential to harm an
information system or enterprise through destruction, disclosure, modification
of data, and/or denial of service… There are potentially major activities which
require incident handling with this type of incident.
LEVEL5 Scans/probes/ This category includes any activity that seeks to access or identify a
attempted corporation or department computer, open ports, protocols, service, or any
access combination for later exploit. This activity does not directly result in a
compromise or denial of service. This type of incident can be caused by
vulnerability scanning tools, network mapping tools, as well as penetration
testing tools. This incident level can be related to expected or unexpected
scans, tests, automated equipment evaluations, as well as outside
reconnaissance of networks and machines.
LEVEL 6 Investigation This category covers unconfirmed incidents that are potentially malicious or
incident anomalous activity deemed by organization/corporation to warrant further
review. Once this incident is determined to require additional investigation,