Table of Contents

ACKNOWLEDGEMENT I
DECLARATION BY THE SCHOLAR II
SUPERVISOR’S CERTIFICATE III
ABSTRACT IV
1.INTRODUCTION 1
1.1 AN INCIDENT 1
1.2 DATA 2
1.3 DATA CLASSIFICATION 2
1.3.1 HIGHLY CONFIDENTIAL 2
1.3.2 SENSITIVE 2
1.3.3 INTERNAL USE ONLY 2
1.3.4 SENSITIVE 3
1.3.5 RESTRICTED 3
1.3.6 PUBLIC 3
1.4 KEY CONCEPTS OF INFORMATION SECURITY 3
1.4.1 CONFIDENTIALITY 3
1.4.2 INTEGRITY 3
1.4.3 AVAILABILITY 3
1.4.4 AUTHENTICATION 4
1.4.5 AUTHORIZATION 4
1.4.6 NON-REPUDIATION 4
2. INCIDENT RESPONSE MANAGEMENT 5
2.1 SIGNS OF AN INCIDENT 5
2.2 INCIDENT CATEGORIES 6
2.2.1 HIGH 6
2.2.2 MEDIUM 6
2.2.3 LOW 7
 2.3 IDENTIFY AN INCIDENT 7
2.3.1 EVENT MANAGEMENT 7
2.3.2 FROM WEB INTERFACE 7
2.3.3 PHONE CALLS 7
2.3.4 EMAIL INTERFACE 7
2.4 HANDLING INCIDENTS 8
2.4.1 PREPARATION 8
2.4.2 IDENTIFICATION 8
2.4.3 CONTAINMENT 8
2.4.4 ERADICATION 9
2.4.5 RECOVERY 9
2.4.6 LEARNING LOSSON 9
3. INCIDENT MANAGEMENT & RESPONSE 10
3.1 INCIDENT MANAGEMENT 10
3.2 INCIDENT RESPONSE 10
3.3 INCIDENT RESPONSE PROCESS 11
3.4 PURPOSE OF INCIDENT RESPONSE 11
3.5 NEED OF INCIDENT RESPONSE 11
3.6 BUSINESS BENEFITS OF AN EFFECTIVE IRM 12
3.7 PREPARATION FOR INCIDENT RESPONSE PROCESS 13
3.7.1 PRIORITIZING ASSETS 13
3.7.2 CONNECT, COMMUNICATE & COLLABORATE 13
3.7.3 DIRECT & DOCUMENT ACTIONS 13
4. INCIDENT RESPONSEM ANAGEMENT TEAM 15
4.1 INCIDENT RESPONSE TEAM MEMBERS & ROLES 15
4.1.1 DUTY OFFICER 15
4.1.2 TRIAGE OFFICER 16
4.1.3 INCIDENT HANDLER 16
 4.1.4 INCIDENT MANAGER 16
4.2 INCIDENT RESPONSE TEAM STRUCTURE 16
4.2.1 CENTRAL INCIDENT RESPONSE TEAM 16
4.2.2 DISTRIBUTED INCIDENT RESPONSE TEAM 16
4.2.3 COORDINATING TEAM 16
4.2.4 EMPLOYEES 17
4.2.5 PARTIALLY OUTSOURCED 17
4.2.6 FULLY OUTSOURCED 17
4.3 IRM METHODOLOGY: THE OODA LOOP 17
4.3.1 OBSERVE 17
4.3.2 ORIENT 18
4.3.3 DECIDE 18
4.3.4 ACT 18
4.4 COMMON INCIDENT TYPE 18
4.4.1 PORT SCANNING ACTIVITY 18
4.4.2 MALWARE INFECTION 18
4.4.3 DISTRIBUTED DOS 19
4.4.4 UNAUTHORIZED ACCESS 19
4.4.5 INSIDER BREACH 19
4.4.6 DESTRUCTIVE ATTACK 19
4.4.7 MULTISTAGE ATTACK 19
4.4.8 FALSE ALARMS 19
5. INCIDENT RESPONSE TOOLS 20
5.1 OBSERVATION PHASE 20
5.2 ORIENT PHASE 21
5.3 DECIDE PHASE 21
5.4 ACT PHASE 21
6. ALIENVAULT’S OSSIM 22
6.1 INSTALLATION OF OSSIM 23
6.2 SCENARIO AND RESULT 52
7. SNORT 56
7.1 INSTALLATION AND SETUP 57
7.2 SCENARIO AND RESULT 62
8. OCS INVENTORY 65
8.1 INSTALLATION AND SETUP 66
8.2 SOFTWARE WALK THROUGH 70
9. REFERENCE LINKS 75
 DECLARATION BY THE STUDENT
I hereby declare that the work reported in the M.Sc. Digital Forensics &
Information Security Minor Project – 1 report entitled “Incident Response
Management” submitted in Institute of Forensics Science, Gujarat Forensic
Sciences University, Gandhinagar, Gujarat, India is an authentic record of my
work carried out under the supervision of Dr. Digvijaysinh Rathod. I have not
submitted this work elsewhere for any other degree. I am fully responsible for the
contents of my M.Sc. Semester 2 Minor Project – 1 report.

________________________
Raihan Patel
Institute of Forensic Sciences
Gujarat Forensic Sciences University, Gandhinagar
India
Date : _____ April, 2017
 SUPERVISOR’S CERTIFICATE
This is to certify the work reported in the M.Sc Digital Forensics & Information
Security Minor Project – 1 report entitled “Incident Response Management”
submitted by Raihan Patel at Institute of Forensic Science, Gujarat Forensic
Sciences University, Gandhinagar, India is a bonafide record of his original work
carried out under my supervision. This work has not been submitted elsewhere for
any other degree.

Dr. Digvijaysinh Rathod

Date: _____ April 2017
 ABSTRACT
Understanding the incident and methodologies to effectively manage unexpected

disruptive events with the objective of minimizing impacts and maintaining or restoring

normal operations within defined time limits should be important part of any companies’

business plan. In this project report, My goal is to explain Incident and Incident response

management briefly with answering questions like why we need IRM and What kind of

benefits it can provide to business, As well as I have explained several tools that can be

helpful to configure Incident Response Management into a company.

1. Introduction
1.1 An Incident:
In the context of information technology, an incident is an event that disrupts
operational processes. An incident may involve the failure of a feature or service that
should have been delivered or some other type of operation failure. Security incidents are
events that indicate that an organization's systems or data may have been compromised.
It is an act of violating explicit or implied security policy resulting in, unauthorized
access, denial of service/disruption, and unauthorized use of a system for processing or
storage of data or change to system software, hardware, firmware characteristics without
the owner's knowledge.
Incidents include minor disruptions, such as running out of disk space on a desktop
machine, as well as major disruptions, such as data breaches involving the exposure of
sensitive information.
Each organization must define what a computer security incident is for their site.
Examples of general definitions for a computer security incident could be:
“Any real or suspected adverse event in relation to the security of computer
systems of computer networks”
“The act of violating an explicit or implied security policy”
Examples of incidents could include activity such as:
• Attempts (either failed or successful) to gain unauthorized access to a system
or its data
• Unwanted disruption or denial of service
• Unauthorized use of a system for the processing or storage of data
• Changes to system hardware, firmware, or software characteristics without the
owner's knowledge, instruction, or consent
• Service Interrupts, Computer Interference, Unauthorized Access, Malicious
Communication, Copyright Violation, Theft, Commercial Use, Unsolicited
Bulk Email are more examples of type of computer security incident

1
1.2 Data:
In general, data is any set of characters that has been gathered and translated for some
purpose, usually analysis. It can be any character, including text and numbers, pictures,
sound, or video. If data is not put into context, it doesn't do anything to a human or
computer. Raw data describes the facts and figures that a company processes every day.

1.3 Data Classification:

Data classification is one of the most important steps in data security. Not all data is created
equal, and few businesses have the time or resources to provide maximum protection to all
their data. That’s why it’s important to classify your data based on how sensitive or
valuable it is – so that you know what your most sensitive data is, where it is and how well
it’s protected.
Common data classifications include:
1.3.1 Highly confidential:
This classification applies to the most sensitive business information that is
intended strictly for use within your company. Its unauthorized disclosure could
seriously and adversely impact your company, business partners, vendors and/or
customers in the short and long term. It could include credit-card transaction data,
customer names and addresses, card magnetic stripe contents, passwords and PINs,
employee payroll files, etc.
1.3.2 Sensitive:
This classification applies to sensitive business information that is intended
for use within your company, and information that you would consider to be private
should be included in this classification. Examples include employee performance
evaluations, internal audit reports, various financial reports, product designs,
partnership agreements, marketing plans and email marketing lists.
1.3.3 Internal use only:
This classification applies to sensitive information that is generally
accessible by a wide audience and is intended for use only within your company.
While its unauthorized disclosure to outsiders should be against policy and may be
harmful, the unlawful disclosure of the information is not expected to impact your
company, employees, business partners, vendors and the like.

2
Other way of classification as described in Michigan is as follows:
1.3.4 Sensitive: Limited in use for a selected group or process.
1.3.5 Restricted: Information that is related to departmental business operations,
but not available for public consumption.
1.3.6 Public: Information that requires no special protection or rules for use.

1.4 Key Concepts of Information Security:

Three basic security concepts important to information on the internet are:
1.4.1 Confidentiality:
Confidentiality is roughly equivalent to privacy. Measures undertaken to ensure
confidentiality are designed to prevent sensitive information from reaching the
wrong people, while making sure that the right people can in fact get it.
1.4.2 Integrity:
Integrity involves maintaining the consistency, accuracy, and trustworthiness of
data over its entire life cycle. Data must not be changed in transit, and steps must be
taken to ensure that data cannot be altered by unauthorized people (for example, in
a breach of confidentiality). These measures include file permissions and user
access controls.
1.4.3 Availability:
Availability is best ensured by rigorously maintaining all hardware, performing
hardware repairs immediately when needed and maintaining a correctly functioning
operating system environment that is free of software conflicts. It’s also important
to keep current with all necessary system upgrades. Providing adequate
communication bandwidth and preventing the occurrence of bottlenecks are equally
important. Redundancy, failover, RAID even high-availability clusters can mitigate
serious consequences when hardware issues do occur.

3
Concepts relating to the people who use that information are:
1.4.4 Authentication:
Authentication is a process of identifying the person before accessing the system. It
allows user to access the system information only if authentication check got passed.
Apart from Username & password combination, the authentication can be
implemented in different ways like asking secret question and answer, OTP (One
Time Password) over SMS, biometric authentication, Token based authentication
like RSA Secure ID token etc.
1.4.5 Authorization:
Once the Authentication passed the Authorization comes in the picture to limit the
user as per the permission set for the user. The Authorization is generally
implemented on Access control list, user role based, user group based and define
the permissions & restrictions to specific user group or granting or revoking the
privileges for the users.
1.4.6 Non-repudiation:
Tracking who is accessing the systems and which of the requests were denied along
with additional details like the Timestamp and the IP address from where the
requests came from. Means confirmation sent by receiver to sender that the
requested services or information was successfully received as Digital confirmation
e.g. Digital Certificates, this not only serves as acknowledgement but also helps to
validate both sender and receiver is genuine.

4
2. Incident Response Management
2.1 Signs of an Incident:
Signs of an incident fall into one of two categories: precursors and indicators.

• A precursor is a sign that an incident may occur in the future.

• An indicator is a sign that an incident may have occurred or may be occurring
now.
Most attacks do not have any identifiable or detectable precursors from the target’s
perspective. If precursors are detected, the organization may have an opportunity to prevent
the incident by altering its security posture to save a target from attack.
At a minimum, the organization could monitor activity involving the target more closely.
Examples of precursors are:

• Web server log entries that show the usage of a vulnerability scanner.
• An announcement of a new exploit that targets a vulnerability of the
organization’s mail server.
• A threat from a group stating that the group will attack the organization.
While precursors are relatively rare, indicators are all too common. Too many types of
indicators exist to exhaustively list them, but some examples are listed below:

• A network intrusion detection sensor alerts when a buffer overflow attempt

occurs against a database server.
• Antivirus software alerts when it detects that a host is infected with malware.
• A system administrator sees a filename with unusual characters.
• A host records an auditing configuration change in its log.
• An application logs multiple failed login attempts from an unfamiliar remote
system.
• An email administrator sees a large number of bounced emails with
suspicious content.
• A network administrator notices an unusual deviation from typical network
traffic flows.

5
2.2 Incident Categories:
2.2.1 High:
The severity of a security incident will be considered “high” if any of the following
conditions exist:

• Threatens to have a significant adverse impact on a large number of systems

and/or people (for example, the entire UNIT is affected)
• Poses a potential large financial risk or legal liability to the Organization.
• Threatens confidential data (for example, the compromise of a server that
contains or names with social security numbers or credit card information)
It adversely impacts an enterprise system or service critical to the operation of a major
portion of the organization (for example, e-mail, customer information system. financial
information system, human resources information system, etc.). It poses a significant and
immediate threat to human safety, such as a death-threat to an individual or group. It has
Has a high probability of propagating to many other systems on premise and/or off premise
and causing significant damage or disruption/
High severity incidents require an immediate response and focused, dedicated attention by
the CISO and other appropriate officials and IT security staff until resolved.
2.2.2 Medium:
The severity of a security incident will be considered “medium” if any of the following
conditions exist:

• Adversely impacts a moderate number of systems and/or people, such as an

individual department, unit, or building
• Adversely impacts a non-critical enterprise system or service
• Adversely impacts a departmental system or service, such as a departmental
file server
• Disrupts a building or departmental network
• Has a moderate probability of propagating to other systems on premise
and/or off premise and causing moderate damage or disruption
Medium severity incidents require a quick response by appropriate personnel (usually from
the affected unit) who have primary responsibility for handling the incident.

6
2.2.3 Low:
Low severity incidents have the following characteristics:
Adversely impacts a very small number of systems or individuals
Disrupts a very small number of network devices or segments
Has little or no risk of propagation or causes only minimal disruption or damage in
their attempt to propagate
Since a single compromised system can “wake up” and negatively affect other systems at
any time, appropriate personal (usually the technical support staff responsible for the
system) must respond as quickly as possible, no later than the next business day.

2.3 Identify an Incident:

Incident can be identified from the following sources
2.3.1 Event Management
Event Management provides qualified alerts when one or more Configuration Items (CI)
have have encountered a disruption in its normal functioning or may encounter disruption
in its normal functioning. In practice, Event Management may lead to generation of a
manual incident OR an automated incident creation.
2.3.2 From Web Interface
Web interface is a very efficient method to identify incidents as it involves no human
interface to log the ticket. Organization need to provide a intuitive interface to the end users
to log incidents.
2.3.3 Phone Calls
Phone calls is the most common way of reporting incidents. This is a labor intensive
method to report incidents. However, this method has its own merits as end-user incidents
can be quickly resolved via First Call Resolution, thus improving customer satisfaction
substantially.
2.3.4 Email Interface
Emailing incident details to Service Desk is the easiest method to report an incident. However, in
most cases, this mode of incident reporting is rigged with lot of inefficiencies.

7
2.4 Handling Incidents
Incident handling includes three functions: incident reporting, incident analysis, and
incident response. The incident reporting function enables a CERT to serve as a central
point of contact for reporting local problems.
This allows all incident reports and activity to be collected in one location where
information can be reviewed and correlated across the parent organization or constituency.
This information can then be used to determine trends and patterns of intruder activity and
recommend corresponding preventative strategies for the whole constituency.
This is one part of the incident analysis function.The other part of incident analysis involves
taking an in-depth look at an incident report or incident activity to determine the scope,
priority, and threat of the incident, along with researching possible response and mitigation
strategies.
Incident response functions can take many forms.A CERT may send out recommendations
for recovery, containment, and prevention to constituents or systems and network
administrators at sites who then perform the response steps themselves.
A CERT may also perform these steps themselves on the affected systems. The response
may also involve sharing information and lessons learned with other response teams and
other appropriate organizations and sites.
According to the SANS Institute, there are six steps to handling an incident most
effectively:
2.4.1 Preparation
The organization educates users and IT staff of the importance of updated security
measures and trains them to respond to computer and network security incidents quickly
and correctly.
2.4.2 Identification
The response team is activated to decide whether a particular event is, in fact, a security
incident. The team may contact the CERT Coordination Center, which tracks Internet
security activity and has the most current information on viruses and worms.
2.4.3 Containment
The team determines how far the problem has spread and contains the problem by
disconnecting all affected systems and devices to prevent further damage.

8
2.4.4 Eradication
The team investigates to discover the origin of the incident. The root cause of the problem
and all traces of malicious code are removed.
2.4.5 Recovery
Data and software are restored from clean backup files, ensuring that no vulnerabilities
remain. Systems are monitored for any sign of weakness or recurrence.
2.4.6 Leaning Lesson
The team analyzes the incident and how it was handled, making recommendations for
better future response and for preventing a recurrence.

9
3. Incident Management & Response
3.1 Incident Management
Incident management is defined as the “capability to effectively manage unexpected
disruptive events with the objective of minimizing impacts and maintaining or restoring
normal operations within defined time limits.”
A viable incident management capability requires the allocation of human and material
resources to support business operations to assure continuity of the minimum of enterprise
operations and contain security breaches in accordance with the enterprise risk strategy.
Incident management involves all of the actions taken prior to (including testing and
planning), during, and after an information security incident occurs. The actions taken
should be designed to mitigate the impact of an incident with the following goals in mind:
Provide an effective means of addressing the situation in such a way that it
minimizes the impact to the enterprise.
Provide management with sufficient information to decide on appropriate courses
of action.
Maintain or restore continuity of enterprise services.
Provide a defense against subsequent attacks.
Provide additional deterrence through the use of technology, investigation and
prosecution
Incident management is a central component of an enterprise strategy for viability and
resiliency as reflected in its BCPs. Incident management is a positive enabler with
beneficial impacts to the enterprise both in dealing with risk associated with internal and
external threats as well as responding to critical business drivers involving regulatory
compliance.

3.2 Incident Response

Incident response is an organized approach to addressing and managing the aftermath of a
security breach or attack (also known as an incident). The goal is to handle the situation in
a way that limits damage and reduces recovery time and costs. An incident response plan
includes a policy that defines, in specific terms, what constitutes an incident and provides
a step-by-step process that should be followed when an incident occurs.

10
An organization's incident response is conducted by the CIRT(computer incident response
team), a carefully selected group that, in addition to security and general IT staff, may
include representatives from legal, human resources, and public relations departments.

3.3 Incident response process

At the end of the day, it’s a business process. In fact, an incident response process is a
business process that enables a company to remain in business. Specifically, an incident
response process is a collection of procedures aimed at identifying, investigating and
responding to potential security incidents in a way that minimizes impact and supports
rapid recovery.
Many Security Expects and IRM experts believes that the more you can approach an
incident response process as a business process - from every angle, and with every audience
- the more successful you will be.

3.4 Purpose of Incident Response

Purpose of incident management is to reinstate normal service operation as fast as possible
and mitigate the negative impact on business operations, thus making sure that agreed
levels of service quality are maintained. An operational state where services are performing
within their agreed service and operational levels is called as Normal service operation.
Main objectives of incident management process are as under
Make sure that standardized procedures and methods are used for prompt and
efficient response, documentation, analysis, reporting of incidents and ongoing
management
Communication and visibility of incidents should be improved.
Improve business perception of IT with the help of a professional approach so that
incidents will be resolved and reported quickly
Line up incident management activities and priorities them accordingly
Enhance and maintain the user satisfaction without losing the quality of IT services

3.5 Need of Incident Response

Incident response is a key component of an enterprise business continuity and resilience
program. The increasing number and diversity of information security threats can disrupt
enterprise business activities and damage enterprise information assets. A sound risk
management program can help reduce the number of incidents, but there are some incidents

11
that can neither be anticipated nor avoided. Therefore, the enterprise needs to have an
incident response capability to detect incidents quickly, contain them, mitigate impact, and
restore and reconstitute services in a trusted manner
Attacks frequently compromise personal and business data, and it is critical to respond
quickly and effectively when security breaches occur.
The concept of computer security incident response has become widely accepted and
implemented. One of the benefits of having an incident response capability is that it
supports responding to incidents systematically (i.e., following a consistent incident
handling methodology) so that the appropriate actions are taken.
Incident response helps personnel to minimize loss or theft of information and disruption
of services caused by incidents. Another benefit of incident response is the ability to use
information gained during incident handling to better prepare for handling future incidents
and to provide stronger protection for systems and data.
An incident response capability also helps with dealing properly with legal issues that may
arise during incidents.

3.6 Business Benefits of an Effective Incident Management

Incident management is tied to the principal enterprise goals for information security:
preserving the confidentiality, integrity and availability of enterprise information assets.
Employing a systematic incident management program that utilizes a formal methodology
offers several benefits to the enterprise such as:
Providing a structured, logical approach to use in situations that are usually chaotic.
Increasing the efficiency of dealing with an incident, which reduces the impact to
the enterprise from both financial and human resources (HR) perspectives
Breaking down an incident into smaller, more manageable phases or stages that can
be addressed in a logical manner.
Providing evidence of due diligence and forethought that may become significant
should legal and liability issues arise following an incident. This is particularly true
when dealing with disclosure regulations and compliance with laws.
An effective incident management program provides a means of dealing with unexpected
circumstances in such a way as to minimize impact to the enterprise. It also provides
management with sufficient information on which to base an appropriate course of action.
Creating an interdisciplinary incident response team that is drawn from all parts of the

12
enterprise and is educated and prepared to respond to events such as social engineering
attacks is a key component of a comprehensive incident management program.
Especially significant is the fact that a robust incident management program as a stand-
alone component of the overall BCP can enhance the enterprise’s competitive position
through greater security awareness, improved defenses and effective resilient responses to
events with negative impacts to the enterprise.

3.7 Preparation for Incident Response Process

3.7.1 Prioritizing assets
Every Company must always know what their important assets are. In other words, what
servers, apps, workloads, or network segments could potentially put them out of business
if they went offline for even an hour? What information could do the same if it fell into the
wrong hands?
By the way, the assets that you consider as important to the business may not be the ones
that your attacker sees as important
Company should develop a list of the top tier applications, users, networks,
databases, and other key assets based on their impact to business operations if they
go offline, or become compromised in other ways
Quantify asset values as accurately as possible because this will help company
justify the budget
Capturing traffic patterns and baselines. That can help in building an accurate
picture of what constitutes normal. Company will need this foundation to spot
anomalies that could signal a potential incident.
3.7.2 Connect, communicate & collaborate
By Discussing with executive leadership, sharing analysis of the current security posture
of the company, reviewing industry trends, key areas of concern, and security expert’s
recommendations. Set expectations on what the IR team will do, along with what other
companies are doing, as well as what to expect in terms of communications, metrics, and
contributions. Find out the best way to work with the legal, HR, and procurement teams to
fast track requests during essential incident response procedures.
3.7.3 Direct & document actions
The incident response team members will need ample instruction, guidance, and direction
on their roles and responsibilities. Team leader should write this down and review it

13
individually and as a team. The time you spend doing this before a major incident will be
worth the investment later on when crisis hits. Everyone involved, especially the executive
team, will appreciate receiving regular updates, so team leader should negotiate a
frequency that works for everyone and stick to it.

14
4. Incident Response Management Team
In developing an incident management capability, an organization must determine who is
currently performing incident management and related tasks and identify who will be part
of the incident management team. Identifying people across the enterprise who must work
together to analyze and resolve incidents and then assigning them specific roles and
responsibilities is one of the most critical tasks that can be done in building and improving
a capability. Incident Response Management Team mainly contains management officials.
An incident response team should be available for anyone who discovers or suspects that
an incident involving the organization has occurred. One or more team members,
depending on the magnitude of the incident and availability of personnel, will then handle
the incident. The incident handlers analyze the incident data, determine the impact of the
incident, and act appropriately to limit the damage and restore normal services. The
incident response team’s success depends on the participation and cooperation of
individuals throughout the organization.

4.1 Incident Response Team Members Roles

For incident management to be successful, it is essential to carefully consider the roles
within a CERT(Computer Emergency Response Team) and to tailor these to your specific
mission, constituency and environment.
A CERT can be a virtual team with no formal members and with tasks distributed between
different employees in various company departments such as the network operations
centre, internal IT security team, legal department, PR department, help desk, etc.
It can also be a department in a company’s organizational structure, with several core
members but also with some members from different departments, who work part-time or
only on a specific task. it can also be an organisation or department with only full-time
members.
The mandatory roles are:
4.1.1 Duty officer
A duty officer has to take care of all in-coming requests as well as carry out periodic or ad
hoc activities dedicated to this role.

15
4.1.2 Triage officer
The triage officer has to deal with all incidents that are reported to or by the team. He needs
to decide whether it is an incident that is to be handled by the team, when to handle it and
who is going to be the incident handler according to the triage process.
4.1.3 Incident handler
The incident handler is a crucial role in the incident handling team. He deals with the
incidents analysing data, creating workarounds, resolving the incident and communicating
clearly about the progress he has made to his incident manager and to and with the
appropriate constituent(s).
4.1.4 Incident manager
The incident manager is responsible for the coordination of all incident handling activities.
He represents the incident handling team outside his team.

4.2 Incident Response Team Structure

Possible structures for an incident response team include the following:
4.2.1 Central Incident Response Team
A single incident response team handles incidents throughout the organization. This model
is effective for small organizations and for organizations with minimal geographic diversity
in terms of computing resources.
4.2.2 Distributed Incident Response Team
The organization has multiple incident response teams, each responsible for a particular
logical or physical segment of the organization. This model is effective for large
organizations (e.g., one team per division) and for organizations with major computing
resources at distant locations (e.g., one team per geographic region, one team per major
facility).
4.2.3 Coordinating Team
An incident response team provides advice to other teams without having authority over
those teams—for example, a department wide team may assist individual agencies’ teams.

16
4.2.4 Employees
The organization performs all of its incident response work, with limited technical and
administrative support from contractors.
4.2.5 Partially Outsourced
The organization outsources portions of its incident response work.
4.2.6 Fully Outsourced
The organization completely outsources its incident response work, typically to an onsite
contractor. This model is most likely to be used when the organization needs a full-time,
onsite incident response team but does not have enough available, qualified employees.

4.3 Incident Response Process Methodology: The OODA Loop

OODA Loop was Developed by US Air Force military strategist John Boyd, the OODA
loop stands for Observe, Orient, Decide, and Act.

4.3.1 Observe
The more observations company can make (and document) about their network and their
business operations, the more successful they’ll be at defense and response. Sharing

17
additional observations with executives could also improve overall business operations and
efficiencies - beyond IR.
Log Analysis; SIEM Alerts; IDS Alerts; Traffic Analysis; Netflow Tools; Vulnerability
Analysis; Application Performance Monitoring tools comes on this phase.
4.3.2 Orient
Get inside the mind of the attacker so that you can orient your defense strategies against
the latest attack tools and tactics. These are constantly changing so make sure you have the
latest threat intelligence feeding your security monitoring tools to ensure that they are
capturing the right information and providing the necessary context.
Incident Triage; Situational Awareness; Threat Intelligence; Security Research tolls comes
on this phase.
4.3.3 Decide
Document all aspects of the incident response process, especially communications
regarding data collection and the decision-making processes.
Company’s Corporate Security Policy are used as tactics on this phase.
4.3.4 Act
Training, communication, and continual improvement are the keys to success in acting
effectively during an incident. Team members should know what is expected of them and
that means in-depth training, detailed run-throughs, and keen attention on how to
continually improve teamwork and the overall process.
Forensics analysis tools; System backup & recovery tools; Patch mgmt. and Security
Awareness Training tools comes under this phase.

4.4 Common Incident Types and Recommended Actions

4.4.1 Port Scanning Activity
Ignore most of these events UNLESS the source IP has a known bad reputation , and there
are multiple events from this same IP in a small timeframe.
4.4.2 Malware Infection
Remediate any malware infections as quickly as possible before they progress. Scan the
rest of your network for indicators of compromise associated with this outbreak (e.g. MD5
hashes).

18
4.4.3 Distributed DoS
Configure web servers to protect against HTTP and SYN flood requests. Coordinate with
your ISP during an attack to block the source IPs.
4.4.4 Unauthorized Access
Detect, monitor and investigate unauthorized access attempts – with priority on those that
are mission-critical and/or contain sensitive data.
4.4.5 Insider Breach
Identify the privileged user accounts for all domains, servers, apps, and critical devices.
Ensure that monitoring is enabled for all systems, and for all system events, and also make
sure it’s feeding your log monitoring infrastructure (your USM or SIEM tools).
4.4.6 Destructive Attack
Backup all critical data and systems. Test, document, and update system recovery
procedures. During a system compromise - capture evidence carefully, and document all
recovery steps as well as all evidentiary data collected.
4.4.7 Multistage Attack
Backup all critical data and systems. Test, document, and update system recovery
procedures. During a system compromise - capture evidence carefully, and document all
recovery steps as well as all evidentiary data collected.
4.4.8 False Alarms
Much of the incident responder’s job is spent eliminating irrelevant information and
removing false positives. You’ll be constantly fine-tuning the radio of security monitoring
to get to just the right signal.

19
5. Incident Response Tools
5.1 Observation Phase
Logs are richest source for understanding what’s going on in the network, but examiner
need an IR tool that makes sense of all of those logs, and that’s what log analysis is all
about. Alienvault’s OSSIM is a good example of log analysis.
IDS’es (HIDS and NIDS) monitor server and network activity in real-time, and typically
use attack signatures or baselines to identify and issue an alert when known attacks or
suspicious activities occur on a server (HIDS) or on a network (NIDS). SNORT is an
example of effective IDS.
Netflow analyzers examine actual traffic within a network (and across the border gateways
too). If you are tracking a particular thread of activity, or just getting a proper idea of what
protocols are in use on your network, and which assets are communicating amongst
themselves, netflow is an excellent approach. NTop is an example of Netflow analyzer.
Vulnerability scanners identify potential areas of risk, and help to assess the overall attack
surface area of an organization, so that remediation tasks can be implemented. OpenVAS
is well known vulnerability scanner.
The whole point of incident response is to avoid downtime as much as possible. So make
sure that you have availability monitoring in place, because an application or service
outage could be the first sign of an incident in progress. Nagios is a good example of
availability monitoring.
Web Proxies are thought of as being purely for controlling access to websites, but their
ability to log what is being connected to is vital. So many modern threats operate over
HTTP – being able to log not only the remote IP address, but the nature of the HTTP
connection itself can be vital for forensics and threat tracking. IPFire is well known web
proxy service.

20
5.2 Orient Phase
In order to know which events to prioritize, you’ll need an understanding of the list of
critical systems in your network, and what software is installed on them. Essentially, you
need to understand your existing environment to evaluate incident criticality as part of the
Orient/Triage process. The best way to do this is to have an automated asset discovery and
inventory that you can update when things change (and as we know, that’s inevitable).
OCSInventory is a good tool for Asset discovery.
Threat intelligence gives you global information about threats in the real world. Things
like indicators of compromise (IoCs), bad reputation IP addresses, command-and-control
servers and more, can be applied against your own network assets, to provide a full context
for the threat. AlienVault’s OTX is widely used tool for Threat intelligence.

5.3 Decide Phase

Document all aspects of the incident response process, especially communications
regarding data collection and the decision-making processes.
Company’s Corporate Security Policy are used as tactics on this phase. Which are usually
stored in hard copies. So, There is no tool that is available for this phase, instead it relies
on skillful employees and IRM team members.

5.4 Act Phase

Data Capture & Incident Response Forensics tools is a broad category that covers all types
of media (e.g. memory forensics, database forensics, network forensics, etc.). Incident
Response Forensics tools examine digital media with the aim of identifying, preserving,
recovering, analyzing and presenting facts and opinions about the digital information, all
designed to create a legal audit trail. The Sleuthkit’s Autopsy is known tool for effective
forensic analysis.

21
6. Incident Response Tools: AlienVault’s OSSIM
OSSIM (Open Source Security Information Management) is an open source security
information and event management system, integrating a selection of tools designed to aid
network administrators in computer security, intrusion detection and prevention.
The project began in 2003 as a collaboration between Dominique Karg, Julio Casal and
later Alberto Román. In 2008 it became the basis for their company AlienVault. Following
the acquisition of the Eureka project label and completion of R&D, AlienVault began
selling a commercial derivative of OSSIM named as AlienVault USM (Unified Security
Management).
As a SIEM system, OSSIM is intended to give security analysts and administrators a view
of all the security-related aspects of their system, by combining log management and asset
management and discovery with information from dedicated information security controls
and detection systems. This information is then correlated together to create contexts to the
information not visible from one piece alone.
OSSIM performs these functions using other well-known open-source software security
components, unifying them under a single browser-based user interface. The interface
provides graphical analysis tools for information collected from the underlying open source
software component (many of which are command line only tools that otherwise log only
to a plain text file) and allows centralized management of configuration options.
The software is distributed freely under the GNU General Public License. Unlike the
individual components which may be installed onto an existing system, OSSIM is
distributed as an installable ISO image designed to deployed to a physical or virtual host
as the core operating system of the host. OSSIM is built using Debian GNU/Linux
distribution as its underlying operating system.

22
6.1 Installation of AlienVault’s OSSIM
First download the ISO from their official website and then configure it in Virtual Box.

[Image 1]

[Image 2]

23
 [Image 3]
[Select Language here ]

24
 [Image 4]
[Select Country]

25
 [Image 5]
[Provide IP Address for the OSSIM]

26
 [Image 6]
[Provide Subnet mask]

27
 [Image 7]
[Provide Gateway Address]

28
 [Image 8]
[Provide password for root user]

29
 [Image 9]
[Installation will start after that]

30
 [Image 10]
[After installation. You will get this screen, Login with root user]

31
 [Image 11]
[After Login You will get this screen, Networking Configuration changes can be done
here]

32
 [Image 12]
[Go to any Windows or Linux OS and enter https://10.0.0.1 in Browser]

[Image 13]
[You will be prompt to login after that, do it with ‘admin’ account]

33
 [Image 14]
[It will ask to configure OSSIM with a wizard]

[Image 15]
[First It will ask to configure Network Interfaces]

34
 [Image 16]
[It will ask to mention all the available asset , usually it scans automatically for it]

[Image 17]
[OSSIM has an amazing feature of deploying HIDS in all assets automatically]

35
 [Image 18]

[Image 19]
[Configuration is done]

36
 [Image 20]
[It provided different alarms and event alerts]

37
[Image 21]

38
 [Image 22]
[In Dashboard, We can see Risk maps to check threats all over the world]

39
 [Image 23]
[Netflow can be examined in live network]

40
 [Image 24]
[All Asset’s availability can be checked]

41
[Image 25]

42
[Image 26]

43
 [Image 27]
[Processing Information of OSSIM can be checked here]

44
 [Image 28]
[Each Program-wide Performance Information]

45
 [Image 29]
[Live log Reporting of all hosts and services]

46
 [Image 30]
[Most Recent Alerts]

47
 [Image 31]
[Option to generate report]

48
 [Image 32]
[Option to create custom policy to monitor assets accordingly]

49
 [Image 33]
[Creating Custom Policy]

50
 [Image 34]
[Option to alter Port detail or add new port]

51
5.2 Scenario and Result
Performing SQLi Attack on an asset from Kali

[Image 35]

[Image 36]

52
 [Image 37]
[Getting Security Alarms]

53
 [Image 38]
[Checking Security Alarm details]

54
 [Image 39]
[SQLi attack detected]

55
7. Incident Response Tool: SNORT
Snort is a free and open source network intrusion prevention system (NIPS) and network
intrusion detection system (NIDS) created by Martin Roesch in 1998. Snort is now
developed by Sourcefire, of which Roesch is the founder and CTO, and which has been
owned by Cisco since 2013.
In 2009, Snort entered InfoWorld's Open Source Hall of Fame as one of the "greatest open
source software of all time"
Snort's open source network-based intrusion detection system (NIDS) has the ability to
perform real-time traffic analysis and packet logging on Internet Protocol (IP) networks.
Snort performs protocol analysis, content searching and matching. These basic services
have many purposes including application-aware triggered quality of service, to de-
prioritize bulk traffic when latency-sensitive applications are in use.
The program can also be used to detect probes or attacks, including, but not limited to,
operating system fingerprinting attempts, common gateway interface, buffer overflows,
server message block probes, and stealth port scans.
Snort can be configured in three main modes: sniffer, packet logger, and network intrusion
detection. In sniffer mode, the program will read network packets and display them on the
console. In packet logger mode, the program will log packets to the disk. In intrusion
detection mode, the program will monitor network traffic and analyze it against a rule set
defined by the user. The program will then perform a specific action based on what has
been identified.

56
7.1 Installation and setup

[Image 40]
[Installing snort]

[Image 41]

57
[Image 42]

[Image 43]

58
[Image 44]

[Image 45]

59
 [Image 46]
[snort’s configuration file]

60
 [Image 47]
[Using LOIC to perform DOS Attack]

61
7.2 Result

[Image 48]

[Image 49]
[Opening captured log file in wireshark]

62
[Image 50]
[Alert file]

63
 [Image 51]
[Custom Rule file to detect DoS Attack]

64
8. Incident Response Tool: OCS Inventory
Open Computer and Software Inventory Next Generation (OCS inventory NG) is free
software that enables users to inventory IT assets. OCS-NG collects information about the
hardware and software of networked machines running the OCS client program. OCS can
visualize the inventory through a web interface. Furthermore, OCS includes the capability
of deploying applications on computers according to search criteria. Agent-side IPDiscover
makes it possible to discover the entirety of networked computers and devices.
The open-source OCS Inventory NG project started in late 2005 and produced its first
release version of OCS Inventory in early 2007.Since version 1.0rc3, most of OCS
Inventory functionality can be adapted or extended via a module system.
The dialogue between OCS client machines and the server depends on the Hypertext
Transfer Protocol (HTTP). The software formats data in XML. The management server
uses Apache, MySQL and Perl. OCS runs on multiple platforms: under Unixes and under
Microsoft Windows (95 or later). A web-interface written in PHP offers consultation of the
inventory, user-rights management, and technical support features.

65
8.1 Installation and Setup

[Image 52]
[Installing OCS Inventory]

[Image 53]

66
 [Image 54]

[Image 55]
[Installing OCS Inventory Agent]

67
 [Image 56]

[Image 57]
[Once Installation is done, It can be opened in browser and it will ask to create a
database]

68
[Image 58]

[Image 59]

69
8.2 Software Walk Through

[Image 60]
[Asking to login]

[Image 61]
[Home Page]

[Image 62]
[List of Host Machine can be found here]
[I haven’t configured any machine using agent that is why all the screenshot says ‘no
result’]

70
 [Image 63]
[Group of Assets can be found here]

[Image 64]
[Filtering can be done based on TAGs]

[Image 65]
[Filtering based on software]

[Image 66]

71
 [Image 67]
[All the deployment options can be found here]

[Image 68]
[Configuration settings can be found here]

[Image 69]
[Network related settings can be found here, such as IPDiscovery]

[Image 70]
[Registry Data can be analyzed here]

72
 [Image 71]
[Administrative Data such as TAGs can be found here]

[Image 72]
[Information about duplicate assets can be found here]

[Image73]
[All plugins can be managed from here]

[Image 74]
[Log Files can be viewer here, If there are any]

73
 [Image 75]
[Statistics of all the assets in the networks are available here]

[Image 76]
[Adding, Removing, Managing user such task can be done here]

[Image 77]
[Local files can be imported into OSC Inventory from here]

74
9. Reference Links
1. https://www.alienvault.com/resource-center/ebook/insider-guide-to-incident-

response

2. https://github.com/meirwah/awesome-incident-response

3. https://www.us-cert.gov/government-users/reporting-requirements

4. https://www.first.org/_assets/resources/guides/csirt_case_classification.html

5. http://www.cert.org/

6. http://whatis.techtarget.com

7. https://en.wikipedia.org

8. https://www.alienvault.com/products/ossim

9. https://www.snort.org/

10. https://www.ocsinventory-ng.org/

75