Cybersecurity

Lecture 8
Incident Handling

Esmiralda Moradian
24-04-2023
Learning outcomes

● Understand security incident and objectives of

incident handling
● Understand incident management policy
● Understand incident handling process
Definitions
● Information security event
– NIST defines an event as “any observable occurrence in a system
or network”
● Adverse events are events with a negative consequence
● Information security incidents
– Are events that can harm an organization’s assets or compromise
its operations.
– Is described as any violation of policy, law, or unacceptable act
that involves information assets
● Incident handling
– actions of detecting, reporting, assessing, responding to, dealing
with, and learning from information security incidents
Security incidents
● Deliberate
– Caused by malware or by intentional breach
● Accidental
– Caused by unintentional human error or unavoidable acts of
nature and
– Caused by technical or non-technical means
● Consequences of security incidents can include
– unauthorized disclosure, modification, destruction,
– unavailability of information, or
– the damage or theft of organizational assets that contain
valuable/sensitive information
Security incidents
● Deliberate DoS/DDoS incidents
– sending data in an unexpected format to a system, service or network in an
attempt to crash it, or disrupt its normal operation
– opening up multiple authorized sessions with a particular system, service or
network in an attempt to exhaust its resources
● Accidental technical DoS incidents caused by operator
– misconfiguration
– breaches of physical security arrangements resulting in theft or willful damage
and destruction of equipment
– accidental damage to HW by fire or water damage/flood
– extreme environmental conditions, and
– system malfunctions or overload
Security incidents (cont.)

● Unauthorized Access
– attempts to retrieve password files
– exploitation of protocol vulnerabilities
– attempts to elevate privileges to resources or information
– direct or indirect disclosure or modification of information,
– breaches of accountability or misuse of information systems
– breaches of physical security arrangements
– misconfigured OS, or
– malfunctions of SW or HW
Security incidents (cont.)

● Malware
● Abuse
Need for Incident Response

● Support in responding to incidents systematically

to minimize loss or theft of information and
disruption of services
● The ability to use information gained during
incident handling to better prepare for handling
future incidents
● Help with dealing properly with legal issues that
may arise during incidents
Objectives of incident handling

● Information security events are detected and dealt in an

efficient way
● Identified information security incidents are assessed and
responded to in the most appropriate and efficient manner
● The adverse effects of security incidents on the organization
and its operations are minimized
● Information security vulnerabilities are assessed and dealt
appropriately
● Lessons are learnt quickly from security incidents,
vulnerabilities and their management
Incident management policy
● Should outline the processes, responsible persons, authority and reporting
lines when a security incident occurs
● Should outline any awareness and training initiatives within the
organization that is related to incident response
● Should be reviewed regularly to ensure it reflects the latest organizational
structure, processes, and technology that can affect incident response
● Before the policy is formulated, the organization should identify the
– objectives
– interested parties internally and externally
– specific incident types and vulnerabilities that need to be highlighted
– any specific role that need to be highlighted
– benefits to the whole organization and to its departments
Related documents

● Security incident management plan

● A continuous monitoring policy
● Information sharing, disclosure and communication
policies
● Information storage and handling policies
● An Incident Response Team (IRT) charter
● Information security incident management awareness
and training program
Incident Response Lifecycle
Security incident management plan

● Should encompass multiple documents

– The forms
– Procedures
– Organizational elements and support tools
– Assessment and decision making related to
incidents
– Responses to and learning lessons from incidents
– Basic flow of incident management activities
Plan and Prepare
● Categorization and classification by using a standardized
approach to information security event/incident
● An information security database structured for the
exchange of information is likely to provide the capability to
share reports/alerts, compare results, improve alert information
and enable a more accurate view of the threats to, and
vulnerabilities of information systems
● Guidance for deciding whether escalation is required during
each relevant process, and to whom, and associated procedures
Incident Handler Communications and
Facilities
● Contact information for team members and others within and outside the
organization
● On-call information for other teams within the organization, including
escalation information
● Incident reporting mechanisms
● Issue tracking system
● Smartphones
● Encryption software
● War room
● Secure storage facility
Checklist: Preparation

● Are all members aware of the security policies of the

organization?
● Do all members of the Computer Incident Response Team know
whom to contact?
● Do all incident responders have access to journals and access to
incident response toolkits to perform the actual incident
response process?
● Have all members participated in incident response exercise to
practice the incident response process and to improve overall
proficiency on a regularly established basis?
Detection and determination

● Detection and determination of whether a deviation from normal

operations within an organization is an incident and its scope
● Define minimum information for identification and classification
of a security incident
● If the incident planning process is to depend on automated
information management and decision support systems, the
functions, implementation, and on-going operation of these
systems should be defined
Detection and Reporting of an incident

● Detection step requires one to gather events from various

sources
– Log files, Error messages, and Other resources
● Detecting and reporting
– the occurrence of information security events
– information security vulnerabilities
● Recording all assessment results and related decisions in the
information security DB
Checklist: Detection
● Where did the incident occur?
● Who reported or discovered the incident?
● How was it discovered?
● Are there any other areas that have been compromised
by the incident? If so, what are they and when were they
discovered?
● What is the scope of the impact?
● What is the business impact?
● Have the source(s) of the incident been located? If so,
where, when, and what are they?
Containment
Eradication
Recovery
Containment
● The primary purpose of this phase is to limit the damage and prevent
any further damage from happening.
● There are few steps to this phase
– Short-term Containment,
– System Back-Up,
– Long-term Containment
● Example of containment
– isolate a network segment of infected workstations
– disconnecting affected systems will isolate the problem from the rest
of the production network and limit the spread of any malware or
reduce the risk of further systems being compromised.
Checklist: Containment
● Short-term containment
– Can the problem be isolated?
– Are all affected systems isolated from non-affected systems?
● System-backup
– Have forensic copies of affected systems been created for further analysis?
– Have all commands and other documentation since the incident has occurred been
kept up to date so far?
– Are the forensic copies stored in a secure location?
• If so, then continue onto the next step
• If not, then place the forensic images into a secure location to prevent
accidental damage and/or tampering
● Long-term containment
– If the system can be taken offline, then proceed to the Eradication phase
– If the system must remain in production proceed with long-term containment
Eradication
● Deals with the actual removal and restoration of affected systems
● Continued documentation of all actions taken is necessary to
determine the cost of man hours and other resources
● Ensure that proper steps were taken to remove malicious and
other illicit content off of the affected systems, and ensuring that
they are clean
● A complete reimaging of a system’s hard drive(s)
● Point where defenses should be improved after learning what
caused the incident
● Ensure that the system cannot be compromised again
Checklist: Eradication

● If possible can the system be reimaged and then hardened with

patches and/or other countermeasures to prevent or reduce the
risk of attacks?
– If not, then please state why?
● Have all malware and other artifacts left behind by the
attackers been removed and the affected systems hardened
against further attacks?
– If not, then please explain why?
Checklist: Response
● Has the affected system(s) been patched and hardened against the recent
attack, as well as possible future ones?
● What day and time would be feasible to restore the affected systems back into
production?
● What tools are you going to use to test, monitor, and verify that the systems
being restored to productions are not compromised by the same methods that
cause the original incident?
● How long are you planning to monitor the restored systems and what are
you going to look for?
● Are there any prior benchmarks that can be used as a baseline to compare
monitoring results of the restored systems against those of the baseline?
Incident Handling Activities
● Make an initial assessment
– Identify the cause using log information
● Implement measures to minimize continuing damage
– rerouting network traffic, filtering or blocking a DDoS, or isolating all or parts
of the compromised network
● Record and collect information
– Image the affected computer(s); Keep logs, notes, records, and data; and Records
related to continuing attacks
● Classes of response should be organized by cost, time, technical resource minimums
● Review by the IRT to determine if the information security incident is under control
● Defining a map of all internal and external functions and organizations that should
be involved during the management of an incident
● Containing and eradicating the security incident
Flow of information

Source: ISO ISO/IEC FDIS 27035-1

Lessons learnt
● The goal is to learn from occurred incidents to improve the team’s
performance and provide reference materials in the event of a similar
incident
● The purpose is to complete any documentation that was not done
during the incident, as well as any additional documentation that may
be beneficial in future incidents
● Identify the lessons learnt from information security incidents and
vulnerabilities
● Review, identify and make improvements to security control
implementation, security incident management policy, risk assessment
and management review results
● Review the effectiveness of the processes, procedures, the reporting
formats and the organizational structure
● Updating the information security DB
● Communicating and sharing the results of review within a trusted
community
Checklist: Lessons Learnt
● Has all necessary documentation from the incident been written?
– If so, then generate the incident response report for the lessons
learned meeting
– If not, then have documentation written as soon as possible
before anything is forgotten and left out of the report
● Does the incident response report document and answer the
following questions: Who? What? Where? Why? And How?
● Can a lessons learned meeting be scheduled within two weeks after
the incident has been resolved?
– If not, then please explain why and when is the next
convenient time to hold it?
Lessons learnt outcomes and meeting
● New or changed requirements for information security controls.
● New or changed threat and vulnerability information and changes to the
organization's existing security risk assessment and management review results
● Changes to the information security incident management plan and its processes,
procedures, the reporting formats and/or the organizational structure, and the
information security DB
● An organization should analyse the data in the information security database on a
regular basis
● At the meeting
– Review the incident response process of the incident that had occurred
– Did the meeting discuss any mistake or areas where the response process could
have been handled better?
• If no such conversations occurred, then please explain why?
– Go through the incident response report with finalization in an executive
summary format
Test and exercise the incident management
plan
● Schedule regular checking and testing of the information security incident
management processes and procedures
● Define the scope of an exercise
● An exercise can have three main goals
1. Validation
2. Training
3. Testing
● Exercises can be discussion-based, tabletop or executed in live environment
● Tasks to be accomplished for a successful exercise: brief participants on the
exercise goals; ensure safety and security of participants, make sure that all
participants know their roles, etc.
● Metrics and governance of incident response capability monitoring
References
● ISO/IEC 27035-1
● ISO/IEC 27035-2
● Andrea Dufkova. National/governmental CERTs
ENISA’s recommendations on baseline capabilities
Update, December 2014
● Patrick Kral. The Incident Handlers Handbook.
● ENISA. Good Practice Guide for Incident
Management
 Questions?

Ask questions in Supervision forum and/or

during the zoom session