Incident Handling Process

Module-0 Shiva Kuma

 Module Summary

Incident handling is a clearly defined set of procedures to manage

and respond to security incidents in a computer or network
environment. This module introduces the overall process of
handling security incidents and walks through each stage of the
incident handling process. Important key points and implementation
details will also be provided regarding all stages of the incident
handling process. This module is also aligned with NIST's Computer
"Security Incident Handling Guide", since it is one of the most
widely used and referenced resources on the matter.
Incident Handling Process Shiva Kuma
 Incident Handling Definition & Scope

Incident handling (IH) has become an important part of an

organization's defensive capability against cybercrime. While
protective measures are constantly being implemented to prevent
or lower the amount of security incidents, an incident handling
capability is undeniably a necessity for any organization that cannot
afford a compromise of its data confidentiality, integrity, or
availability.

Incident Handling Process Shiva Kuma

 EVENT & INCIDENT

An event is an action occurring in a system or network. Examples of

events are:

1. A user sending an email

2. A mouse click

3. A firewall allowing a connection request

Incident Handling Process Shiva Kuma

 incident
An incident is an event with a negative consequence. One example of an incident
is a system crash. Another example is unauthorized access to sensitive data.
Incidents can also occur due to natural disasters, power failures, etc.

Examples of incidents are:

1. Data theft

2. Funds theft

3. Unauthorized access to data

4. Installation and usage of malware and remote access tools

Incident Handling Process Shiva Kuma

 Incident handling

Incident handling is a clearly defined set of procedures to manage

and respond to security incidents in a computer or network
environment.

IT security incidents frequently involve the compromise of personal

and business data, and it is therefore crucial to respond quickly and
effectively. In some incidents, the impact may be limited to a few
devices, while in others a large part of the environment can be
compromised.

Incident Handling Process Shiva Kuma

 What Is The Cyber Kill Chain?

we need to understand the attack lifecycle (a.k.a. the cyber kill

chain). This lifecycle describes how attacks manifest themselves.
Understanding this lifecycle will provide us with valuable insights on
how far in the network an attacker is and what they may have
access to during the investigation phase of an incident.

The cyber kill chain consists of seven (7) different stages, as

depicted in the image below:

Incident Handling Process Shiva Kuma

 RECON & weaponize
The recon stage is the initial stage, and it involves the part where an attacker
chooses their target. Additionally, the attacker then performs information gathering
to become more familiar with the target and gathers as much useful data as possible,
which can be used in not only this stage but also in other stages of this chain.

In the weaponize stage, the malware to be used for initial access is developed and
embedded into some type of exploit or deliverable payload. This malware is crafted to
be extremely lightweight and undetectable by the antivirus and detection tools. It is
likely that the attacker has gathered information to identify the present antivirus or
EDR technology in the target organization.

Incident Handling Process Shiva Kuma

 EXPLOIT
In the delivery stage, the exploit or payload is delivered to the victim(s). Traditional
approaches are phishing emails that either contain a malicious attachment or a link to a
web page. The web page can be twofold: either containing an exploit or hosting the
malicious payload to avoid sending it through email scanning tools. In all fairness, the
web page can also mimic a legit website used by the target organization in an attempt to
trick the victim into entering their credentials and collect them. Some attackers call the
victim on the phone with a social engineering pretext in an attempt to convince the
victim to run the payload. The payload in these trust-gaining cases is hosted on an
attacker-controlled web site that mimics a well-known web site to the victim (e.g., a copy
of the target organization's website)

Incident Handling Process Shiva Kuma

 EXPLOITATION

The exploitation stage is the moment when an exploit or a delivered

payload is triggered. During the exploitation stage of the cyber kill
chain, the attacker typically attempts to execute code on the target
system in order to gain access or control.

Incident Handling Process Shiva Kuma

 INSTALLATION STAGE
In the installation stage, the initial stager is executed and is running on the compromised machine. As
already discussed, the installation stage can be carried out in various ways, depending on the attacker's
goals and the nature of the compromise. Some common techniques used in the installation stage include:

Droppers: Attackers may use droppers to deliver malware onto the target system. A dropper is a small
piece of code that is designed to install malware on the system and execute it.

Backdoors: A backdoor is a type of malware that is designed to provide the attacker with ongoing access
to the compromised system.

Rootkits: A rootkit is a type of malware that is designed to hide its presence on a compromised system.
Rootkits are often used in the installation stage to evade detection by antivirus software and other
security tools.

Incident Handling Process Shiva Kuma

 COMMAND AND CONTROL

In the command and control stage, the attacker establishes a

remote access capability to the compromised machine. As
discussed, it is not uncommon to use a modular initial stager that
loads additional scripts 'on-the-fly'. However, advanced groups will
utilize separate tools in order to ensure that multiple variants of
their malware live in a compromised network, and if one of them
gets discovered and contained, they still have the means to return
to the environment.

Incident Handling Process Shiva Kuma

 ACTION

The final stage of the chain is the action or objective of the attack.
The objective of each attack can vary. Some adversaries may go
after exfiltrating confidential data, while others may want to obtain
the highest level of access possible within a network to deploy
ransomware.

Incident Handling Process Shiva Kuma

 Incident Handling Process Overview

The incident handling process defines a capability for organizations

to prepare, detect, and respond to malicious events. Note that this
process is suited for responding to IT security events, but its stages
do not correspond to the stages of the cyber kill chain in a one-to-
one manner.

Incident Handling Process Shiva Kuma

 Incident Handling Process Overview (ctnd..)

Incident handlers spend most of their time in the first two stages,
preparation and detection & analysis. This is where we spend a lot
of time improving ourselves and looking for the next malicious
event. When a malicious event is detected, we then move on to the
next stage and respond to the event (but there should always be
resources operating on the first two stages, so that there is no
disruption of preparation and detection capabilities).

Incident Handling Process Shiva Kuma

 Preparation Stage

In the preparation stage, we have two separate objectives. The first one is
the establishment of incident handling capability within the organization. The
second is the ability to protect against and prevent IT security incidents by
implementing appropriate protective measures. Such measures include
endpoint and server hardening, active directory tiering, multi-factor
authentication, privileged access management, and so on and so forth. While
protecting against incidents is not the responsibility of the incident handling
team, this activity is fundamental to the overall success of that team.

Incident Handling Process Shiva Kuma

 Preparation Prerequisites

During the preparation, we need to ensure that we have:

1. Skilled incident handling team members (incident handling team members

can be outsourced, but a basic capability and understanding of incident
handling are necessary in-house regardless)

2. Trained workforce (as much as possible, through security awareness activities

or other means of training)

3. Clear policies and documentation

4. Tools (software and hardware)

Incident Handling Process Shiva Kuma

 Clear Policies & Documentation
Some of the written policies and documentation should contain an up-to-date version of the following information:

1. Contact information and roles of the incident handling team members

2. Contact information for the legal and compliance department, management team, IT support, communications and media relations department, law
enforcement, internet service providers, facility management, and external incident response team

3. Incident response policy, plan, and procedures

4. Incident information sharing policy and procedures

5. Baselines of systems and networks, out of a golden image and a clean state environment

6. Network diagrams

7. Organization-wide asset management database

8. User accounts with excessive privileges that can be used on-demand by the team when necessary (also to business-critical systems, which are handled with
the skills needed to administer that specific system). These user accounts are normally enabled when an incident is confirmed during the initial investigation
and then disabled once it is over. A mandatory password reset is also performed when disabling the users.

9. Ability to acquire hardware, software, or an external resource without a complete procurement process (urgent purchase of up to a certain amount). The last
thing you need during an incident is to wait for weeks for the approval of a $500 tool.

10. Forensic/Investigative cheat sheets

Incident Handling Process Shiva Kuma

 Tools (Software & Hardware)
1. Additional laptop or a forensic workstation for each incident handling team member to preserve disk images and log files, perform data analysis, and investigate
without any restrictions (we know malware will be tested here, so tools such as antivirus should be disabled). These devices should be handled appropriately
and not in a way that introduces risks to the organization.

2. Digital forensic image acquisition and analysis tools

3. Memory capture and analysis tools

4. Live response capture and analysis

5. Log analysis tools

6. Network capture and analysis tools

7. Network cables and switches

8. Write blockers

9. Hard drives for forensic imaging

10. Power cables

11. Screwdrivers, tweezers, and other relevant tools to repair or disassemble hardware devices if needed

12. Indicator of Compromise (IOC) creator and the ability to search for IOCs across the organization

13. Chain of custody forms

14. Encryption software

15. Ticket tracking system

16. Secure facility for storage and investigation

Shiva Kuma
 Detection & Analysis Stage (Part 1)

The detection & analysis phase involves all aspects of detecting an incident, such as utilizing sensors, logs,
and trained personnel. It also includes information and knowledge sharing, as well as utilizing context-based
threat intelligence. Segmentation of the architecture and having a clear understanding of and visibility within
the network are also important factors.

Threats are introduced to the organization via an infinite amount of attack vectors, and their detection can
come from sources such as:

1. An employee that notices abnormal behavior

2. An alert from one of our tools (EDR(Endpoint Detection and Response), IDS, Firewall, SIEM(Security
Information and Event Management), etc.)

3. Threat hunting activities

4. A third-party notification informing us that they discovered signs of our organization being compromised

Incident Handling Process Shiva Kuma

 Initial Investigation
When a security incident is detected, you should conduct some initial investigation and establish context before
assembling the team and calling an organization-wide incident response. Think about how information is
presented in the event of an administrative account connecting to an IP address at HH:MM:SS.
1. Date/Time when the incident was reported. Additionally, who detected the incident and/or who reported it?
2. How was the incident detected?
3. What was the incident? Phishing? System unavailability? etc.
4. Assemble a list of impacted systems (if relevant)
5. Document who has accessed the impacted systems and what actions have been taken. Make a note of
whether this is an ongoing incident or the suspicious activity has been stopped
6. Physical location, operating systems, IP addresses and hostnames, system owner, system's purpose, current
state of the system
7. (If malware is involved) List of IP addresses, time and date of detection, type of malware, systems impacted,
export of malicious files with forensic information on them (such as hashes, copies of the files, etc.)

Incident Handling Process Shiva Kuma

 Incident Severity & Extent Questions

When handling a security incident, we should also try to answer the

following questions to get an idea of the incident's severity and
extent:
•What is the exploitation impact?
•What are the exploitation requirements?
•Can any business-critical systems be affected by the incident?
•Are there any suggested remediation steps?
•How many systems have been impacted?
•Is the exploit being used in the wild?
•Does the exploit have any worm-like capabilities?

Incident Handling Process Shiva Kuma

 Incident Confidentiality & Communication

Incidents are very confidential topics and as such, all of the

information gathered should be kept on a need-to-know basis,
unless applicable laws or a management decision instruct us
otherwise. There are multiple reasons for this. The adversary may
be, for example, an employee of the company, or if a breach has
occurred, the communication to internal and external parties should
be handled by the appointed person in accordance with the legal
department.

Incident Handling Process Shiva Kuma

 Detection & Analysis Stage (Part 2)

When an investigation is started, we aim to understand what and

how it happened. To analyze the incident-related data properly and
efficiently, the incident handling team members need deep
technical knowledge and experience in the field. One may ask,
"Why do we care about how an incident happened? Why don't we
simply rebuild the impacted systems and basically forget it ever
happened?".

Incident Handling Process Shiva Kuma

 The Investigation

The investigation starts based on the initially gathered (and limited) information
that contain what we know about the incident so far. With this initial data, we will
begin a 3-step cyclic process that will iterate over and over again as the
investigation evolves. This process includes:

1. Creation and usage of indicators of compromise (IOC)

2. Identification of new leads and impacted systems

3. Data collection and analysis from the new leads and

impacted systems

Incident Handling Process Shiva Kuma

 Containment, Eradication, & Recovery Stage

When the investigation is complete and we have understood the type of incident and the impact
on the business (based on all the leads gathered and the information assembled in the timeline),
it is time to enter the containment stage to prevent the incident from causing more damage.

In this stage, we take action to prevent the spread of the incident. We divide the actions into
short-term containment and long-term containment. It is important that containment actions are
coordinated and executed across all systems simultaneously. Otherwise, we risk notifying
attackers that we are after them, in which case they might change their techniques and tools in
order to persist in the environment.

Incident Handling Process Shiva Kuma

 Containment

In short-term containment, the actions taken leave a minimal footprint on the systems on which they occur.
Some of these actions can include, placing a system in a separate/isolated VLAN, pulling the network cable
out of the system(s) or modifying the attacker's C2(C&C) DNS name to a system under our control or to a
non-existing one. The actions here contain the damage and provide time to develop a more concrete
remediation strategy. Additionally, since we keep the systems unaltered (as much as possible), we have the
opportunity to take forensic images and preserve evidence if this wasn't already done during the
investigation (this is also known as the backup substage of the containment stage). If a short-term
containment action requires shutting down a system, we have to ensure that this is communicated to the
business and appropriate permissions are granted.

In long-term containment actions, we focus on persistent actions and changes. These can include changing
user passwords, applying firewall rules, inserting a host intrusion detection system, applying a system patch,
and shutting down systems. While doing these activities, we should keep the business and the relevant
stakeholders updated. Bear in mind that just because a system is now patched does not mean that the
incident is over. Eradication, recovery, and post-incident activities are still pending.
Incident Handling Process Shiva Kuma
 Eradication

Once the incident is contained, eradication is necessary to eliminate both the

root cause of the incident and what is left of it to ensure that the adversary is out
of the systems and network. Some of the activities in this stage include removing
the detected malware from systems, rebuilding some systems, and restoring
others from backup. During the eradication stage, we may extend the previously
performed containment activities by applying additional patches, which were not
immediately required. Additional system-hardening activities are often
performed during the eradication stage (not only on the impacted system but
across the network in some cases).

Incident Handling Process Shiva Kuma

 Recovery
In the recovery stage, we bring systems back to normal operation. Of course, the
business needs to verify that a system is in fact working as expected and that it contains
all the necessary data. When everything is verified, these systems are brought into the
production environment. All restored systems will be subject to heavy logging and
monitoring after an incident, as compromised systems tend to be targets again if the
adversary regains access to the environment in a short period of time. Typical suspicious
events to monitor for are:
• Unusual logons (e.g. user or service accounts that have never logged in there before)
• Unusual processes
• Changes to the registry in locations that are usually modified by malware

The recovery stage in some large incidents may take months, since it is often approached
in phases. During the early phases, the focus is on increasing overall security to prevent
future incidents through quick wins and the elimination of low-hanging fruits. The later
phases focus on permanent, long-term changes to keep the organization as secure as
possible.
Incident Handling Process Shiva Kuma
 Post-Incident Activity Stage

In this stage, our objective is to document the incident and improve

our capabilities based on lessons learned from it. This stage gives
us an opportunity to reflect on the threat by understanding what
occurred, what we did, and how our actions and activities worked
out. This information is best gathered and analyzed in a meeting
with all stakeholders that were involved during the incident. It
generally takes place within a few days after the incident, when the
incident report has been finalized.

Incident Handling Process Shiva Kuma

 Reporting
The final report is a crucial part of the entire process. A complete report will contain
answers to questions such as:
• What happened and when?
• Performance of the team dealing with the incident in regard to plans, playbooks,
policies, and procedures
• Did the business provide the necessary information and respond promptly to aid in
handling the incident in an efficient manner? What can be improved?
• What actions have been implemented to contain and eradicate the incident?
• What preventive measures should be put in place to prevent similar incidents in the
future?
• What tools and resources are needed to detect and analyze similar incidents in the
future?
Such reports can eventually provide us with measurable results. For example, they
can provide us with knowledge around how many incidents have been handled, how
much time the team spends per incident, and the different actions that were
performed during the handling process.
Incident Handling Process Shiva Kuma
 THANK YOU

Module-1 Shiva Kuma