Technical University of Mombasa

Session 6: Incident Response

Lesson Objectives
- Define cybersecurity incident
- Incident categories,
- Incident response
- Incident recovery

6.1 Introduction: Defining a cyber security incident

Definition 1
A cybersecurity incident (or incident) is a single or a series of unwanted or unexpected
information security events that have a significant probability of compromising
business operations and preservation of confidentiality, integrity and availability of
information.

An Event is any observable occurrence in a system or network, or is is change in a

particular set of circumstances.
An event :
- can be one or more occurrences, and can have several causes.
- can consist of something that does not happen.
- can sometimes be referred to as an “incident” or an “accident”.

Adverse events are events with a negative consequence, such as system crashes, packet
floods, unauthorized use of system privileges, unauthorized access to sensitive data,
and execution of malware that destroys data.

A cybersecurity event is an identified occurrence of a system, service or network state

indicating a possible breach of information security policy or failure of safeguards, or a
previously unknown situation that may be relevant to security.

Definition 2
Cyber security incident is a breach of a system’s security policy in order to affect its
integrity or availability or the unauthorised access or attempted access to a system.

Activities commonly recognised as cyber incidents are:

• attempts to gain unauthorised access to a system and/or to data
• the unauthorised use of systems and/or data
• modification of a system's firmware, software or hardware without the system-
owner's consent
• malicious disruption and/or denial of service

1
6.2 Incident Categories
The categories and attacks are based on NIST (National Institute of Standards and
Technology - of USA)

Category Name Description

Compromised Successful destruction, corruption, or disclosure of sensitive
information corporate information or Intellectual Property
Compromised Compromised host (root account, Trojan, rootkit), network device,
Asset application, user account. This includes malware infected hosts
where an attacker is actively controlling the host.
Unauthorised In this category an individual (internal or external) gains logical or
Access physical access without permission to a national or local network,
system, application, data, or other resource.
Malicious Code Successful installation of malicious software (e.g. virus, worm,
Trojan horse, or other code-based malicious entity) that infects an
operating system or application. Organisations are NOT required
to report malicious logic that has been successfully quarantined by
antivirus (AV) software.
(Distributed) An attack that successfully prevents or impairs the normal
Denial of Service authorized functionality of networks, systems or applications by
exhausting resources.
This activity includes being the victim or participating in the DoS.
Theft or Loss Theft or loss of sensitive equipment (Laptop, hard disk, media etc.)
of organisation.
Phishing Use of fraudulent computer network technology to entice
organisation’s users to divulge important information, such as
obtaining users’ bank account details and credentials by deceptive
emails or fraudulent web site
Scans/Probes/ This category includes any activity that seeks to access or identify
Attempted Access an organisation computer, open ports, protocols, service, or any
combination for later exploit. This
activity does not directly result in a compromise or denial of
service.
Policy Violations Deliberate violation of cybersecurity policy such as:
- Inappropriate use of corporate asset such as computer, network,
or application.
- Unauthorised escalation of privileges or deliberate attempt to
subvert access controls.

Note:
Attack Vectors are the means used by the attackers to exploit vulnerabilities. Examples
are:
- External/Removable Media

2
 - Attrition: An attack that employs brute force methods to compromise, degrade,
or destroy systems, networks, or services
- Web
- Email
- Social Engineering
- Improper Usage

6.2 Incident Response

The purpose of a cybersecurity incident response plan is to help your organization
respond to security incidents quickly and efficiently. In the event of a security incident,
having a comprehensive incidence response plan in place will help to minimize damage
to your organization, as well as mitigate the risks and impacts of a security breach.
Using the checklist in this blog will help you to better prepare for a security incident
and ensure your incident response plan is complete and up-to-date.

An effective cybersecurity incident response (IR) plan should codify all the steps
required to detect and react to cybersecurity incidents, determine the scope and risks,
and provide the steps for a rapid and thorough response. An executable, step-by-step
plan will make your response faster and more orderly (versus haphazard or frenzied,
which is often the case), and will allow your teams to avoid mistakes that could cause
damage to your organization, customers, and brand. Your IR plan should also
determine how you will communicate to your stakeholders across all business units and
geographies about the risks of an incident, as well as communicating the results of your
security response.

The Six Stages of Incident Response

Incident response is one of those things that should be practised regularly like fire
safety training or disaster recovery testing so that when something bad happens, your
actions are almost second nature ensuring a favourable outcome.

The six stages of incident response (as developed by Mr. Deuble of Cisco) are:
i) Preparation,
ii) Identification,
iii) Containment,
iv) Eradication,
v) Recovery and
vi) Lessons learned.

i) Preparation
The preparation phase is about ensuring you have the appropriate (response plans,
policies, call trees and other documents in place and that you have identified the
members of your incident response team including external entities.

ii) Identification

3
In the identification phase you need to work out whether you are dealing with an event
or an incident. This is where understanding your environment is critical as it means
looking for significant deviations from "normal" traffic baselines or other methods.

iii) Containment
This should occur only if the indications observed during the Identification stage
conclusively shows that an incident has or is occurring. The primary goal is to minimize
the breadth of the incident and isolate it from causing wide-spread damage.
At the containment stage you will want to work with the business to limit the damage
caused to systems and prevent any further damage from occurring. This includes short-
and long-term containment activities.

iv) Eradication
The stage in the process when infected files are fully deleted or the system(s) is restored
to its normal operational state. This may involve replacement of hardware.
During the fourth stage the emphasis is on ensuring you have a clean system ready to
restore. This may be a complete reimage of a system, or a restore from a known good
backup.

v) Recovery
At this point, it’s time to determine when to bring the system back in to production and
how long we monitor the system for any signs of abnormal activity.

vi) Lessons Learned

This final stage is often skipped as the business moves back into normal operations but
it’s critical to look back and heed the lessons learned. These lessons will allow you to
incorporate additional activities and knowledge back into your incident response
process to produce better future outcomes and additional defenses.
Follow-up is required to perform a post-incident analysis to document exactly what
happened and when.

Post incident activities are important to ensure the organization understands how the
incident occurred and ensure the organization takes steps to prevent the same type of
incidents from occurring again.

6.3 Incidence Recovery

Can also be referred to as Contingency Planning and Disaster Recovery.
This is where the organization develops a contingency plan to deal with and recover
from the inevitable security break-downs. The contingency plan should include the
following –
i) The interim methods of working that will allow the organization to survive the
disaster; this stage is concerned with coping with the disaster itself by ensuring
safety, minimizing damage and enabling a return to work.
ii) The long-term processes that will allow the organization to recover from the

4
 disaster; this stage is concerned with minimizing the consequences of the
disaster.
Typically, the first step in contingency planning is to classify systems and
applications in order of their necessity to business operation. This enables the
organization to know when each must be functioning again for the business to
survive. Through this knowledge, efforts are channeled in the most productive
way.

If the business is not kept running in the short-term, then long term recovery will not be
relevant and therefore immediate standby arrangements are critical to the
organization’s chances of disaster recovery and to the overall costs involved. Standby
arrangements include:
• Hot site facilities: In this case, everything to enable IS operation is
already installed. These sites allow almost instantaneous business
operation, provided that back-ups are available.
• Cold site facilities: Where an equipped but empty data center is
available. These sites are general purpose and therefore cheaper than hot
sites. They, however, make it slower to get business operations running
since there is the need to install business appropriate features in them
after the disaster.
• Portable facilities: Provision is made from portable vehicles, or semi-
portable prefabricated buildings. These are a popular option.

The suggested structure of the disaster-planning document includes the following key
elements:
(i). Introduction and Index: Including a brief description of the manual, how it is
structured, who holds the copies of the plan, how to use the plan, etc.
(ii). Definition of computer disaster: Provided should be a definition of what, to the
organization, a disaster is (say a loss of service or loss of revenue). Also included should
be the organization’s policy on disaster planning. Because there will be different
recovery strategies for different types of disaster, the document should define levels of
disasters (say a small fire causing little damage or interruption to a major fire that
destroys an entire data area).
(iii). Assumptions: The assumptions upon which the plans are based should be
explained and the assumptions should be reviewed/tested regularly. The plan may, for
example, assume that all key personnel will be available, which may not be the case.
(iv). Disaster exclusions: Even those disasters that the plan does not cover for will need
to be identified in the document (say a nuclear attack, etc).
(v). Inventories: All the software and hardware, including data and voice
communications equipment, will need to be itemized. Other things to itemize include
staff organization charts, floor plans, wiring diagrams, and entrance and exit routes.
Availability of standby systems, contractual agreements and commitments, and supply
of replacement equipment should be highlighted.
(vi). Emergency budgets: This section should detail how urgent cash flows will be

5
generated during the disaster. Claims from insurance companies should be identified.
(vii). Invocation: This section details how the alarm is raised and the disaster recovery
plan invoked. Disaster management teams must be defined; included here should also
be the organizational structure of all recovery teams, presented to an appropriate level
of detail and outlining all respective team actions.
(viii). Logistics: Logistical planning will include sections on transport, staffing, supplies
such as media, communications, access and security arrangements, services, etc.
Without adequate logistical planning, there is a high degree of risk that the disaster
recovery plan will fail.
(ix). Maintenance and testing: This section defines how the recovery plan will be tested
and maintained.
(x). Appendices: This is the area in which to file the following:
• Insurance policies
• Any third-party standby service agreements
• Vendor agreements
• Important or useful correspondence
• Results from risk analysis
• Business impact reviews, etc

CASE STUDY
University Hospital has been receiving calls to the Help Desk electronic health records
files cannot be accessed by physicians within several departments.
- Detection is being made by the Help Desk – How does the Hospital determine
they have an incident?
- By definition this is a indicator due to the volume of call?
- By definition this is an event that is causing impact to availability
- By definition after looking a production schedules there is no indication that
these systems or servers holding these data have outages that would cause this
issue - INCIDENT detected!

Is it this simple? No not all the time but it can be just as Streamlined
Users and Help Desk personnel are just the “Barometers” of what is taking place within
your enterprise/